1. 06 Nov, 2008 7 commits
  2. 30 Oct, 2008 1 commit
  3. 23 Oct, 2008 1 commit
  4. 13 Oct, 2008 1 commit
  5. 20 Aug, 2008 1 commit
    • Linus Torvalds's avatar
      vfat: fix 'sync' mount deadlock due to BKL->lock_super conversion · 5f22ca9b
      Linus Torvalds authored
      There was another FAT BKL conversion deadlock reported by Bart
      Trojanowski due to the BKL being used as a recursive lock by FAT, which
      was missed because it only triggers with 'sync' (or 'dirsync') mounts.
      
      The recursion worked for the BKL, but after the conversion to lock_super
      (which uses a mutex), it just deadlocks.
      
      Thanks to Bart for debugging this and testing the fix.  The lock
      debugging information from the original report:
      
        =============================================
        [ INFO: possible recursive locking detected ]
        2.6.27-rc3-bisect-00448-ga7f5aaf3 #16
        ---------------------------------------------
        mv/4020 is trying to acquire lock:
         (&type->s_lock_key#9){--..}, at: [<c01a90fe>] lock_super+0x1e/0x20
      
        but task is already holding lock:
         (&type->s_lock_key#9){--..}, at: [<c01a90fe>] lock_super+0x1e/0x20
      
        other info that might help us debug this:
        3 locks held by mv/4020:
         #0:  (&sb->s_type->i_mutex_key#9/1){--..}, at: [<c01b2336>] do_unlinkat+0x66/0x140
         #1:  (&sb->s_type->i_mutex_key#9){--..}, at: [<c01b0954>] vfs_unlink+0x84/0x110
         #2:  (&type->s_lock_key#9){--..}, at: [<c01a90fe>] lock_super+0x1e/0x20
      
        stack backtrace:
        Pid: 4020, comm: mv Not tainted 2.6.27-rc3-bisect-00448-ga7f5aaf3 #16
         [<c014e694>] validate_chain+0x984/0xea0
         [<c0108d70>] ? native_sched_clock+0x0/0xf0
         [<c014ee9c>] __lock_acquire+0x2ec/0x9b0
         [<c014f5cf>] lock_acquire+0x6f/0x90
         [<c01a90fe>] ? lock_super+0x1e/0x20
         [<c044e5fd>] mutex_lock_nested+0xad/0x300
         [<c01a90fe>] ? lock_super+0x1e/0x20
         [<c01a90fe>] ? lock_super+0x1e/0x20
         [<c01a90fe>] lock_super+0x1e/0x20
         [<f8b3a700>] fat_write_inode+0x60/0x2b0 [fat]
         [<c0450878>] ? _spin_unlock_irqrestore+0x48/0x80
         [<f8b3a953>] ? fat_sync_inode+0x3/0x20 [fat]
         [<f8b3a962>] fat_sync_inode+0x12/0x20 [fat]
         [<f8b37c7e>] fat_remove_entries+0xbe/0x120 [fat]
         [<f8b422ef>] vfat_unlink+0x5f/0x90 [vfat]
         [<f8b42290>] ? vfat_unlink+0x0/0x90 [vfat]
         [<c01b0968>] vfs_unlink+0x98/0x110
         [<c01b2400>] do_unlinkat+0x130/0x140
         [<c016a8f5>] ? audit_syscall_entry+0x105/0x150
         [<c01b253b>] sys_unlinkat+0x3b/0x40
         [<c01040d3>] sysenter_do_call+0x12/0x3f
         =======================
      
      where the deadlock is due to the nesting of lock_super from vfat_unlink
      to fat_write_inode:
      
       - do_unlinkat
         - vfs_unlink
           - vfat_unlink
             * lock_super
             - fat_remove_entries
               - fat_sync_inode
                 - fat_write_inode
                   * lock_super
      
      and the fix is to simply remove the use of lock_super() in fat_write_inode.
      
      The lock_super() there had been just an automatic conversion of the
      kernel lock to the superblock lock, but no locking was actually needed
      there, since the code in fat_write_inode already protected all relevant
      accesses with a spinlock (sbi->inode_hash_lock to be exact).  The only
      code inside the BKL (and thus the superblock lock) was accesses tp local
      variables or calls to functions that have long been SMP-safe (i.e.
      sb_bread, mark_buffe_dirty and brlese).
      
      Bart reports:
       "Looks good.  I ran 10 parallel processes creating 1M files truncating
        them, writing to them again and then deleting them.  This patch fixes
        the issue I ran into.
      
        Signed-off-by: Bart Trojanowski <bart@jukie.net>"
      Reported-and-tested-by: default avatarBart Trojanowski <bart@jukie.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5f22ca9b
  6. 26 Jul, 2008 1 commit
  7. 25 Jul, 2008 2 commits
    • Joe Peterson's avatar
      fatfs: add UTC timestamp option · b271e067
      Joe Peterson authored
      Provide a new mount option ("tz=UTC") for DOS (vfat/msdos) filesystems,
      allowing timestamps to be in coordinated universal time (UTC) rather than
      local time in applications where doing this is advantageous.
      
      In particular, portable devices that use fat/vfat (such as digital
      cameras) can benefit from using UTC in their internal clocks, thus
      avoiding daylight saving time errors and general time ambiguity issues.
      The user of the device does not have to worry about changing the time when
      moving from place or when daylight saving changes.
      
      The new mount option, when set, disables the counter-adjustment that Linux
      currently makes to FAT timestamp info in anticipation of the normal
      userspace time zone correction.  When used in this new mode, all daylight
      saving time and time zone handling is done in userspace as is normal for
      many other filesystems (like ext3).  The default mode, which remains
      unchanged, is still appropriate when mounting volumes written in Windows
      (because of its use of local time).
      
      I originally based this patch on one submitted last year by Paul Collins,
      but I updated it to work with current source and changed variable/option
      naming.  Ogawa Hirofumi (who maintains these filesystems) and I discussed
      this patch at length on lkml, and he suggested using the option name in
      the attached version of the patch.  Barry Bouwsma pointed out a good
      addition to the patch as well.
      Signed-off-by: default avatarJoe Peterson <joe@skyrush.com>
      Signed-off-by: default avatarPaul Collins <paul@ondioline.org>
      Acked-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Barry Bouwsma <free_beer_for_all@yahoo.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b271e067
    • OGAWA Hirofumi's avatar
      fat: fix parse_options() · 8d44d974
      OGAWA Hirofumi authored
      Current parse_options() exits too early.  We need to run the code of
      bottom in this function even if users doesn't specify options.
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8d44d974
  8. 20 Jun, 2008 1 commit
    • Linus Torvalds's avatar
      Replace BKL with superblock lock in fat/msdos/vfat · 8f593427
      Linus Torvalds authored
      This replaces the use of the BKL in the FAT family of filesystems with the
      existing superblock lock instead.
      
      The code already appears to do mostly proper locking with its own private
      spinlocks (and mutexes), but while the BKL could possibly have been
      dropped entirely, converting it to use the superblock lock (which is just
      a regular mutex) is the conservative thing to do.
      
      As a per-filesystem mutex, it not only won't have any of the possible
      latency issues related to the BKL, but the lock is obviously private to
      the particular filesystem instance and will thus not cause problems for
      entirely unrelated users like the BKL can.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      8f593427
  9. 29 Apr, 2008 1 commit
  10. 28 Apr, 2008 5 commits
  11. 08 Feb, 2008 1 commit
  12. 07 Feb, 2008 2 commits
  13. 06 Feb, 2008 1 commit
  14. 22 Oct, 2007 2 commits
  15. 17 Oct, 2007 1 commit
  16. 16 Oct, 2007 1 commit
  17. 20 Jul, 2007 1 commit
    • Paul Mundt's avatar
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt authored
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      20c2df83
  18. 17 Jul, 2007 1 commit
  19. 16 Jul, 2007 1 commit
  20. 17 May, 2007 1 commit
    • Christoph Lameter's avatar
      Remove SLAB_CTOR_CONSTRUCTOR · a35afb83
      Christoph Lameter authored
      SLAB_CTOR_CONSTRUCTOR is always specified. No point in checking it.
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Dave Kleikamp <shaggy@austin.ibm.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Mark Fasheh <mark.fasheh@oracle.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Jan Kara <jack@ucw.cz>
      Cc: David Chinner <dgc@sgi.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a35afb83
  21. 08 May, 2007 2 commits
  22. 07 May, 2007 1 commit
    • Christoph Lameter's avatar
      slab allocators: Remove SLAB_DEBUG_INITIAL flag · 50953fe9
      Christoph Lameter authored
      I have never seen a use of SLAB_DEBUG_INITIAL.  It is only supported by
      SLAB.
      
      I think its purpose was to have a callback after an object has been freed
      to verify that the state is the constructor state again?  The callback is
      performed before each freeing of an object.
      
      I would think that it is much easier to check the object state manually
      before the free.  That also places the check near the code object
      manipulation of the object.
      
      Also the SLAB_DEBUG_INITIAL callback is only performed if the kernel was
      compiled with SLAB debugging on.  If there would be code in a constructor
      handling SLAB_DEBUG_INITIAL then it would have to be conditional on
      SLAB_DEBUG otherwise it would just be dead code.  But there is no such code
      in the kernel.  I think SLUB_DEBUG_INITIAL is too problematic to make real
      use of, difficult to understand and there are easier ways to accomplish the
      same effect (i.e.  add debug code before kfree).
      
      There is a related flag SLAB_CTOR_VERIFY that is frequently checked to be
      clear in fs inode caches.  Remove the pointless checks (they would even be
      pointless without removeal of SLAB_DEBUG_INITIAL) from the fs constructors.
      
      This is the last slab flag that SLUB did not support.  Remove the check for
      unimplemented flags from SLUB.
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      50953fe9
  23. 21 Feb, 2007 1 commit
  24. 12 Feb, 2007 2 commits
  25. 07 Dec, 2006 1 commit