[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080210093938.GA12683@one.firstfloor.org>
Date: Sun, 10 Feb 2008 10:39:38 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Andi Kleen <andi@...stfloor.org>, Andi Kleen <ak@...e.de>,
mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [1/5] CPA: Split static_protections into required_static_prot and advised_static_prot
On Sat, Feb 09, 2008 at 06:09:23PM +0100, Thomas Gleixner wrote:
> On Sat, 9 Feb 2008, Andi Kleen wrote:
> > > > 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.
> > >
> > > Your patches do change the behaviour. The range checking breaks the
> > > enforcement of some restrictions for the sake of keeping the large
> > > page intact.
> >
> > You mean in try_preserve_large_page()?
> >
> > No actually they were not completely enforced previously at all, because
> > it did only check the restrictions of the first page.
>
> Right, you poked my nose to it. I did not think about it when I coded
> it. It is wrong and needs to be fixed, but not by the range check you
> introduced.
Well I need the range check for a different piece of code (init_memory_mapping())
For that a range check is definitely needed and the existing code there
also does an (although quite fishy) range check. The DEBUG_RODATA case
is also handled correctly there because DEBUG_RODATA is applied explicitely
using pageattr later.
You have not commented on that at all so I assume it's ok for you.
> > On the end of my patch series the enforcement is actually stricter
> > than it was before, although not 100%.
>
> As far as I can tell it is more relaxed, as it will make overlapping
> regions of rodata and rwdata completely rw instead of splitting it up.
In try_preserve_large_page()? No because it only checks the first page.
In all other cases (in the existing code; my patchkit adds a new case
in mm/init_32.c) it always only checks single 4K pages so the only
overlap case would be sub 4K. For that there can be no split up.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists