[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/traps: Fix failed ASSERT() in do_guest_trap()



>>> On 10.08.16 at 11:53, <andrew.cooper3@xxxxxxxxxx> wrote:
> c/s 2e426d6 "x86/traps: Drop use_error_code parameter from do_{,guest_}trap()"
> introduced an assertion which covered the correctness of shifting 1u by an
> input parameter.
> 
> While all other inputs provide a constants vector, the `int $N` handling path
> from do_general_protection() passes any vector.
> 
> This path is triggered by XTF, which uses `int 0x20` to facilitate returning
> to kernel mode after running specific tests in user mode.
> 
> No vectors above 32 have an error code, so adjust the logic to cope.
> 
> Reported-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

> RFC:
> 
> 1) Should we start making use of Linux's "Fixes:" tag?

It wouldn't hurt if someone did, but mentioning the offending commit
in the description would seem enough (and often better) to me. In no
case would I like seeing just a commit ID, without also the title being
quoted, as that will always mean one has to consult the repo for
understanding what exact change was broken (that is, of course,
only for those of us who can't memorize all the commit ID-s and their
respective titles of the last few years).

> 2) I considered using TRAP_nr instead of 32, but "(trapnr < TRAP_nr)" is odd,
> and it hides the visual correctness of seeing that 1u is never shifted out of
> range.

Either variant is fine with me.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.