All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Suleiman Souhlal <ssouhlal@freebsd.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Suleiman Souhlal <suleiman@google.com>,
	linux-mm <linux-mm@kvack.org>, hugh <hugh@veritas.com>
Subject: Re: [PATCH] mm: avoid dirtying shared mappings on mlock
Date: Fri, 12 Oct 2007 12:50:22 +0200	[thread overview]
Message-ID: <1192186222.27435.22.camel@twins> (raw)
In-Reply-To: <200710120414.11026.nickpiggin@yahoo.com.au>

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

On Fri, 2007-10-12 at 04:14 +1000, Nick Piggin wrote:
> On Friday 12 October 2007 20:37, Peter Zijlstra wrote:
> > On Fri, 2007-10-12 at 02:57 +1000, Nick Piggin wrote:
> > > On Friday 12 October 2007 19:03, Peter Zijlstra wrote:
> > > > Subject: mm: avoid dirtying shared mappings on mlock
> > > >
> > > > Suleiman noticed that shared mappings get dirtied when mlocked.
> > > > Avoid this by teaching make_pages_present about this case.
> > > >
> > > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > > > Acked-by: Suleiman Souhlal <suleiman@google.com>
> > >
> > > Umm, I don't see the other piece of this thread, so I don't
> > > know what the actual problem was.
> > >
> > > But I would really rather not do this. If you do this, then you
> > > now can get random SIGBUSes when you write into the memory if it
> > > can't allocate blocks or ... (some other filesystem specific
> > > condition).
> >
> > I'm not getting this, make_pages_present() only has to ensure all the
> > pages are read from disk and in memory. How is this different from a
> > read-scan?
> 
> I guess because we've mlocked a region that has PROT_WRITE access...
> but actually, I suppose mlock doesn't technically require that we
> can write to the memory, only that the page isn't swapped out.
> 
> Still, it is nice to be able to have a reasonable guarantee of
> writability.
> 
> 
> > The pages will still be read-only due to dirty tracking, so the first
> > write will still do page_mkwrite().
> 
> Which can SIGBUS, no?

Sure, but that is no different than any other mmap'ed write. I'm not
seeing how an mlocked region is special here.

I agree it would be nice if mmap'ed writes would have better error
reporting than SIGBUS, but such is life.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-10-12 10:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-26 23:52 [PATCH] Don't needlessly dirty mlocked pages when initially faulting them in Suleiman Souhlal
2007-07-27  0:23 ` Andrew Morton
2007-07-27  6:33   ` Peter Zijlstra
2007-10-12  6:50     ` Suleiman Souhlal
2007-10-12  9:03       ` [PATCH] mm: avoid dirtying shared mappings on mlock Peter Zijlstra
2007-10-11 16:57         ` Nick Piggin
2007-10-11 16:57           ` Nick Piggin
2007-10-11 17:07           ` Nick Piggin
2007-10-11 17:07             ` Nick Piggin
2007-10-12 10:37           ` Peter Zijlstra
2007-10-11 18:14             ` Nick Piggin
2007-10-11 18:14               ` Nick Piggin
2007-10-12 10:50               ` Peter Zijlstra [this message]
2007-10-12 12:23                 ` Nick Piggin
2007-10-12 12:23                   ` Nick Piggin
2007-10-12 14:53                 ` Arjan van de Ven
2007-10-12 14:53                   ` Arjan van de Ven
2007-10-12 14:58                   ` Peter Zijlstra
2007-10-12 17:45                     ` Suleiman Souhlal
2007-10-12 17:45                       ` Suleiman Souhlal
2007-10-12 17:53                       ` Arjan van de Ven
2007-10-12 17:53                         ` Arjan van de Ven
2007-10-12 18:02                       ` Peter Zijlstra
2007-10-12 18:02                         ` Peter Zijlstra
2007-10-12 13:10     ` [PATCH] Don't needlessly dirty mlocked pages when initially faulting them in Mauro Giachero

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=1192186222.27435.22.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=ssouhlal@freebsd.org \
    --cc=suleiman@google.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.