[Hardy-xen] SRU: Fix OMG how did this ever work (32bit)

[Stefan Bader]

On 21.06.2011 17:55, Stefan Bader wrote:
> SRU Justification:
> 
> Impact: For i386 PGDs are stored in a linked list. For this two elements of
> struct page are (mis-)used. To have a backwards pointer, the private field is
> assigned a pointer to the index field of the previous struct page. The main
> problem there was that list_add and list_del operations accidentally were done
> twice. Which leads to accesses to (after first list operation) innocent struct
> pages.
> 
> Fix: This is a bit more than needed to fix the bug itself, but it will bring our
> code more into a shape that resembles upstream (factually there is only a 2.6.18
> upstream but that code did not do the double list access).
> 
> Testcase: Running a 32bit domU (64bit Hardy dom0, though that should not matter)
> with the xen kernel and doing a lot of process starts (like the aslr qa
> regression test does) would quite soon crash because the destructor of a PTE
> (which incidentally is stored in index) was suddenly overwritten.
> 
> Patches are attached directly. Those would go into the patches directory.
> 
> Note, that I attributed it to fix bug 705562 which has not yet been verified.
> But the way of failure was just exactly the same.
> 
> -Stefan
> 
After a nights sleep some additional notes. The list add operation in reality
was not a problem. That section was disabled by ifndef CONFIG_XEN and I wonder
whether I should add this case again. On the other hand this code will never be
compiled without CONFIG_XEN defined...

The list delete problem can be covered by the fact that the second delete was
only done when the quicklists number of elements get trimmed down. And that does
not happen all the times.

And at least some relaxing news that at a first glance Lucid is not affected by
this. List add and delete are only done in the constructor and destructor
functions and those seem to be only called once from alloc and free.
-Stefan