From: Ingo Molnar <mingo@elte.hu>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
Christoph Lameter <cl@linux-foundation.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
"arjan@linux.intel.com" <arjan@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"hpa@zytor.com" <hpa@zytor.com>,
"andi@firstfloor.org" <andi@firstfloor.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [patch 1/2] x86: track memtype for RAM in page struct - v3
Date: Wed, 1 Oct 2008 11:29:06 +0200 [thread overview]
Message-ID: <20081001092906.GA14912@elte.hu> (raw)
In-Reply-To: <20080930211418.GK15609@linux-os.sc.intel.com>
* Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> On Tue, Sep 30, 2008 at 04:21:28AM -0700, Ingo Molnar wrote:
> >
> > * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> >
> > > On Thursday 25 September 2008 01:53, Venki Pallipadi wrote:
> > >
> > > > /*
> > > > + * RED-PEN: TODO: Add PageReserved() check as well here,
> > > > + * once we add SetPageReserved() to all the drivers using
> > > > + * set_memory_* or set_pages_*.
> > > > + *
> > > > + * This will help prevent accidentally freeing pages
> > > > + * before setting the attribute back to WB.
> > > > + */
> > >
> > > I'd rather we didn't add any more uses of PageReserved without a
> > > really good reason.
> > >
> > > At this point in time (or at least last time I looked, a year or
> > > two ago), it isn't a whole lot of work to remove PG_reserved
> > > completely. If the waters get muddied up again, it could require
> > > another significant rework to remove it in future...
> >
> > agreed.
>
> If a driver by mistake free's a RAM page before changing its memory
> attribute back to WB, we want the generic -mm to catch it.
>
> Today, free_pages_check() prevents freeing the page with PageReserved
> set. We want to use this and make sure that either set_page_uc/wc() or
> the driver calling these API's set the PageReserved bit. There are
> already some drivers which do SetPageReserved() before changing the
> attribute.
no, the generic -mm does not 'catch' PageReserved, it simply _ignores_
it. So i agree about having a debug check there, it's just that what you
propose does not achieve that.
PageReserved is a legacy thing that should not be used in new code.
Using it will only hide bugs and adds quirkiness to the PAT code.
> I don't know the history behind PageReserved. But is there a
> recommended way to achieve what we want? Either we need to use
> PageReserved bit or add some arch specific checks (in the x86 case,
> check arch_1) in free_pages_check(). Right?
the best way i think would be to add arch_1 to PAGE_FLAGS_CHECK_AT_FREE.
That way the mm becomes very noisy if this is ever freed.
Nick, Andrew, any preferences?
Ingo
next prev parent reply other threads:[~2008-10-01 9:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-13 0:00 [patch 0/2] PAT fix/optimization Venkatesh Pallipadi
2008-09-13 0:00 ` [patch 1/2] x86: track memtype for RAM in page struct Venkatesh Pallipadi
2008-09-13 17:03 ` Jeremy Fitzhardinge
2008-09-14 13:29 ` Ingo Molnar
2008-09-14 14:18 ` Jeremy Fitzhardinge
2008-09-14 14:22 ` Ingo Molnar
2008-09-23 21:46 ` Venki Pallipadi
2008-09-23 21:59 ` Christoph Lameter
2008-09-24 15:53 ` [patch 1/2] x86: track memtype for RAM in page struct - v3 Venki Pallipadi
2008-09-27 17:59 ` Ingo Molnar
2008-09-30 7:28 ` Nick Piggin
2008-09-30 11:21 ` Ingo Molnar
2008-09-30 21:14 ` Suresh Siddha
2008-10-01 9:29 ` Ingo Molnar [this message]
2008-10-02 2:27 ` Nick Piggin
2008-09-13 17:24 ` [patch 1/2] x86: track memtype for RAM in page struct Frans Pop
2008-09-14 14:12 ` Ingo Molnar
2008-09-23 21:48 ` Pallipadi, Venkatesh
2008-09-13 0:00 ` [patch 2/2] x86: Handle error returns in set_memory_* Venkatesh Pallipadi
2008-09-14 13:27 ` Ingo Molnar
2008-09-14 14:35 ` Frans Pop
2008-09-14 14:10 ` Ingo Molnar
2008-09-30 8:36 ` Frans Pop
2008-09-30 21:29 ` Suresh Siddha
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=20081001092906.GA14912@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=arjan@linux.intel.com \
--cc=cl@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.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.