1. 28 8月, 2006 8 次提交
    • P
      [PATCH] lockdep: fix blkdev_open() warning · 6946bd63
      Peter Zijlstra 提交于
      On Wed, 2006-08-09 at 07:57 +0200, Rolf Eike Beer wrote:
      > =============================================
      > [ INFO: possible recursive locking detected ]
      > ---------------------------------------------
      > parted/7929 is trying to acquire lock:
      >  (&bdev->bd_mutex){--..}, at: [<c105eb8d>] __blkdev_put+0x1e/0x13c
      >
      > but task is already holding lock:
      >  (&bdev->bd_mutex){--..}, at: [<c105eec6>] do_open+0x72/0x3a8
      >
      > other info that might help us debug this:
      > 1 lock held by parted/7929:
      >  #0:  (&bdev->bd_mutex){--..}, at: [<c105eec6>] do_open+0x72/0x3a8
      > stack backtrace:
      >  [<c1003aad>] show_trace_log_lvl+0x58/0x15b
      >  [<c100495f>] show_trace+0xd/0x10
      >  [<c1004979>] dump_stack+0x17/0x1a
      >  [<c102dee5>] __lock_acquire+0x753/0x99c
      >  [<c102e3b0>] lock_acquire+0x4a/0x6a
      >  [<c1204501>] mutex_lock_nested+0xc8/0x20c
      >  [<c105eb8d>] __blkdev_put+0x1e/0x13c
      >  [<c105ecc4>] blkdev_put+0xa/0xc
      >  [<c105f18a>] do_open+0x336/0x3a8
      >  [<c105f21b>] blkdev_open+0x1f/0x4c
      >  [<c1057b40>] __dentry_open+0xc7/0x1aa
      >  [<c1057c91>] nameidata_to_filp+0x1c/0x2e
      >  [<c1057cd1>] do_filp_open+0x2e/0x35
      >  [<c1057dd7>] do_sys_open+0x38/0x68
      >  [<c1057e33>] sys_open+0x16/0x18
      >  [<c1002845>] sysenter_past_esp+0x56/0x8d
      
      OK, I'm having a look here; its all new to me so bear with me.
      
      blkdev_open() calls
        do_open(bdev, ...,BD_MUTEX_NORMAL) and takes
          mutex_lock_nested(&bdev->bd_mutex, BD_MUTEX_NORMAL)
      
      then something fails, and we're thrown to:
      
      out_first: where
          if (bdev != bdev->bd_contains)
            blkdev_put(bdev->bd_contains) which is
              __blkdev_put(bdev->bd_contains, BD_MUTEX_NORMAL) which does
                mutex_lock_nested(&bdev->bd_contains->bd_mutex, BD_MUTEX_NORMAL) <--- lockdep trigger
      
      When going to out_first, dbev->bd_contains is either bdev or whole, and
      since we take the branch it must be whole. So it seems to me the
      following patch would be the right one:
      
      [akpm@osdl.org: compile fix]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Acked-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6946bd63
    • D
      [PATCH] 1394: fix for recently added firewire patch that breaks things on ppc · 7334bb4a
      Danny Tholen 提交于
      Recently a patch was added for preliminary suspend/resume handling on
      !PPC_PMAC.  However, this broke both suspend and firewire on powerpc
      because it saves the pci state after the device has already been disabled.
      
      This moves the save state to before the pmac specific code.
      Signed-off-by: NDanny Tholen <obiwan@mailmij.org>
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ben Collins <bcollins@ubuntu.com>
      Cc: Jody McIntyre <scjody@modernduck.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7334bb4a
    • A
      [PATCH] Fix docs for fs.suid_dumpable · a2e0b563
      Alexey Dobriyan 提交于
      Sergey Vlasov noticed that there is not kernel.suid_dumpable, but
      fs.suid_dumpable.
      
      How KERN_SETUID_DUMPABLE ended up in fs_table[]? Hell knows...
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a2e0b563
    • R
      [PATCH] tty: remove bogus call to cdev_del() · cc36e7f1
      Rolf Eike Beer 提交于
      When cdev_add() failed there is no reason to call cdev_del().
      Signed-off-by: NRolf Eike Beer <eike-kernel@sf-tec.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cc36e7f1
    • B
      [PATCH] rtc-s3c.c: fix time setting checks · 641741e0
      Ben Dooks 提交于
      Fix the year check on setting the time with the S3C24XX RTC driver.  Also
      move the debug to before the set to see what is going on if it does fail.
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      641741e0
    • R
      [PATCH] swsusp: Fix swap_type_of · b6b5bce3
      Rafael J. Wysocki 提交于
      There is a bug in mm/swapfile.c#swap_type_of() that makes swsusp only be
      able to use the first active swap partition as the resume device.  Fix it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Hugh Dickins <hugh@veritas.com>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b6b5bce3
    • D
      [PATCH] dm: Fix deadlock under high i/o load in raid1 setup. · c06aad85
      Daniel Kobras 提交于
      On an nForce4-equipped machine with two SATA disk in raid1 setup using dmraid,
      we experienced frequent deadlock of the system under high i/o load.  'cat
      /dev/zero > ~/zero' was the most reliable way to reproduce them: Randomly
      after a few GB, 'cp' would be left in 'D' state along with kjournald and
      kmirrord.  The functions cp and kjournald were blocked in did vary, but
      kmirrord's wchan always pointed to 'mempool_alloc()'.  We've seen this pattern
      on 2.6.15 and 2.6.17 kernels.  http://lkml.org/lkml/2005/4/20/142 indicates
      that this problem has been around even before.
      
      So much for the facts, here's my interpretation: mempool_alloc() first tries
      to atomically allocate the requested memory, or falls back to hand out
      preallocated chunks from the mempool.  If both fail, it puts the calling
      process (kmirrord in this case) on a private waitqueue until somebody refills
      the pool.  Where the only 'somebody' is kmirrord itself, so we have a
      deadlock.
      
      I worked around this problem by falling back to a (blocking) kmalloc when
      before kmirrord would have ended up on the waitqueue.  This defeats part of
      the benefits of using the mempool, but at least keeps the system running.  And
      it could be done with a two-line change.  Note that mempool_alloc() clears the
      GFP_NOIO flag internally, and only uses it to decide whether to wait or return
      an error if immediate allocation fails, so the attached patch doesn't change
      behaviour in the non-deadlocking case.  Path is against current git
      (2.6.18-rc4), but should apply to earlier versions as well.  I've tested on
      2.6.15, where this patch makes the difference between random lockup and a
      stable system.
      Signed-off-by: NDaniel Kobras <kobras@linux.de>
      Acked-by: NAlasdair G Kergon <agk@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c06aad85
    • B
      [PATCH] drivers/rtc: fix rtc-s3c.c · 9a654518
      Ben Dooks 提交于
      In the cleanups of drivers/rtc/s3c-rtc.c, the base address for the
      registers got broken.  This patch fixes that by ensuring the readb/writeb
      are all prefixed with the base returned from ioremap()ing the registers.
      
      Also fix check for valid year range, which was the wrong way around.
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9a654518
  2. 27 8月, 2006 23 次提交
  3. 26 8月, 2006 5 次提交
  4. 25 8月, 2006 4 次提交