26 May, 2011
1 commit
-
This serves no useful purpose that I can discern. All callers (rename,
rmdir) hold their own reference to the dentry.A quick audit of all file systems showed no relevant checks on the value
of d_count in vfs_rmdir/vfs_rename_dir paths.Signed-off-by: Sage Weil
Signed-off-by: Al Viro
31 Mar, 2011
1 commit
-
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi
10 Mar, 2011
1 commit
-
... it returns an error unconditionally
Signed-off-by: Al Viro
07 Jan, 2011
3 commits
-
Signed-off-by: Nick Piggin
-
Require filesystems be aware of .d_revalidate being called in rcu-walk
mode (nd->flags & LOOKUP_RCU). For now do a simple push down, returning
-ECHILD from all implementations.Signed-off-by: Nick Piggin
-
Reduce some branches and memory accesses in dcache lookup by adding dentry
flags to indicate common d_ops are set, rather than having to check them.
This saves a pointer memory access (dentry->d_op) in common path lookup
situations, and saves another pointer load and branch in cases where we
have d_op but not the particular operation.Patched with:
git grep -E '[.>]([[:space:]])*d_op([[:space:]])*=' | xargs sed -e 's/\([^\t ]*\)->d_op = \(.*\);/d_set_d_op(\1, \2);/' -e 's/\([^\t ]*\)\.d_op = \(.*\);/d_set_d_op(\&\1, \2);/' -i
Signed-off-by: Nick Piggin
26 Oct, 2010
2 commits
-
note: for race-free uses you inode_lock held
Signed-off-by: Al Viro
-
__block_write_begin and block_prepare_write are identical except for slightly
different calling conventions. Convert all callers to the __block_write_begin
calling conventions and drop block_prepare_write.Signed-off-by: Christoph Hellwig
Signed-off-by: Al Viro
22 May, 2010
1 commit
-
Signed-off-by: Stephen Hemminger
Signed-off-by: Al Viro
25 Apr, 2010
2 commits
-
Commit 48b32a3553a54740d236b79a90f20147a25875e3 ("reiserfs: use generic
xattr handlers") introduced a problem that causes corruption when extended
attributes are replaced with a smaller value.The issue is that the reiserfs_setattr to shrink the xattr file was moved
from before the write to after the write.The root issue has always been in the reiserfs xattr code, but was papered
over by the fact that in the shrink case, the file would just be expanded
again while the xattr was written.The end result is that the last 8 bytes of xattr data are lost.
This patch fixes it to use new_size.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=14826
Signed-off-by: Jeff Mahoney
Reported-by: Christian Kujau
Tested-by: Christian Kujau
Cc: Edward Shishkin
Cc: Jethro Beekman
Cc: Greg Surbey
Cc: Marco Gatti
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Commit 677c9b2e393a0cd203bd54e9c18b012b2c73305a ("reiserfs: remove
privroot hiding in lookup") removed the magic from the lookup code to hide
the .reiserfs_priv directory since it was getting loaded at mount-time
instead. The intent was that the entry would be hidden from the user via
a poisoned d_compare, but this was faulty.This introduced a security issue where unprivileged users could access and
modify extended attributes or ACLs belonging to other users, including
root.This patch resolves the issue by properly hiding .reiserfs_priv. This was
the intent of the xattr poisoning code, but it appears to have never
worked as expected. This is fixed by using d_revalidate instead of
d_compare.This patch makes -oexpose_privroot a no-op. I'm fine leaving it this way.
The effort involved in working out the corner cases wrt permissions and
caching outweigh the benefit of the feature.Signed-off-by: Jeff Mahoney
Acked-by: Edward Shishkin
Reported-by: Matt McCutchen
Tested-by: Matt McCutchen
Cc: Frederic Weisbecker
Cc: Al Viro
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Mar, 2010
1 commit
-
…it slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
05 Mar, 2010
1 commit
-
Currently various places in the VFS call vfs_dq_init directly. This means
we tie the quota code into the VFS. Get rid of that and make the
filesystem responsible for the initialization. For most metadata operations
this is a straight forward move into the methods, but for truncate and
open it's a bit more complicated.For truncate we currently only call vfs_dq_init for the sys_truncate case
because open already takes care of it for ftruncate and open(O_TRUNC) - the
new code causes an additional vfs_dq_init for those which is harmless.For open the initialization is moved from do_filp_open into the open method,
which means it happens slightly earlier now, and only for regular files.
The latter is fine because we don't need to initialize it for operations
on special files, and we already do it as part of the namespace operations
for directories.Add a dquot_file_open helper that filesystems that support generic quotas
can use to fill in ->open.Signed-off-by: Christoph Hellwig
Signed-off-by: Jan Kara
09 Jan, 2010
1 commit
-
…t/frederic/random-tracing
* 'reiserfs/kill-bkl' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing:
reiserfs: Relax reiserfs_xattr_set_handle() while acquiring xattr locks
reiserfs: Fix unreachable statement
reiserfs: Don't call reiserfs_get_acl() with the reiserfs lock
reiserfs: Relax lock on xattr removing
reiserfs: Relax the lock before truncating pages
reiserfs: Fix recursive lock on lchown
reiserfs: Fix mistake in down_write() conversion
07 Jan, 2010
1 commit
-
Fix remaining xattr locks acquired in reiserfs_xattr_set_handle()
while we are holding the reiserfs lock to avoid lock inversions.Signed-off-by: Frederic Weisbecker
Cc: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar
05 Jan, 2010
1 commit
-
When we remove an xattr, we call lookup_and_delete_xattr()
that takes some private xattr inodes mutexes. But we hold
the reiserfs lock at this time, which leads to dependency
inversions.We can safely call lookup_and_delete_xattr() without the
reiserfs lock, where xattr inodes lookups only need the
xattr inodes mutexes.Signed-off-by: Frederic Weisbecker
Cc: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar
03 Jan, 2010
2 commits
-
Fix a mistake in commit 0719d3434747889b314a1e8add776418c4148bcf
(reiserfs: Fix reiserfs lock i_xattr_sem dependency inversion)
that has converted a down_write() into a down_read() accidentally.Signed-off-by: Frederic Weisbecker
Cc: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
…t/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
02 Jan, 2010
6 commits
-
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
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
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: [] reiserfs_for_each_xattr+0x23f/0x290but task is already holding lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x29/0x40which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_lookup+0x62/0x140
[] __lookup_hash+0xef/0x110
[] lookup_one_len+0x8d/0xc0
[] open_xa_dir+0xea/0x1b0
[] reiserfs_for_each_xattr+0x70/0x290
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32-> #0 (&sb->s_type->i_mutex_key#4/3){+.+.+.}:
[] __lock_acquire+0x18f6/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_for_each_xattr+0x23f/0x290
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32other info that might help us debug this:
1 lock held by rm/3242:
#0: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x29/0x40stack backtrace:
Pid: 3242, comm: rm Not tainted 2.6.32-atom #179
Call Trace:
[] ? printk+0x18/0x1a
[] print_circular_bug+0xca/0xd0
[] __lock_acquire+0x18f6/0x19e0
[] ? mark_held_locks+0x62/0x80
[] ? trace_hardirqs_on+0xb/0x10
[] ? mutex_unlock+0x8/0x10
[] lock_acquire+0x68/0x90
[] ? reiserfs_for_each_xattr+0x23f/0x290
[] ? reiserfs_for_each_xattr+0x23f/0x290
[] mutex_lock_nested+0x5b/0x340
[] ? reiserfs_for_each_xattr+0x23f/0x290
[] reiserfs_for_each_xattr+0x23f/0x290
[] ? delete_one_xattr+0x0/0x100
[] reiserfs_delete_xattrs+0x1a/0x60
[] ? reiserfs_write_lock_once+0x29/0x50
[] reiserfs_delete_inode+0x9f/0x150
[] ? _atomic_dec_and_lock+0x4f/0x70
[] ? reiserfs_delete_inode+0x0/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] ? mutex_unlock+0x8/0x10
[] ? vfs_readdir+0x7d/0xb0
[] ? filldir64+0x0/0xf0
[] ? sysenter_exit+0xf/0x16
[] ? trace_hardirqs_on_caller+0x124/0x170
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32Signed-off-by: Frederic Weisbecker
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
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: [] do_journal_begin_r+0x94/0x360but task is already holding lock:
(&sb->s_type->i_mutex_key#4/2){+.+...}, at: [] xattr_unlink+0x57/0xb0which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&sb->s_type->i_mutex_key#4/2){+.+...}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] xattr_unlink+0x57/0xb0
[] delete_one_xattr+0x29/0x100
[] reiserfs_for_each_xattr+0x10b/0x290
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32-> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_write_lock+0x29/0x40
[] do_journal_begin_r+0x9c/0x360
[] journal_begin+0x80/0x130
[] reiserfs_remount+0x223/0x4e0
[] do_remount_sb+0xa6/0x140
[] do_mount+0x560/0x750
[] sys_mount+0x84/0xb0
[] sysenter_do_call+0x12/0x32-> #0 (&journal->j_mutex){+.+...}:
[] __lock_acquire+0x18f6/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] do_journal_begin_r+0x94/0x360
[] journal_begin+0x80/0x130
[] reiserfs_unlink+0x83/0x2e0
[] xattr_unlink+0x64/0xb0
[] delete_one_xattr+0x29/0x100
[] reiserfs_for_each_xattr+0x10b/0x290
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32other info that might help us debug this:
2 locks held by rm/3202:
#0: (&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] reiserfs_for_each_xattr+0x9b/0x290
#1: (&sb->s_type->i_mutex_key#4/2){+.+...}, at: [] xattr_unlink+0x57/0xb0stack backtrace:
Pid: 3202, comm: rm Not tainted 2.6.32-atom #178
Call Trace:
[] ? printk+0x18/0x1a
[] print_circular_bug+0xca/0xd0
[] __lock_acquire+0x18f6/0x19e0
[] ? xattr_unlink+0x57/0xb0
[] lock_acquire+0x68/0x90
[] ? do_journal_begin_r+0x94/0x360
[] ? do_journal_begin_r+0x94/0x360
[] mutex_lock_nested+0x5b/0x340
[] ? do_journal_begin_r+0x94/0x360
[] do_journal_begin_r+0x94/0x360
[] ? run_timer_softirq+0x1a6/0x220
[] ? __do_softirq+0x50/0x140
[] journal_begin+0x80/0x130
[] ? __do_softirq+0xf2/0x140
[] ? hrtimer_interrupt+0xdf/0x220
[] reiserfs_unlink+0x83/0x2e0
[] ? mark_held_locks+0x62/0x80
[] ? trace_hardirqs_on_thunk+0xc/0x10
[] ? restore_all_notrace+0x0/0x18
[] ? xattr_unlink+0x57/0xb0
[] xattr_unlink+0x64/0xb0
[] delete_one_xattr+0x29/0x100
[] reiserfs_for_each_xattr+0x10b/0x290
[] ? delete_one_xattr+0x0/0x100
[] ? mutex_lock_nested+0x299/0x340
[] reiserfs_delete_xattrs+0x1a/0x60
[] ? reiserfs_write_lock_once+0x29/0x50
[] reiserfs_delete_inode+0x9f/0x150
[] ? _atomic_dec_and_lock+0x4f/0x70
[] ? reiserfs_delete_inode+0x0/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] ? mutex_unlock+0x8/0x10
[] ? vfs_readdir+0x7d/0xb0
[] ? filldir64+0x0/0xf0
[] ? sysenter_exit+0xf/0x16
[] ? trace_hardirqs_on_caller+0x124/0x170
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32Signed-off-by: Frederic Weisbecker
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
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: [] reiserfs_write_lock_once+0x29/0x50but task is already holding lock:
(&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] open_xa_dir+0xd8/0x1b0which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#4/3){+.+.+.}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] open_xa_dir+0x43/0x1b0
[] reiserfs_for_each_xattr+0x62/0x260
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlink+0x10/0x20
[] sysenter_do_call+0x12/0x32-> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[] __lock_acquire+0x18f6/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_lookup+0x62/0x140
[] __lookup_hash+0xef/0x110
[] lookup_one_len+0x8d/0xc0
[] open_xa_dir+0xea/0x1b0
[] xattr_lookup+0x15/0x160
[] reiserfs_xattr_get+0x56/0x2a0
[] reiserfs_get_acl+0xa2/0x360
[] reiserfs_cache_default_acl+0x3a/0x160
[] reiserfs_mkdir+0x6c/0x2c0
[] vfs_mkdir+0xd6/0x180
[] sys_mkdirat+0xc0/0xd0
[] sys_mkdir+0x20/0x30
[] sysenter_do_call+0x12/0x32other info that might help us debug this:
2 locks held by cp/3204:
#0: (&sb->s_type->i_mutex_key#4/1){+.+.+.}, at: [] lookup_create+0x26/0xa0
#1: (&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] open_xa_dir+0xd8/0x1b0stack backtrace:
Pid: 3204, comm: cp Not tainted 2.6.32-atom #173
Call Trace:
[] ? printk+0x18/0x1a
[] print_circular_bug+0xca/0xd0
[] __lock_acquire+0x18f6/0x19e0
[] ? check_usage+0x6a/0x460
[] lock_acquire+0x68/0x90
[] ? reiserfs_write_lock_once+0x29/0x50
[] ? reiserfs_write_lock_once+0x29/0x50
[] mutex_lock_nested+0x5b/0x340
[] ? reiserfs_write_lock_once+0x29/0x50
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_lookup+0x62/0x140
[] ? debug_check_no_locks_freed+0x8a/0x140
[] ? trace_hardirqs_on_caller+0x124/0x170
[] __lookup_hash+0xef/0x110
[] lookup_one_len+0x8d/0xc0
[] open_xa_dir+0xea/0x1b0
[] xattr_lookup+0x15/0x160
[] reiserfs_xattr_get+0x56/0x2a0
[] reiserfs_get_acl+0xa2/0x360
[] ? new_inode+0x27/0xa0
[] reiserfs_cache_default_acl+0x3a/0x160
[] ? _spin_unlock+0x27/0x40
[] reiserfs_mkdir+0x6c/0x2c0
[] ? __d_lookup+0x108/0x190
[] ? mark_held_locks+0x62/0x80
[] ? mutex_lock_nested+0x2bd/0x340
[] ? generic_permission+0x1a/0xa0
[] ? security_inode_permission+0x1e/0x20
[] vfs_mkdir+0xd6/0x180
[] sys_mkdirat+0xc0/0xd0
[] ? up_read+0x16/0x30
[] ? restore_all_notrace+0x0/0x18
[] sys_mkdir+0x20/0x30
[] sysenter_do_call+0x12/0x32Signed-off-by: Frederic Weisbecker
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
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: [] reiserfs_write_lock_once+0x29/0x50but task is already holding lock:
(&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] open_xa_dir+0xd8/0x1b0which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#4/3){+.+.+.}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] open_xa_dir+0x43/0x1b0
[] reiserfs_for_each_xattr+0x62/0x260
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlink+0x10/0x20
[] sysenter_do_call+0x12/0x32-> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[] __lock_acquire+0x18f6/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_lookup+0x62/0x140
[] __lookup_hash+0xef/0x110
[] lookup_one_len+0x8d/0xc0
[] open_xa_dir+0xea/0x1b0
[] xattr_lookup+0x15/0x160
[] reiserfs_xattr_get+0x56/0x2a0
[] reiserfs_get_acl+0xa2/0x360
[] reiserfs_cache_default_acl+0x3a/0x160
[] reiserfs_mkdir+0x6c/0x2c0
[] vfs_mkdir+0xd6/0x180
[] sys_mkdirat+0xc0/0xd0
[] sys_mkdir+0x20/0x30
[] sysenter_do_call+0x12/0x32other info that might help us debug this:
2 locks held by cp/3204:
#0: (&sb->s_type->i_mutex_key#4/1){+.+.+.}, at: [] lookup_create+0x26/0xa0
#1: (&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] open_xa_dir+0xd8/0x1b0stack backtrace:
Pid: 3204, comm: cp Not tainted 2.6.32-atom #173
Call Trace:
[] ? printk+0x18/0x1a
[] print_circular_bug+0xca/0xd0
[] __lock_acquire+0x18f6/0x19e0
[] ? check_usage+0x6a/0x460
[] lock_acquire+0x68/0x90
[] ? reiserfs_write_lock_once+0x29/0x50
[] ? reiserfs_write_lock_once+0x29/0x50
[] mutex_lock_nested+0x5b/0x340
[] ? reiserfs_write_lock_once+0x29/0x50
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_lookup+0x62/0x140
[] ? debug_check_no_locks_freed+0x8a/0x140
[] ? trace_hardirqs_on_caller+0x124/0x170
[] __lookup_hash+0xef/0x110
[] lookup_one_len+0x8d/0xc0
[] open_xa_dir+0xea/0x1b0
[] xattr_lookup+0x15/0x160
[] reiserfs_xattr_get+0x56/0x2a0
[] reiserfs_get_acl+0xa2/0x360
[] ? new_inode+0x27/0xa0
[] reiserfs_cache_default_acl+0x3a/0x160
[] ? _spin_unlock+0x27/0x40
[] reiserfs_mkdir+0x6c/0x2c0
[] ? __d_lookup+0x108/0x190
[] ? mark_held_locks+0x62/0x80
[] ? mutex_lock_nested+0x2bd/0x340
[] ? generic_permission+0x1a/0xa0
[] ? security_inode_permission+0x1e/0x20
[] vfs_mkdir+0xd6/0x180
[] sys_mkdirat+0xc0/0xd0
[] ? up_read+0x16/0x30
[] ? restore_all_notrace+0x0/0x18
[] sys_mkdir+0x20/0x30
[] sysenter_do_call+0x12/0x32v2: Don't drop reiserfs_mutex_lock_nested_safe() as we'll still
need it laterSigned-off-by: Frederic Weisbecker
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
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: [] reiserfs_write_lock+0x35/0x50
[ 990.013233]
[ 990.013233] but task is already holding lock:
[ 990.013233] (&REISERFS_I(inode)->i_xattr_sem){+.+.+.}, at: [] 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] [] __lock_acquire+0xf9c/0x1560
[ 990.013233] [] lock_acquire+0x8f/0xb0
[ 990.013233] [] down_write+0x44/0x80
[ 990.013233] [] reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233] [] reiserfs_xattr_set+0xb0/0x150
[ 990.013233] [] user_set+0x8a/0x90
[ 990.013233] [] reiserfs_setxattr+0xaa/0xb0
[ 990.013233] [] __vfs_setxattr_noperm+0x36/0xa0
[ 990.013233] [] vfs_setxattr+0xbc/0xc0
[ 990.013233] [] setxattr+0xc0/0x150
[ 990.013233] [] sys_fsetxattr+0x8d/0xa0
[ 990.013233] [] system_call_fastpath+0x16/0x1b
[ 990.013233]
[ 990.013233] -> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[ 990.013233] [] __lock_acquire+0x12d0/0x1560
[ 990.013233] [] lock_acquire+0x8f/0xb0
[ 990.013233] [] __mutex_lock_common+0x47/0x3b0
[ 990.013233] [] mutex_lock_nested+0x3e/0x50
[ 990.013233] [] reiserfs_write_lock+0x35/0x50
[ 990.013233] [] reiserfs_prepare_write+0x45/0x180
[ 990.013233] [] reiserfs_xattr_set_handle+0x2a6/0x470
[ 990.013233] [] reiserfs_xattr_set+0xb0/0x150
[ 990.013233] [] user_set+0x8a/0x90
[ 990.013233] [] reiserfs_setxattr+0xaa/0xb0
[ 990.013233] [] __vfs_setxattr_noperm+0x36/0xa0
[ 990.013233] [] vfs_setxattr+0xbc/0xc0
[ 990.013233] [] setxattr+0xc0/0x150
[ 990.013233] [] sys_fsetxattr+0x8d/0xa0
[ 990.013233] [] 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: [] vfs_setxattr+0x78/0xc0
[ 990.013233] #1: (&REISERFS_I(inode)->i_xattr_sem){+.+.+.}, at: [] 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] [] print_circular_bug+0xe9/0xf0
[ 990.013233] [] __lock_acquire+0x12d0/0x1560
[ 990.013233] [] ? reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233] [] lock_acquire+0x8f/0xb0
[ 990.013233] [] ? reiserfs_write_lock+0x35/0x50
[ 990.013233] [] ? reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233] [] __mutex_lock_common+0x47/0x3b0
[ 990.013233] [] ? reiserfs_write_lock+0x35/0x50
[ 990.013233] [] ? reiserfs_write_lock+0x35/0x50
[ 990.013233] [] ? mark_held_locks+0x72/0xa0
[ 990.013233] [] ? __mutex_unlock_slowpath+0xbd/0x140
[ 990.013233] [] ? trace_hardirqs_on_caller+0x14d/0x1a0
[ 990.013233] [] mutex_lock_nested+0x3e/0x50
[ 990.013233] [] reiserfs_write_lock+0x35/0x50
[ 990.013233] [] reiserfs_prepare_write+0x45/0x180
[ 990.013233] [] reiserfs_xattr_set_handle+0x2a6/0x470
[ 990.013233] [] reiserfs_xattr_set+0xb0/0x150
[ 990.013233] [] ? __mutex_lock_common+0x284/0x3b0
[ 990.013233] [] user_set+0x8a/0x90
[ 990.013233] [] reiserfs_setxattr+0xaa/0xb0
[ 990.013233] [] __vfs_setxattr_noperm+0x36/0xa0
[ 990.013233] [] vfs_setxattr+0xbc/0xc0
[ 990.013233] [] setxattr+0xc0/0x150
[ 990.013233] [] ? sched_clock_cpu+0xb8/0x100
[ 990.013233] [] ? trace_hardirqs_off+0xd/0x10
[ 990.013233] [] ? cpu_clock+0x43/0x50
[ 990.013233] [] ? fget+0xb0/0x110
[ 990.013233] [] ? fget+0x0/0x110
[ 990.013233] [] ? sysret_check+0x27/0x62
[ 990.013233] [] sys_fsetxattr+0x8d/0xa0
[ 990.013233] [] system_call_fastpath+0x16/0x1bReported-and-tested-by: Christian Kujau
Signed-off-by: Frederic Weisbecker
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar
17 Dec, 2009
2 commits
-
The reiserfs lock -> inode mutex dependency gets inverted when we
relax the lock while walking to the tree.To fix this, use a specialized version of reiserfs_mutex_lock_safe
that takes care of mutex subclasses. Then we can grab the inode
mutex with I_MUTEX_XATTR subclass without any reiserfs lock
dependency.This fixes the following report:
[ INFO: possible circular locking dependency detected ]
2.6.32-06793-gf405425-dirty #2
-------------------------------------------------------
mv/18566 is trying to acquire lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28=
/0x40but task is already holding lock:
(&sb->s_type->i_mutex_key#5/3){+.+.+.}, at: []
reiserfs_for_each_xattr+0x10c/0x380which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#5/3){+.+.+.}:
[] validate_chain+0xa23/0xf70
[] __lock_acquire+0x4e5/0xa70
[] lock_acquire+0x7a/0xa0
[] mutex_lock_nested+0x5f/0x2b0
[] reiserfs_for_each_xattr+0x84/0x380
[] reiserfs_delete_xattrs+0x15/0x50
[] reiserfs_delete_inode+0x8f/0x140
[] generic_delete_inode+0x9c/0x150
[] generic_drop_inode+0x3d/0x60
[] iput+0x47/0x50
[] do_unlinkat+0xdb/0x160
[] sys_unlink+0x10/0x20
[] sysenter_do_call+0x12/0x36-> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[] validate_chain+0xf68/0xf70
[] __lock_acquire+0x4e5/0xa70
[] lock_acquire+0x7a/0xa0
[] mutex_lock_nested+0x5f/0x2b0
[] reiserfs_write_lock+0x28/0x40
[] search_by_key+0x1f7b/0x21b0
[] search_by_entry_key+0x1f/0x3b0
[] reiserfs_find_entry+0x77/0x400
[] reiserfs_lookup+0x85/0x130
[] __lookup_hash+0xb4/0x110
[] lookup_one_len+0xb3/0x100
[] reiserfs_for_each_xattr+0x120/0x380
[] reiserfs_delete_xattrs+0x15/0x50
[] reiserfs_delete_inode+0x8f/0x140
[] generic_delete_inode+0x9c/0x150
[] generic_drop_inode+0x3d/0x60
[] iput+0x47/0x50
[] dentry_iput+0x6f/0xf0
[] d_kill+0x24/0x50
[] dput+0x5b/0x120
[] sys_renameat+0x1b9/0x230
[] sys_rename+0x28/0x30
[] sysenter_do_call+0x12/0x36other info that might help us debug this:
2 locks held by mv/18566:
#0: (&sb->s_type->i_mutex_key#5/1){+.+.+.}, at: []
lock_rename+0xcc/0xd0
#1: (&sb->s_type->i_mutex_key#5/3){+.+.+.}, at: []
reiserfs_for_each_xattr+0x10c/0x380stack backtrace:
Pid: 18566, comm: mv Tainted: G C 2.6.32-06793-gf405425-dirty #2
Call Trace:
[] ? printk+0x18/0x1e
[] print_circular_bug+0xc0/0xd0
[] validate_chain+0xf68/0xf70
[] ? trace_hardirqs_off+0xb/0x10
[] __lock_acquire+0x4e5/0xa70
[] lock_acquire+0x7a/0xa0
[] ? reiserfs_write_lock+0x28/0x40
[] mutex_lock_nested+0x5f/0x2b0
[] ? reiserfs_write_lock+0x28/0x40
[] ? reiserfs_write_lock+0x28/0x40
[] ? schedule+0x27a/0x440
[] reiserfs_write_lock+0x28/0x40
[] search_by_key+0x1f7b/0x21b0
[] ? __lock_acquire+0x506/0xa70
[] ? lock_release_non_nested+0x1e7/0x340
[] ? reiserfs_write_lock+0x28/0x40
[] ? trace_hardirqs_on_caller+0x124/0x170
[] ? trace_hardirqs_on+0xb/0x10
[] ? T.316+0x15/0x1a0
[] ? sched_clock_cpu+0x9d/0x100
[] search_by_entry_key+0x1f/0x3b0
[] ? __mutex_unlock_slowpath+0x9a/0x120
[] ? trace_hardirqs_on_caller+0x124/0x170
[] reiserfs_find_entry+0x77/0x400
[] reiserfs_lookup+0x85/0x130
[] ? sched_clock_cpu+0x9d/0x100
[] __lookup_hash+0xb4/0x110
[] lookup_one_len+0xb3/0x100
[] reiserfs_for_each_xattr+0x120/0x380
[] ? delete_one_xattr+0x0/0x1c0
[] ? math_error+0x22/0x150
[] ? reiserfs_write_lock+0x28/0x40
[] reiserfs_delete_xattrs+0x15/0x50
[] ? reiserfs_write_lock+0x28/0x40
[] reiserfs_delete_inode+0x8f/0x140
[] ? generic_delete_inode+0x5f/0x150
[] ? reiserfs_delete_inode+0x0/0x140
[] generic_delete_inode+0x9c/0x150
[] generic_drop_inode+0x3d/0x60
[] iput+0x47/0x50
[] dentry_iput+0x6f/0xf0
[] d_kill+0x24/0x50
[] dput+0x5b/0x120
[] sys_renameat+0x1b9/0x230
[] ? sched_clock_cpu+0x9d/0x100
[] ? trace_hardirqs_off+0xb/0x10
[] ? cpu_clock+0x4e/0x60
[] ? do_page_fault+0x155/0x370
[] ? up_read+0x16/0x30
[] ? do_page_fault+0x155/0x370
[] sys_rename+0x28/0x30
[] sysenter_do_call+0x12/0x36Reported-by: Alexander Beregalov
Signed-off-by: Frederic Weisbecker
Cc: Chris Mason
Cc: Ingo Molnar
Cc: Thomas Gleixner -
Add a flags argument to struct xattr_handler and pass it to all xattr
handler methods. This allows using the same methods for multiple
handlers, e.g. for the ACL methods which perform exactly the same action
for the access and default ACLs, just using a different underlying
attribute. With a little more groundwork it'll also allow sharing the
methods for the regular user/trusted/secure handlers in extN, ocfs2 and
jffs2 like it's already done for xfs in this patch.Also change the inode argument to the handlers to a dentry to allow
using the handlers mechnism for filesystems that require it later,
e.g. cifs.[with GFS2 bits updated by Steven Whitehouse ]
Signed-off-by: Christoph Hellwig
Reviewed-by: James Morris
Acked-by: Joel Becker
Signed-off-by: Al Viro
14 Sep, 2009
2 commits
-
reiserfs_xattr_init is called with the reiserfs write lock held, but
if the ".reiserfs_priv" entry is not created, we take the superblock
root directory inode mutex until .reiserfs_priv is created.This creates a lock dependency inversion against other sites such as
reiserfs_file_release() which takes an inode mutex and the reiserfs
lock after.Signed-off-by: Frederic Weisbecker
Cc: Jeff Mahoney
Cc: Chris Mason
Cc: Ingo Molnar
Cc: Alexander Beregalov
Cc: Laurent Riffard -
While searching a pathname, an inode mutex can be acquired
in do_lookup() which calls reiserfs_lookup() which in turn
acquires the write lock.On the other side reiserfs_fill_super() can acquire the write_lock
and then call reiserfs_lookup_privroot() which can acquire an
inode mutex (the root of the mount point).So we theoretically risk an AB - BA lock inversion that could lead
to a deadlock.As for other lock dependencies found since the bkl to mutex
conversion, the fix is to use reiserfs_mutex_lock_safe() which
drops the lock dependency to the write lock.[ Impact: fix a possible deadlock with reiserfs ]
Cc: Jeff Mahoney
Cc: Chris Mason
Cc: Ingo Molnar
Cc: Alexander Beregalov
Signed-off-by: Frederic Weisbecker
13 Jul, 2009
1 commit
-
* Remove smp_lock.h from files which don't need it (including some headers!)
* Add smp_lock.h to files which do need it
* Make smp_lock.h include conditional in hardirq.h
It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPTThis will make hardirq.h inclusion cheaper for every PREEMPT=n config
(which includes allmodconfig/allyesconfig, BTW)Signed-off-by: Alexey Dobriyan
Signed-off-by: Linus Torvalds
12 Jun, 2009
1 commit
-
This patch adds an -oexpose_privroot option to allow access to the privroot.
Signed-off-by: Jeff Mahoney
Signed-off-by: Al Viro
18 May, 2009
3 commits
-
This adds CONFIG_REISERFS_FS_XATTR protection from reiserfs_permission.
This is needed to avoid warnings during file deletions and chowns with
xattrs disabled.Signed-off-by: Jeff Mahoney
Signed-off-by: Linus Torvalds -
This avoids an Oops in open_xa_root that can occur when deleting a file
with xattrs disabled. It assumes that the xattr root will be there, and
that is not guaranteed.Signed-off-by: Jeff Mahoney
Signed-off-by: Linus Torvalds -
With xattr cleanup even with xattrs disabled, much of the initial setup
is still performed. Some #ifdefs are just not needed since the options
they protect wouldn't be available anyway.This cleans those up.
Signed-off-by: Jeff Mahoney
Signed-off-by: Linus Torvalds
09 May, 2009
4 commits
-
With Al Viro's patch to move privroot lookup to fs mount, there's no need
to have special code to hide the privroot in reiserfs_lookup.I've also cleaned up the privroot hiding in reiserfs_readdir_dentry and
removed the last user of reiserfs_xattrs().Signed-off-by: Jeff Mahoney
Signed-off-by: Al Viro -
The xattr_root caching was broken from my previous patch set. It wouldn't
cause corruption, but could cause decreased performance due to allocating
a larger chunk of the journal (~ 27 blocks) than it would actually use.This patch loads the xattr root dentry at xattr initialization and creates
it on-demand. Since we're using the cached dentry, there's no point
in keeping lookup_or_create_dir around, so that's removed.Signed-off-by: Jeff Mahoney
Signed-off-by: Al Viro -
... even if it's a negative dentry. That way we can set ->d_op on
root before anyone could race with us. Simplify d_compare(), while
we are at it.Signed-off-by: Al Viro
-
2.6.30-rc3 introduced some sanity checks in the VFS code to avoid NFS
bugs by ensuring that lookup_one_len is always called under i_mutex.This patch expands the i_mutex locking to enclose lookup_one_len. This was
always required, but not not enforced in the reiserfs code since it
does locking around the xattr interactions with the xattr_sem.This is obvious enough, and it survived an overnight 50 thread ACL test.
Signed-off-by: Jeff Mahoney
Signed-off-by: Al Viro
31 Mar, 2009
3 commits
-
This patch ifdefs xattr_create when xattrs aren't enabled.
Signed-off-by: Jeff Mahoney
Signed-off-by: Linus Torvalds -
* reiserfs-updates: (35 commits)
reiserfs: rename [cn]_* variables
reiserfs: rename p_._ variables
reiserfs: rename p_s_tb to tb
reiserfs: rename p_s_inode to inode
reiserfs: rename p_s_bh to bh
reiserfs: rename p_s_sb to sb
reiserfs: strip trailing whitespace
reiserfs: cleanup path functions
reiserfs: factor out buffer_info initialization
reiserfs: add atomic addition of selinux attributes during inode creation
reiserfs: use generic readdir for operations across all xattrs
reiserfs: journaled xattrs
reiserfs: use generic xattr handlers
reiserfs: remove i_has_xattr_dir
reiserfs: make per-inode xattr locking more fine grained
reiserfs: eliminate per-super xattr lock
reiserfs: simplify xattr internal file lookups/opens
reiserfs: Clean up xattrs when REISERFS_FS_XATTR is unset
reiserfs: remove IS_PRIVATE helpers
reiserfs: remove link detection code
...Fixed up conflicts manually due to:
- quota name cleanups vs variable naming changes:
fs/reiserfs/inode.c
fs/reiserfs/namei.c
fs/reiserfs/stree.c
fs/reiserfs/xattr.c
- exported include header cleanups
include/linux/reiserfs_fs.h -
The current reiserfs xattr implementation open codes reiserfs_readdir
and frees the path before calling the filldir function. Typically, the
filldir function is something that modifies the file system, such as a
chown or an inode deletion that also require reading of an inode
associated with each direntry. Since the file system is modified, the
path retained becomes invalid for the next run. In addition, it runs
backwards in attempt to minimize activity.This is clearly suboptimal from a code cleanliness perspective as well
as performance-wise.This patch implements a generic reiserfs_for_each_xattr that uses the
generic readdir and a specific filldir routine that simply populates an
array of dentries and then performs a specific operation on them. When
all files have been operated on, it then calls the operation on the
directory itself.The result is a noticable code reduction and better performance.
Signed-off-by: Jeff Mahoney
Signed-off-by: Linus Torvalds