>>> On 29.06.16 at 13:21, wrote:
> The other reason I am hesitant about PTR_ERR() is that it obfuscates the
> semantics sufficiently for Coverity to give up.
Mind giving some more detail? These inline functions aren't all that
obfuscating - just a couple of casts. If that's enough to confuse
Cove
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, 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 err
At 03:55 -0600 on 29 Jun (1467172554), Jan Beulich wrote:
> >>> On 28.06.16 at 20:56, 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
>>> On 28.06.16 at 20:56, wrote:
> On 28/06/16 18:56, Andrew Cooper wrote:
>>
>>
>> This is the first in a number of changes trying to clean up error reporting
> of
>> memory conditions.
>
> One area which is constantly causing problems is creation of domains in
> low memory conditions. In the
On 28/06/16 18:56, Andrew Cooper wrote:
>
>
> This is the first in a number of changes trying to clean up error reporting of
> memory conditions.
One area which is constantly causing problems is creation of domains in
low memory conditions. In the case where the toolstack gets its
calculations w
