All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Anna Schumaker <Anna.Schumaker@netapp.com>
Subject: Re: parallel lookups on NFS
Date: Sun, 1 May 2016 00:31:38 +0100	[thread overview]
Message-ID: <20160430233138.GF25498@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1462055616.10011.62.camel@poochiereds.net>

On Sat, Apr 30, 2016 at 06:33:36PM -0400, Jeff Layton wrote:
> I'll do the same (re: KASAN).
> 
> Also FWIW, a few months ago I hit some oopses in the same inline
> function (get_freepointer). It turned out to be a double-free due to my
> own misuse of the fsnotify API. I wonder though if this might also be a
> double free somewhere?

It is a double-free somewhere, all right...  What happens there is that
nfs_readdir really relies upon being the only thread to manipulate the
page cache of that directory.  We get nfs_revalidate_mapping() called
and if it ends up evicting a page currently in use by nfs_do_filldir(),
you get nfs_readdir_clear_array() called _twice_ - once on kicking it
out of page cache (and those kfree of the names are obviously Not Good(tm)
for nfs_do_filldir() copying those names to userland) and then when
nfs_do_filldir() gets to cache_page_release().

Sigh...

  reply	other threads:[~2016-04-30 23:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-24  2:34 parallel lookups on NFS Al Viro
2016-04-24 12:46 ` Jeff Layton
2016-04-24 19:18   ` Al Viro
2016-04-24 19:18     ` Al Viro
2016-04-24 20:51     ` Jeff Layton
2016-04-29  7:58     ` Al Viro
2016-04-30 13:15       ` Jeff Layton
2016-04-30 13:15         ` Jeff Layton
2016-04-30 13:22         ` Jeff Layton
2016-04-30 14:22           ` Al Viro
2016-04-30 14:22             ` Al Viro
2016-04-30 14:43             ` Jeff Layton
2016-04-30 18:58               ` Al Viro
2016-04-30 18:58                 ` Al Viro
2016-04-30 19:29                 ` Al Viro
     [not found]                   ` <1462048765.10011.44.camel@poochiereds.net>
2016-04-30 20:57                     ` Al Viro
2016-04-30 22:17                       ` Jeff Layton
2016-04-30 22:33                       ` Jeff Layton
2016-04-30 23:31                         ` Al Viro [this message]
2016-05-01  0:02                           ` Al Viro
2016-05-01  0:18                             ` Al Viro
2016-05-01  1:08                               ` Al Viro
2016-05-01 13:35                                 ` Jeff Layton
2016-04-30 23:23                       ` Jeff Layton
2016-04-30 23:29                         ` 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=20160430233138.GF25498@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=Anna.Schumaker@netapp.com \
    --cc=jlayton@poochiereds.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=trond.myklebust@primarydata.com \
    /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.