[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen BUG at page_alloc.c:1738 (Xen 4.5)



>>> On 31.05.15 at 00:43, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 30/05/2015 23:07, M A Young wrote:
>> On Fri, 29 May 2015, Andrew Cooper wrote:
>>> FC22 is miscompiling the C to:
>>>
>>> struct page_info *page = mfn_to_page(mfn);
>>> struct domain *owner = page_get_owner_and_reference(page);
>>> if ( owner )
>>>     put_page(mfn_to_page(0));
>>>
>>> which is wrong, and why free_domheap_pages() does legitimately complain
>>> about the wonky refcount.
>> With a bit of experimentation I have found that compiling with the 
>> -fno-caller-saves flag gets this code segment back to the Fedora 21 
>> version, thus avoiding the bug.
> 
> After sending this email, I wondered whether the optimiser as assuming
> that %rdi was preserved.  Indeed, it turns out that the generated code
> for page_get_owner_and_reference leaves %rdi unmodified, and safe for
> reuse after return.
> 
> If the 'mov %r8,%rdi' were simply omitted, the code would work, as %rdi
> still contains the correct result of the original calculation.

And %r8 is known to be preserved too?

> Therefore, I suspect that the bug is in the -fcaller-saves optimisation
> code.

I suppose together with us allowing it to do such for global functions
by marking everything hidden (i.e. something possibly not seeing much
testing).

Questions now are:
1) Was a bug against gcc opened already?
2) What do we do about it? Working around the issue by setting
-fno-caller-saves seems awkward, as we'd likely have nothing but
the gcc version to tie this to. And considering distros carry their
own patch sets, the version alone may not even be enough. (I
didn't see any reports against our tip facing a similar issue despite
it being built with gcc 5 now too afaik.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.