Jiri Slaby [Thu, 19 Nov 2009 16:16:37 +0000 (17:16 +0100)]
resource: add helpers for fetching rlimits
We want to be sure that compiler fetches the limit variable only
once, so add helpers for fetching current and maximal resource
limits which do that.
Add them to sched.h (instead of resource.h) due to circular dependency
sched.h->resource.h->task_struct
Alternative would be to create a separate res_access.h or similar.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: James Morris <jmorris@namei.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Jiri Slaby [Fri, 20 Nov 2009 13:16:33 +0000 (14:16 +0100)]
resource: move kernel function inside __KERNEL__
It is an internal function. Move it inside __KERNEL__ ifdef, along
with task_struct declaration.
Then we get:
--- /usr/include/linux/resource.h 2009-09-14 15:09:29.
000000000 +0200
+++ usr/include/linux/resource.h 2010-01-04 11:30:54.
000000000 +0100
@@ -3,8 +3,6 @@
#include <linux/time.h>
-struct task_struct;
-
/*
* Resource control/accounting header file for linux
*/
@@ -70,6 +68,5 @@
*/
#include <asm/resource.h>
-int getrusage(struct task_struct *p, int who, struct rusage *ru);
#endif
***********
include/linux/Kbuild is untouched, since unifdef is run even on
headers-y nowadays.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Jiri Slaby [Fri, 28 Aug 2009 08:47:16 +0000 (10:47 +0200)]
SECURITY: selinux, fix update_rlimit_cpu parameter
Don't pass current RLIMIT_RTTIME to update_rlimit_cpu() in
selinux_bprm_committing_creds, since update_rlimit_cpu expects
RLIMIT_CPU limit.
Use proper rlim[RLIMIT_CPU].rlim_cur instead to fix that.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Acked-by: James Morris <jmorris@namei.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Eric Paris <eparis@parisplace.org>
Cc: David Howells <dhowells@redhat.com>
Linus Torvalds [Sat, 2 Jan 2010 19:17:05 +0000 (11:17 -0800)]
Merge branch 'reiserfs/kill-bkl' of git://git./linux/kernel/git/frederic/random-tracing
* 'reiserfs/kill-bkl' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing:
reiserfs: Safely acquire i_mutex from xattr_rmdir
reiserfs: Safely acquire i_mutex from reiserfs_for_each_xattr
reiserfs: Fix journal mutex <-> inode mutex lock inversion
reiserfs: Fix unwanted recursive reiserfs lock in reiserfs_unlink()
reiserfs: Relax lock before open xattr dir in reiserfs_xattr_set_handle()
reiserfs: Relax reiserfs lock while freeing the journal
reiserfs: Fix reiserfs lock <-> i_mutex dependency inversion on xattr
reiserfs: Warn on lock relax if taken recursively
reiserfs: Fix reiserfs lock <-> i_xattr_sem dependency inversion
reiserfs: Fix remaining in-reclaim-fs <-> reclaim-fs-on locking inversion
reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion
reiserfs: Fix reiserfs lock and journal lock inversion dependency
reiserfs: Fix possible recursive lock
Kusanagi Kouichi [Sat, 2 Jan 2010 04:36:09 +0000 (20:36 -0800)]
Documentation: Rename Documentation/DMA-mapping.txt
It seems that Documentation/DMA-mapping.txt was supposed to be renamed
to Documentation/PCI/PCI-DMA-mapping.txt.
Signed-off-by: Kusanagi Kouichi <slash@ac.auone-net.jp>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
H Hartley Sweeten [Sat, 2 Jan 2010 04:35:54 +0000 (20:35 -0800)]
DocBook: fix ioremap return type
ioremap() returns a void __iomem * not an unsigned long. Update the
Documentation file to reflect this.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
H Hartley Sweeten [Sat, 2 Jan 2010 04:35:41 +0000 (20:35 -0800)]
Documentation: fix ioremap return type
ioremap() returns a void __iomem * not a char *. Update the documentation
file to reflect this.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jaswinder Singh Rajput [Sat, 2 Jan 2010 04:35:23 +0000 (20:35 -0800)]
writeback: add missing kernel-doc notation
Fix the following htmldocs warning:
Warning(fs/fs-writeback.c:255): No description found for parameter 'sb'
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Wu Fengguang <fengguang.wu@intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Jan Kara <jack@suse.cz>
Cc: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Frederic Weisbecker [Wed, 30 Dec 2009 06:40:39 +0000 (07:40 +0100)]
reiserfs: Safely acquire i_mutex from xattr_rmdir
Relax the reiserfs lock before taking the inode mutex from
xattr_rmdir() to avoid the usual reiserfs lock <-> inode mutex
bad dependency.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Frederic Weisbecker [Wed, 30 Dec 2009 06:28:58 +0000 (07:28 +0100)]
reiserfs: Safely acquire i_mutex from reiserfs_for_each_xattr
Relax the reiserfs lock before taking the inode mutex from
reiserfs_for_each_xattr() to avoid the usual bad dependencies:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-atom #179
-------------------------------------------------------
rm/3242 is trying to acquire lock:
(&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [<
c11428ef>] reiserfs_for_each_xattr+0x23f/0x290
but task is already holding lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [<
c1143389>] reiserfs_write_lock+0x29/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
[<
c105ea7f>] __lock_acquire+0x11ff/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c1401aab>] mutex_lock_nested+0x5b/0x340
[<
c1143339>] reiserfs_write_lock_once+0x29/0x50
[<
c1117022>] reiserfs_lookup+0x62/0x140
[<
c10bd85f>] __lookup_hash+0xef/0x110
[<
c10bf21d>] lookup_one_len+0x8d/0xc0
[<
c1141e3a>] open_xa_dir+0xea/0x1b0
[<
c1142720>] reiserfs_for_each_xattr+0x70/0x290
[<
c11429ba>] reiserfs_delete_xattrs+0x1a/0x60
[<
c111ea2f>] reiserfs_delete_inode+0x9f/0x150
[<
c10c9c32>] generic_delete_inode+0xa2/0x170
[<
c10c9d4f>] generic_drop_inode+0x4f/0x70
[<
c10c8b07>] iput+0x47/0x50
[<
c10c0965>] do_unlinkat+0xd5/0x160
[<
c10c0b13>] sys_unlinkat+0x23/0x40
[<
c1002ec4>] sysenter_do_call+0x12/0x32
-> #0 (&sb->s_type->i_mutex_key#4/3){+.+.+.}:
[<
c105f176>] __lock_acquire+0x18f6/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c1401aab>] mutex_lock_nested+0x5b/0x340
[<
c11428ef>] reiserfs_for_each_xattr+0x23f/0x290
[<
c11429ba>] reiserfs_delete_xattrs+0x1a/0x60
[<
c111ea2f>] reiserfs_delete_inode+0x9f/0x150
[<
c10c9c32>] generic_delete_inode+0xa2/0x170
[<
c10c9d4f>] generic_drop_inode+0x4f/0x70
[<
c10c8b07>] iput+0x47/0x50
[<
c10c0965>] do_unlinkat+0xd5/0x160
[<
c10c0b13>] sys_unlinkat+0x23/0x40
[<
c1002ec4>] sysenter_do_call+0x12/0x32
other info that might help us debug this:
1 lock held by rm/3242:
#0: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<
c1143389>] reiserfs_write_lock+0x29/0x40
stack backtrace:
Pid: 3242, comm: rm Not tainted 2.6.32-atom #179
Call Trace:
[<
c13ffa13>] ? printk+0x18/0x1a
[<
c105d33a>] print_circular_bug+0xca/0xd0
[<
c105f176>] __lock_acquire+0x18f6/0x19e0
[<
c105c932>] ? mark_held_locks+0x62/0x80
[<
c105cc3b>] ? trace_hardirqs_on+0xb/0x10
[<
c1401098>] ? mutex_unlock+0x8/0x10
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c11428ef>] ? reiserfs_for_each_xattr+0x23f/0x290
[<
c11428ef>] ? reiserfs_for_each_xattr+0x23f/0x290
[<
c1401aab>] mutex_lock_nested+0x5b/0x340
[<
c11428ef>] ? reiserfs_for_each_xattr+0x23f/0x290
[<
c11428ef>] reiserfs_for_each_xattr+0x23f/0x290
[<
c1143180>] ? delete_one_xattr+0x0/0x100
[<
c11429ba>] reiserfs_delete_xattrs+0x1a/0x60
[<
c1143339>] ? reiserfs_write_lock_once+0x29/0x50
[<
c111ea2f>] reiserfs_delete_inode+0x9f/0x150
[<
c11b0d4f>] ? _atomic_dec_and_lock+0x4f/0x70
[<
c111e990>] ? reiserfs_delete_inode+0x0/0x150
[<
c10c9c32>] generic_delete_inode+0xa2/0x170
[<
c10c9d4f>] generic_drop_inode+0x4f/0x70
[<
c10c8b07>] iput+0x47/0x50
[<
c10c0965>] do_unlinkat+0xd5/0x160
[<
c1401098>] ? mutex_unlock+0x8/0x10
[<
c10c3e0d>] ? vfs_readdir+0x7d/0xb0
[<
c10c3af0>] ? filldir64+0x0/0xf0
[<
c1002ef3>] ? sysenter_exit+0xf/0x16
[<
c105cbe4>] ? trace_hardirqs_on_caller+0x124/0x170
[<
c10c0b13>] sys_unlinkat+0x23/0x40
[<
c1002ec4>] sysenter_do_call+0x12/0x32
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Frederic Weisbecker [Wed, 30 Dec 2009 06:26:28 +0000 (07:26 +0100)]
reiserfs: Fix journal mutex <-> inode mutex lock inversion
We need to relax the reiserfs lock before locking the inode mutex
from xattr_unlink(), otherwise we'll face the usual bad dependencies:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-atom #178
-------------------------------------------------------
rm/3202 is trying to acquire lock:
(&journal->j_mutex){+.+...}, at: [<
c113c234>] do_journal_begin_r+0x94/0x360
but task is already holding lock:
(&sb->s_type->i_mutex_key#4/2){+.+...}, at: [<
c1142a67>] xattr_unlink+0x57/0xb0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&sb->s_type->i_mutex_key#4/2){+.+...}:
[<
c105ea7f>] __lock_acquire+0x11ff/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c1401a7b>] mutex_lock_nested+0x5b/0x340
[<
c1142a67>] xattr_unlink+0x57/0xb0
[<
c1143179>] delete_one_xattr+0x29/0x100
[<
c11427bb>] reiserfs_for_each_xattr+0x10b/0x290
[<
c11429ba>] reiserfs_delete_xattrs+0x1a/0x60
[<
c111ea2f>] reiserfs_delete_inode+0x9f/0x150
[<
c10c9c32>] generic_delete_inode+0xa2/0x170
[<
c10c9d4f>] generic_drop_inode+0x4f/0x70
[<
c10c8b07>] iput+0x47/0x50
[<
c10c0965>] do_unlinkat+0xd5/0x160
[<
c10c0b13>] sys_unlinkat+0x23/0x40
[<
c1002ec4>] sysenter_do_call+0x12/0x32
-> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
[<
c105ea7f>] __lock_acquire+0x11ff/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c1401a7b>] mutex_lock_nested+0x5b/0x340
[<
c1143359>] reiserfs_write_lock+0x29/0x40
[<
c113c23c>] do_journal_begin_r+0x9c/0x360
[<
c113c680>] journal_begin+0x80/0x130
[<
c1127363>] reiserfs_remount+0x223/0x4e0
[<
c10b6dd6>] do_remount_sb+0xa6/0x140
[<
c10ce6a0>] do_mount+0x560/0x750
[<
c10ce914>] sys_mount+0x84/0xb0
[<
c1002ec4>] sysenter_do_call+0x12/0x32
-> #0 (&journal->j_mutex){+.+...}:
[<
c105f176>] __lock_acquire+0x18f6/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c1401a7b>] mutex_lock_nested+0x5b/0x340
[<
c113c234>] do_journal_begin_r+0x94/0x360
[<
c113c680>] journal_begin+0x80/0x130
[<
c1116d63>] reiserfs_unlink+0x83/0x2e0
[<
c1142a74>] xattr_unlink+0x64/0xb0
[<
c1143179>] delete_one_xattr+0x29/0x100
[<
c11427bb>] reiserfs_for_each_xattr+0x10b/0x290
[<
c11429ba>] reiserfs_delete_xattrs+0x1a/0x60
[<
c111ea2f>] reiserfs_delete_inode+0x9f/0x150
[<
c10c9c32>] generic_delete_inode+0xa2/0x170
[<
c10c9d4f>] generic_drop_inode+0x4f/0x70
[<
c10c8b07>] iput+0x47/0x50
[<
c10c0965>] do_unlinkat+0xd5/0x160
[<
c10c0b13>] sys_unlinkat+0x23/0x40
[<
c1002ec4>] sysenter_do_call+0x12/0x32
other info that might help us debug this:
2 locks held by rm/3202:
#0: (&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [<
c114274b>] reiserfs_for_each_xattr+0x9b/0x290
#1: (&sb->s_type->i_mutex_key#4/2){+.+...}, at: [<
c1142a67>] xattr_unlink+0x57/0xb0
stack backtrace:
Pid: 3202, comm: rm Not tainted 2.6.32-atom #178
Call Trace:
[<
c13ff9e3>] ? printk+0x18/0x1a
[<
c105d33a>] print_circular_bug+0xca/0xd0
[<
c105f176>] __lock_acquire+0x18f6/0x19e0
[<
c1142a67>] ? xattr_unlink+0x57/0xb0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c113c234>] ? do_journal_begin_r+0x94/0x360
[<
c113c234>] ? do_journal_begin_r+0x94/0x360
[<
c1401a7b>] mutex_lock_nested+0x5b/0x340
[<
c113c234>] ? do_journal_begin_r+0x94/0x360
[<
c113c234>] do_journal_begin_r+0x94/0x360
[<
c10411b6>] ? run_timer_softirq+0x1a6/0x220
[<
c103cb00>] ? __do_softirq+0x50/0x140
[<
c113c680>] journal_begin+0x80/0x130
[<
c103cba2>] ? __do_softirq+0xf2/0x140
[<
c104f72f>] ? hrtimer_interrupt+0xdf/0x220
[<
c1116d63>] reiserfs_unlink+0x83/0x2e0
[<
c105c932>] ? mark_held_locks+0x62/0x80
[<
c11b8d08>] ? trace_hardirqs_on_thunk+0xc/0x10
[<
c1002fd8>] ? restore_all_notrace+0x0/0x18
[<
c1142a67>] ? xattr_unlink+0x57/0xb0
[<
c1142a74>] xattr_unlink+0x64/0xb0
[<
c1143179>] delete_one_xattr+0x29/0x100
[<
c11427bb>] reiserfs_for_each_xattr+0x10b/0x290
[<
c1143150>] ? delete_one_xattr+0x0/0x100
[<
c1401cb9>] ? mutex_lock_nested+0x299/0x340
[<
c11429ba>] reiserfs_delete_xattrs+0x1a/0x60
[<
c1143309>] ? reiserfs_write_lock_once+0x29/0x50
[<
c111ea2f>] reiserfs_delete_inode+0x9f/0x150
[<
c11b0d1f>] ? _atomic_dec_and_lock+0x4f/0x70
[<
c111e990>] ? reiserfs_delete_inode+0x0/0x150
[<
c10c9c32>] generic_delete_inode+0xa2/0x170
[<
c10c9d4f>] generic_drop_inode+0x4f/0x70
[<
c10c8b07>] iput+0x47/0x50
[<
c10c0965>] do_unlinkat+0xd5/0x160
[<
c1401068>] ? mutex_unlock+0x8/0x10
[<
c10c3e0d>] ? vfs_readdir+0x7d/0xb0
[<
c10c3af0>] ? filldir64+0x0/0xf0
[<
c1002ef3>] ? sysenter_exit+0xf/0x16
[<
c105cbe4>] ? trace_hardirqs_on_caller+0x124/0x170
[<
c10c0b13>] sys_unlinkat+0x23/0x40
[<
c1002ec4>] sysenter_do_call+0x12/0x32
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Frederic Weisbecker [Wed, 30 Dec 2009 06:12:03 +0000 (07:12 +0100)]
reiserfs: Fix unwanted recursive reiserfs lock in reiserfs_unlink()
reiserfs_unlink() may or may not be called under the reiserfs
lock.
But it also takes the reiserfs lock and can then acquire it
recursively which leads to do_journal_begin_r() that fails to
relax the reiserfs lock before grabbing the journal mutex,
creating an unexpected lock inversion.
We need to ensure reiserfs_unlink() won't get the reiserfs lock
recursively using reiserfs_write_lock_once().
This fixes the following warning that precedes a lock inversion
report (reiserfs lock <-> journal mutex).
------------[ cut here ]------------
WARNING: at fs/reiserfs/lock.c:95 reiserfs_lock_check_recursive+0x3a/0x50()
Hardware name: MS-7418
Unwanted recursive reiserfs lock!
Pid: 3208, comm: dbench Not tainted 2.6.32-atom #177
Call Trace:
[<
c114327a>] ? reiserfs_lock_check_recursive+0x3a/0x50
[<
c114327a>] ? reiserfs_lock_check_recursive+0x3a/0x50
[<
c10373a7>] warn_slowpath_common+0x67/0xc0
[<
c114327a>] ? reiserfs_lock_check_recursive+0x3a/0x50
[<
c1037446>] warn_slowpath_fmt+0x26/0x30
[<
c114327a>] reiserfs_lock_check_recursive+0x3a/0x50
[<
c113c213>] do_journal_begin_r+0x83/0x360
[<
c105eb16>] ? __lock_acquire+0x1296/0x19e0
[<
c1142a57>] ? xattr_unlink+0x57/0xb0
[<
c113c670>] journal_begin+0x80/0x130
[<
c1116d5d>] reiserfs_unlink+0x7d/0x2d0
[<
c1142a57>] ? xattr_unlink+0x57/0xb0
[<
c1142a57>] ? xattr_unlink+0x57/0xb0
[<
c1142a57>] ? xattr_unlink+0x57/0xb0
[<
c1142a64>] xattr_unlink+0x64/0xb0
[<
c1143169>] delete_one_xattr+0x29/0x100
[<
c11427ab>] reiserfs_for_each_xattr+0x10b/0x290
[<
c1143140>] ? delete_one_xattr+0x0/0x100
[<
c1401ca9>] ? mutex_lock_nested+0x299/0x340
[<
c11429aa>] reiserfs_delete_xattrs+0x1a/0x60
[<
c11432f9>] ? reiserfs_write_lock_once+0x29/0x50
[<
c111ea1f>] reiserfs_delete_inode+0x9f/0x150
[<
c11b0d0f>] ? _atomic_dec_and_lock+0x4f/0x70
[<
c111e980>] ? reiserfs_delete_inode+0x0/0x150
[<
c10c9c32>] generic_delete_inode+0xa2/0x170
[<
c10c9d4f>] generic_drop_inode+0x4f/0x70
[<
c10c8b07>] iput+0x47/0x50
[<
c10c0965>] do_unlinkat+0xd5/0x160
[<
c10505c6>] ? up_read+0x16/0x30
[<
c1022ab7>] ? do_page_fault+0x187/0x330
[<
c1002fd8>] ? restore_all_notrace+0x0/0x18
[<
c1022930>] ? do_page_fault+0x0/0x330
[<
c105cbe4>] ? trace_hardirqs_on_caller+0x124/0x170
[<
c10c0a00>] sys_unlink+0x10/0x20
[<
c1002ec4>] sysenter_do_call+0x12/0x32
---[ end trace
2e35d71a6cc69d0c ]---
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Frederic Weisbecker [Wed, 30 Dec 2009 06:03:53 +0000 (07:03 +0100)]
reiserfs: Relax lock before open xattr dir in reiserfs_xattr_set_handle()
We call xattr_lookup() from reiserfs_xattr_get(). We then hold
the reiserfs lock when we grab the i_mutex. But later, we may
relax the reiserfs lock, creating dependency inversion between
both locks.
The lookups and creation jobs ar already protected by the
inode mutex, so we can safely relax the reiserfs lock, dropping
the unwanted reiserfs lock -> i_mutex dependency, as shown
in the following lockdep report:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-atom #173
-------------------------------------------------------
cp/3204 is trying to acquire lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [<
c11432b9>] reiserfs_write_lock_once+0x29/0x50
but task is already holding lock:
(&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [<
c1141e18>] open_xa_dir+0xd8/0x1b0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#4/3){+.+.+.}:
[<
c105ea7f>] __lock_acquire+0x11ff/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c1401a2b>] mutex_lock_nested+0x5b/0x340
[<
c1141d83>] open_xa_dir+0x43/0x1b0
[<
c1142722>] reiserfs_for_each_xattr+0x62/0x260
[<
c114299a>] reiserfs_delete_xattrs+0x1a/0x60
[<
c111ea1f>] reiserfs_delete_inode+0x9f/0x150
[<
c10c9c32>] generic_delete_inode+0xa2/0x170
[<
c10c9d4f>] generic_drop_inode+0x4f/0x70
[<
c10c8b07>] iput+0x47/0x50
[<
c10c0965>] do_unlinkat+0xd5/0x160
[<
c10c0a00>] sys_unlink+0x10/0x20
[<
c1002ec4>] sysenter_do_call+0x12/0x32
-> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[<
c105f176>] __lock_acquire+0x18f6/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c1401a2b>] mutex_lock_nested+0x5b/0x340
[<
c11432b9>] reiserfs_write_lock_once+0x29/0x50
[<
c1117012>] reiserfs_lookup+0x62/0x140
[<
c10bd85f>] __lookup_hash+0xef/0x110
[<
c10bf21d>] lookup_one_len+0x8d/0xc0
[<
c1141e2a>] open_xa_dir+0xea/0x1b0
[<
c1141fe5>] xattr_lookup+0x15/0x160
[<
c1142476>] reiserfs_xattr_get+0x56/0x2a0
[<
c1144042>] reiserfs_get_acl+0xa2/0x360
[<
c114461a>] reiserfs_cache_default_acl+0x3a/0x160
[<
c111789c>] reiserfs_mkdir+0x6c/0x2c0
[<
c10bea96>] vfs_mkdir+0xd6/0x180
[<
c10c0c10>] sys_mkdirat+0xc0/0xd0
[<
c10c0c40>] sys_mkdir+0x20/0x30
[<
c1002ec4>] sysenter_do_call+0x12/0x32
other info that might help us debug this:
2 locks held by cp/3204:
#0: (&sb->s_type->i_mutex_key#4/1){+.+.+.}, at: [<
c10bd8d6>] lookup_create+0x26/0xa0
#1: (&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [<
c1141e18>] open_xa_dir+0xd8/0x1b0
stack backtrace:
Pid: 3204, comm: cp Not tainted 2.6.32-atom #173
Call Trace:
[<
c13ff993>] ? printk+0x18/0x1a
[<
c105d33a>] print_circular_bug+0xca/0xd0
[<
c105f176>] __lock_acquire+0x18f6/0x19e0
[<
c105d3aa>] ? check_usage+0x6a/0x460
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c11432b9>] ? reiserfs_write_lock_once+0x29/0x50
[<
c11432b9>] ? reiserfs_write_lock_once+0x29/0x50
[<
c1401a2b>] mutex_lock_nested+0x5b/0x340
[<
c11432b9>] ? reiserfs_write_lock_once+0x29/0x50
[<
c11432b9>] reiserfs_write_lock_once+0x29/0x50
[<
c1117012>] reiserfs_lookup+0x62/0x140
[<
c105ccca>] ? debug_check_no_locks_freed+0x8a/0x140
[<
c105cbe4>] ? trace_hardirqs_on_caller+0x124/0x170
[<
c10bd85f>] __lookup_hash+0xef/0x110
[<
c10bf21d>] lookup_one_len+0x8d/0xc0
[<
c1141e2a>] open_xa_dir+0xea/0x1b0
[<
c1141fe5>] xattr_lookup+0x15/0x160
[<
c1142476>] reiserfs_xattr_get+0x56/0x2a0
[<
c1144042>] reiserfs_get_acl+0xa2/0x360
[<
c10ca2e7>] ? new_inode+0x27/0xa0
[<
c114461a>] reiserfs_cache_default_acl+0x3a/0x160
[<
c1402eb7>] ? _spin_unlock+0x27/0x40
[<
c111789c>] reiserfs_mkdir+0x6c/0x2c0
[<
c10c7cb8>] ? __d_lookup+0x108/0x190
[<
c105c932>] ? mark_held_locks+0x62/0x80
[<
c1401c8d>] ? mutex_lock_nested+0x2bd/0x340
[<
c10bd17a>] ? generic_permission+0x1a/0xa0
[<
c11788fe>] ? security_inode_permission+0x1e/0x20
[<
c10bea96>] vfs_mkdir+0xd6/0x180
[<
c10c0c10>] sys_mkdirat+0xc0/0xd0
[<
c10505c6>] ? up_read+0x16/0x30
[<
c1002fd8>] ? restore_all_notrace+0x0/0x18
[<
c10c0c40>] sys_mkdir+0x20/0x30
[<
c1002ec4>] sysenter_do_call+0x12/0x32
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Frederic Weisbecker [Wed, 30 Dec 2009 04:56:08 +0000 (05:56 +0100)]
reiserfs: Relax reiserfs lock while freeing the journal
Keeping the reiserfs lock while freeing the journal on
umount path triggers a lock inversion between bdev->bd_mutex
and the reiserfs lock.
We don't need the reiserfs lock at this stage. The filesystem
is not usable anymore, and there are no more pending commits,
everything got flushed (even this operation was done in parallel
and didn't required the reiserfs lock from the current process).
This fixes the following lockdep report:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-atom #172
-------------------------------------------------------
umount/3904 is trying to acquire lock:
(&bdev->bd_mutex){+.+.+.}, at: [<
c10de2c2>] __blkdev_put+0x22/0x160
but task is already holding lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [<
c1143279>] reiserfs_write_lock+0x29/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&REISERFS_SB(s)->lock){+.+.+.}:
[<
c105ea7f>] __lock_acquire+0x11ff/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c140199b>] mutex_lock_nested+0x5b/0x340
[<
c1143229>] reiserfs_write_lock_once+0x29/0x50
[<
c111c485>] reiserfs_get_block+0x85/0x1620
[<
c10e1040>] do_mpage_readpage+0x1f0/0x6d0
[<
c10e1640>] mpage_readpages+0xc0/0x100
[<
c1119b89>] reiserfs_readpages+0x19/0x20
[<
c108f1ec>] __do_page_cache_readahead+0x1bc/0x260
[<
c108f2b8>] ra_submit+0x28/0x40
[<
c1087e3e>] filemap_fault+0x40e/0x420
[<
c109b5fd>] __do_fault+0x3d/0x430
[<
c109d47e>] handle_mm_fault+0x12e/0x790
[<
c1022a65>] do_page_fault+0x135/0x330
[<
c1403663>] error_code+0x6b/0x70
[<
c10ef9ca>] load_elf_binary+0x82a/0x1a10
[<
c10ba130>] search_binary_handler+0x90/0x1d0
[<
c10bb70f>] do_execve+0x1df/0x250
[<
c1001746>] sys_execve+0x46/0x70
[<
c1002fa5>] syscall_call+0x7/0xb
-> #2 (&mm->mmap_sem){++++++}:
[<
c105ea7f>] __lock_acquire+0x11ff/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c109b1ab>] might_fault+0x8b/0xb0
[<
c11b8f52>] copy_to_user+0x32/0x70
[<
c10c3b94>] filldir64+0xa4/0xf0
[<
c1109116>] sysfs_readdir+0x116/0x210
[<
c10c3e1d>] vfs_readdir+0x8d/0xb0
[<
c10c3ea9>] sys_getdents64+0x69/0xb0
[<
c1002ec4>] sysenter_do_call+0x12/0x32
-> #1 (sysfs_mutex){+.+.+.}:
[<
c105ea7f>] __lock_acquire+0x11ff/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c140199b>] mutex_lock_nested+0x5b/0x340
[<
c110951c>] sysfs_addrm_start+0x2c/0xb0
[<
c1109aa0>] create_dir+0x40/0x90
[<
c1109b1b>] sysfs_create_dir+0x2b/0x50
[<
c11b2352>] kobject_add_internal+0xc2/0x1b0
[<
c11b2531>] kobject_add_varg+0x31/0x50
[<
c11b25ac>] kobject_add+0x2c/0x60
[<
c1258294>] device_add+0x94/0x560
[<
c11036ea>] add_partition+0x18a/0x2a0
[<
c110418a>] rescan_partitions+0x33a/0x450
[<
c10de5bf>] __blkdev_get+0x12f/0x2d0
[<
c10de76a>] blkdev_get+0xa/0x10
[<
c11034b8>] register_disk+0x108/0x130
[<
c11a87a9>] add_disk+0xd9/0x130
[<
c12998e5>] sd_probe_async+0x105/0x1d0
[<
c10528af>] async_thread+0xcf/0x230
[<
c104bfd4>] kthread+0x74/0x80
[<
c1003aab>] kernel_thread_helper+0x7/0x3c
-> #0 (&bdev->bd_mutex){+.+.+.}:
[<
c105f176>] __lock_acquire+0x18f6/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c140199b>] mutex_lock_nested+0x5b/0x340
[<
c10de2c2>] __blkdev_put+0x22/0x160
[<
c10de40a>] blkdev_put+0xa/0x10
[<
c113ce22>] free_journal_ram+0xd2/0x130
[<
c113ea18>] do_journal_release+0x98/0x190
[<
c113eb2a>] journal_release+0xa/0x10
[<
c1128eb6>] reiserfs_put_super+0x36/0x130
[<
c10b776f>] generic_shutdown_super+0x4f/0xe0
[<
c10b7825>] kill_block_super+0x25/0x40
[<
c11255df>] reiserfs_kill_sb+0x7f/0x90
[<
c10b7f4a>] deactivate_super+0x7a/0x90
[<
c10cccd8>] mntput_no_expire+0x98/0xd0
[<
c10ccfcc>] sys_umount+0x4c/0x310
[<
c10cd2a9>] sys_oldumount+0x19/0x20
[<
c1002ec4>] sysenter_do_call+0x12/0x32
other info that might help us debug this:
2 locks held by umount/3904:
#0: (&type->s_umount_key#30){+++++.}, at: [<
c10b7f45>] deactivate_super+0x75/0x90
#1: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<
c1143279>] reiserfs_write_lock+0x29/0x40
stack backtrace:
Pid: 3904, comm: umount Not tainted 2.6.32-atom #172
Call Trace:
[<
c13ff903>] ? printk+0x18/0x1a
[<
c105d33a>] print_circular_bug+0xca/0xd0
[<
c105f176>] __lock_acquire+0x18f6/0x19e0
[<
c108b66f>] ? free_pcppages_bulk+0x1f/0x250
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c10de2c2>] ? __blkdev_put+0x22/0x160
[<
c10de2c2>] ? __blkdev_put+0x22/0x160
[<
c140199b>] mutex_lock_nested+0x5b/0x340
[<
c10de2c2>] ? __blkdev_put+0x22/0x160
[<
c105c932>] ? mark_held_locks+0x62/0x80
[<
c10afe12>] ? kfree+0x92/0xd0
[<
c10de2c2>] __blkdev_put+0x22/0x160
[<
c105cc3b>] ? trace_hardirqs_on+0xb/0x10
[<
c10de40a>] blkdev_put+0xa/0x10
[<
c113ce22>] free_journal_ram+0xd2/0x130
[<
c113ea18>] do_journal_release+0x98/0x190
[<
c113eb2a>] journal_release+0xa/0x10
[<
c1128eb6>] reiserfs_put_super+0x36/0x130
[<
c1050596>] ? up_write+0x16/0x30
[<
c10b776f>] generic_shutdown_super+0x4f/0xe0
[<
c10b7825>] kill_block_super+0x25/0x40
[<
c10f41e0>] ? vfs_quota_off+0x0/0x20
[<
c11255df>] reiserfs_kill_sb+0x7f/0x90
[<
c10b7f4a>] deactivate_super+0x7a/0x90
[<
c10cccd8>] mntput_no_expire+0x98/0xd0
[<
c10ccfcc>] sys_umount+0x4c/0x310
[<
c10cd2a9>] sys_oldumount+0x19/0x20
[<
c1002ec4>] sysenter_do_call+0x12/0x32
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Frederic Weisbecker [Wed, 30 Dec 2009 04:06:21 +0000 (05:06 +0100)]
reiserfs: Fix reiserfs lock <-> i_mutex dependency inversion on xattr
While deleting the xattrs of an inode, we hold the reiserfs lock
and grab the inode->i_mutex of the targeted inode and the root
private xattr directory.
Later on, we may relax the reiserfs lock for various reasons, this
creates inverted dependencies.
We can remove the reiserfs lock -> i_mutex dependency by relaxing
the former before calling open_xa_dir(). This is fine because the
lookup and creation of xattr private directories done in
open_xa_dir() are covered by the targeted inode mutexes. And deeper
operations in the tree are still done under the write lock.
This fixes the following lockdep report:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-atom #173
-------------------------------------------------------
cp/3204 is trying to acquire lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [<
c11432b9>] reiserfs_write_lock_once+0x29/0x50
but task is already holding lock:
(&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [<
c1141e18>] open_xa_dir+0xd8/0x1b0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#4/3){+.+.+.}:
[<
c105ea7f>] __lock_acquire+0x11ff/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c1401a2b>] mutex_lock_nested+0x5b/0x340
[<
c1141d83>] open_xa_dir+0x43/0x1b0
[<
c1142722>] reiserfs_for_each_xattr+0x62/0x260
[<
c114299a>] reiserfs_delete_xattrs+0x1a/0x60
[<
c111ea1f>] reiserfs_delete_inode+0x9f/0x150
[<
c10c9c32>] generic_delete_inode+0xa2/0x170
[<
c10c9d4f>] generic_drop_inode+0x4f/0x70
[<
c10c8b07>] iput+0x47/0x50
[<
c10c0965>] do_unlinkat+0xd5/0x160
[<
c10c0a00>] sys_unlink+0x10/0x20
[<
c1002ec4>] sysenter_do_call+0x12/0x32
-> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[<
c105f176>] __lock_acquire+0x18f6/0x19e0
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c1401a2b>] mutex_lock_nested+0x5b/0x340
[<
c11432b9>] reiserfs_write_lock_once+0x29/0x50
[<
c1117012>] reiserfs_lookup+0x62/0x140
[<
c10bd85f>] __lookup_hash+0xef/0x110
[<
c10bf21d>] lookup_one_len+0x8d/0xc0
[<
c1141e2a>] open_xa_dir+0xea/0x1b0
[<
c1141fe5>] xattr_lookup+0x15/0x160
[<
c1142476>] reiserfs_xattr_get+0x56/0x2a0
[<
c1144042>] reiserfs_get_acl+0xa2/0x360
[<
c114461a>] reiserfs_cache_default_acl+0x3a/0x160
[<
c111789c>] reiserfs_mkdir+0x6c/0x2c0
[<
c10bea96>] vfs_mkdir+0xd6/0x180
[<
c10c0c10>] sys_mkdirat+0xc0/0xd0
[<
c10c0c40>] sys_mkdir+0x20/0x30
[<
c1002ec4>] sysenter_do_call+0x12/0x32
other info that might help us debug this:
2 locks held by cp/3204:
#0: (&sb->s_type->i_mutex_key#4/1){+.+.+.}, at: [<
c10bd8d6>] lookup_create+0x26/0xa0
#1: (&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [<
c1141e18>] open_xa_dir+0xd8/0x1b0
stack backtrace:
Pid: 3204, comm: cp Not tainted 2.6.32-atom #173
Call Trace:
[<
c13ff993>] ? printk+0x18/0x1a
[<
c105d33a>] print_circular_bug+0xca/0xd0
[<
c105f176>] __lock_acquire+0x18f6/0x19e0
[<
c105d3aa>] ? check_usage+0x6a/0x460
[<
c105f2c8>] lock_acquire+0x68/0x90
[<
c11432b9>] ? reiserfs_write_lock_once+0x29/0x50
[<
c11432b9>] ? reiserfs_write_lock_once+0x29/0x50
[<
c1401a2b>] mutex_lock_nested+0x5b/0x340
[<
c11432b9>] ? reiserfs_write_lock_once+0x29/0x50
[<
c11432b9>] reiserfs_write_lock_once+0x29/0x50
[<
c1117012>] reiserfs_lookup+0x62/0x140
[<
c105ccca>] ? debug_check_no_locks_freed+0x8a/0x140
[<
c105cbe4>] ? trace_hardirqs_on_caller+0x124/0x170
[<
c10bd85f>] __lookup_hash+0xef/0x110
[<
c10bf21d>] lookup_one_len+0x8d/0xc0
[<
c1141e2a>] open_xa_dir+0xea/0x1b0
[<
c1141fe5>] xattr_lookup+0x15/0x160
[<
c1142476>] reiserfs_xattr_get+0x56/0x2a0
[<
c1144042>] reiserfs_get_acl+0xa2/0x360
[<
c10ca2e7>] ? new_inode+0x27/0xa0
[<
c114461a>] reiserfs_cache_default_acl+0x3a/0x160
[<
c1402eb7>] ? _spin_unlock+0x27/0x40
[<
c111789c>] reiserfs_mkdir+0x6c/0x2c0
[<
c10c7cb8>] ? __d_lookup+0x108/0x190
[<
c105c932>] ? mark_held_locks+0x62/0x80
[<
c1401c8d>] ? mutex_lock_nested+0x2bd/0x340
[<
c10bd17a>] ? generic_permission+0x1a/0xa0
[<
c11788fe>] ? security_inode_permission+0x1e/0x20
[<
c10bea96>] vfs_mkdir+0xd6/0x180
[<
c10c0c10>] sys_mkdirat+0xc0/0xd0
[<
c10505c6>] ? up_read+0x16/0x30
[<
c1002fd8>] ? restore_all_notrace+0x0/0x18
[<
c10c0c40>] sys_mkdir+0x20/0x30
[<
c1002ec4>] sysenter_do_call+0x12/0x32
v2: Don't drop reiserfs_mutex_lock_nested_safe() as we'll still
need it later
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Frederic Weisbecker [Wed, 30 Dec 2009 02:20:19 +0000 (03:20 +0100)]
reiserfs: Warn on lock relax if taken recursively
When we relax the reiserfs lock to avoid creating unwanted
dependencies against others locks while grabbing these,
we want to ensure it has not been taken recursively, otherwise
the lock won't be really relaxed. Only its depth will be decreased.
The unwanted dependency would then actually happen.
To prevent from that, add a reiserfs_lock_check_recursive() call
in the places that need it.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Frederic Weisbecker [Tue, 29 Dec 2009 23:39:22 +0000 (00:39 +0100)]
reiserfs: Fix reiserfs lock <-> i_xattr_sem dependency inversion
i_xattr_sem depends on the reiserfs lock. But after we grab
i_xattr_sem, we may relax/relock the reiserfs lock while waiting
on a freezed filesystem, creating a dependency inversion between
the two locks.
In order to avoid the i_xattr_sem -> reiserfs lock dependency, let's
create a reiserfs_down_read_safe() that acts like
reiserfs_mutex_lock_safe(): relax the reiserfs lock while grabbing
another lock to avoid undesired dependencies induced by the
heivyweight reiserfs lock.
This fixes the following warning:
[ 990.005931] =======================================================
[ 990.012373] [ INFO: possible circular locking dependency detected ]
[ 990.013233] 2.6.33-rc1 #1
[ 990.013233] -------------------------------------------------------
[ 990.013233] dbench/1891 is trying to acquire lock:
[ 990.013233] (&REISERFS_SB(s)->lock){+.+.+.}, at: [<
ffffffff81159505>] reiserfs_write_lock+0x35/0x50
[ 990.013233]
[ 990.013233] but task is already holding lock:
[ 990.013233] (&REISERFS_I(inode)->i_xattr_sem){+.+.+.}, at: [<
ffffffff8115899a>] reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233]
[ 990.013233] which lock already depends on the new lock.
[ 990.013233]
[ 990.013233]
[ 990.013233] the existing dependency chain (in reverse order) is:
[ 990.013233]
[ 990.013233] -> #1 (&REISERFS_I(inode)->i_xattr_sem){+.+.+.}:
[ 990.013233] [<
ffffffff81063afc>] __lock_acquire+0xf9c/0x1560
[ 990.013233] [<
ffffffff8106414f>] lock_acquire+0x8f/0xb0
[ 990.013233] [<
ffffffff814ac194>] down_write+0x44/0x80
[ 990.013233] [<
ffffffff8115899a>] reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233] [<
ffffffff81158e30>] reiserfs_xattr_set+0xb0/0x150
[ 990.013233] [<
ffffffff8115a6aa>] user_set+0x8a/0x90
[ 990.013233] [<
ffffffff8115901a>] reiserfs_setxattr+0xaa/0xb0
[ 990.013233] [<
ffffffff810e2596>] __vfs_setxattr_noperm+0x36/0xa0
[ 990.013233] [<
ffffffff810e26bc>] vfs_setxattr+0xbc/0xc0
[ 990.013233] [<
ffffffff810e2780>] setxattr+0xc0/0x150
[ 990.013233] [<
ffffffff810e289d>] sys_fsetxattr+0x8d/0xa0
[ 990.013233] [<
ffffffff81002dab>] system_call_fastpath+0x16/0x1b
[ 990.013233]
[ 990.013233] -> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[ 990.013233] [<
ffffffff81063e30>] __lock_acquire+0x12d0/0x1560
[ 990.013233] [<
ffffffff8106414f>] lock_acquire+0x8f/0xb0
[ 990.013233] [<
ffffffff814aba77>] __mutex_lock_common+0x47/0x3b0
[ 990.013233] [<
ffffffff814abebe>] mutex_lock_nested+0x3e/0x50
[ 990.013233] [<
ffffffff81159505>] reiserfs_write_lock+0x35/0x50
[ 990.013233] [<
ffffffff811340e5>] reiserfs_prepare_write+0x45/0x180
[ 990.013233] [<
ffffffff81158bb6>] reiserfs_xattr_set_handle+0x2a6/0x470
[ 990.013233] [<
ffffffff81158e30>] reiserfs_xattr_set+0xb0/0x150
[ 990.013233] [<
ffffffff8115a6aa>] user_set+0x8a/0x90
[ 990.013233] [<
ffffffff8115901a>] reiserfs_setxattr+0xaa/0xb0
[ 990.013233] [<
ffffffff810e2596>] __vfs_setxattr_noperm+0x36/0xa0
[ 990.013233] [<
ffffffff810e26bc>] vfs_setxattr+0xbc/0xc0
[ 990.013233] [<
ffffffff810e2780>] setxattr+0xc0/0x150
[ 990.013233] [<
ffffffff810e289d>] sys_fsetxattr+0x8d/0xa0
[ 990.013233] [<
ffffffff81002dab>] system_call_fastpath+0x16/0x1b
[ 990.013233]
[ 990.013233] other info that might help us debug this:
[ 990.013233]
[ 990.013233] 2 locks held by dbench/1891:
[ 990.013233] #0: (&sb->s_type->i_mutex_key#12){+.+.+.}, at: [<
ffffffff810e2678>] vfs_setxattr+0x78/0xc0
[ 990.013233] #1: (&REISERFS_I(inode)->i_xattr_sem){+.+.+.}, at: [<
ffffffff8115899a>] reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233]
[ 990.013233] stack backtrace:
[ 990.013233] Pid: 1891, comm: dbench Not tainted 2.6.33-rc1 #1
[ 990.013233] Call Trace:
[ 990.013233] [<
ffffffff81061639>] print_circular_bug+0xe9/0xf0
[ 990.013233] [<
ffffffff81063e30>] __lock_acquire+0x12d0/0x1560
[ 990.013233] [<
ffffffff8115899a>] ? reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233] [<
ffffffff8106414f>] lock_acquire+0x8f/0xb0
[ 990.013233] [<
ffffffff81159505>] ? reiserfs_write_lock+0x35/0x50
[ 990.013233] [<
ffffffff8115899a>] ? reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233] [<
ffffffff814aba77>] __mutex_lock_common+0x47/0x3b0
[ 990.013233] [<
ffffffff81159505>] ? reiserfs_write_lock+0x35/0x50
[ 990.013233] [<
ffffffff81159505>] ? reiserfs_write_lock+0x35/0x50
[ 990.013233] [<
ffffffff81062592>] ? mark_held_locks+0x72/0xa0
[ 990.013233] [<
ffffffff814ab81d>] ? __mutex_unlock_slowpath+0xbd/0x140
[ 990.013233] [<
ffffffff810628ad>] ? trace_hardirqs_on_caller+0x14d/0x1a0
[ 990.013233] [<
ffffffff814abebe>] mutex_lock_nested+0x3e/0x50
[ 990.013233] [<
ffffffff81159505>] reiserfs_write_lock+0x35/0x50
[ 990.013233] [<
ffffffff811340e5>] reiserfs_prepare_write+0x45/0x180
[ 990.013233] [<
ffffffff81158bb6>] reiserfs_xattr_set_handle+0x2a6/0x470
[ 990.013233] [<
ffffffff81158e30>] reiserfs_xattr_set+0xb0/0x150
[ 990.013233] [<
ffffffff814abcb4>] ? __mutex_lock_common+0x284/0x3b0
[ 990.013233] [<
ffffffff8115a6aa>] user_set+0x8a/0x90
[ 990.013233] [<
ffffffff8115901a>] reiserfs_setxattr+0xaa/0xb0
[ 990.013233] [<
ffffffff810e2596>] __vfs_setxattr_noperm+0x36/0xa0
[ 990.013233] [<
ffffffff810e26bc>] vfs_setxattr+0xbc/0xc0
[ 990.013233] [<
ffffffff810e2780>] setxattr+0xc0/0x150
[ 990.013233] [<
ffffffff81056018>] ? sched_clock_cpu+0xb8/0x100
[ 990.013233] [<
ffffffff8105eded>] ? trace_hardirqs_off+0xd/0x10
[ 990.013233] [<
ffffffff810560a3>] ? cpu_clock+0x43/0x50
[ 990.013233] [<
ffffffff810c6820>] ? fget+0xb0/0x110
[ 990.013233] [<
ffffffff810c6770>] ? fget+0x0/0x110
[ 990.013233] [<
ffffffff81002ddc>] ? sysret_check+0x27/0x62
[ 990.013233] [<
ffffffff810e289d>] sys_fsetxattr+0x8d/0xa0
[ 990.013233] [<
ffffffff81002dab>] system_call_fastpath+0x16/0x1b
Reported-and-tested-by: Christian Kujau <lists@nerdbynature.de>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Linus Torvalds [Fri, 1 Jan 2010 01:26:05 +0000 (17:26 -0800)]
twl4030-irq.c: fix compiler warning due to raw-spinlock conversion
Commit
239007b844 ("genirq: Convert irq_desc.lock to raw_spinlock")
seems to have missed this driver, leaving it to use the normal spin-lock
functions for the irq descriptor lock, which is now a raw lock.
Reported-and-compile-tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Fri, 1 Jan 2010 00:44:43 +0000 (16:44 -0800)]
pci: avoid compiler warning in quirks.c
Introduced by commit
5b889bf23 ("PCI: Fix build if quirks are not
enabled"), which made the pci_dev_reset_methods[] array static and
'const', but didn't then change the code to match, and use a const
pointer when moving it to quirks.c.
Trivially fixed by just adding the required 'const' to the iterator
variable.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Thu, 31 Dec 2009 23:17:26 +0000 (15:17 -0800)]
Merge git://git./linux/kernel/git/sfrench/cifs-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6:
[CIFS] Enable mmap on forcedirectio mounts
cifs: NULL out tcon, pSesInfo, and srvTcp pointers when chasing DFS referrals
Linus Torvalds [Thu, 31 Dec 2009 20:01:24 +0000 (12:01 -0800)]
Merge branch 'for-linus' of git://git./linux/kernel/git/ieee1394/linux1394-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire, ieee1394: update Kconfig help
firewire, ieee1394: update MAINTAINERS entries
firewire: ohci: always use packet-per-buffer mode for isochronous reception
firewire: cdev: fix another memory leak in an error path
firewire: fix use of multiple AV/C devices, allow multiple FCP listeners
Comments from Stefan:
Distributors who still ship the old stack (ieee1394, ohci1394,
raw1394, sbp2, eth1394 and more) should now switch to the new one
(firewire-core, firewire-ohci, firewire-sbp2, firewire-net). In the
first iteration, those distributors might want to ship the old stack
also (but blacklisted) as a fallback for their users if unforeseen
problems with the newer replacement drivers are encountered.
The older FireWire stack contains several known problems which are
not going to be fixed; instead, those issues are addressed by the new
stack. An incomplete list of these issues is kept in bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=10046
We have a guide on migration from the older to the newer stack:
http://ieee1394.wiki.kernel.org/index.php/Juju_Migration
Rafael J. Wysocki [Thu, 31 Dec 2009 18:06:35 +0000 (19:06 +0100)]
PCI: Fix build if quirks are not enabled
After commit
b9c3b266411d27f1a6466c19d146d08db576bfea ("PCI: support
device-specific reset methods") the kernel build is broken if
CONFIG_PCI_QUIRKS is unset.
Fix this by moving pci_dev_specific_reset() to drivers/pci/quirks.c and
providing an empty replacement for !CONFIG_PCI_QUIRKS builds.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Thu, 31 Dec 2009 19:57:35 +0000 (11:57 -0800)]
Merge branch 'x86-fixes-for-linus-2' of git://git./linux/kernel/git/tip/linux-2.6-tip
* 'x86-fixes-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
dma-debug: Fix bug causing build warning
Linus Torvalds [Thu, 31 Dec 2009 19:56:24 +0000 (11:56 -0800)]
Merge branch 'perf-fixes-for-linus-2' of git://git./linux/kernel/git/tip/linux-2.6-tip
* 'perf-fixes-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
perf: Fix NULL deref in inheritance code
perf: Pass appropriate frame pointer to dump_trace()
Linus Torvalds [Thu, 31 Dec 2009 19:54:13 +0000 (11:54 -0800)]
Merge branch 'x86-fixes-for-linus' of git://git./linux/kernel/git/tip/linux-2.6-tip
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86/agp: Fix agp_amd64_init() initialization with CONFIG_GART_IOMMU enabled
x86: SGI UV: Fix writes to led registers on remote uv hubs
x86, kmemcheck: Use KERN_WARNING for error reporting
x86: Use KERN_DEFAULT log-level in __show_regs()
x86, compress: Force i386 instructions for the decompressor
x86/amd-iommu: Fix initialization failure panic
dma-debug: Do not add notifier when dma debugging is disabled.
x86: Fix objdump version check in chkobjdump.awk for different formats.
Trivial conflicts in arch/x86/include/asm/uv/uv_hub.h due to me having
applied an earlier version of an SGI UV fix.
Linus Torvalds [Thu, 31 Dec 2009 19:52:24 +0000 (11:52 -0800)]
Merge branch 'perf-fixes-for-linus' of git://git./linux/kernel/git/tip/linux-2.6-tip
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
perf kmem: Fix statistics typo
kprobes: Fix distinct type warning
perf: Rename perf_event_hw_event in design document
perf tools: Add missing header files to LIB_H Makefile variable
perf record: We should fork only if a program was specified to run
perf diff: Fix usage array, it must end with a NULL entry
Linus Torvalds [Thu, 31 Dec 2009 19:52:01 +0000 (11:52 -0800)]
Merge branch 'tracing-fixes-for-linus' of git://git./linux/kernel/git/tip/linux-2.6-tip
* 'tracing-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
tracing: Fix sign fields in ftrace_define_fields_##call()
tracing/syscalls: Fix typo in SYSCALL_DEFINE0
tracing/kprobe: Show sign of fields in trace_kprobe format files
ksym_tracer: Remove trace_stat
ksym_tracer: Fix race when incrementing count
ksym_tracer: Fix to allow writing newline to ksym_trace_filter
ksym_tracer: Fix to make the tracer work
tracing: Kconfig spelling fixes and cleanups
tracing: Fix setting tracer specific options
Documentation: Update ftrace-design.txt
Documentation: Update tracepoint-analysis.txt
Documentation: Update mmiotrace.txt
Linus Torvalds [Thu, 31 Dec 2009 19:12:35 +0000 (11:12 -0800)]
Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: iforce - wait for command completion when closing the device
Input: twl4030-pwrbutton - switch to using threaded IRQ
Input: twl4030_keypad - switch to using threaded IRQ
Input: lifebook - add CONFIG_DMI dependency
Input: wistron - fix test for CONFIG_PM
Input: psmouse - fix compile warning in hgpk module
Input: matrix-keypad - handle cases when GPIOs can't be wakeup sources
Input: iforce - fix oops on device disconnect
Input: ff-memless - add notion of direction to for rumble effects
Input: ff-memless - another fix for signed to unsigned overflow
Input: ff-memless - start playing FF effects immediately
Input: serio - do not mark kseriod freezable anymore
Input: speed up suspend/shutdown for PS/2 mice and keyboards
Ingo Molnar [Thu, 31 Dec 2009 14:16:23 +0000 (15:16 +0100)]
dma-debug: Fix bug causing build warning
Stephen Rothwell reported the following build warning:
lib/dma-debug.c: In function 'dma_debug_device_change':
lib/dma-debug.c:680: warning: 'return' with no value, in function returning non-void
Introduced by commit
f797d9881b62c2ddb1d2e7bd80d87141949c84aa
("dma-debug: Do not add notifier when dma debugging is disabled").
Return 0 [notify-done] when disabled. (this is standard bus notifier behavior.)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@kernel.org>
LKML-Reference: <
20091231125624.GA14666@liondog.tnic>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Peter Zijlstra [Wed, 30 Dec 2009 15:00:35 +0000 (16:00 +0100)]
perf: Fix NULL deref in inheritance code
Liming found a NULL deref when a task has a perf context but no
counters when it forks.
This can occur in two cases, a race during construction where
the fork hits after installing the context but before the first
counter gets inserted, or more reproducably, a fork after the
last counter is closed (which leaves the context around).
Reported-by: Wang Liming <liming.wang@windriver.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
CC: <stable@kernel.org>
LKML-Reference: <
1262185684.7135.222.camel@laptop>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Frederic Weisbecker [Thu, 31 Dec 2009 04:53:02 +0000 (05:53 +0100)]
perf: Pass appropriate frame pointer to dump_trace()
Pass the frame pointer from the regs of the interrupted path
to dump_trace() while processing the stack trace.
Currently, dump_trace() takes the current bp and starts the
callchain from dump_trace() itself. This is wasteful because
we need to walk through the entire NMI/DEBUG stack before
retrieving the interrupted point.
We can fix that by just using the frame pointer from the
captured regs. It points exactly where we want to start.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <
1262235183-5320-1-git-send-regression-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Linus Torvalds [Thu, 31 Dec 2009 00:00:24 +0000 (16:00 -0800)]
Merge branch 'release' of git://git./linux/kernel/git/lenb/linux-acpi-2.6
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPI: introduce kernel parameter acpi_sleep=sci_force_enable
ACPI: WMI: Survive BIOS with duplicate GUIDs
dell-wmi - fix condition to abort driver loading
wmi: check find_guid() return value to prevent oops
dell-wmi, hp-wmi, msi-wmi: check wmi_get_event_data() return value
ACPI: hp-wmi, msi-wmi: clarify that wmi_install_notify_handler() returns an acpi_status
dell-wmi: sys_init_module: 'dell_wmi'->init suspiciously returned 21, it should
ACPI video: correct error-handling code
ACPI video: no warning message if "acpi_backlight=vendor" is used
ACPI: fix ACPI=n allmodconfig build
thinkpad-acpi: improve Kconfig help text
thinkpad-acpi: update volume subdriver documentation
thinkpad-acpi: make volume subdriver optional
thinkpad-acpi: don't fail to load the entire module due to ALSA problems
thinkpad-acpi: don't take the first ALSA slot by default
Len Brown [Wed, 30 Dec 2009 23:32:32 +0000 (18:32 -0500)]
Merge branch 'resume-sci-force-bootparam' into release
Zhang Rui [Wed, 30 Dec 2009 07:36:42 +0000 (15:36 +0800)]
ACPI: introduce kernel parameter acpi_sleep=sci_force_enable
Introduce kernel parameter acpi_sleep=sci_force_enable
some laptop requires SCI_EN being set directly on resume,
or else they hung somewhere in the resume code path.
We already have a blacklist for these laptops but we still need
this option, especially when debugging some suspend/resume problems,
in case there are systems that need this workaround and are not yet
in the blacklist.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Linus Torvalds [Wed, 30 Dec 2009 21:46:29 +0000 (13:46 -0800)]
Merge branch 'fixes' of git://git./linux/kernel/git/djbw/async_tx
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx:
drivers/dma: Correct use after free
drivers/dma: drop unnecesary memset
ioat2,3: put channel hardware in known state at init
async_tx: expand async raid6 test to cover ioatdma corner case
ioat3: fix p-disabled q-continuation
sh: fix DMA driver's descriptor chaining and cookie assignment
dma: at_hdmac: correct incompatible type for argument 1 of 'spin_lock_bh'
Linus Torvalds [Wed, 30 Dec 2009 21:25:56 +0000 (13:25 -0800)]
Merge branch 'for_linus' of git://git./linux/kernel/git/tytso/ext4
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: Patch up how we claim metadata blocks for quota purposes
ext4: Ensure zeroout blocks have no dirty metadata
ext4: return correct wbc.nr_to_write in ext4_da_writepages
ext4: Update documentation to correct the inode_readahead_blks option name
jbd2: don't use __GFP_NOFAIL in journal_init_common()
ext4: flush delalloc blocks when space is low
fs-writeback: Add helper function to start writeback if idle
ext4: Eliminate potential double free on error path
ext4: fix unsigned long long printk warning in super.c
ext4, jbd2: Add barriers for file systems with exernal journals
ext4: replace BUG() with return -EIO in ext4_ext_get_blocks
ext4: add module aliases for ext2 and ext3
ext4: Don't ask about supporting ext2/3 in ext4 if ext4 is not configured
ext4: remove unused #include <linux/version.h>
Linus Torvalds [Wed, 30 Dec 2009 21:14:25 +0000 (13:14 -0800)]
Merge branch 'slab/urgent' of git://git./linux/kernel/git/penberg/slab-2.6
* 'slab/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6:
SLAB: Fix lockdep annotation breakage
Linus Torvalds [Wed, 30 Dec 2009 21:13:24 +0000 (13:13 -0800)]
Merge branch 'for-linus' of git://git./linux/kernel/git/jbarnes/pci-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
PCI/cardbus: Add a fixup hook and fix powerpc
PCI: change PCI nomenclature in drivers/pci/ (non-comment changes)
PCI: change PCI nomenclature in drivers/pci/ (comment changes)
PCI: fix section mismatch on update_res()
PCI: add Intel 82599 Virtual Function specific reset method
PCI: add Intel USB specific reset method
PCI: support device-specific reset methods
PCI: Handle case when no pci device can provide cache line size hint
PCI/PM: Propagate wake-up enable for PCIe devices too
vgaarbiter: fix a typo in the vgaarbiter Documentation
Linus Torvalds [Wed, 30 Dec 2009 20:56:17 +0000 (12:56 -0800)]
Merge branch 'kvm-updates/2.6.33' of git://git./virt/kvm/kvm
* 'kvm-updates/2.6.33' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: get rid of kvm_create_vm() unused label warning on s390
KVM: powerpc: Fix mtsrin in book3s_64 mmu
KVM: ia64: fix build breakage due to host spinlock change
KVM: x86: Extend KVM_SET_VCPU_EVENTS with selective updates
KVM: LAPIC: make sure IRR bitmap is scanned after vm load
KVM: Fix possible circular locking in kvm_vm_ioctl_assign_device()
KVM: MMU: remove prefault from invlpg handler
Linus Torvalds [Wed, 30 Dec 2009 20:55:10 +0000 (12:55 -0800)]
Merge branch 'for-linus' of git://git./linux/kernel/git/tiwai/sound-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
ALSA: hda - Fix Oops at reloading beep devices
ALSA: hda - Don't cache beep controls
ALSA: Fix a typo in Procfile.txt
ALSA: sound/arm: Fix build failure caused by missing struct aaci definition
ALSA: hda - use snd_hda_jack_detect() again in patch_sigmatel.c
ALSA: hda - Disable tigger at pin-sensing on AD codecs
ALSA: hda - HDMI sticky stream tag support
ALSA: Fix indentation in pcm_native.c
Rolf Eike Beer [Sat, 26 Dec 2009 16:58:11 +0000 (17:58 +0100)]
kfifo: Fix typo in comment
It's DECLARE_KFIFO, not DECLARED_KFIFO.
Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Wed, 30 Dec 2009 20:43:21 +0000 (12:43 -0800)]
Merge branch 'for-linus' of git://git.kernel.dk/linux-2.6-block
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
block: blk_rq_err_sectors cleanup
block: Honor the gfp_mask for alloc_page() in blkdev_issue_discard()
block: Fix incorrect alignment offset reporting and update documentation
cfq-iosched: don't regard requests with long distance as close
aoe: switch to the new bio_flush_dcache_pages() interface
drivers/block/mg_disk.c: use resource_size()
drivers/block/DAC960.c: use DAC960_V2_Controller
block: Fix topology stacking for data and discard alignment
drbd: remove unused #include <linux/version.h>
drbd: remove duplicated #include
drbd: Fix test of unsigned in _drbd_fault_random()
drbd: Constify struct file_operations
cfq-iosched: Remove prio_change logic for workload selection
cfq-iosched: Get rid of nr_groups
cfq-iosched: Remove the check for same cfq group from allow_merge
drbd: fix test of unsigned in _drbd_fault_random()
block: remove Documentation/block/as-iosched.txt
Len Brown [Wed, 30 Dec 2009 06:21:42 +0000 (01:21 -0500)]
dell-wmi: sys_init_module: 'dell_wmi'->init suspiciously returned 21, it should follow 0/-E convention
wmi_install_notify_handler() returns an acpi_error,
but dell_wmi_init() needs return a -errno style error.
Signed-off-by: Len Brown <len.brown@intel.com>
Tested-by: Paul Rolland <rol@as2917.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Paul Rolland [Wed, 30 Dec 2009 06:19:12 +0000 (01:19 -0500)]
wmi: check find_guid() return value to prevent oops
Signed-off-by: rol@as2917.net <Paul Rolland>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Wed, 30 Dec 2009 20:39:19 +0000 (12:39 -0800)]
Merge branch 'for-linus' of git://neil.brown.name/md
* 'for-linus' of git://neil.brown.name/md:
md: allow a resync that is waiting for other resync to complete, to be aborted.
md: remove unnecessary code from do_md_run
md: make recovery started by do_md_run() visible via sync_action
md: fix small irregularity with start_ro module parameter
md: Fix unfortunate interaction with evms
Linus Torvalds [Wed, 30 Dec 2009 20:37:35 +0000 (12:37 -0800)]
Merge git://git./linux/kernel/git/davem/net-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (74 commits)
Revert "b43: Enforce DMA descriptor memory constraints"
iwmc3200wifi: fix array out-of-boundary access
wl1251: timeout one too soon in wl1251_boot_run_firmware()
mac80211: fix propagation of failed hardware reconfigurations
mac80211: fix race with suspend and dynamic_ps_disable_work
ath9k: fix missed error codes in the tx status check
ath9k: wake hardware during AMPDU TX actions
ath9k: wake hardware for interface IBSS/AP/Mesh removal
ath9k: fix suspend by waking device prior to stop
cfg80211: fix error path in cfg80211_wext_siwscan
wl1271_cmd.c: cleanup char => u8
iwlwifi: Storage class should be before const qualifier
ath9k: Storage class should be before const qualifier
cfg80211: fix race between deauth and assoc response
wireless: remove remaining qual code
rt2x00: Add USB ID for Linksys WUSB 600N rev 2.
ath5k: fix SWI calibration interrupt storm
mac80211: fix ibss join with fixed-bssid
libertas: Remove carrier signaling from the scan code
orinoco: fix GFP_KERNEL in orinoco_set_key with interrupts disabled
...
Linus Torvalds [Wed, 30 Dec 2009 20:36:58 +0000 (12:36 -0800)]
Merge git://git./linux/kernel/git/herbert/crypto-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
hwrng: core - Fix double unlock in rng_dev_read
Serge E. Hallyn [Tue, 29 Dec 2009 20:50:19 +0000 (14:50 -0600)]
generic_permission: MAY_OPEN is not write access
generic_permission was refusing CAP_DAC_READ_SEARCH-enabled
processes from opening DAC-protected files read-only, because
do_filp_open adds MAY_OPEN to the open mask.
Ignore MAY_OPEN. After this patch, CAP_DAC_READ_SEARCH is
again sufficient to open(fname, O_RDONLY) on a file to which
DAC otherwise refuses us read permission.
Reported-by: Mike Kazantsev <mk.fraggod@gmail.com>
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Tested-by: Mike Kazantsev <mk.fraggod@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Mike Travis [Mon, 28 Dec 2009 21:28:25 +0000 (13:28 -0800)]
x86_64 SGI UV: Fix writes to led registers on remote uv hubs.
The wrong address was being used to write the SCIR led regs on remote
hubs. Also, there was an inconsistency between how BIOS and the kernel
indexed these regs. Standardize on using the lower 6 bits of the APIC
ID as the index.
This patch fixes the problem of writing to an errant address to a
cpu # >= 64.
Signed-off-by: Mike Travis <travis@sgi.com>
Reviewed-by: Jack Steiner <steiner@sgi.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Hugh Dickins [Wed, 30 Dec 2009 20:17:34 +0000 (20:17 +0000)]
mm: move sys_mmap_pgoff from util.c
Move sys_mmap_pgoff() from mm/util.c to mm/mmap.c and mm/nommu.c,
where we'd expect to find such code: especially now that it contains
the MAP_HUGETLB handling. Revert mm/util.c to how it was in 2.6.32.
This patch just ignores MAP_HUGETLB in the nommu case, as in 2.6.32,
whereas 2.6.33-rc2 reported -ENOSYS. Perhaps validate_mmap_request()
should reject it with -EINVAL? Add that later if necessary.
Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
James Bottomley [Wed, 30 Dec 2009 19:21:06 +0000 (13:21 -0600)]
libsrp: fix compile failure
commit
45465487897a1c6d508b14b904dc5777f7ec7e04 ("kfifo: move struct
kfifo in place") caused a compile failure in ibmvscsitgt.c because it
changed a pointer to kfifo in the libsrp.h structure to a direct
inclusion without including <linux/kfifo.h>.
The fix is simple, just add the include, but how did this happen? This
change, introduced at -rc2, hardly looks like a bug fix, and it clearly
didn't go through linux-next, which would have picked up this compile
failure (it only occurs on ppc because of the ibm virtual scsi target).
[ Apparently all of -mm wasn't in linux-next.. ]
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dmitry Torokhov [Wed, 30 Dec 2009 20:18:24 +0000 (12:18 -0800)]
Input: iforce - wait for command completion when closing the device
We need to wait for the command to disable FF effects to complete before
continuing with closing the device.
Tested-by: Johannes Ebke <johannes.ebke@physik.uni-muenchen.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Theodore Ts'o [Wed, 30 Dec 2009 19:20:45 +0000 (14:20 -0500)]
ext4: Patch up how we claim metadata blocks for quota purposes
As reported in Kernel Bugzilla #14936, commit d21cd8f triggered a BUG
in the function ext4_da_update_reserve_space() found in
fs/ext4/inode.c. The root cause of this BUG() was caused by the fact
that ext4_calc_metadata_amount() can severely over-estimate how many
metadata blocks will be needed, especially when using direct
block-mapped files.
In addition, it can also badly *under* estimate how much space is
needed, since ext4_calc_metadata_amount() assumes that the blocks are
contiguous, and this is not always true. If the application is
writing blocks to a sparse file, the number of metadata blocks
necessary can be severly underestimated by the functions
ext4_da_reserve_space(), ext4_da_update_reserve_space() and
ext4_da_release_space(). This was the cause of the dq_claim_space
reports found on kerneloops.org.
Unfortunately, doing this right means that we need to massively
over-estimate the amount of free space needed. So in some cases we
may need to force the inode to be written to disk asynchronously in
to avoid spurious quota failures.
http://bugzilla.kernel.org/show_bug.cgi?id=14936
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Lai Jiangshan [Tue, 15 Dec 2009 07:39:38 +0000 (15:39 +0800)]
tracing: Fix sign fields in ftrace_define_fields_##call()
Add is_signed_type() call to trace_define_field() in ftrace macros.
The code previously just passed in 0 (false), disregarding whether
or not the field was actually a signed type.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <
4B273D3A.6020007@cn.fujitsu.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Lai Jiangshan [Tue, 15 Dec 2009 07:39:26 +0000 (15:39 +0800)]
tracing/syscalls: Fix typo in SYSCALL_DEFINE0
The struct syscall_metadata variable name in SYSCALL_DEFINE0
should be __syscall_meta__##sname instead of __syscall_meta_##sname
to match the name that is in SYSCALL_DEFINE1/2/3/4/5/6.
This error causes event_enter_##sname->data to point to the wrong
location, which causes syscalls which are defined by SYSCALL_DEFINE0()
not to be traced.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <
4B273D2E.1010807@cn.fujitsu.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Lai Jiangshan [Tue, 15 Dec 2009 07:39:19 +0000 (15:39 +0800)]
tracing/kprobe: Show sign of fields in trace_kprobe format files
The format files of trace_kprobe do not show the sign of the fields.
The other format files show the field signed type of the fields and
this patch makes the trace_kprobe formats consistent with the others.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <
4B273D27.5040009@cn.fujitsu.com>
Acked-by: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
FUJITA Tomonori [Mon, 28 Dec 2009 09:11:56 +0000 (18:11 +0900)]
x86/agp: Fix agp_amd64_init() initialization with CONFIG_GART_IOMMU enabled
with CONFIG_GART_IOMMU enabled drivers/char/agp/amd64-agp.c has:
#ifndef CONFIG_GART_IOMMU
module_init(agp_amd64_init);
module_exit(agp_amd64_cleanup);
#endif
agp_amd64_init() was called via gart_iommu_init with
CONFIG_GART_IOMMU=y agp_amd64_init() was called via module_init
with CONFIG_GART_IOMMU=n
The commit
75f1cdf1dda92cae037ec848ae63690d91913eac changes the
x86 dma initialization routine: gart_iommu_init() is called only
when GART IOMMU is detected. So when GART IOMMU isn't detected,
agp_amd64_init isn't called.
Marin Mitov reported this issue:
http://marc.info/?l=linux-kernel&m=
126192729110083&w=2
With this patch, agp_amd64_init() is always called via
module_init (the above ifndef is removed). If agp_amd64_init()
is called via gart_iommu_init() earlier, agp_amd64_init()
finishes without doing anything (when it is called via
module_init).
Reported-by: Marin Mitov <mitov@issp.bas.bg>
Tested-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: davej@redhat.com
LKML-Reference: <
20091228181118C.fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Len Brown [Wed, 30 Dec 2009 07:51:38 +0000 (02:51 -0500)]
Merge branch 'video-error-case' into release
Len Brown [Wed, 30 Dec 2009 07:51:31 +0000 (02:51 -0500)]
Merge branch 'bugzilla-13671' into release
Len Brown [Wed, 30 Dec 2009 07:51:05 +0000 (02:51 -0500)]
Merge branch 'thinkpad' into release
Len Brown [Wed, 30 Dec 2009 07:51:01 +0000 (02:51 -0500)]
Merge branch 'wmi' into release
Carlos Corbacho [Sat, 26 Dec 2009 19:14:59 +0000 (19:14 +0000)]
ACPI: WMI: Survive BIOS with duplicate GUIDs
It would appear that in BIOS's with nVidia hooks, the GUID
05901221-D566-11D1-B2F0-
00A0C9062910 is duplicated. For now, the simplest
solution is to just ignore any duplicate GUIDs. These particular hooks are not
currently supported/ used in the kernel, so whoever does that can figure out
what the 'right' solution should be (if there's a better one).
http://bugzilla.kernel.org/show_bug.cgi?id=14846
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Oldřich Jedlička <oldium.pro@seznam.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
Dmitry Torokhov [Fri, 25 Dec 2009 19:49:35 +0000 (11:49 -0800)]
dell-wmi - fix condition to abort driver loading
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The commit
1fdd407f4e3f2ecb453954cbebb6c22491c61853 incorrectly made driver
abort loading when known GUID is present when it should have done exactly
the opposite.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>
Paul Rolland [Wed, 30 Dec 2009 06:07:40 +0000 (01:07 -0500)]
wmi: check find_guid() return value to prevent oops
Signed-off-by: Paul Rolland <rol@as2917.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Len Brown [Sun, 27 Dec 2009 04:02:24 +0000 (23:02 -0500)]
dell-wmi, hp-wmi, msi-wmi: check wmi_get_event_data() return value
When acpi_evaluate_object() is passed ACPI_ALLOCATE_BUFFER,
the caller must kfree the returned buffer if AE_OK is returned.
The callers of wmi_get_event_data() pass ACPI_ALLOCATE_BUFFER,
and thus must check its return value before accessing
or kfree() on the buffer.
Signed-off-by: Len Brown <len.brown@intel.com>
Len Brown [Sun, 27 Dec 2009 03:04:03 +0000 (22:04 -0500)]
ACPI: hp-wmi, msi-wmi: clarify that wmi_install_notify_handler() returns an acpi_status
Emphasize that that wmi_install_notify_handler() returns an acpi_status
rather than -errno by by testing ACPI_SUCCESS(), ACPI_FAILURE().
No functional change in this patch, but this confusion caused a bug in dell-wmi.
Signed-off-by: Len Brown <len.brown@intel.com>
Len Brown [Sun, 27 Dec 2009 02:51:38 +0000 (21:51 -0500)]
dell-wmi: sys_init_module: 'dell_wmi'->init suspiciously returned 21, it should
follow 0/-E convention
wmi_install_notify_handler() returns an acpi_error,
but dell_wmi_init() needs return a -errno style error.
Tested-by: Paul Rolland <rol@as2917.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Gui Jianfeng [Wed, 30 Dec 2009 07:41:07 +0000 (08:41 +0100)]
block: blk_rq_err_sectors cleanup
blk_rq_err_sectors() seems useless, get rid of it.
Signed-off-by: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Felipe Balbi [Wed, 30 Dec 2009 07:16:28 +0000 (23:16 -0800)]
Input: twl4030-pwrbutton - switch to using threaded IRQ
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Felipe Balbi [Wed, 30 Dec 2009 07:15:51 +0000 (23:15 -0800)]
Input: twl4030_keypad - switch to using threaded IRQ
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Dmitry Torokhov [Wed, 30 Dec 2009 07:19:31 +0000 (23:19 -0800)]
Input: lifebook - add CONFIG_DMI dependency
Lifebook protocol can only be activated if we find known DMI signature.
It is useles without DMI.
Reported-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Rakib Mullick [Wed, 30 Dec 2009 07:19:31 +0000 (23:19 -0800)]
Input: wistron - fix test for CONFIG_PM
This should fix the following compile warning:
drivers/input/misc/wistron_btns.c:1331:5: warning: "CONFIG_PM" is not defined
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
René Bolldorf [Wed, 30 Dec 2009 07:06:52 +0000 (23:06 -0800)]
Input: psmouse - fix compile warning in hgpk module
The variable 'dev' is unused in function 'hgpk_register'.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Zhang Rui [Wed, 29 Jul 2009 00:53:29 +0000 (08:53 +0800)]
ACPI video: correct error-handling code
backlight_device_register may return an ERR_PTR
value rather than a valid pointer.
Problem found by Julia Lawall, properly fixed by Zhang Rui.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Len Brown <len.brown@intel.com>
Li Zefan [Wed, 30 Dec 2009 06:24:03 +0000 (14:24 +0800)]
ksym_tracer: Remove trace_stat
trace_stat is problematic. Don't use it, use seqfile instead.
This fixes a race that reading the stat file is not protected by
any lock, which can lead to use after free.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <
4B3AF203.40200@cn.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Li Zefan [Wed, 30 Dec 2009 06:23:40 +0000 (14:23 +0800)]
ksym_tracer: Fix race when incrementing count
We are under rcu read section but not holding the write lock, so
count++ is not atomic. Use atomic64_t instead.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <
4B3AF1EC.9010608@cn.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Li Zefan [Wed, 30 Dec 2009 06:23:19 +0000 (14:23 +0800)]
ksym_tracer: Fix to allow writing newline to ksym_trace_filter
It used to work, but now doesn't:
# echo > ksym_filter
bash: echo: write error: Invalid argument
It's caused by
d954fbf0ff6b5fdfb32350e85a2f15d3db976506
("tracing: Fix wrong usage of strstrip in trace_ksyms").
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <
4B3AF1D7.5040400@cn.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Li Zefan [Wed, 30 Dec 2009 06:22:22 +0000 (14:22 +0800)]
ksym_tracer: Fix to make the tracer work
ksym tracer doesn't work:
# echo tasklist_lock:rw- > ksym_trace_filter
-bash: echo: write error: No such device
It's because we pass to perf_event_create_kernel_counter()
a cpu number which is not present.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <
4B3AF19E.1010201@cn.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Zhang Rui [Mon, 13 Jul 2009 02:33:24 +0000 (10:33 +0800)]
ACPI video: no warning message if "acpi_backlight=vendor" is used
AML code always sends notifications to ACPI video device,
even if we disable the ACPI backlight control by using
boot option "acpi_backlight=vendor".
In this case we should not print any warning message.
http://bugzilla.kernel.org/show_bug.cgi?id=13671#c14
Sigend-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Ingo Molnar [Thu, 17 Dec 2009 07:50:25 +0000 (08:50 +0100)]
ACPI: fix ACPI=n allmodconfig build
Today's -tip failed to build because commit
9e368fa011d4e0aa050db348d69514900520e40b ("ipmi: add PNP discovery (ACPI
namespace via PNPACPI)") from today's upstream kernel causes the following
build failure on x86, for CONFIG_ACPI=n && CONFIG_IPMI_SI=y:
drivers/char/ipmi/ipmi_si_intf.c:3208: error: 'ipmi_pnp_driver' undeclared (first use in this function)
drivers/char/ipmi/ipmi_si_intf.c:3208: error: (Each undeclared identifier is reported only once
drivers/char/ipmi/ipmi_si_intf.c:3208: error: for each function it appears in.)
drivers/char/ipmi/ipmi_si_intf.c:3334: error: 'ipmi_pnp_driver' undeclared (first use in this function)
The reason is that the ipmi_pnp_driver depends on ACPI facilities and is only
made available under ACPI - while the registration and unregistration is made
dependent on CONFIG_PNP:
#ifdef CONFIG_PNP
pnp_register_driver(&ipmi_pnp_driver);
#endif
The solution is to only register this driver under ACPI. (Also, the CONFIG_PNP
dependency is not needed because pnp_register_driver() is stubbed out in the
!CONFIG_PNP case.)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Aneesh Kumar K.V [Wed, 30 Dec 2009 04:39:06 +0000 (23:39 -0500)]
ext4: Ensure zeroout blocks have no dirty metadata
This fixes a bug (found by Curt Wohlgemuth) in which new blocks
returned from an extent created with ext4_ext_zeroout() can have dirty
metadata still associated with them.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Curt Wohlgemuth <curtw@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
NeilBrown [Wed, 30 Dec 2009 04:25:23 +0000 (15:25 +1100)]
md: allow a resync that is waiting for other resync to complete, to be aborted.
If two arrays share a device, then they will not both resync at the
same time. One will wait for the other to complete.
While waiting, the MD_RECOVERY_INTR flag is not checked so a device
failure, which would make the resync pointless, does not cause the
resync to abort, so the failed device cannot be removed (as it cannot
be remove while a resync is happening).
So add a test for MD_RECOVERY_INTR.
Reported-by: Brett Russ <bruss@netezza.com>
Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown [Wed, 30 Dec 2009 04:19:08 +0000 (15:19 +1100)]
md: remove unnecessary code from do_md_run
Since commit
dfc7064500061677720fa26352963c772d3ebe6b,
->hot_remove_disks has not removed non-failed devices from
an array until recovery is no longer possible.
So the code in do_md_run to get around the fact that
md_check_recovery (which calls ->hot_remove_disks) would
remove partially-in-sync devices is no longer needed.
So remove it.
Signed-off-by: NeilBrown <neilb@suse.de>
Dan Williams [Tue, 22 Dec 2009 01:18:36 +0000 (18:18 -0700)]
md: make recovery started by do_md_run() visible via sync_action
By default md_do_sync() will perform recovery if no other actions are
specified. However, action_show() relies on MD_RECOVERY_RECOVER to be
set otherwise it returns 'idle'. So, add a missing set
MD_RECOVERY_RECOVER when starting recovery.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown [Wed, 30 Dec 2009 01:08:50 +0000 (12:08 +1100)]
md: fix small irregularity with start_ro module parameter
The start_ro modules parameter can be used to force arrays to be
started in 'auto-readonly' in which they are read-only until the first
write. This ensures that no resync/recovery happens until something
else writes to the device. This is important for resume-from-disk
off an md array.
However if an array is started 'readonly' (by writing 'readonly' to
the 'array_state' sysfs attribute) we want it to be really 'readonly',
not 'auto-readonly'.
So strengthen the condition to only set auto-readonly if the
array is not already read-only.
Signed-off-by: NeilBrown <neilb@suse.de>
David S. Miller [Wed, 30 Dec 2009 03:44:25 +0000 (19:44 -0800)]
Merge branch 'master' of git://git./linux/kernel/git/linville/wireless-2.6
NeilBrown [Wed, 30 Dec 2009 01:08:49 +0000 (12:08 +1100)]
md: Fix unfortunate interaction with evms
evms configures md arrays by:
open device
send ioctl
close device
for each different ioctl needed.
Since 2.6.29, the device can disappear after the 'close'
unless a significant configuration has happened to the device.
The change made by "SET_ARRAY_INFO" can too minor to stop the device
from disappearing, but important enough that losing the change is bad.
So: make sure SET_ARRAY_INFO sets mddev->ctime, and keep the device
active as long as ctime is non-zero (it gets zeroed with lots of other
things when the array is stopped).
This is suitable for -stable kernels since 2.6.29.
Signed-off-by: NeilBrown <neilb@suse.de>
Cc: stable@kernel.org
Frederic Weisbecker [Tue, 29 Dec 2009 20:51:15 +0000 (21:51 +0100)]
reiserfs: Fix remaining in-reclaim-fs <-> reclaim-fs-on locking inversion
Commit
500f5a0bf5f0624dae34307010e240ec090e4cde
(reiserfs: Fix possible recursive lock) fixed a vmalloc under reiserfs
lock that triggered a lockdep warning because of a
IN-FS-RECLAIM <-> RECLAIM-FS-ON locking dependency inversion.
But this patch has ommitted another vmalloc call in the same path
that allocates the journal. Relax the lock for this one too.
Reported-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
John W. Linville [Tue, 29 Dec 2009 19:07:42 +0000 (14:07 -0500)]
Revert "b43: Enforce DMA descriptor memory constraints"
This reverts commit
9bd568a50c446433038dec2a5186c5c57c3dbd23.
That commit is shown to cause allocation failures during initialization
on some machines.
http://bugzilla.kernel.org/show_bug.cgi?id=14844
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Stefan Richter [Sat, 26 Dec 2009 00:36:53 +0000 (01:36 +0100)]
firewire, ieee1394: update Kconfig help
Update the Kconfig help texts of both stacks to encourage a general move
from the older to the newer drivers. However, do not label ieee1394 as
"Obsolete" yet, as the newer drivers have not been deployed as default
stack in the majority of Linux distributions yet, and those who start
doing so now may still want to install the old drivers as fallback for
unforeseen issues.
Since Linux 2.6.32, FireWire audio devices can be driven by the newer
firewire driver stack too, hence remove an outdated comment about audio
devices. Also remove comments about library versions since the 2nd
generation of libraw1394 and libdc1394 is now in common use; details on
library versions can be read at the wiki link from the help texts.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Stefan Richter [Sat, 26 Dec 2009 00:36:12 +0000 (01:36 +0100)]
firewire, ieee1394: update MAINTAINERS entries
Ben and Kristian have not been involved in maintenance of the IEEE 1394
drivers for quite some time; submitters are not required to Cc them on
patches.
The linux1394.org domain has been dead for a while and is no longer
under control of a Linux developer. The current web site of the
Linux 1394 project is http://ieee1394.wiki.kernel.org/.
The classic drivers/ieee1394/ stack is now obsolete from the development
point of view, though still a useful alternative in productive use. But
nobody should attempt to submit style cleanup patches for it or to
develop new drivers on top of this stack, hence mark its MAINTAINERS
entry as Obsolete.
drivers/ieee1394/raw1394*, like the rest of the old stack, does not
receive bigger code changes anymore, hence shrink the MAINTAINERS
database a bit by dropping raw1394's special entry. If something
important and urgent is going to come up for raw1394, I will make sure
that Dan will be notified of it besides via linux1394-devel.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
Cc: Ben Collins <ben.collins@ubuntu.com>
Cc: Kristian Hoegsberg <krh@bitplanet.net>
Stefan Richter [Sat, 26 Dec 2009 00:35:14 +0000 (01:35 +0100)]
firewire: ohci: always use packet-per-buffer mode for isochronous reception
This is a minimal change meant for the short term: Never set the
ohci->use_dualbuffer flag to true.
There are two reasons to do so:
- Packet-per-buffer mode and dual-buffer mode do not behave the same
under certain circumstances, notably if several packets are covered
by a single fw_cdev_iso_packet descriptor.
http://marc.info/?l=linux1394-devel&m=
124965653718313
Therefore the driver stack should not silently choose one or the
other mode but should leave the choice to the high-level driver
(regardless if kernel driver or userspace driver). Or simply always
only offer packet-per-buffer mode, since a considerable number of
controllers, even current ones, does not offer dual-buffer support.
- Even under circumstances where packet-per-buffer mode and
dual-buffer mode behave exactly the same --- notably when used
through libraw1394, libdc1394, as well as the current two kernel
drivers which use isochronous reception (firewire-net and firedtv)
--- we are still faced with the problem that several OHCI 1.1
controllers have bugs in dual-buffer mode. Although it looks like
we have identified most of those buggy controllers by now, we
cannot be quite sure about that.
So, use packet-per-buffer by default from now on. This change should
be followed up by a more complete solution: Either extend the
in-kernel API and the userspace ABI by a choice between the two IR modes
or remove all dual-buffer related code from firewire-ohci.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Stefan Richter [Sat, 26 Dec 2009 00:34:29 +0000 (01:34 +0100)]
firewire: cdev: fix another memory leak in an error path
If copy_from_user in an FW_CDEV_IOC_SEND_RESPONSE ioctl failed, the
fw_request pointed to by the inbound_transaction_resource is no
longer referenced and needs to be freed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Clemens Ladisch [Thu, 24 Dec 2009 11:05:58 +0000 (12:05 +0100)]
firewire: fix use of multiple AV/C devices, allow multiple FCP listeners
Control of more than one AV/C device at once --- e.g. camcorders, tape
decks, audio devices, TV tuners --- failed or worked only unreliably,
depending on driver implementation. This affected kernelspace and
userspace drivers alike and was caused by firewire-core's inability to
accept multiple registrations of FCP listeners.
The fix allows multiple address handlers to be registered for the FCP
command and response registers. When a request for these registers is
received, all handlers are invoked, and the Firewire response is
generated by the core and not by any handler.
The cdev API does not change, i.e., userspace is still expected to send
a response for FCP requests; this response is silently ignored.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, rebased, whitespace)
OGAWA Hirofumi [Tue, 29 Dec 2009 07:53:54 +0000 (08:53 +0100)]
block: Honor the gfp_mask for alloc_page() in blkdev_issue_discard()
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Martin K. Petersen [Tue, 29 Dec 2009 07:35:35 +0000 (08:35 +0100)]
block: Fix incorrect alignment offset reporting and update documentation
queue_sector_alignment_offset returned the wrong value which caused
partitions to report an incorrect alignment_offset. Since offset
alignment calculation is needed several places it has been split into a
separate helper function. The topology stacking function has been
updated accordingly.
Furthermore, comments have been added to clarify how the stacking
function works.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Tested-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Mike Travis [Mon, 28 Dec 2009 21:28:25 +0000 (13:28 -0800)]
x86: SGI UV: Fix writes to led registers on remote uv hubs
The wrong address was being used to write the SCIR led regs on
remote hubs. Also, there was an inconsistency between how BIOS
and the kernel indexed these regs. Standardize on using the
lower 6 bits of the APIC ID as the index.
This patch fixes the problem of writing to an errant address to
a cpu # >= 64.
Signed-off-by: Mike Travis <travis@sgi.com>
Reviewed-by: Jack Steiner <steiner@sgi.com>
Cc: Robin Holt <holt@sgi.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@kernel.org
LKML-Reference: <
4B3922F9.3060905@sgi.com>
[ v2: fix a number of annoying checkpatch artifacts and whitespace noise ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Zhu Yi [Mon, 28 Dec 2009 06:23:11 +0000 (14:23 +0800)]
iwmc3200wifi: fix array out-of-boundary access
Allocate priv->rx_packets[IWM_RX_ID_HASH + 1] because the max array
index is IWM_RX_ID_HASH according to IWM_RX_ID_GET_HASH().
Cc: stable@kernel.org
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Roel Kluin [Sat, 26 Dec 2009 19:31:59 +0000 (20:31 +0100)]
wl1251: timeout one too soon in wl1251_boot_run_firmware()
`loop' reaches INIT_LOOP + 1 after the loop. so if ACX_INTR_INIT_COMPLETE
occurs in the last iteration the write occurs but also the error out as if a
timeout occurred. This is probably very unlikely to ever occur.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Luis R. Rodriguez [Thu, 24 Dec 2009 20:38:22 +0000 (15:38 -0500)]
mac80211: fix propagation of failed hardware reconfigurations
mac80211 does not propagate failed hardware reconfiguration
requests. For suspend and resume this is important due to all
the possible issues that can come out of the suspend <-> resume
cycle. Not propagating the error means cfg80211 will assume
the resume for the device went through fine and mac80211 will
continue on trying to poke at the hardware, enable timers,
queue work, and so on for a device which is completley
unfunctional.
The least we can do is to propagate device start issues and
warn when this occurs upon resume. A side effect of this patch
is we also now propagate the start errors upon harware
reconfigurations (non-suspend), but this should also be desirable
anyway, there is not point in continuing to reconfigure a
device if mac80211 was unable to start the device.
For further details refer to the thread:
http://marc.info/?t=
126151038700001&r=1&w=2
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>