[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |