[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/4] fix XENMEM_add_to_physmap preemption handling
>>> On 18.12.13 at 18:59, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > On Wed, 2013-12-18 at 14:35 +0000, Jan Beulich wrote: >> J >> /* Check for continuation if it's not the last interation. */ >> - if ( xatp->size > 0 && hypercall_preempt_check() ) >> + if ( xatp->size > ++done && hypercall_preempt_check() ) > > Hiding the loop increment inside the preemption checking is a bit subtle > (it took me a while to find it). Can't it go either before or after this > loop? With a suitable +/- 1 to the rc below if necessary. It could, but I find it quite natural to be together with the check. >> @@ -724,6 +731,12 @@ long do_memory_op(unsigned long cmd, XEN >> { >> struct xen_add_to_physmap xatp; >> >> + BUILD_BUG_ON((typeof(xatp.size))-1 > (UINT_MAX >> >> MEMOP_EXTENT_SHIFT)); > > What does "typeof(xatp.size)-1" evaluate to? typeof can't return an int, > cant it? Properly parenthesized this is ((uint16_t)-1), i.e. 0xffff (typeof() doesn't produce a value, but a type). >> + >> + /* Check for faked input. */ > > Faked as in "malicious" or faked as in "something we made up for > continuation purposes" ? As in "malicious" (or buggy), i.e. the caller passing an out of range "cmd" to HYPERVISOR_memory_op. Do you have any better wording in mind? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |