[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] linux/x86-64: allow kernel init memory to be freed
>>> Keir Fraser <keir@xxxxxxxxxxxxx> 02.03.07 16:23 >>> >On 2/3/07 11:04, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote: > >> + if (addr >= __START_KERNEL_map) { >> + /* make_readonly() reports all kernel addresses. */ >> + __make_page_writable(__va(__pa(addr))); >> + __make_page_readonly((void *)addr); >> + } > >I'm confused by this: > 1. Why does the write-protection need to be changed unconditionally, or >even at all? Is there anything write-protected in the init sections? The mappings in the direct map area must be writeable and, as the comment says, make_readonly() forces all kernel space mappings to be set up as read-only during boot. Thus this does *not* depend on XENFEAT_writable_page_tables, unless make_readonly() is changed. > 2. Is it safe to keep init mappings above START_KERNEL_map at all, even >read-only? I'd have thought we'd be in trouble if the balloon driver manages >to allocate those pages and tries to free them to Xen. Perhaps they should >be blown away entirely? Yes, ultimately I wanted them to go away entirely, likewise in native. That is why I wanted to push this change through mainline rather than directly into Xen (it also is somewhat more involved as I [mis-]use change_page_attr_addr() here instead of creating a new function to do this zapping, and as I also at once extend the range mark_rodata_ro() handles). But indeed, I didn't consider the balloon driver here, which would - as I understand it now - erroneously think it freed such pages when Xen really didn't due to a remaining reference. So - would you be okay with taking the full-blown patch (probably not, as it touches another file not currently in the sparse tree), or should I create a __make_page_inaccessible() function along the lines of __make_page_readonly()/__make_page_writable()? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |