public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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