[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2] gnttab: correct GNTTABOP_cache_flush empty batch handling
>>> 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? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |