lkml.org 
[lkml]   [2009]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] Support for unconditional page sanitization
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.



\
 
 \ /
  Last update: 2009-05-24 12:59    [W:0.085 / U:3.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site