Re: [PATCH] Support for unconditional page sanitization

[pageexec@freemail.hu]

On 23 May 2009 at 14:05, Arjan van de Ven wrote:

> On Sat, 23 May 2009 11:21:41 -0700
> "Larry H." <research@subreption.com> wrote:
> 
> > +static inline void sanitize_highpage(struct page *page)
> 
> any reason we're not reusing clear_highpage() for this?
> (I know it's currently slightly different, but that is fixable)

KM_USER0 users are not supposed to be called from soft/hard irq
contexts for high memory pages, something that cannot be guaranteed
at this low level of page freeing (i.e., we could be interrupting
a clear_highmem and overwrite its KM_USER0 mapping, leaving it dead
in the water when we return there). in other words, sanitization
must be able to nest within KM_USER*, so that pretty much calls for
its own slot.

the alternative is to change KM_USER* semantics and allow its use
from the same contexts as free_page et al., but given the existing
users, that may very well be considered overkill.

on a related note, one could already say that disabling interrupts
during a memset over a page or more is already bad enough for your
real-time response times, so you may want to make this whole change
depend on the kernel's preemption model or at least document it.

> also, have you checked that you stopped clearing the page in the
> normal anonymous memory pagefault handler path? If the page is 
> guaranteed to be clear already you can save that copy
> (basically you move the clear from allocate to free..)

all new page allocations end up in prep_new_page and the clear_highpage
(memset) there depends on !sanitize_all_mem.