07 Jul, 2011

1 commit

  • hfs_find_init() may fail with ENOMEM, but there are places, where
    the returned value is not checked. The consequences can be very
    unpleasant, e.g. kfree uninitialized pointer and
    inappropriate mutex unlocking.

    The patch adds checks for errors in hfs_find_init().

    Found by Linux Driver Verification project (linuxtesting.org).

    Signed-off-by: Alexey Khoroshilov
    Signed-off-by: Christoph Hellwig

    Alexey Khoroshilov
     

17 Dec, 2010

1 commit


23 Nov, 2010

1 commit

  • Avoid doing unessecary work in fsync. Do nothing unless the inode
    was marked dirty, and only write the various metadata inodes out if
    they contain any dirty state from this inode. This is archived by
    adding three new dirty bits to the hfsplus-specific inode which are
    set in the correct places.

    Signed-off-by: Christoph Hellwig

    Christoph Hellwig
     

14 Oct, 2010

3 commits

  • Make sure the initial insertation of the catalog entry already contains
    the device number by calling init_special_inode early and setting writing
    out the dev field of the on-disk permission structure. The latter is
    facilitated by sharing the almost identical hfsplus_set_perms helpers
    between initial catalog entry creating and ->write_inode.

    Unless we crashed just after mknod this bug was harmless as the inode
    is marked dirty at the end of hfsplus_mknod, and hfsplus_write_inode
    will update the catalog entry to contain the correct value.

    Signed-off-by: Christoph Hellwig

    Christoph Hellwig
     
  • The rootflags field in hfsplus_inode_info only caches the immutable and
    append-only flags in the VFS inode, so we can easily get rid of it.

    Signed-off-by: Christoph Hellwig

    Christoph Hellwig
     
  • HFS implements hardlink by using indirect catalog entries that refer to a hidden
    directly. The link target is cached in the dev field in the HFS+ specific
    inode, which is also used for the device number for device files, and inside
    for passing the nlink value of the indirect node from hfsplus_cat_write_inode
    to a helper function. Now if we happen to write out the indirect node while
    hfsplus_link is creating the catalog entry we'll get a link pointing to the
    linkid of the current nlink value. This can easily be reproduced by a large
    enough loop of local git-clone operations.

    Stop abusing the dev field in the HFS+ inode for short term storage by
    refactoring the way the permission structure in the catalog entry is
    set up, and rename the dev field to linkid to avoid any confusion.

    While we're at it also prevent creating hard links to special files, as
    the HFS+ dev and linkid share the same space in the on-disk structure.

    Signed-off-by: Christoph Hellwig

    Christoph Hellwig
     

01 Oct, 2010

2 commits

  • HFSPLUS_I doesn't return a pointer to the hfsplus-specific inode
    information like all other FOO_I macros, but dereference the pointer in a way
    that made it look like a direct struct derefence. This only works as long
    as the HFSPLUS_I macro is used directly and prevents us from keepig a local
    hfsplus_inode_info pointer. Fix the calling convention and introduce a local
    hip variable in all functions that use it constantly.

    Signed-off-by: Christoph Hellwig

    Christoph Hellwig
     
  • HFSPLUS_SB doesn't return a pointer to the hfsplus-specific superblock
    information like all other FOO_SB macros, but dereference the pointer in a way
    that made it look like a direct struct derefence. This only works as long
    as the HFSPLUS_SB macro is used directly and prevents us from keepig a local
    hfsplus_sb_info pointer. Fix the calling convention and introduce a local
    sbi variable in all functions that use it constantly.

    Signed-off-by: Christoph Hellwig

    Christoph Hellwig
     

17 Oct, 2008

1 commit

  • When an hfsplus image gets corrupted it might happen that the catalog
    namelength field gets b0rked. If we mount such an image the memcpy() in
    hfsplus_cat_build_key_uni() writes more than the 255 that fit in the name
    field. Depending on the size of the overwritten data, we either only get
    memory corruption or also trigger an oops like this:

    [ 221.628020] BUG: unable to handle kernel paging request at c82b0000
    [ 221.629066] IP: [] hfsplus_find_cat+0x10d/0x151
    [ 221.629066] *pde = 0ea29163 *pte = 082b0160
    [ 221.629066] Oops: 0002 [#1] PREEMPT DEBUG_PAGEALLOC
    [ 221.629066] Modules linked in:
    [ 221.629066]
    [ 221.629066] Pid: 4845, comm: mount Not tainted (2.6.27-rc4-00123-gd3ee1b4-dirty #28)
    [ 221.629066] EIP: 0060:[] EFLAGS: 00010206 CPU: 0
    [ 221.629066] EIP is at hfsplus_find_cat+0x10d/0x151
    [ 221.629066] EAX: 00000029 EBX: 00016210 ECX: 000042c2 EDX: 00000002
    [ 221.629066] ESI: c82d70ca EDI: c82b0000 EBP: c82d1bcc ESP: c82d199c
    [ 221.629066] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
    [ 221.629066] Process mount (pid: 4845, ti=c82d1000 task=c8224060 task.ti=c82d1000)
    [ 221.629066] Stack: c080b3c4 c82aa8f8 c82d19c2 00016210 c080b3be c82d1bd4 c82aa8f0 00000300
    [ 221.629066] 01000000 750008b1 74006e00 74006900 65006c00 c82d6400 c013bd35 c8224060
    [ 221.629066] 00000036 00000046 c82d19f0 00000082 c8224548 c8224060 00000036 c0d653cc
    [ 221.629066] Call Trace:
    [ 221.629066] [] ? trace_hardirqs_off+0xb/0xd
    [ 221.629066] [] ? trace_hardirqs_off_caller+0x14/0x9b
    [ 221.629066] [] ? trace_hardirqs_off+0xb/0xd
    [ 221.629066] [] ? trace_hardirqs_off_caller+0x14/0x9b
    [ 221.629066] [] ? trace_hardirqs_off+0xb/0xd
    [ 221.629066] [] ? native_sched_clock+0x82/0x96
    [ 221.629066] [] ? __kernel_text_address+0x1b/0x27
    [ 221.629066] [] ? dump_trace+0xca/0xd6
    [ 221.629066] [] ? save_stack_address+0x0/0x2c
    [ 221.629066] [] ? save_stack_trace+0x1c/0x3a
    [ 221.629066] [] ? save_trace+0x37/0x8d
    [ 221.629066] [] ? add_lock_to_list+0x67/0x8d
    [ 221.629066] [] ? validate_chain+0x8a4/0x9f4
    [ 221.629066] [] ? down+0xc/0x2f
    [ 221.629066] [] ? __lock_acquire+0x68a/0x6e0
    [ 221.629066] [] ? trace_hardirqs_off+0xb/0xd
    [ 221.629066] [] ? trace_hardirqs_off_caller+0x14/0x9b
    [ 221.629066] [] ? trace_hardirqs_off+0xb/0xd
    [ 221.629066] [] ? native_sched_clock+0x82/0x96
    [ 221.629066] [] ? mark_held_locks+0x43/0x5a
    [ 221.629066] [] ? trace_hardirqs_on+0xb/0xd
    [ 221.629066] [] ? trace_hardirqs_on_caller+0xf4/0x12f
    [ 221.629066] [] ? _spin_unlock_irqrestore+0x42/0x58
    [ 221.629066] [] ? down+0x2b/0x2f
    [ 221.629066] [] ? hfsplus_iget+0xa0/0x154
    [ 221.629066] [] ? hfsplus_fill_super+0x280/0x447
    [ 221.629066] [] ? native_sched_clock+0x82/0x96
    [ 221.629066] [] ? trace_hardirqs_off_caller+0x14/0x9b
    [ 221.629066] [] ? trace_hardirqs_off_caller+0x14/0x9b
    [ 221.629066] [] ? __lock_acquire+0x68a/0x6e0
    [ 221.629066] [] ? string+0x2b/0x74
    [ 221.629066] [] ? vsnprintf+0x2e9/0x512
    [ 221.629066] [] ? dump_trace+0xca/0xd6
    [ 221.629066] [] ? save_stack_trace+0x1c/0x3a
    [ 221.629066] [] ? save_stack_trace+0x1c/0x3a
    [ 221.629066] [] ? save_trace+0x37/0x8d
    [ 221.629066] [] ? add_lock_to_list+0x67/0x8d
    [ 221.629066] [] ? validate_chain+0x8a4/0x9f4
    [ 221.629066] [] ? up+0xc/0x2f
    [ 221.629066] [] ? __lock_acquire+0x68a/0x6e0
    [ 221.629066] [] ? trace_hardirqs_off+0xb/0xd
    [ 221.629066] [] ? trace_hardirqs_off_caller+0x14/0x9b
    [ 221.629066] [] ? trace_hardirqs_off+0xb/0xd
    [ 221.629066] [] ? native_sched_clock+0x82/0x96
    [ 221.629066] [] ? snprintf+0x1b/0x1d
    [ 221.629066] [] ? disk_name+0x25/0x67
    [ 221.629066] [] ? get_sb_bdev+0xcd/0x10b
    [ 221.629066] [] ? kstrdup+0x2a/0x4c
    [ 221.629066] [] ? hfsplus_get_sb+0x13/0x15
    [ 221.629066] [] ? hfsplus_fill_super+0x0/0x447
    [ 221.629066] [] ? vfs_kern_mount+0x3b/0x76
    [ 221.629066] [] ? do_kern_mount+0x32/0xba
    [ 221.629066] [] ? do_new_mount+0x46/0x74
    [ 221.629066] [] ? do_mount+0x175/0x193
    [ 221.629066] [] ? trace_hardirqs_on_caller+0xf4/0x12f
    [ 221.629066] [] ? __get_free_pages+0x1e/0x24
    [ 221.629066] [] ? lock_kernel+0x19/0x8c
    [ 221.629066] [] ? sys_mount+0x51/0x9b
    [ 221.629066] [] ? sys_mount+0x64/0x9b
    [ 221.629066] [] ? sysenter_do_call+0x12/0x31
    [ 221.629066] =======================
    [ 221.629066] Code: 89 c2 c1 e2 08 c1 e8 08 09 c2 8b 85 e8 fd ff ff 66 89 50 06 89 c7 53 83 c7 08 56 57 68 c4 b3 80 c0 e8 8c 5c ef ff 89 d9 c1 e9 02 a5 89 d9 83 e1 03 74 02 f3 a4 83 c3 06 8b 95 e8 fd ff ff 0f
    [ 221.629066] EIP: [] hfsplus_find_cat+0x10d/0x151 SS:ESP 0068:c82d199c
    [ 221.629066] ---[ end trace e417a1d67f0d0066 ]---

    Since hfsplus_cat_build_key_uni() returns void and only has one callsite,
    the check is performed at the callsite.

    Signed-off-by: Eric Sesterhenn
    Reviewed-by: Pekka Enberg
    Cc: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Sesterhenn
     

15 Feb, 2007

1 commit

  • After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

19 Jan, 2006

5 commits

  • Set the correct type and creator for symlinks.

    Signed-off-by: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roman Zippel
     
  • HFS+ also requires the correct creation date so recent version of OS X
    recognize it as link.
    Improve link handling:
    - if something is wrong with the link, ignore the link attribute and treat
    it as regular file (this also fixes a missing unlock during lookup).
    - check for incorrect link counts during unlink.

    Signed-off-by: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roman Zippel
     
  • Read the correct ctime from disk (it was written but never read for some
    reason). Read also creation date, which is used in the next patch. (Problem
    found by Olivier Castan )

    Signed-off-by: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roman Zippel
     
  • Add support for HFSX, which allows for case-sensitive filenames.

    Signed-off-by: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Elliott
     
  • Add the log level and a "hfs: " prefix to all kernel prints. (HFS and HFS+
    will use the same prefix, as they share some code and could be merged at some
    point.)

    Signed-off-by: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roman Zippel
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds