Re: [Xen-devel] [PATCH 09/11] gnttab: avoid spurious maptrack handle allocation failures

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.06.17 at 14:02, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 21/06/17 10:37, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -397,7 +397,7 @@ get_maptrack_handle(
>>      struct vcpu          *curr = current;
>>      unsigned int          i, head;
>>      grant_handle_t        handle;
>> -    struct grant_mapping *new_mt;
>> +    struct grant_mapping *new_mt = NULL;
>>  
>>      handle = __get_maptrack_handle(lgt, curr);
>>      if ( likely(handle != -1) )
>> @@ -408,8 +408,13 @@ get_maptrack_handle(
>>      /*
>>       * If we've run out of frames, try stealing an entry from another
>>       * VCPU (in case the guest isn't mapping across its VCPUs evenly).
>> +     * Also use this path in case we're out of memory, to avoid spurious
>> +     * failures.
>>       */
>> -    if ( nr_maptrack_frames(lgt) >= max_maptrack_frames )
>> +    if ( nr_maptrack_frames(lgt) < max_maptrack_frames )
>> +        new_mt = alloc_xenheap_page();
>> +
>> +    if ( !new_mt )
>>      {
>>          /*
>>           * Can drop the lock since no other VCPU can be adding a new
> 
> * frame once they've run out.
> */
> 
> It doesn't look like this comment is true any more, which brings the
> locking correctness into question.

Oh, indeed. I'll need to revive the locking change I had done here
and then dropped because we did realize we didn't need it for
XSA-218.

Jan


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