LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@suse.de>, mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [1/5] CPA: Split static_protections into required_static_prot and advised_static_prot
Date: Sat, 9 Feb 2008 16:13:22 +0100	[thread overview]
Message-ID: <20080209151322.GB6773@basil.nowhere.org> (raw)
In-Reply-To: <alpine.LFD.1.00.0802091525400.3145@apollo.tec.linutronix.de>

On Sat, Feb 09, 2008 at 03:56:02PM +0100, Thomas Gleixner wrote:
> On Fri, 8 Feb 2008, Andi Kleen wrote:
> > There is a big difference between NX and RO. NX absolutely has to be cleared
> > or the kernel will fail while RO just can be set, but does not need to.
> > And for a large page area not setting NX if there is a area below 
> > it that needs it is essential, while making it ro is optional again.

Optional as in it doesn't need to be forced.

> 
> No, it's not optional. Making the PMD RO will write protect all 4k
> PTEs below independent of their setting. So there is the same
> restriction as we have with NX.

If there is a boundary between a RO area
and a RW area and you want to map it with 2MB pages then NX is required,
but RO is optional on the page and if you prefer TLB use minimalization
over debugging it is optional. Is it clear now? 

Note the behaviour for pageattr and thus DEBUG_RODATA / debugging
sitations where you don't care about your TLB this
does not change, this makes only a difference for the initial init_32
direct mapping setup.

-Andi

  reply	other threads:[~2008-02-09 15:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-08 16:36 [PATCH] [0/5] pageattr protection patchkit v2 for the latest kernel Andi Kleen
2008-02-08 16:36 ` [PATCH] [1/5] CPA: Split static_protections into required_static_prot and advised_static_prot Andi Kleen
2008-02-09 14:56   ` Thomas Gleixner
2008-02-09 15:13     ` Andi Kleen [this message]
2008-02-09 15:50       ` Thomas Gleixner
2008-02-09 16:39         ` Andi Kleen
2008-02-09 17:09           ` Thomas Gleixner
2008-02-10  9:39             ` Andi Kleen
2008-02-08 16:36 ` [PATCH] [2/5] Support range checking for required/advisory protections Andi Kleen
2008-02-08 16:36 ` [PATCH] [3/5] CPA: Make advised protection check truly advisory Andi Kleen
2008-02-09 15:38   ` Thomas Gleixner
2008-02-09 16:56     ` Andi Kleen
2008-02-09 17:38       ` Thomas Gleixner
2008-02-10  9:19         ` Andi Kleen
2008-02-10 16:50           ` Thomas Gleixner
2008-02-08 16:36 ` [PATCH] [4/5] Don't use inline for the protection checks Andi Kleen
2008-02-08 16:36 ` [PATCH] [5/5] Switch i386 early boot page table initialization over to use required_static_prot() Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2008-02-08 13:27 [PATCH] [1/5] CPA: Split static_protections into required_static_prot and advised_static_prot Andi Kleen

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=20080209151322.GB6773@basil.nowhere.org \
    --to=andi@firstfloor.org \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH] [1/5] CPA: Split static_protections into required_static_prot and advised_static_prot' \
    /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

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