linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	William Lee Irwin III <wli@movementarian.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: pud_bad vs pud_bad
Date: Thu, 5 Feb 2009 20:12:44 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0902052004550.12955@blonde.anvils> (raw)
In-Reply-To: <20090205194932.GB3129@elte.hu>

On Thu, 5 Feb 2009, Ingo Molnar wrote:
> * Hugh Dickins <hugh@veritas.com> wrote:
> > 
> > Simpler and more compact, but not as strict: in particular, a value of
> > 0 or 1 is identified as bad by that 64-bit test, but not by the 32-bit.
> 
> yes, indeed you are right - the 64-bit test does not allow the KERNPG_TABLE 
> bits to go zero.
> 
> Those are the present, rw, accessed and dirty bits. Do they really matter 
> that much? If a toplevel entry goes !present or readonly, we notice that 
> _fast_, without any checks. If it goes !access or !dirty - does that matter?

I've not given it a great deal of thought, why this or that bit.
These p??_bad checks originate from 2.4 or earlier, and by mistake
got weakened somewhere along the way, and last time it was discussed
we agreed to strenghthen them (and IIRC Jeremy himself did so).

> 
> These checks are done all the time, and even a single instruction can count. 
> The bits that are checked are enough to notice random memory corruption.

Well, I am surprised that you would be arguing for weakening such
a very simple check.

Hugh

--
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>

  parent reply	other threads:[~2009-02-05 20:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-05 18:23 Jeremy Fitzhardinge
2009-02-05 18:43 ` Ingo Molnar
2009-02-05 18:54   ` Jeremy Fitzhardinge
2009-02-05 19:10     ` Ingo Molnar
2009-02-05 19:26       ` Jeremy Fitzhardinge
2009-02-05 19:31         ` Ingo Molnar
2009-02-05 19:38       ` Hugh Dickins
2009-02-05 19:49         ` Ingo Molnar
2009-02-05 19:58           ` wli
2009-02-05 20:14             ` Hugh Dickins
2009-02-05 20:56               ` wli
2009-02-05 21:09                 ` Hugh Dickins
2009-02-05 20:12           ` Hugh Dickins [this message]
2009-02-05 20:42         ` Jeremy Fitzhardinge
2009-02-05 20:51           ` Hugh Dickins
2009-02-05 21:05             ` Jeremy Fitzhardinge
2009-02-05 21:50               ` Ingo Molnar
2009-02-05 22:07                 ` Jeremy Fitzhardinge
2009-02-05 23:42                   ` Ingo Molnar
2009-02-06  0:08                     ` Jeremy Fitzhardinge
2009-02-06  0:50                       ` Ingo Molnar
2009-02-05 20:57           ` Ingo Molnar

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=Pine.LNX.4.64.0902052004550.12955@blonde.anvils \
    --to=hugh@veritas.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=wli@movementarian.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