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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 4 Dec 2017, Jan Beulich wrote:
> >>> On 01.12.17 at 22:38, <sstabellini@xxxxxxxxxx> wrote:
> > On Thu, 30 Nov 2017, 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>
> > 
> > Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> 
> Thanks. Since this and the other patch mainly affect ARM, I'd like
> to have your opinion please regarding their backporting.

Yes, I think they could be backported.

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