linux-stable.git/fs/dcache.c, branch linux-3.14.y

fix d_walk()/non-delayed __d_free() race

2016-09-11T07:59:58+00:00

I checked Jari's explanation below and found that v3.14.77 and v3.12.62
are missing the same fix as 3.10. In fact Al's original commit 3d56c25
("fix d_walk()/non-delayed __d_free() race") used to mention to check 
this __d_materialise_dentry() function in the Cc: stable line, but this
got lost during the backports.

Normally all of our 3 kernels need to apply the following patch that
Ben correctly put in 3.16 and 3.2. I'm fixing the backport in 3.10.103
right now.

On Mon, Aug 22, 2016 at 04:56:57PM +0300, Jari Ruusu wrote:
> This patch for 3.10 branch appears to be missing one important
> 
> +       dentry->d_flags |= DCACHE_RCUACCESS;
> 
> in fs/dcache.c __d_materialise_dentry() function. When Ben Hutchings
> backported Al Viro's original fix to stable branches that he maintains,
> he added that one additional line to both 3.2 and 3.16 branches. Please
> consider including that additional one line fix for 3.10 stable branch
> also.
> 
> 
> Ben Hutchings said this on his 3.2.82-rc1 patch:
> [bwh: Backported to 3.2:
>  - Adjust context
>  - Also set the flag in __d_materialise_dentry())]
> 
> http://marc.info/?l=linux-kernel&m=147117565612275&w=2
> 
> 
> Ben Hutchings said this on his 3.16.37-rc1 patch:
> [bwh: Backported to 3.16:
>  - Adjust context
>  - Also set the flag in __d_materialise_dentry())]
> 
> http://marc.info/?l=linux-kernel&m=147117433412006&w=2
> 
> 
> Also mentioned by Sasha Levin on 3.18 and 4.1 commits:
> Cc: stable@vger.kernel.org # v3.2+ (and watch out for __d_materialise_dentry())
> 
> http://marc.info/?l=linux-stable-commits&m=146648034410827&w=2
> http://marc.info/?l=linux-stable-commits&m=146647471009771&w=2


Signed-off-by: Greg Kroah-Hartman

fix d_walk()/non-delayed __d_free() race

2016-06-24T17:15:29+00:00

commit 3d56c25e3bb0726a5c5e16fc2d9e38f8ed763085 upstream.

Ascend-to-parent logics in d_walk() depends on all encountered child
dentries not getting freed without an RCU delay.  Unfortunately, in
quite a few cases it is not true, with hard-to-hit oopsable race as
the result.

Fortunately, the fix is simiple; right now the rule is "if it ever
been hashed, freeing must be delayed" and changing it to "if it
ever had a parent, freeing must be delayed" closes that hole and
covers all cases the old rule used to cover.  Moreover, pipes and
sockets remain _not_ covered, so we do not introduce RCU delay in
the cases which are the reason for having that delay conditional
in the first place.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

lock_parent: don't step on stale ->d_parent of all-but-freed one

2016-03-03T23:06:46+00:00

commit c2338f2dc7c1e9f6202f370c64ffd7f44f3d4b51 upstream.

Dentry that had been through (or into) __dentry_kill() might be seen
by shrink_dentry_list(); that's normal, it'll be taken off the shrink
list and freed if __dentry_kill() has already finished.  The problem
is, its ->d_parent might be pointing to already freed dentry, so
lock_parent() needs to be careful.

We need to check that dentry hasn't already gone into __dentry_kill()
*and* grab rcu_read_lock() before dropping ->d_lock - the latter makes
sure that whatever we see in ->d_parent after dropping ->d_lock it
won't be freed until we drop rcu_read_lock().

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

dcache: add missing lockdep annotation

2016-03-03T23:06:46+00:00

commit 9f12600fe425bc28f0ccba034a77783c09c15af4 upstream.

lock_parent() very much on purpose does nested locking of dentries, and
is careful to maintain the right order (lock parent first).  But because
it didn't annotate the nested locking order, lockdep thought it might be
a deadlock on d_lock, and complained.

Add the proper annotation for the inner locking of the child dentry to
make lockdep happy.

Introduced by commit 046b961b45f9 ("shrink_dentry_list(): take parent's
->d_lock earlier").

Reported-and-tested-by: Josh Boyer 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

dentry_kill() doesn't need the second argument now

2016-03-03T23:06:46+00:00

commit 8cbf74da435d1bd13dbb790f94c7ff67b2fb6af4 upstream.

it's 1 in the only remaining caller.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

dealing with the rest of shrink_dentry_list() livelock

2016-03-03T23:06:46+00:00

commit b2b80195d8829921506880f6dccd21cabd163d0d upstream.

We have the same problem with ->d_lock order in the inner loop, where
we are dropping references to ancestors.  Same solution, basically -
instead of using dentry_kill() we use lock_parent() (introduced in the
previous commit) to get that lock in a safe way, recheck ->d_count
(in case if lock_parent() has ended up dropping and retaking ->d_lock
and somebody managed to grab a reference during that window), trylock
the inode->i_lock and use __dentry_kill() to do the rest.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

shrink_dentry_list(): take parent's ->d_lock earlier

2016-03-03T23:06:46+00:00

commit 046b961b45f93a92e4c70525a12f3d378bced130 upstream.

The cause of livelocks there is that we are taking ->d_lock on
dentry and its parent in the wrong order, forcing us to use
trylock on the parent's one.  d_walk() takes them in the right
order, and unfortunately it's not hard to create a situation
when shrink_dentry_list() can't make progress since trylock
keeps failing, and shrink_dcache_parent() or check_submounts_and_drop()
keeps calling d_walk() disrupting the very shrink_dentry_list() it's
waiting for.

Solution is straightforward - if that trylock fails, let's unlock
the dentry itself and take locks in the right order.  We need to
stabilize ->d_parent without holding ->d_lock, but that's doable
using RCU.  And we'd better do that in the very beginning of the
loop in shrink_dentry_list(), since the checks on refcount, etc.
would need to be redone anyway.

That deals with a half of the problem - killing dentries on the
shrink list itself.  Another one (dropping their parents) is
in the next commit.

locking parent is interesting - it would be easy to do rcu_read_lock(),
lock whatever we think is a parent, lock dentry itself and check
if the parent is still the right one.  Except that we need to check
that *before* locking the dentry, or we are risking taking ->d_lock
out of order.  Fortunately, once the D1 is locked, we can check if
D2->d_parent is equal to D1 without the need to lock D2; D2->d_parent
can start or stop pointing to D1 only under D1->d_lock, so taking
D1->d_lock is enough.  In other words, the right solution is
rcu_read_lock/lock what looks like parent right now/check if it's
still our parent/rcu_read_unlock/lock the child.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

expand dentry_kill(dentry, 0) in shrink_dentry_list()

2016-03-03T23:06:46+00:00

commit ff2fde9929feb2aef45377ce56b8b12df85dda69 upstream.

Result will be massaged to saner shape in the next commits.  It is
ugly, no questions - the point of that one is to be a provably
equivalent transformation (and it might be worth splitting a bit
more).

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

split dentry_kill()

2016-03-03T23:06:46+00:00

commit e55fd011549eae01a230e3cace6f4d031b6a3453 upstream.

... into trylocks and everything else.  The latter (actual killing)
is __dentry_kill().

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

lift the "already marked killed" case into shrink_dentry_list()

2016-03-03T23:06:46+00:00

commit 64fd72e0a44bdd62c5ca277cb24d0d02b2d8e9dc upstream.

It can happen only when dentry_kill() is called with unlock_on_failure
equal to 0 - other callers had dentry pinned until the moment they've
got ->d_lock and DCACHE_DENTRY_KILLED is set only after lockref_mark_dead().

IOW, only one of three call sites of dentry_kill() might end up reaching
that code.  Just move it there.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman