From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Howells <dhowells@redhat.com>
Cc: "Ted Ts'o" <tytso@mit.edu>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
Al Viro <viro@zeniv.linux.org.uk>, Linux-MM <linux-mm@kvack.org>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Do we need to unrevert "fs: do not prefault sys_write() user buffer pages"?
Date: Tue, 22 Jun 2021 08:53:05 -0700 [thread overview]
Message-ID: <CAHk-=wjLM_W6W-gk7EJ69Yaoq54x_zj+BJs3Xxt5QRPSDaKCKg@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wgM0ZMqY9fuYx0H6UninvbZjMyJeL=7Zz4=AmtO98QncA@mail.gmail.com>
On Tue, Jun 22, 2021 at 8:32 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> But yes, it could get unmapped again before the actual copy happens
> with the lock held. But that's why the copy is using that atomic
> version, so if that happens, we'll end up repeating.
Side note: search for "iov_iter_fault_in_writeable()" on lkml for a
gfs2 patch-series that is buggy, exactly because it does *not* use the
atomic user space accesses, and just tries to do the fault-in to hide
the real bug.
So you are correct that the fault-in is something people need to be
very wary of. Without the atomic side of the access, it's pure voodoo
programming.
You have two choices:
- don't hold any filesystem locks (*) over a user space access
- do the user space access with the atomic versions and repeat (with
pre-faulting to make the repeat work)
There's one special case of that "no filesystem locks" case that I put
that (*) for: you could do a read-recursive lock if the filesystem
page fault path can only ever take read locks. But none of our regular
locks are read-recursive apart from the very special case of the
spinning rwlock in interrupts (see comment in
queued_read_lock_slowpath()).
That special read-recursive model "works", but I would seriously
caution against it, simply because such locks can get very unfair very
quickly. So it's a DoS magnet. It's part of why none of the normal
locking models really have that (any more - rwlocks used to all be
that way).
Linus
next prev parent reply other threads:[~2021-06-22 15:53 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 15:20 Do we need to unrevert "fs: do not prefault sys_write() user buffer pages"? David Howells
2021-06-22 15:27 ` Al Viro
2021-06-22 15:36 ` Al Viro
2021-06-22 17:25 ` Matthew Wilcox
2021-06-22 17:39 ` Linus Torvalds
2021-06-22 17:55 ` David Howells
2021-06-22 18:04 ` Matthew Wilcox
2021-06-22 18:07 ` Linus Torvalds
2021-06-22 18:16 ` Nadav Amit
2021-06-22 18:23 ` Matthew Wilcox
2021-06-22 18:28 ` Linus Torvalds
2021-06-22 18:36 ` Matthew Wilcox
2021-06-22 18:51 ` Nadav Amit
2021-06-22 18:57 ` Linus Torvalds
2021-06-22 18:23 ` David Howells
2021-06-22 18:32 ` Linus Torvalds
2021-06-22 18:13 ` David Howells
2021-06-22 15:32 ` Linus Torvalds
2021-06-22 15:53 ` Linus Torvalds [this message]
2021-06-22 15:32 ` Matthew Wilcox
2021-06-22 16:27 ` David Howells
2021-06-22 21:55 ` David Laight
2021-06-22 22:04 ` Matthew Wilcox
2021-06-22 22:31 ` David Laight
2021-06-22 22:20 ` Dave Chinner
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='CAHk-=wjLM_W6W-gk7EJ69Yaoq54x_zj+BJs3Xxt5QRPSDaKCKg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=dhowells@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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).