22 May, 2010
3 commits
-
... and get rid of the last __put_super_and_need_restart() caller
Signed-off-by: Al Viro
-
We used to remove from s_list and s_instances at the same
time. So let's *not* do the former and skip superblocks
that have empty s_instances in the loops over s_list.The next step, of course, will be to get rid of rescan logics
in those loops.Signed-off-by: Al Viro
-
We set the "it's dead, don't mount on it" flag _and_ do not remove it if
we turn the damn thing negative and leave it around. And if it goes
positive afterwards, well...Fortunately, there's only one place where that needs to be caught:
only d_delete() can turn the sucker negative without immediately freeing
it; all other places that can lead to ->d_iput() call are followed by
unconditionally freeing struct dentry in question. So the fix is obvious:Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16014
Reported-by: Adam Tkac
Tested-by: Adam Tkac
Cc: [2.6.34.x]Signed-off-by: Al Viro
04 Mar, 2010
3 commits
-
rehashing the negative placeholder opens a race with d_lookup();
we unhash it almost immediately (by d_move()), but the race
window is there. Since d_move() doesn't rely on target being
hashed, we don't need that d_rehash() at all.Signed-off-by: Al Viro
-
Analog of is_subdir for vfsmount,dentry pairs, moved from audit_tree.c
Signed-off-by: Al Viro
-
Cleanup EXPORT* macros according to Documantation/CodingStyle.
Move EXPORT* macros to the line immediately after the closing
function brace.Signed-off-by: H Hartley Sweeten
Signed-off-by: Al Viro
17 Dec, 2009
1 commit
-
The EXPORT_SYMBOL for d_alloc_name is in fs/libfs.c but the function
is in fs/dcache.c. Move the EXPORT_SYMBOL to the line immediately
after the closing function brace line in fs/dcache.c as mentioned
in Documentation/CodingStyle.Signed-off-by: H Hartley Sweeten
Signed-off-by: Al Viro
18 Jul, 2009
1 commit
-
might_sleep() is called late-ish in cond_resched(), after the
need_resched()/preempt enabled/system running tests are
checked.It's better to check the sleeps while atomic earlier and not
depend on some environment datas that reduce the chances to
detect a problem.Also define cond_resched_*() helpers as macros, so that the
FILE/LINE reported in the sleeping while atomic warning
displays the real origin and not sched.hChanges in v2:
- Call __might_sleep() directly instead of might_sleep() which
may call cond_resched()- Turn cond_resched() into a macro so that the file:line
couple reported refers to the caller of cond_resched() and
not __cond_resched() itself.Changes in v3:
- Also propagate this __might_sleep() pull up to
cond_resched_lock() and cond_resched_softirq()Signed-off-by: Frederic Weisbecker
Signed-off-by: Peter Zijlstra
LKML-Reference:
Signed-off-by: Ingo Molnar
12 Jun, 2009
1 commit
-
d_unlinked() will be used in middle-term to ban checkpointing when opened
but unlinked file is detected, and in long term, to detect such situation
and special case on it.Signed-off-by: Alexey Dobriyan
Signed-off-by: Al Viro
09 May, 2009
1 commit
-
Fix ordering of LRU when moving referenced dentries to the head of the list
(they should go to the head of the list in the same order as they were found
from the tail, rather than reverse order).Signed-off-by: Nick Piggin
Signed-off-by: Al Viro
21 Apr, 2009
1 commit
-
is_under() will DTRT anyway. And yes, is_subdir() behaviour
is intentional.Signed-off-by: Al Viro
01 Apr, 2009
2 commits
-
Signed-off-by: Al Viro
-
Don't pull it in sched.h; very few files actually need it and those
can include directly. sched.h itself only needs forward declaration
of struct fs_struct;Signed-off-by: Al Viro
28 Mar, 2009
1 commit
-
Make sure that comments describe what's going on and not how, and always
use __d_instantiate instead of two separate branches, one with
d_instantiate and one with __d_instantiate.Signed-off-by: Christoph Hellwig
Signed-off-by: Al Viro
28 Feb, 2009
1 commit
-
Commit 4ea3ada2955e4519befa98ff55dd62d6dfbd1705 declares d_obtain_alias()
as EXPORT_SYMBOL_GPL where it's supposed to replace d_alloc_anon which was
previously declared as EXPORT_SYMBOL and thus available to any loadable
module.This patch reverts that.
Signed-off-by: Benny Halevy
Acked-by: Linus Torvalds
Cc: Christoph Hellwig
Cc: "J. Bruce Fields"
Cc: Trond Myklebust
Acked-by: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Jan, 2009
1 commit
-
Signed-off-by: Heiko Carstens
09 Jan, 2009
1 commit
-
Use the new generic implementation.
Signed-off-by: Wu Fengguang
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Jan, 2009
5 commits
-
Instead of creating the "filp" kmem_cache in vfs_caches_init(),
we can do it a litle be later in files_init(), so that filp_cachep
is static to fs/file_table.cAcked-by: Paul E. McKenney
Signed-off-by: Eric Dumazet
Signed-off-by: Al Viro -
Explain that you really need to use the return value of d_path rather than
the buffer you passed into it.Also fix the comment for seq_path(), the function arguments changed
recently but the comment hadn't been updated in sync.Signed-off-by: Arjan van de Ven
Cc: Al Viro
Cc: Christoph Hellwig
Signed-off-by: Andrew Morton
Signed-off-by: Al Viro -
no function named d_put(), it should be dput().
Impact: fix document and comment, no functionality changed
Signed-off-by: Zhao Lei
Signed-off-by: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Al Viro -
We want ->name.len to match the resulting name on *both*
source and targetSigned-off-by: Al Viro
-
struct dentry is one of the most critical structures in the kernel. So it's
sad to see it going neglected.With CONFIG_PROFILING turned on (which is probably the common case at least
for distros and kernel developers), sizeof(struct dcache) == 208 here
(64-bit). This gives 19 objects per slab.I packed d_mounted into a hole, and took another 4 bytes off the inline
name length to take the padding out from the end of the structure. This
shinks it to 200 bytes. I could have gone the other way and increased the
length to 40, but I'm aiming for a magic number, read on...I then got rid of the d_cookie pointer. This shrinks it to 192 bytes. Rant:
why was this ever a good idea? The cookie system should increase its hash
size or use a tree or something if lookups are a problem. Also the "fast
dcookie lookups" in oprofile should be moved into the dcookie code -- how
can oprofile possibly care about the dcookie_mutex? It gets dropped after
get_dcookie() returns so it can't be providing any sort of protection.At 192 bytes, 21 objects fit into a 4K page, saving about 3MB on my system
with ~140 000 entries allocated. 192 is also a multiple of 64, so we get
nice cacheline alignment on 64 and 32 byte line systems -- any given dentry
will now require 3 cachelines to touch all fields wheras previously it
would require 4.I know the inline name size was chosen quite carefully, however with the
reduction in cacheline footprint, it should actually be just about as fast
to do a name lookup for a 36 character name as it was before the patch (and
faster for other sizes). The memory footprint savings for names which are
36 bytes long should more than make up for the memory cost for
33-36 byte names.Performance is a feature...
Signed-off-by: Al Viro
23 Oct, 2008
9 commits
-
Hi Al,
remember that debug session we did at KS? You suggested this patch back
then....From 7751eaf30474b8cbfaea64795805a17eab05ac53 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven
Date: Tue, 16 Sep 2008 16:51:17 -0700
Subject: [PATCH] fs: add a sanity check in d_freewe're seeing some corruption in the dentry->d_alias list that
appears like a free of an entry still on the list; this patch
adds a WARN_ON() to catch this scenario, as suggested by Al ViroSigned-off-by: Arjan van de Ven
-
Parameters @hash and @len have been removed since 2.4.3,
now just to delete them.Signed-off-by: Qinghuang Feng
-
This calls d_move(), so fsnotify_d_instantiate() is unnecessary like
rename path.Signed-off-by: OGAWA Hirofumi
-
This adds __d_instantiate() for users which is already taking
dcache_lock, and replace with it.The part of d_add_ci() isn't equivalent. But it should be needed
fsnotify_d_instantiate() actually, because the path is to add the
inode to negative dentry. fsnotify_d_instantiate() should be called
after change from negative to positive.Signed-off-by: OGAWA Hirofumi
-
This adds d_ancestor() instead of d_isparent(), then use it.
If new_dentry == old_dentry, is_subdir() returns 1, looks strange.
"new_dentry == old_dentry" is not subdir obviously. But I'm not
checking callers for now, so this keeps current behavior.Signed-off-by: OGAWA Hirofumi
-
Signed-off-by: OGAWA Hirofumi
-
Remove d_alloc_anon now that no users are left.
Signed-off-by: Christoph Hellwig
Signed-off-by: Al Viro -
Switch all users of d_alloc_anon to d_obtain_alias.
Signed-off-by: Christoph Hellwig
Signed-off-by: Al Viro -
The calling conventions of d_alloc_anon are rather unfortunate for all
users, and it's name is not very descriptive either.Add d_obtain_alias as a new exported helper that drops the inode
reference in the failure case, too and allows to pass-through NULL
pointers and inodes to allow for tail-calls in the export operations.Incidentally this helper already existed as a private function in
libfs.c as exportfs_d_alloc so kill that one and switch the callers
to d_obtain_alias.Signed-off-by: Christoph Hellwig
Signed-off-by: Al Viro
29 Sep, 2008
1 commit
-
The VFS interface for the 'd_compare()' is a bit special (read: 'odd'),
because it really just essentially replaces a memcmp(). The filesystem
is supposed to just compare the two names with whatever case-independent
or other function.And when I say 'is supposed to', I obviously mean that 'procfs does odd
things, and actually looks at the dentry that we don't even pass down,
rather than just the name'. Which results in problems, because we
actually call d_compare before we have even verified that the dentry is
still hashed at all.And that causes a problm since the inode that procfs looks at may have
been free'd and the d_inode pointer is NULL. procfs just assumes that
all dentries are positive, since procfs itself never generates a
negative one. But memory pressure will still result in the dentry
getting torn down, and as it is removed by RCU, it still remains visible
on some lists - and to d_compare.If the filesystem just did a name comparison, we wouldn't care. And we
could just fix procfs to know about negative dentries too. But rather
than have the low-level filesystems know about internal VFS details,
just move the check for a unhashed dentry up a bit, so that we will only
call d_compare on dentries that are still active.The actual oops this caused didn't look like a NULL pointer dereference
because procfs did a 'container_of(inode, struct proc_inode, vfs_inode)'
to get at its internal proc_inode information from the inode pointer,
and accessed a field below the inode. So the oops would look something
likeBUG: unable to handle kernel paging request at fffffffffffffff0
IP: [] proc_sys_compare+0x36/0x50and was seen on both x86-64 (Alexey Dobriyan and Hugh Dickins) and
ppc64 (Hugh Dickins).Reported-by: Alexey Dobriyan
Acked-by: Hugh Dickins
Cc: Al Viro
Reviewed-by: "Eric W. Biederman"
Signed-of-by: Linus Torvalds
25 Aug, 2008
1 commit
-
As pointed out during review d_add_ci argument order should match d_add,
so switch the dentry and inode arguments.Signed-off-by: Christoph Hellwig
Signed-off-by: Al Viro
28 Jul, 2008
1 commit
-
This add a dcache entry to the dcache for lookup, but changing the name
that is associated with the entry rather than the one passed in to the
lookup routine.First, it sees if the case-exact match already exists in the dcache and
uses it if one exists. Otherwise, it allocates a new node with the new
name and splices it into the dcache.Original code from ntfs_lookup in fs/ntfs/namei.c by Anton Altaparmakov.
Signed-off-by: Barry Naujok
Signed-off-by: Anton Altaparmakov
Acked-by: Christoph Hellwig
27 Jul, 2008
1 commit
-
Add cond_resched_lock(&dcache_lock) while scanning LRU lists on
superblocks in __shrink_dcache_sb()Signed-off-by: Kentaro Makita
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 Jul, 2008
1 commit
-
[Summary]
Split LRU-list of unused dentries to one per superblock to avoid soft
lock up during NFS mounts and remounting of any filesystem.Previously I posted here:
http://lkml.org/lkml/2008/3/5/590[Descriptions]
- background
dentry_unused is a list of dentries which are not referenced.
dentry_unused grows up when references on directories or files are
released. This list can be very long if there is huge free memory.- the problem
When shrink_dcache_sb() is called, it scans all dentry_unused linearly
under spin_lock(), and if dentry->d_sb is differnt from given
superblock, scan next dentry. This scan costs very much if there are
many entries, and very ineffective if there are many superblocks.IOW, When we need to shrink unused dentries on one dentry, but scans
unused dentries on all superblocks in the system. For example, we scan
500 dentries to unmount a filesystem, but scans 1,000,000 or more unused
dentries on other superblocks.In our case , At mounting NFS*, shrink_dcache_sb() is called to shrink
unused dentries on NFS, but scans 100,000,000 unused dentries on
superblocks in the system such as local ext3 filesystems. I hear NFS
mounting took 1 min on some system in use.* : NFS uses virtual filesystem in rpc layer, so NFS is affected by
this problem.100,000,000 is possible number on large systems.
Per-superblock LRU of unused dentried can reduce the cost in
reasonable manner.- How to fix
I found this problem is solved by David Chinner's "Per-superblock
unused dentry LRU lists V3"(1), so I rebase it and add some fix to
reclaim with fairness, which is in Andrew Morton's comments(2).1) http://lkml.org/lkml/2006/5/25/318
2) http://lkml.org/lkml/2006/5/25/320Split LRU-list of unused dentries to each superblocks. Then, NFS
mounting will check dentries under a superblock instead of all. But
this spliting will break LRU of dentry-unused. So, I've attempted to
make reclaim unused dentrins with fairness by calculate number of
dentries to scan on this sb based on following waynumber of dentries to scan on this sb =
count * (number of dentries on this sb / number of dentries in the machine)- ToDo
- I have to measuring performance number and do stress tests.- When unmount occurs during prune_dcache(), scanning on same
superblock, It is unable to reach next superblock because it is gone
away. We restart scannig superblock from first one, it causes
unfairness of reclaim unused dentries on first superblock. But I think
this happens very rarely.- Test Results
Result on 6GB boxes with excessive unused dentries.
Without patch:
$ cat /proc/sys/fs/dentry-state
10181835 10180203 45 0 0 0
# mount -t nfs 10.124.60.70:/work/kernel-src nfs
real 0m1.830s
user 0m0.001s
sys 0m1.653sWith this patch:
$ cat /proc/sys/fs/dentry-state
10236610 10234751 45 0 0 0
# mount -t nfs 10.124.60.70:/work/kernel-src nfs
real 0m0.106s
user 0m0.002s
sys 0m0.032s[akpm@linux-foundation.org: fix comments]
Signed-off-by: Kentaro Makita
Cc: Neil Brown
Cc: Trond Myklebust
Cc: David Chinner
Cc: "J. Bruce Fields"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
24 Jun, 2008
3 commits
-
Comment from Al Viro: add prepend_name() wrapper.
Signed-off-by: Miklos Szeredi
Signed-off-by: Al Viro -
Fix the following sparse warnings:
fs/dcache.c:2183:19: warning: symbol 'filp_cachep' was not declared. Should it be static?
fs/dcache.c:115:3: warning: context imbalance in 'dentry_iput' - unexpected unlock
fs/dcache.c:188:2: warning: context imbalance in 'dput' - different lock contexts for basic block
fs/dcache.c:400:2: warning: context imbalance in 'prune_one_dentry' - different lock contexts for basic block
fs/dcache.c:431:22: warning: context imbalance in 'prune_dcache' - different lock contexts for basic block
fs/dcache.c:563:2: warning: context imbalance in 'shrink_dcache_sb' - different lock contexts for basic block
fs/dcache.c:1385:6: warning: context imbalance in 'd_delete' - wrong count at exit
fs/dcache.c:1636:2: warning: context imbalance in '__d_unalias' - unexpected unlock
fs/dcache.c:1735:2: warning: context imbalance in 'd_materialise_unique' - different lock contexts for basic blockSigned-off-by: Miklos Szeredi
Reviewed-by: Matthew Wilcox
Acked-by: Christoph Hellwig
Signed-off-by: Al Viro -
The path that __d_path() computes can become slightly inconsistent when it
races with mount operations: it grabs the vfsmount_lock when traversing mount
points but immediately drops it again, only to re-grab it when it reaches the
next mount point. The result is that the filename computed is not always
consisent, and the file may never have had that name. (This is unlikely, but
still possible.)Fix this by grabbing the vfsmount_lock for the whole duration of
__d_path().Signed-off-by: Andreas Gruenbacher
Signed-off-by: John Johansen
Signed-off-by: Miklos Szeredi
Acked-by: Christoph Hellwig
Signed-off-by: Al Viro
23 Jun, 2008
1 commit
-
Signed-off-by: Jan Engelhardt
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Al Viro
