Re: [PATCH] linux/x86-64: allow kernel init memory to be freed

["Jan Beulich" <jbeulich@novell.com>]

>>> Keir Fraser <keir@xensource.com> 02.03.07 16:23 >>>
>On 2/3/07 11:04, "Jan Beulich" <jbeulich@novell.com> 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