Re: [Xen-devel] [PATCH 1/2] gnttab: correct GNTTABOP_cache_flush empty batch handling

[Andre Przywara <andre.przywara@xxxxxxxxxx>]

Hi,

On 04/12/17 09:00, Jan Beulich wrote:
>>>> On 01.12.17 at 16:31, <andre.przywara@xxxxxxxxxx> wrote:
>> On 30/11/17 14:31, Jan Beulich wrote:
>>> Jann validly points out that with a caller bogusly requesting a zero-
>>> element batch with non-zero high command bits (the ones used for
>>> continuation encoding), the assertion right before the call to
>>> hypercall_create_continuation() would trigger. A similar situation would
>>> arise afaict for non-empty batches with op and/or length zero in every
>>> element.
>>>
>>> While we want the former to succeed (as we do elsewhere for similar
>>> no-op requests), the latter can clearly be converted to an error, as
>>> this is a state that can't be the result of a prior operation.
>>>
>>> Take the opportunity and also correct the order of argument checks:
>>> We shouldn't accept zero-length elements with unknown bits set in "op".
>>> Also constify cache_flush()'s first parameter.
>>>
>>> Reported-by: Jann Horn <jannh@xxxxxxxxxx>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> Took me a while to wrap my head around it, because the actual fix is
>> just the "*cur_ref = 0;" line, I think.
>> But this looks correct to me.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxxxxx>
> 
> I guess this was meant to be Reviewed-by?

Sure, seems my mind was still smoking from chasing all possible call
chains ;-)

Cheers,
Andre.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel