All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: "<linux-kernel@vger.kernel.org> Mailing List"
	<linux-kernel@vger.kernel.org>,
	"<linux-fsdevel@vger.kernel.org>" <linux-fsdevel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Dcache oops
Date: Fri, 3 Jun 2016 23:17:36 +0100	[thread overview]
Message-ID: <20160603221736.GV14480@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20160603214630.GU14480@ZenIV.linux.org.uk>

On Fri, Jun 03, 2016 at 10:46:31PM +0100, Al Viro wrote:
> On Fri, Jun 03, 2016 at 05:17:06PM -0400, Oleg Drokin wrote:
> 
> > > Can the same thing be reproduced (with NFS fix) on v4.6, ede4090, 7f427d3,
> > > 4e8440b?
> > 
> > Well, that was faster than I expected. 4e8440b triggers right away, so I guess
> > there's no point in trying the later ones?
> > BTW, just to confirm you are noticing - this is a DEBUG_PAGEALLOC build,
> > so all freed memory is unmapped which is likely causing this oops - as a sign
> > of use after free.
>  
> > [   54.990119] BUG: unable to handle kernel paging request at ffff8800d2b7f000
> 
> Again a page-aligned nd->last.name and even smaller nd->last.len.  It smells
> like a page that used to contain a symlink body, but got freed under us.

OK, I think I understand what's going on there.  We have a pathname that ends
with a trailing symlink.  Traverse that symlink up to the last component.  And
get EOPENSTALE on attempt to open that.  At that point we proceed to
retry_lookup: and call lookup_open().  But we'd *already* done put_link()
on the first pass, so now nd->last.name points into freed page.

Damn...  I'm very tempted to rip the retry_lookup logics out of there and
just let the damn thing repeat the whole pathname resolution ;-/  do_last()
will become so much saner after that...

Let's at least verify that this is what's going on - remove
                if (error == -EOPENSTALE)
                        goto stale_open;
from do_last() and see if that fixes the damn thing.  Alternative solution
would be to turn that
        if (nd->depth)
                put_link(nd);
        error = should_follow_link(nd, &path, nd->flags & LOOKUP_FOLLOW,
                                   inode, seq);
        if (unlikely(error))
                return error;
in do_last() into
        error = should_follow_link(nd, &path, nd->flags & LOOKUP_FOLLOW,
                                   inode, seq);
	if (unlikely(error)) {
		if (nd->depth == 2) {
			struct saved *last = nd->stack[0];
			do_delayed_call(&last->done);
			if (!(nd->flags & LOOKUP_RCU))
				path_put(&last->link);
			nd->stack[0] = nd->stack[1];
			nd->depth--;
		}
		return error;
	}	
but I would really prefer the first approach - it allows to remove arseloads
of convoluted crap from do_last().

  reply	other threads:[~2016-06-03 22:17 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-02 22:46 NFS/d_splice_alias breakage Oleg Drokin
2016-06-02 23:59 ` [PATCH] Allow d_splice_alias to accept hashed dentries green
2016-06-03  0:25   ` Oleg Drokin
2016-06-03  0:44 ` NFS/d_splice_alias breakage Trond Myklebust
2016-06-03  0:44   ` Trond Myklebust
2016-06-03  0:54   ` Oleg Drokin
2016-06-03  0:54     ` Oleg Drokin
2016-06-03  3:26     ` Al Viro
2016-06-03  3:38       ` Al Viro
2016-06-03  3:28   ` Al Viro
2016-06-03  3:37 ` Al Viro
2016-06-03  3:43   ` Oleg Drokin
2016-06-03  4:26     ` Al Viro
2016-06-03  4:42       ` Al Viro
2016-06-03  4:53         ` Al Viro
2016-06-03  4:58       ` Oleg Drokin
2016-06-03  5:56         ` Al Viro
2016-06-06 23:36           ` Oleg Drokin
2016-06-10  1:33             ` Oleg Drokin
2016-06-10 16:49               ` Oleg Drokin
2016-06-20 13:25           ` Oleg Drokin
2016-06-20 14:08             ` Al Viro
2016-06-20 14:54               ` Trond Myklebust
2016-06-20 14:54                 ` Trond Myklebust
2016-06-20 15:28                 ` Al Viro
2016-06-20 15:43               ` Anna Schumaker
2016-06-20 15:45                 ` Oleg Drokin
2016-06-20 15:47                 ` Trond Myklebust
2016-06-20 15:47                   ` Trond Myklebust
2016-06-03 16:38       ` Dcache oops Oleg Drokin
2016-06-03 18:22         ` Al Viro
2016-06-03 18:35           ` Oleg Drokin
2016-06-03 20:07             ` Al Viro
2016-06-03 21:17               ` Oleg Drokin
2016-06-03 21:46                 ` Al Viro
2016-06-03 22:17                   ` Al Viro [this message]
2016-06-03 21:18               ` Linus Torvalds
2016-06-03 21:26                 ` Al Viro
2016-06-03 22:00                   ` Linus Torvalds
2016-06-03 22:23                     ` Al Viro
2016-06-03 22:29                       ` Al Viro
2016-06-03 22:36                       ` Linus Torvalds
2016-06-03 22:42                         ` Oleg Drokin
2016-06-03 22:43                         ` Al Viro
2016-06-03 22:37                       ` Al Viro
2016-06-03 22:49                         ` Oleg Drokin
2016-06-03 23:58                         ` Oleg Drokin
2016-06-04  0:56                           ` Al Viro
2016-06-04 12:25                             ` Jeff Layton
2016-06-04 16:12                             ` Oleg Drokin
2016-06-04 16:21                               ` [PATCH] nfs4: Fix potential use after free of state in nfs4_do_reclaim green
2016-06-04 19:57                                 ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160603221736.GV14480@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=green@linuxhacker.ru \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.