From: Nick Piggin <npiggin@suse.de>
To: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Andi Kleen <andi@firstfloor.org>,
	Wu Fengguang <fengguang.wu@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] HWPOISON: remove the unsafe __set_page_locked()
Date: Mon, 28 Sep 2009 01:01:18 +0200	[thread overview]
Message-ID: <20090927230118.GH6327@wotan.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0909272251180.4402@sister.anvils>
On Sun, Sep 27, 2009 at 10:57:29PM +0100, Hugh Dickins wrote:
> On Sun, 27 Sep 2009, Nick Piggin wrote:
> > On Sun, Sep 27, 2009 at 05:26:25PM +0100, Hugh Dickins wrote:
> > > 
> > > I don't particularly like adding a GFP_LOCKED just for this, and I
> > > don't particularly like having to remember to unlock the thing on the
> > > various(?) error paths between getting the page and adding it to cache.
> > 
> > God no, please no more crazy branches in the page allocator.
> > 
> > I'm going to resubmit my patches to allow 0-ref page allocations,
> > so the pagecache will be able to work with those to do what we
> > want here.
> >  
> > > But it is a good idea, and if doing it that way would really close a
> > > race window which checking page->mapping (or whatever) cannot (I'm
> > > simply not sure about that), then it would seem the best way to go.
> > 
> > Yep, seems reasonable: the ordering is no technical burden, and a
> > simple comment pointing to hwpoison will keep it maintainable.
> 
> You move from "God no" to "Yep, seems reasonable"!
> 
> I think perhaps you couldn't bring yourself to believe that I was
> giving any support to Andi's GFP_LOCKED idea.  Pretend I did not!
> 
> I'll assume we stick with the "God no", and we'll see how what
> you come up with affects what they want.
Well, yes, I mean "no" to a GFP_LOCKED... If you follow me :)
Reasonable being the basic idea of setting up our flags before we
increment page count, although of course we'd want to see how all
the error cases etc pan out.
There is no real rush AFAIKS to fix this one single pagecache site
while we have problems with slab allocators and all other unaudited
places that nonatomically modify page flags with an elevated
page reference ... just mark HWPOISON as broken for the moment, or
cut it down to do something much simpler I guess?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply	other threads:[~2009-09-28 17:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-26  3:15 [RFC][PATCH] HWPOISON: remove the unsafe __set_page_locked() Wu Fengguang
2009-09-26  3:49 ` Andi Kleen
2009-09-26 10:52   ` Wu Fengguang
2009-09-26 11:31     ` Wu Fengguang
2009-09-27 10:47       ` Wu Fengguang
2009-09-27 19:20         ` Nick Piggin
2009-09-28  8:44           ` Wu Fengguang
2009-09-29  5:16             ` Wu Fengguang
2009-10-01  2:02             ` Nick Piggin
2009-10-02 10:54               ` Wu Fengguang
2009-09-26 11:09 ` Hugh Dickins
2009-09-26 11:48   ` Wu Fengguang
2009-09-26 11:58     ` Hugh Dickins
2009-09-26 15:05     ` Andi Kleen
2009-09-26 19:12       ` Nick Piggin
2009-09-26 19:14     ` Nick Piggin
2009-09-26 19:06   ` Nick Piggin
2009-09-26 21:32     ` Andi Kleen
2009-09-27 16:26       ` Hugh Dickins
2009-09-27 19:22         ` Nick Piggin
2009-09-27 21:57           ` Hugh Dickins
2009-09-27 23:01             ` Nick Piggin [this message]
2009-09-28  1:19               ` Andi Kleen
2009-09-28  1:52                 ` Wu Fengguang
2009-09-28  2:57                 ` Nick Piggin
2009-09-28  4:11                   ` Andi Kleen
2009-09-28  4:29                     ` Nick Piggin
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=20090927230118.GH6327@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=fengguang.wu@intel.com \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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).