Message ID | 592E9234020000780015E06A@prv-mh.provo.novell.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 31/05/17 08:51, Jan Beulich wrote: > While f32400e90c ("x86: fix build with gcc 7")'s change to > compat_array_access_ok() is necessary, I had blindly and needlessly > also added it to array_access_ok(). There's no conditional expression > involved there, so undo it. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Hi Jan, On 31/05/17 08:51, Jan Beulich wrote: > While f32400e90c ("x86: fix build with gcc 7")'s change to > compat_array_access_ok() is necessary, I had blindly and needlessly > also added it to array_access_ok(). There's no conditional expression > involved there, so undo it. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > No ARM counterpart, as Julien means to remove the macro anyway. To double-check, I am CCed on this e-mail because you would like this patch in Xen 4.9, right? Cheers,
>>> On 01.06.17 at 13:06, <julien.grall@arm.com> wrote: > On 31/05/17 08:51, Jan Beulich wrote: >> While f32400e90c ("x86: fix build with gcc 7")'s change to >> compat_array_access_ok() is necessary, I had blindly and needlessly >> also added it to array_access_ok(). There's no conditional expression >> involved there, so undo it. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> No ARM counterpart, as Julien means to remove the macro anyway. > > To double-check, I am CCed on this e-mail because you would like this > patch in Xen 4.9, right? No, because of the "No ARM counterpart ..." remark. Of course I wouldn't mind this going into 4.9, but I did specifically not submit the patch before branching because the code as is will do there. I simply didn't want to leave this in place for the longer term. Jan
Hi, On 01/06/17 12:14, Jan Beulich wrote: >>>> On 01.06.17 at 13:06, <julien.grall@arm.com> wrote: >> On 31/05/17 08:51, Jan Beulich wrote: >>> While f32400e90c ("x86: fix build with gcc 7")'s change to >>> compat_array_access_ok() is necessary, I had blindly and needlessly >>> also added it to array_access_ok(). There's no conditional expression >>> involved there, so undo it. >>> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>> --- >>> No ARM counterpart, as Julien means to remove the macro anyway. >> >> To double-check, I am CCed on this e-mail because you would like this >> patch in Xen 4.9, right? > > No, because of the "No ARM counterpart ..." remark. Of course > I wouldn't mind this going into 4.9, but I did specifically not submit > the patch before branching because the code as is will do there. I > simply didn't want to leave this in place for the longer term. Oh. Yes the patch has been sent and acked by Stefano. Hopefully it will get merged soon. Regarding the patch, I would avoid to add it in Xen 4.9 if it is not fixing a regression/critical bug. Cheers,
--- a/xen/include/asm-x86/x86_64/uaccess.h +++ b/xen/include/asm-x86/x86_64/uaccess.h @@ -42,7 +42,7 @@ extern void *xlat_malloc(unsigned long * #define array_access_ok(addr, count, size) \ (likely(((count) ?: 0UL) < (~0UL / (size))) && \ - access_ok(addr, 0 + (count) * (size))) + access_ok(addr, (count) * (size))) #define __compat_addr_ok(d, addr) \ ((unsigned long)(addr) < HYPERVISOR_COMPAT_VIRT_START(d))