Re: regression from your recent change to x86's copy_user_handle_tail()

2015-04-23 Thread Jan Beulich
>>> On 23.04.15 at 17:33, wrote: > On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich wrote: >> >> while the description of commit cae2a173fe certainly makes sense, the >> change itself ignores the __probe_kernel_write() code path, for which >> the destination address is expected to be in kernel space

Re: regression from your recent change to x86's copy_user_handle_tail()

2015-04-23 Thread Linus Torvalds
On Thu, Apr 23, 2015 at 8:43 AM, Jan Beulich wrote: >> >> Did you have a test-case for this? I guess we're talking odd ftrace >> uses or kgdb? > > I'm afraid not one you'd like - we've seen ftrace initialization fail for > quite some time on our Xen kernels, but in a way only affecting > ftrace it

Re: regression from your recent change to x86's copy_user_handle_tail()

2015-04-23 Thread Jan Beulich
>>> On 23.04.15 at 17:33, wrote: > On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich wrote: >> >> while the description of commit cae2a173fe certainly makes sense, the >> change itself ignores the __probe_kernel_write() code path, for which >> the destination address is expected to be in kernel space

Re: regression from your recent change to x86's copy_user_handle_tail()

2015-04-23 Thread Linus Torvalds
On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich wrote: > > while the description of commit cae2a173fe certainly makes sense, the > change itself ignores the __probe_kernel_write() code path, for which > the destination address is expected to be in kernel space but accesses > may still fault. I.e. th