Le 28/01/2021 à 15:42, Jens Axboe a écrit :
On 1/28/21 6:52 AM, Zorro Lang wrote:
On Wed, Jan 27, 2021 at 08:06:37PM -0700, Jens Axboe wrote:
On 1/27/21 8:13 PM, Zorro Lang wrote:
On Thu, Jan 28, 2021 at 10:18:07AM +1000, Nicholas Piggin wrote:
Excerpts from Jens Axboe's message of January 28, 2021 5:29 am:
On 1/27/21 9:38 AM, Christophe Leroy wrote:
Le 27/01/2021 à 15:56, Zorro Lang a écrit :
On powerpc, io_uring test hit below KUAP fault on __do_page_fault.
The fail source line is:
if (unlikely(!is_user && bad_kernel_fault(regs, error_code, address,
is_write)))
return SIGSEGV;
The is_user() is based on user_mod(regs) only. This's not suit for
io_uring, where the helper thread can assume the user app identity
and could perform this fault just fine. So turn to use mm to decide
if this is valid or not.
I don't understand why testing is_user would be an issue. KUAP purpose
it to block any unallowed access from kernel to user memory
(Equivalent to SMAP on x86). So it really must be based on MSR_PR bit,
that is what is_user provides.
If the kernel access is legitimate, kernel should have opened
userspace access then you shouldn't get this "Bug: Read fault blocked
by KUAP!".
As far as I understand, the fault occurs in
iov_iter_fault_in_readable() which calls fault_in_pages_readable() And
fault_in_pages_readable() uses __get_user() so it is a legitimate
access and you really should get a KUAP fault.
So the problem is somewhere else, I think you proposed patch just
hides the problem, it doesn't fix it.
If we do kthread_use_mm(), can we agree that the user access is valid?
Yeah the io uring code is fine, provided it uses the uaccess primitives
like any other kernel code. It's looking more like a an arch/powerpc bug.
We should be able to copy to/from user space, and including faults, if
that's been done and the new mm assigned. Because it really should be.
If SMAP was a problem on x86, we would have seen it long ago.
I'm assuming this may be breakage related to the recent uaccess changes
related to set_fs and friends? Or maybe recent changes on the powerpc
side?
Zorro, did 5.10 work?
Would be interesting to know.
Sure Nick and Jens, which 5.10 rc? version do you want to know ? Or any git
commit(be the HEAD) in 5.10 phase?
I forget which versions had what series of this, but 5.10 final - and if
that fails, then 5.9 final. IIRC, 5.9 was pre any of these changes, and
5.10 definitely has them.
I justed built linux v5.10 with same .config file, and gave it same test.
v5.10 (HEAD=2c85ebc57b Linux 5.10) can't reproduce this bug:
# ./check generic/013 generic/051
FSTYP -- xfs (non-debug)
PLATFORM -- Linux/ppc64le ibm-p9z-xxx-xxxx 5.10.0 #3 SMP Thu Jan 28
04:12:14 EST 2021
MKFS_OPTIONS -- -f -m crc=1,finobt=1,reflink=1,rmapbt=1,bigtime=1,inobtcount=1
/dev/sda3
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/sda3
/mnt/xfstests/scratch
generic/013 138s ... 77s
generic/051 103s ... 143s
Ran: generic/013 generic/051
Passed all 2 tests
Thanks for testing that, so I think it's safe to conclude that there's a
regression in powerpc fault handling for kthreads that use
kthread_use_mm in this release. A bisect would definitely find it, but
might be pointless if Christophe or Nick already have an idea of what it
is.
I don't have any idea yet, but I'd be curious to see the vmlinux binary
matching the reported Oops.
Christophe
