From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] Please pull NFS client bugfixes....
Date: Thu, 07 Jan 2010 20:22:32 -0500 [thread overview]
Message-ID: <1262913752.2659.100.camel@localhost> (raw)
In-Reply-To: <alpine.LFD.2.00.1001071707430.7821@localhost.localdomain>
On Thu, 2010-01-07 at 17:12 -0800, Linus Torvalds wrote:
>
> On Thu, 7 Jan 2010, Trond Myklebust wrote:
> > >
> > > Because it means that you can trivially take page faults before the thing
> > > is validated (think threads).
> >
> > Which would mean that another process/thread already has part of the
> > file mmapped on the same client. I'm not arguing that have to revalidate
> > in _that_ case.
>
> No, I'm talking about the new mapping. Nothing else.
>
> If the mmap'ing thread releases mmap_sem, and then does the revalidate,
> then you can have
>
> thread1 thread2
> ------- -------
>
> mmap
> map it in
> release mmap_sem
> page-fault the mapping before it got validated
> ->post_mmap()
> revalidate outside mmap_sem
>
> See? No "already part of the file mmapped" case at all. The exact mmap
> that you just set up - without the revalidation having happened.
>
> In fact, because of this kind of _fundamental_ race, I don't see why I
> would ever accept any patches that add multiple mmap() down-calls at
> different phases to the filesystem at the VFS layer.
>
> A filesystem that depends on the different phases would be a fundamentally
> buggy filesystem. Right now mmap is "atomic", and you can pre-populate (or
> pre-verify, like NFS does) the mapping in the _knowledge_ that there are
> no page faults that will populate it concurrently. Exactly because we hold
> the mmap_sem for writing.
I don't think anyone has been advocating doing the revalidation _after_
the call to mmap_region(). All I want is to be able to do it as part of
the mmap() syscall. It would be quite OK to add a ->pre_mmap() (which is
what I believe Peter's patches do).
All I want to ensure is that people who use non-posix-lock based
synchronisation can set the 'noac' flag, and be assured that if mmap()
is called _after_ they have grabbed their lock, then the page cache will
be duly revalidated (under the lock), and the fresh data will be made
available.
Trond
next prev parent reply other threads:[~2010-01-08 1:22 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-07 20:29 [GIT PULL] Please pull NFS client bugfixes Trond Myklebust
2010-01-07 21:00 ` Andi Kleen
2010-01-07 21:23 ` Peter Staubach
2010-01-07 21:35 ` Andi Kleen
2010-01-07 21:53 ` Trond Myklebust
2010-01-07 23:51 ` Andi Kleen
2010-01-08 0:14 ` Trond Myklebust
2010-01-08 0:34 ` Linus Torvalds
2010-01-08 0:45 ` Andi Kleen
2010-01-08 1:03 ` Trond Myklebust
2010-01-08 1:03 ` Trond Myklebust
2010-01-08 1:12 ` Linus Torvalds
2010-01-08 1:22 ` Trond Myklebust [this message]
2010-01-08 1:26 ` Trond Myklebust
2010-01-09 0:56 ` [RFC PATCH 0/2] Fix up the NFS mmap code Trond Myklebust
2010-01-09 0:56 ` [RFC PATCH 2/2] NFS: Fix a potential deadlock in nfs_file_mmap() Trond Myklebust
2010-01-09 1:54 ` Al Viro
2010-01-09 0:56 ` [RFC PATCH 1/2] VFS: Add a mmap_file() callback to struct file_operations Trond Myklebust
2010-01-09 1:17 ` [RFC PATCH 0/2] Fix up the NFS mmap code Linus Torvalds
2010-01-09 1:38 ` Al Viro
2010-01-09 1:46 ` Al Viro
2010-01-09 1:57 ` Linus Torvalds
2010-01-09 2:11 ` Al Viro
2010-01-09 2:22 ` Linus Torvalds
2010-01-09 2:30 ` Al Viro
2010-01-09 2:40 ` Al Viro
2010-01-09 2:43 ` Al Viro
2010-01-10 2:00 ` Andi Kleen
2010-01-08 1:30 ` [GIT PULL] Please pull NFS client bugfixes Linus Torvalds
2010-01-08 1:35 ` Linus Torvalds
2010-01-08 2:00 ` Linus Torvalds
2010-01-14 13:18 ` Peter Zijlstra
2010-01-08 5:19 ` Andi Kleen
2010-01-08 1:22 ` Linus Torvalds
2010-01-08 0:43 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2023-01-07 18:09 Trond Myklebust
2023-01-07 18:43 ` pr-tracker-bot
2022-09-12 21:34 Trond Myklebust
2022-09-12 21:57 ` pr-tracker-bot
2021-01-12 14:31 Trond Myklebust
2021-01-12 18:00 ` pr-tracker-bot
2020-09-28 17:27 Trond Myklebust
2020-09-28 18:16 ` pr-tracker-bot
2020-05-15 21:00 Trond Myklebust
2020-05-15 21:10 ` pr-tracker-bot
2020-05-02 13:35 Trond Myklebust
2020-05-02 18:45 ` pr-tracker-bot
2019-08-27 19:26 Trond Myklebust
2019-08-27 20:55 ` pr-tracker-bot
2019-08-08 21:26 Trond Myklebust
2019-08-09 1:30 ` pr-tracker-bot
2019-06-05 21:02 Schumaker, Anna
2019-04-13 14:56 Trond Myklebust
2019-04-13 22:00 ` pr-tracker-bot
2018-12-19 16:49 Trond Myklebust
2018-12-20 2:50 ` pr-tracker-bot
2018-12-20 15:23 ` Geert Uytterhoeven
2018-03-12 17:29 Trond Myklebust
2018-02-25 17:02 Trond Myklebust
2017-01-28 17:04 Trond Myklebust
2017-01-16 20:14 Trond Myklebust
2016-10-21 20:30 Anna Schumaker
2015-10-07 2:52 Trond Myklebust
2015-09-25 15:14 Trond Myklebust
2015-07-28 16:03 Trond Myklebust
2015-03-06 3:46 Trond Myklebust
2015-01-29 21:37 Trond Myklebust
2015-01-16 14:35 Trond Myklebust
2014-11-14 23:04 Trond Myklebust
2014-09-19 19:32 Trond Myklebust
2014-01-31 21:41 Trond Myklebust
2013-12-05 17:20 Trond Myklebust
2013-11-16 21:09 Myklebust, Trond
2013-09-30 22:02 Myklebust, Trond
2013-05-26 19:29 Myklebust, Trond
2013-03-26 18:26 Myklebust, Trond
2013-03-03 0:08 Myklebust, Trond
2013-02-21 3:38 Myklebust, Trond
2013-01-07 15:45 Myklebust, Trond
2012-11-03 19:48 Myklebust, Trond
2012-10-22 17:42 Myklebust, Trond
2012-09-12 19:19 Myklebust, Trond
2012-07-13 15:14 Myklebust, Trond
2012-05-02 3:57 Myklebust, Trond
2012-04-24 20:18 [GIT PULL] please " Myklebust, Trond
2011-12-20 6:15 [GIT PULL] Please " Trond Myklebust
2011-11-22 11:50 Trond Myklebust
2011-08-19 1:05 Trond Myklebust
2011-07-12 23:30 Trond Myklebust
2011-05-13 20:23 Trond Myklebust
2011-04-08 18:40 [GIT PULL] please " Trond Myklebust
2011-03-14 18:09 [GIT PULL] Please " Trond Myklebust
2010-11-26 18:56 Trond Myklebust
2010-05-26 19:42 Trond Myklebust
2010-05-07 2:22 Trond Myklebust
2010-04-29 16:48 Trond Myklebust
2010-03-23 17:00 Trond Myklebust
2010-03-17 21:55 Trond Myklebust
2010-02-04 19:10 Trond Myklebust
2009-05-26 19:06 Trond Myklebust
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=1262913752.2659.100.camel@localhost \
--to=trond.myklebust@netapp.com \
--cc=andi@firstfloor.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).