Re: Domain creation errors

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 29/06/16 12:11, Tim Deegan wrote:
> At 03:55 -0600 on 29 Jun (1467172554), Jan Beulich wrote:
>>>>> On 28.06.16 at 20:56, <andrew.cooper3@citrix.com> wrote:
>>> Using PTR_ERR() is less disruptive to the code, but will cause
>>> collateral damage for anyone with out-of-tree patches, as the code will
>>> compile but the error logic will be wrong.  The use of PTR_ERR() is also
>>> quite dangerous in the context of a PV guest, as the resulting pointer
>>> is under 64bit guest ABI control.
>>>
>>> I am leaning towards the first option, which at least has the advantage
>>> that any out-of-tree code will break in an obvious way.
>>>
>>> Any opinions or alternate suggestions?
>> To be honest I'm not worried much about out of tree code, and
>> the err.h abstractions are precisely for cases like this. So I'm for
>> the PTR_ERR() variant.
> +1, FWIW.  Can the x86_64/PV problem be avoided by using non-canonical
> error addresses?

I can look into that, but it will definitely complicate the PTR_ERR()
handling.  Linux gets away with the status quo as the pointers which are
actually error integers fall into kernel-controlled memory.

The other reason I am hesitant about PTR_ERR() is that it obfuscates the
semantics sufficiently for Coverity to give up.  As Coverity has found
legitimate issues with the use of alloc_domheap_pages() in the past, I
am hesitant to make things harder to interpret.

~Andrew

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