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

move the call of __d_drop(anon) into __d_materialise_unique(dentry, anon)

2017-06-20T12:04:14+00:00

commit 6f18493e541c690169c3b1479d47d95f624161cf upstream.

and lock the right list there

Signed-off-by: Al Viro 
Acked-by: NeilBrown 
Signed-off-by: Jiri Slaby 
Signed-off-by: Willy Tarreau

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

2016-08-27T09:39:59+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 
[wt: add the required change to __d_materialise_dentry() for kernels
  older than v3.17]
Signed-off-by: Willy Tarreau

dcache: Handle escaped paths in prepend_path

2015-10-22T21:37:52+00:00

commit cde93be45a8a90d8c264c776fab63487b5038a65 upstream.

A rename can result in a dentry that by walking up d_parent
will never reach it's mnt_root.  For lack of a better term
I call this an escaped path.

prepend_path is called by four different functions __d_path,
d_absolute_path, d_path, and getcwd.

__d_path only wants to see paths are connected to the root it passes
in.  So __d_path needs prepend_path to return an error.

d_absolute_path similarly wants to see paths that are connected to
some root.  Escaped paths are not connected to any mnt_root so
d_absolute_path needs prepend_path to return an error greater
than 1.  So escaped paths will be treated like paths on lazily
unmounted mounts.

getcwd needs to prepend "(unreachable)" so getcwd also needs
prepend_path to return an error.

d_path is the interesting hold out.  d_path just wants to print
something, and does not care about the weird cases.  Which raises
the question what should be printed?

Given that / should result in -ENOENT I
believe it is desirable for escaped paths to be printed as empty
paths.  As there are not really any meaninful path components when
considered from the perspective of a mount tree.

So tweak prepend_path to return an empty path with an new error
code of 3 when it encounters an escaped path.

Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

vfs: Remove incorrect debugging WARN in prepend_path

2015-10-01T10:07:38+00:00

commit 93e3bce6287e1fb3e60d3324ed08555b5bbafa89 upstream.

The warning message in prepend_path is unclear and outdated.  It was
added as a warning that the mechanism for generating names of pseudo
files had been removed from prepend_path and d_dname should be used
instead.  Unfortunately the warning reads like a general warning,
making it unclear what to do with it.

Remove the warning.  The transition it was added to warn about is long
over, and I added code several years ago which in rare cases causes
the warning to fire on legitimate code, and the warning is now firing
and scaring people for no good reason.

Reported-by: Ivan Delalande 
Reported-by: Omar Sandoval 
Fixes: f48cfddc6729e ("vfs: In d_path don't call d_dname on a mount point")
Signed-off-by: "Eric W. Biederman" 
[ vlee: Backported to 3.10. Adjusted context. ]
Signed-off-by: Vinson Lee 
Signed-off-by: Greg Kroah-Hartman

freeing unlinked file indefinitely delayed

2015-08-10T19:20:29+00:00

commit 75a6f82a0d10ef8f13cd8fe7212911a0252ab99e upstream.

	Normally opening a file, unlinking it and then closing will have
the inode freed upon close() (provided that it's not otherwise busy and
has no remaining links, of course).  However, there's one case where that
does *not* happen.  Namely, if you open it by fhandle with cold dcache,
then unlink() and close().

	In normal case you get d_delete() in unlink(2) notice that dentry
is busy and unhash it; on the final dput() it will be forcibly evicted from
dcache, triggering iput() and inode removal.  In this case, though, we end
up with *two* dentries - disconnected (created by open-by-fhandle) and
regular one (used by unlink()).  The latter will have its reference to inode
dropped just fine, but the former will not - it's considered hashed (it
is on the ->s_anon list), so it will stay around until the memory pressure
will finally do it in.  As the result, we have the final iput() delayed
indefinitely.  It's trivial to reproduce -

void flush_dcache(void)
{
        system("mount -o remount,rw /");
}

static char buf[20 * 1024 * 1024];

main()
{
        int fd;
        union {
                struct file_handle f;
                char buf[MAX_HANDLE_SZ];
        } x;
        int m;

        x.f.handle_bytes = sizeof(x);
        chdir("/root");
        mkdir("foo", 0700);
        fd = open("foo/bar", O_CREAT | O_RDWR, 0600);
        close(fd);
        name_to_handle_at(AT_FDCWD, "foo/bar", &x.f, &m, 0);
        flush_dcache();
        fd = open_by_handle_at(AT_FDCWD, &x.f, O_RDWR);
        unlink("foo/bar");
        write(fd, buf, sizeof(buf));
        system("df .");			/* 20Mb eaten */
        close(fd);
        system("df .");			/* should've freed those 20Mb */
        flush_dcache();
        system("df .");			/* should be the same as #2 */
}

will spit out something like
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/root         322023 303843      1131 100% /
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/root         322023 303843      1131 100% /
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/root         322023 283282     21692  93% /
- inode gets freed only when dentry is finally evicted (here we trigger
than by remount; normally it would've happened in response to memory
pressure hell knows when).

Acked-by: J. Bruce Fields 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

d_walk() might skip too much

2015-07-04T02:48:09+00:00

When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called "d_walk() might skip too much".

3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.

The patch below was not written by me. I only applied Al Viro's "d_walk()
might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.

Signed-off-by: Jari Ruusu 
Cc: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman

d_walk() might skip too much

2015-06-06T06:19:54+00:00

commit 2159184ea01e4ae7d15f2017e296d4bc82d5aeb0 upstream.

when we find that a child has died while we'd been trying to ascend,
we should go into the first live sibling itself, rather than its sibling.

Off-by-one in question had been introduced in "deal with deadlock in
d_walk()" and the fix needs to be backported to all branches this one
has been backported to.

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

dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"

2015-04-29T08:34:02+00:00

commit 20defcec264ceab2630356fb9d397f3d237b5e6d upstream in 3.2-stable

Steven Rostedt reported:
> Porting -rt to the latest 3.2 stable tree I triggered this bug:
>
> =====================================
> [ BUG: bad unlock balance detected! ]
> -------------------------------------
> rm/1638 is trying to release lock (rcu_read_lock) at:
> [] rcu_read_unlock+0x0/0x23
> but there are no more locks to release!
>
> other info that might help us debug this:
> 2 locks held by rm/1638:
>  #0:  (&sb->s_type->i_mutex_key#9/1){+.+.+.}, at: [] do_rmdir+0x5f/0xd2
>  #1:  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [] vfs_rmdir+0x49/0xac
>
> stack backtrace:
> Pid: 1638, comm: rm Not tainted 3.2.66-test-rt96+ #2
> Call Trace:
>  [] ? printk+0x1d/0x1f
>  [] print_unlock_inbalance_bug+0xc3/0xcd
>  [] lock_release_non_nested+0x98/0x1ec
>  [] ? trace_hardirqs_off_caller+0x18/0x90
>  [] ? local_clock+0x2d/0x50
>  [] ? d_hash+0x2f/0x2f
>  [] ? d_hash+0x2f/0x2f
>  [] lock_release+0x192/0x1ad
>  [] rcu_read_unlock+0x17/0x23
>  [] shrink_dcache_parent+0x227/0x270
>  [] vfs_rmdir+0x68/0xac
>  [] do_rmdir+0x98/0xd2
>  [] ? fput+0x1a3/0x1ab
>  [] ? sysenter_exit+0xf/0x1a
>  [] ? trace_hardirqs_on_caller+0x118/0x149
>  [] sys_unlinkat+0x2b/0x35
>  [] sysenter_do_call+0x12/0x12
>
>
>
>
> There's a path to calling rcu_read_unlock() without calling
> rcu_read_lock() in have_submounts().
>
> 	goto positive;
>
> positive:
> 	if (!locked && read_seqretry(&rename_lock, seq))
> 		goto rename_retry;
>
> rename_retry:
> 	rcu_read_unlock();
>
> in the above path, rcu_read_lock() is never done before calling
> rcu_read_unlock();

I reviewed locking contexts in all three functions that I changed when
backporting "deal with deadlock in d_walk()".  It's actually worse
than this:

- We don't hold this_parent->d_lock at the 'positive' label in
  have_submounts(), but it is unlocked after 'rename_retry'.
- There is an rcu_read_unlock() after the 'out' label in
  select_parent(), but it's not held at the 'goto out'.

Fix all three lock imbalances.

Reported-by: Steven Rostedt 
Signed-off-by: Ben Hutchings 
Tested-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman

deal with deadlock in d_walk()

2015-04-29T08:34:00+00:00

commit ca5358ef75fc69fee5322a38a340f5739d997c10 upstream.

... by not hitting rename_retry for reasons other than rename having
happened.  In other words, do _not_ restart when finding that
between unlocking the child and locking the parent the former got
into __dentry_kill().  Skip the killed siblings instead...

Signed-off-by: Al Viro 
Cc: Ben Hutchings 
[hujianyang: Backported to 3.10 refer to the work of Ben Hutchings in 3.2:
 - As we only have try_to_ascend() and not d_walk(), apply this
   change to all callers of try_to_ascend()
 - Adjust context to make __dentry_kill() apply to d_kill()]
Signed-off-by: hujianyang 
Signed-off-by: Greg Kroah-Hartman

move d_rcu from overlapping d_child to overlapping d_alias

2015-04-29T08:34:00+00:00

commit 946e51f2bf37f1656916eb75bd0742ba33983c28 upstream.

Signed-off-by: Al Viro 
Cc: Ben Hutchings 
[hujianyang: Backported to 3.10 refer to the work of Ben Hutchings in 3.2:
 - Apply name changes in all the different places we use d_alias and d_child
 - Move the WARN_ON() in __d_free() to d_free() as we don't have dentry_free()]
Signed-off-by: hujianyang 
Signed-off-by: Greg Kroah-Hartman