1. 01 5月, 2013 1 次提交
  2. 28 2月, 2013 1 次提交
  3. 21 9月, 2012 1 次提交
  4. 05 5月, 2012 1 次提交
  5. 07 7月, 2011 1 次提交
  6. 17 12月, 2010 1 次提交
  7. 23 11月, 2010 1 次提交
    • C
      hfsplus: optimize fsync · e3494705
      Christoph Hellwig 提交于
      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: NChristoph Hellwig <hch@tuxera.com>
      e3494705
  8. 14 10月, 2010 3 次提交
    • C
      hfsplus: create correct initial catalog entries for device files · 90e61690
      Christoph Hellwig 提交于
      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: NChristoph Hellwig <hch@tuxera.com>
      90e61690
    • C
      hfsplus: remove superflous rootflags field in hfsplus_inode_info · 722c55d1
      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: NChristoph Hellwig <hch@tuxera.com>
      722c55d1
    • C
      hfsplus: fix link corruption · f6089ff8
      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: NChristoph Hellwig <hch@tuxera.com>
      f6089ff8
  9. 01 10月, 2010 2 次提交
    • C
      hfsplus: fix HFSPLUS_I calling convention · 6af502de
      Christoph Hellwig 提交于
      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: NChristoph Hellwig <hch@tuxera.com>
      6af502de
    • C
      hfsplus: fix HFSPLUS_SB calling convention · dd73a01a
      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: NChristoph Hellwig <hch@tuxera.com>
      dd73a01a
  10. 17 10月, 2008 1 次提交
    • E
      hfsplus: fix Buffer overflow with a corrupted image · efc7ffcb
      Eric Sesterhenn 提交于
      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: [<c022d4b1>] 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-gd3ee1b40-dirty #28)
      [  221.629066] EIP: 0060:[<c022d4b1>] 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]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
      [  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
      [  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
      [  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
      [  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
      [  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
      [  221.629066]  [<c01302d2>] ? __kernel_text_address+0x1b/0x27
      [  221.629066]  [<c010487a>] ? dump_trace+0xca/0xd6
      [  221.629066]  [<c0109e32>] ? save_stack_address+0x0/0x2c
      [  221.629066]  [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
      [  221.629066]  [<c013b571>] ? save_trace+0x37/0x8d
      [  221.629066]  [<c013b62e>] ? add_lock_to_list+0x67/0x8d
      [  221.629066]  [<c013ea1c>] ? validate_chain+0x8a4/0x9f4
      [  221.629066]  [<c013553d>] ? down+0xc/0x2f
      [  221.629066]  [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
      [  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
      [  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
      [  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
      [  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
      [  221.629066]  [<c013da5d>] ? mark_held_locks+0x43/0x5a
      [  221.629066]  [<c013dc3a>] ? trace_hardirqs_on+0xb/0xd
      [  221.629066]  [<c013dbf4>] ? trace_hardirqs_on_caller+0xf4/0x12f
      [  221.629066]  [<c06abec8>] ? _spin_unlock_irqrestore+0x42/0x58
      [  221.629066]  [<c013555c>] ? down+0x2b/0x2f
      [  221.629066]  [<c022aa68>] ? hfsplus_iget+0xa0/0x154
      [  221.629066]  [<c022b0b9>] ? hfsplus_fill_super+0x280/0x447
      [  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
      [  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
      [  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
      [  221.629066]  [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
      [  221.629066]  [<c041c9e4>] ? string+0x2b/0x74
      [  221.629066]  [<c041cd16>] ? vsnprintf+0x2e9/0x512
      [  221.629066]  [<c010487a>] ? dump_trace+0xca/0xd6
      [  221.629066]  [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
      [  221.629066]  [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
      [  221.629066]  [<c013b571>] ? save_trace+0x37/0x8d
      [  221.629066]  [<c013b62e>] ? add_lock_to_list+0x67/0x8d
      [  221.629066]  [<c013ea1c>] ? validate_chain+0x8a4/0x9f4
      [  221.629066]  [<c01354d3>] ? up+0xc/0x2f
      [  221.629066]  [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
      [  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
      [  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
      [  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
      [  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
      [  221.629066]  [<c041cfb7>] ? snprintf+0x1b/0x1d
      [  221.629066]  [<c01ba466>] ? disk_name+0x25/0x67
      [  221.629066]  [<c0183960>] ? get_sb_bdev+0xcd/0x10b
      [  221.629066]  [<c016ad92>] ? kstrdup+0x2a/0x4c
      [  221.629066]  [<c022a7b3>] ? hfsplus_get_sb+0x13/0x15
      [  221.629066]  [<c022ae39>] ? hfsplus_fill_super+0x0/0x447
      [  221.629066]  [<c0183583>] ? vfs_kern_mount+0x3b/0x76
      [  221.629066]  [<c0183602>] ? do_kern_mount+0x32/0xba
      [  221.629066]  [<c01960d4>] ? do_new_mount+0x46/0x74
      [  221.629066]  [<c0196277>] ? do_mount+0x175/0x193
      [  221.629066]  [<c013dbf4>] ? trace_hardirqs_on_caller+0xf4/0x12f
      [  221.629066]  [<c01663b2>] ? __get_free_pages+0x1e/0x24
      [  221.629066]  [<c06ac07b>] ? lock_kernel+0x19/0x8c
      [  221.629066]  [<c01962e6>] ? sys_mount+0x51/0x9b
      [  221.629066]  [<c01962f9>] ? sys_mount+0x64/0x9b
      [  221.629066]  [<c01038bd>] ? 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 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 83 c3 06 8b 95 e8 fd ff ff 0f
      [  221.629066] EIP: [<c022d4b1>] 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: NEric Sesterhenn <snakebyte@gmx.de>
      Reviewed-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      efc7ffcb
  11. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      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: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  12. 19 1月, 2006 5 次提交
  13. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4