Re: [PATCH v4 1/2] XEN/X86: Improve semantic support for x86_init.mapping.pagetable_reserve

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, 24 Aug 2012, Stefano Stabellini wrote:
> On Fri, 24 Aug 2012, Thomas Gleixner wrote:
> > And how exactly are they allocated between from pgt_buf w/o increasing
> > pgt_buf_end ?
> 
> So let's suppose that we change the check in mask_rw_pte to be:
> 
> pfn >= pgt_buf_start && pfn < pgt_buf_end
> 
> as it was originally. This is what could happen:
> 
> 1) pgt_buf_start - pgt_buf_end gets mapped RO;
> 2) pgt_buf_end - pgt_buf_top gets mapped RW;
> 3) a new pagetable page is allocated, pgt_buf_end is increased;
> 4) this new pagetable page is hooked into the pagetable;
> 5) since a mapping of this page already exists (it was done in
>    point 2), and this mapping is RW, Linux crashes.
> 
> 
> Thanks for taking the time to look into this issue. I know it is
> difficult and not very pleasant.

Indeed, it's a nightmare.

Now all of this is only relevant up to the point where paging_init()
has been done. After that xen_pagetable_setup_done() switches the
set_pte function pointer and the nastyness gets replaced.

Now the functions called up to that point which are relevant to page
table setups are quite limited and we know exactly that we are setting
up an early page table pte. So why don't we use a different
indirection for that? Even if there are functions which are used later
on as well it's not a problem to switch the pointer as you do already
for set_pte.

No weird boundary checks, just a plain native_set_pte for !XEN and a
special case for XEN.

Yes, it's some work to analyse all the relevant code pathes and make
the necessary changes, but that's the only sensible thing to do.

The current magic is doomed for failure and completely
unmaintainable. It's really time to find a proper solution for this
early mapping stuff instead of bandaiding it over and over.

Thanks,

	tglx