On 12/11/18 09:54, Jan Beulich wrote: >>>> On 09.11.18 at 15:42, <andrew.coop...@citrix.com> wrote: >> For order 32 or more, the shift will truncate. Spotted by Coverity. > I find this pretty absurd. What about order 64 or more? Are you > suggesting you expect 16Tb or larger bad page ranges? > >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > Anyway, as I don't mind the adjustment > Acked-by: Jan Beulich <jbeul...@suse.com> > > But I'm sure you're aware we have many more examples of > 1U (or even plain 1) getting shifted by an order value.
There is nothing absurd here. The complaint is that there are two parts of a single calculation at different widths, where C's integer promotion rules results in code which reads correctly, but behaves incorrectly. If badpage->mfn was uint32_t, there would be no complaint, because all parts of the expression would be evaluated at the same width. This complaint is only because you've got a 32bit shift, and a 64bit addition. As for likelihood, I really hope we don't need mark a 16Tb range as bad, but given the ability to express this, would you really notice that the result was subtly wrong? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
