From: Andrew Morton <akpm@zip.com.au>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch 6/12] hold atomic kmaps across generic_file_read
Date: Sat, 10 Aug 2002 02:08:59 -0700 [thread overview]
Message-ID: <3D54D82B.87A4E1A9@zip.com.au> (raw)
In-Reply-To: Pine.LNX.4.44.0208100005070.1474-100000@home.transmeta.com
Linus Torvalds wrote:
>
> On Fri, 9 Aug 2002, Andrew Morton wrote:
> >
> > What would be nice is a way of formalising the prefault, to pin
> > the mm's pages across the copy_*_user() in some manner, perhaps?
>
> Too easy to create a DoS-type attack with any trivial implementation.
hmm, yes. The pin has to be held across ->prepare_write. That
tears it.
> However, I don't think pinning is worthwhile, since even if the page goes
> away, the prefaulting was just a performance optimization. The code should
> work fine without it. In fact, it would probably be good to _not_ prefault
> for a development kernel, and verify that the code works without it. That
> way we can sleep safe in the knowledge that there isn't some race through
> code that requires the prefaulting..
OK. That covers reads. But we need to do something short-term to get
these large performance benefits, and I don't know how to properly fix
the write deadlock. The choices here are:
- live with the current __get_user thing
- make filemap_nopage aware of the problem, via a new `struct page *'
in task_struct (this would be very messy on the reader side).
- or?
(Of course, the write deadlock is a different and longstanding
problem, and I don't _have_ to fix it here, weasel, weasel)
> I agree that if you could guarantee pinning the out-of-line code would be
> a bit simpler, but since we have to handle the EFAULT case anyway, I doubt
> that it is _that_ much simpler.
>
> Also, there are actually advantages to doing it the "hard" way. If we ever
> want to, we can actually play clever tricks that avoid doing the copy at
> all with the slow path.
>
> Example tricks: we can, if we want to, do a read() with no copy for a
> common case by adding a COW-bit to the page cache, and if you do aligned
> reads into a page that will fault on write, you can just map in the page
> cache page directly, mark it COW in the page cache (assuming the page
> count tells us we're the only user, of course), and mark it COW in the
> mapping.
glibc malloc currently returns well-aligned-address + 8. If
it were taught to return well-aligned-address+0 then presumably a
lot of applications would automatically benefit from these
zero-copy reads.
next prev parent reply other threads:[~2002-08-10 8:55 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-10 0:57 [patch 6/12] hold atomic kmaps across generic_file_read Andrew Morton
2002-08-10 1:33 ` Linus Torvalds
2002-08-10 3:53 ` Andrew Morton
2002-08-10 3:53 ` Linus Torvalds
2002-08-10 6:12 ` Andrew Morton
2002-08-10 7:25 ` Linus Torvalds
2002-08-10 9:08 ` Andrew Morton [this message]
2002-08-10 12:44 ` Daniel Phillips
2002-08-10 17:01 ` Linus Torvalds
2002-08-10 18:16 ` Daniel Phillips
2002-08-10 18:32 ` Linus Torvalds
2002-08-10 18:46 ` Daniel Phillips
2002-08-10 14:16 ` Rik van Riel
2002-08-10 17:03 ` Linus Torvalds
2002-08-10 17:36 ` Jamie Lokier
2002-08-10 17:46 ` Linus Torvalds
2002-08-10 17:55 ` Jamie Lokier
2002-08-10 18:42 ` Linus Torvalds
2002-08-10 18:52 ` Jeff Garzik
2002-08-10 19:01 ` Christoph Hellwig
2002-08-10 19:04 ` Jeff Garzik
2002-08-12 15:20 ` Ingo Oeser
2002-08-12 0:18 ` Albert D. Cahalan
2002-08-12 14:11 ` Jeff Garzik
2002-08-12 14:46 ` David Woodhouse
2002-08-10 19:10 ` Jamie Lokier
2002-08-10 22:42 ` Linus Torvalds
2002-08-11 3:17 ` Simon Kirby
2002-08-11 6:07 ` Andrew Morton
2002-08-11 8:46 ` Simon Kirby
2002-08-11 9:36 ` Andrew Morton
2002-08-11 9:49 ` Andrew Morton
2002-08-11 10:28 ` Andrew Morton
2002-08-11 18:52 ` Linus Torvalds
2002-08-12 3:28 ` Andrew Morton
2002-08-12 3:27 ` Linus Torvalds
2002-08-12 4:08 ` Andrew Morton
2002-08-12 6:20 ` Simon Kirby
2002-08-12 6:44 ` Andrew Morton
2002-08-12 19:43 ` Trond Myklebust
2002-08-12 20:43 ` Andrew Morton
2002-08-11 8:00 ` Daniel Phillips
2002-08-11 19:00 ` Linus Torvalds
2002-08-11 19:43 ` Daniel Phillips
2002-08-11 0:34 ` Andrew Morton
2002-08-11 0:56 ` Linus Torvalds
2002-08-11 1:27 ` Andrew Morton
2002-08-12 7:45 ` Rusty Russell
2002-08-12 9:45 ` Daniel Phillips
2002-08-12 20:29 ` Linus Torvalds
2002-08-12 21:21 ` Daniel Phillips
2002-08-12 17:30 ` Linus Torvalds
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=3D54D82B.87A4E1A9@zip.com.au \
--to=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox