1. 01 10月, 2010 8 次提交
  2. 10 8月, 2010 6 次提交
  3. 17 5月, 2010 1 次提交
  4. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  5. 06 3月, 2010 1 次提交
  6. 29 10月, 2009 1 次提交
  7. 24 9月, 2009 1 次提交
    • T
      fs: Make unload_nls() NULL pointer safe · 6d729e44
      Thomas Gleixner 提交于
      Most call sites of unload_nls() do:
      	if (nls)
      		unload_nls(nls);
      
      Check the pointer inside unload_nls() like we do in kfree() and
      simplify the call sites.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Steve French <sfrench@us.ibm.com>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
      Cc: Petr Vandrovec <vandrove@vc.cvut.cz>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6d729e44
  8. 13 7月, 2009 1 次提交
  9. 12 6月, 2009 4 次提交
    • C
      hfsplus: add ->sync_fs · 7fbc6df0
      Christoph Hellwig 提交于
      Add a ->sync_fs method for data integrity syncs, and reimplement
      ->write_super ontop of it.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      7fbc6df0
    • C
      ->write_super lock_super pushdown · ebc1ac16
      Christoph Hellwig 提交于
      Push down lock_super into ->write_super instances and remove it from the
      caller.
      
      Following filesystem don't need ->s_lock in ->write_super and are skipped:
      
       * bfs, nilfs2 - no other uses of s_lock and have internal locks in
      	->write_super
       * ext2 - uses BKL in ext2_write_super and has internal calls without s_lock
       * reiserfs - no other uses of s_lock as has reiserfs_write_lock (BKL) in
       	->write_super
       * xfs - no other uses of s_lock and uses internal lock (buffer lock on
      	superblock buffer) to serialize ->write_super.  Also xfs_fs_write_super
      	is superflous and will go away in the next merge window
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      ebc1ac16
    • C
      push BKL down into ->put_super · 6cfd0148
      Christoph Hellwig 提交于
      Move BKL into ->put_super from the only caller.  A couple of
      filesystems had trivial enough ->put_super (only kfree and NULLing of
      s_fs_info + stuff in there) to not get any locking: coda, cramfs, efs,
      hugetlbfs, omfs, qnx4, shmem, all others got the full treatment.  Most
      of them probably don't need it, but I'd rather sort that out individually.
      Preferably after all the other BKL pushdowns in that area.
      
      [AV: original used to move lock_super() down as well; these changes are
      removed since we don't do lock_super() at all in generic_shutdown_super()
      now]
      [AV: fuse, btrfs and xfs are known to need no damn BKL, exempt]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6cfd0148
    • C
      remove ->write_super call in generic_shutdown_super · 8c85e125
      Christoph Hellwig 提交于
      We just did a full fs writeout using sync_filesystem before, and if
      that's not enough for the filesystem it can perform it's own writeout
      in ->put_super, which many filesystems already do.
      
      Move a call to foofs_write_super into every foofs_put_super for now to
      guarantee identical behaviour until it's cleaned up by the individual
      filesystem maintainers.
      
      Exceptions:
      
       - affs already has identical copy & pasted code at the beginning of
         affs_put_super so no need to do it twice.
       - xfs does the right thing without it and I have changes pending for
         the xfs tree touching this are so I don't really need conflicts
         here..
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8c85e125
  10. 03 4月, 2009 1 次提交
  11. 01 4月, 2009 1 次提交
  12. 28 3月, 2009 1 次提交
  13. 22 1月, 2009 1 次提交
  14. 14 11月, 2008 1 次提交
  15. 23 10月, 2008 1 次提交
    • M
      [PATCH] move executable checking into ->permission() · f696a365
      Miklos Szeredi 提交于
      For execute permission on a regular files we need to check if file has
      any execute bits at all, regardless of capabilites.
      
      This check is normally performed by generic_permission() but was also
      added to the case when the filesystem defines its own ->permission()
      method.  In the latter case the filesystem should be responsible for
      performing this check.
      
      Move the check from inode_permission() inside filesystems which are
      not calling generic_permission().
      
      Create a helper function execute_ok() that returns true if the inode
      is a directory or if any execute bits are present in i_mode.
      
      Also fix up the following code:
      
       - coda control file is never executable
       - sysctl files are never executable
       - hfs_permission seems broken on MAY_EXEC, remove
       - hfsplus_permission is eqivalent to generic_permission(), remove
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      f696a365
  16. 20 10月, 2008 2 次提交
  17. 17 10月, 2008 3 次提交
    • E
      hfsplus: check read_mapping_page() return value · 649f1ee6
      Eric Sesterhenn 提交于
      While testing more corrupted images with hfsplus, i came across
      one which triggered the following bug:
      
      [15840.675016] BUG: unable to handle kernel paging request at fffffffb
      [15840.675016] IP: [<c0116a4f>] kmap+0x15/0x56
      [15840.675016] *pde = 00008067 *pte = 00000000
      [15840.675016] Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
      [15840.675016] Modules linked in:
      [15840.675016]
      [15840.675016] Pid: 11575, comm: ln Not tainted (2.6.27-rc4-00123-gd3ee1b40-dirty #29)
      [15840.675016] EIP: 0060:[<c0116a4f>] EFLAGS: 00010202 CPU: 0
      [15840.675016] EIP is at kmap+0x15/0x56
      [15840.675016] EAX: 00000246 EBX: fffffffb ECX: 00000000 EDX: cab919c0
      [15840.675016] ESI: 000007dd EDI: cab0bcf4 EBP: cab0bc98 ESP: cab0bc94
      [15840.675016]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      [15840.675016] Process ln (pid: 11575, ti=cab0b000 task=cab919c0 task.ti=cab0b000)
      [15840.675016] Stack: 00000000 cab0bcdc c0231cfb 00000000 cab0bce0 00000800 ca9290c0 fffffffb
      [15840.675016]        cab145d0 cab919c0 cab15998 22222222 22222222 22222222 00000001 cab15960
      [15840.675016]        000007dd cab0bcf4 cab0bd04 c022cb3a cab0bcf4 cab15a6c ca9290c0 00000000
      [15840.675016] Call Trace:
      [15840.675016]  [<c0231cfb>] ? hfsplus_block_allocate+0x6f/0x2d3
      [15840.675016]  [<c022cb3a>] ? hfsplus_file_extend+0xc4/0x1db
      [15840.675016]  [<c022ce41>] ? hfsplus_get_block+0x8c/0x19d
      [15840.675016]  [<c06adde4>] ? sub_preempt_count+0x9d/0xab
      [15840.675016]  [<c019ece6>] ? __block_prepare_write+0x147/0x311
      [15840.675016]  [<c0161934>] ? __grab_cache_page+0x52/0x73
      [15840.675016]  [<c019ef4f>] ? block_write_begin+0x79/0xd5
      [15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
      [15840.675016]  [<c019f22a>] ? cont_write_begin+0x27f/0x2af
      [15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
      [15840.675016]  [<c0139ebe>] ? tick_program_event+0x28/0x4c
      [15840.675016]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
      [15840.675016]  [<c022b723>] ? hfsplus_write_begin+0x2d/0x32
      [15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
      [15840.675016]  [<c0161988>] ? pagecache_write_begin+0x33/0x107
      [15840.675016]  [<c01879e5>] ? __page_symlink+0x3c/0xae
      [15840.675016]  [<c019ad34>] ? __mark_inode_dirty+0x12f/0x137
      [15840.675016]  [<c0187a70>] ? page_symlink+0x19/0x1e
      [15840.675016]  [<c022e6eb>] ? hfsplus_symlink+0x41/0xa6
      [15840.675016]  [<c01886a9>] ? vfs_symlink+0x99/0x101
      [15840.675016]  [<c018a2f6>] ? sys_symlinkat+0x6b/0xad
      [15840.675016]  [<c018a348>] ? sys_symlink+0x10/0x12
      [15840.675016]  [<c01038bd>] ? sysenter_do_call+0x12/0x31
      [15840.675016]  =======================
      [15840.675016] Code: 00 00 75 10 83 3d 88 2f ec c0 02 75 07 89 d0 e8 12 56 05 00 5d c3 55 ba 06 00 00 00 89 e5 53 89 c3 b8 3d eb 7e c0 e8 16 74 00 00 <8b> 03 c1 e8 1e 69 c0 d8 02 00 00 05 b8 69 8e c0 2b 80 c4 02 00
      [15840.675016] EIP: [<c0116a4f>] kmap+0x15/0x56 SS:ESP 0068:cab0bc94
      [15840.675016] ---[ end trace 4fea40dad6b70e5f ]---
      
      This happens because the return value of read_mapping_page() is passed on
      to kmap unchecked.  The bug is triggered after the first
      read_mapping_page() in hfsplus_block_allocate(), this patch fixes all
      three usages in this functions but leaves the ones further down in the
      file unchanged.
      Signed-off-by: NEric Sesterhenn <snakebyte@gmx.de>
      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>
      649f1ee6
    • 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
    • M
      hfsplus: quieten down mounting hfsplus journaled fs read only · 81a73719
      Mike Crowe 提交于
      Check whether the file system was to be mounted read only anyway before
      warning about changing the mount to read only.
      Signed-off-by: NMike Crowe <mac@mcrowe.com>
      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>
      81a73719
  18. 14 10月, 2008 1 次提交
  19. 27 7月, 2008 3 次提交
  20. 26 7月, 2008 1 次提交