Hi,
On 15.07.2022 22:37, Jens Axboe wrote:
> On 7/15/22 2:28 PM, Marek Szyprowski wrote:
>> On 14.07.2022 13:02, Dylan Yudaken wrote:
>>> this is in preparation for multishot receive from io_uring, where it needs
>>> to have access to the original struct user_msghdr.
>>>
>>> functionally this should be a no-op.
>>>
>>> Acked-by: Paolo Abeni <pabeni@xxxxxxxxxx>
>>> Signed-off-by: Dylan Yudaken <dylany@xxxxxx>
>> This patch landed in linux next-20220715 as commit 1a3e4e94a1b9 ("net:
>> copy from user before calling __get_compat_msghdr"). Unfortunately it
>> causes a serious regression on the ARM64 based Khadas VIM3l board:
>>
>> Unable to handle kernel access to user memory outside uaccess routines
>> at virtual address 00000000ffc4a5c8
>> Mem abort info:
>> ESR = 0x000000009600000f
>> EC = 0x25: DABT (current EL), IL = 32 bits
>> SET = 0, FnV = 0
>> EA = 0, S1PTW = 0
>> FSC = 0x0f: level 3 permission fault
>> Data abort info:
>> ISV = 0, ISS = 0x0000000f
>> CM = 0, WnR = 0
>> user pgtable: 4k pages, 48-bit VAs, pgdp=0000000001909000
>> [00000000ffc4a5c8] pgd=0800000001a7b003, p4d=0800000001a7b003,
>> pud=0800000001a0e003, pmd=0800000001913003, pte=00e800000b9baf43
>> Internal error: Oops: 9600000f [#1] PREEMPT SMP
>> Modules linked in:
>> CPU: 0 PID: 247 Comm: systemd-udevd Not tainted 5.19.0-rc6+ #12437
>> Hardware name: Khadas VIM3L (DT)
>> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> pc : get_compat_msghdr+0xd0/0x1b0
>> lr : get_compat_msghdr+0xcc/0x1b0
>> ...
>> Call trace:
>> get_compat_msghdr+0xd0/0x1b0
>> ___sys_sendmsg+0xd0/0xe0
>> __sys_sendmsg+0x68/0xc4
>> __arm64_compat_sys_sendmsg+0x28/0x3c
>> invoke_syscall+0x48/0x114
>> el0_svc_common.constprop.0+0x60/0x11c
>> do_el0_svc_compat+0x1c/0x50
>> el0_svc_compat+0x58/0x100
>> el0t_32_sync_handler+0x90/0x140
>> el0t_32_sync+0x190/0x194
>> Code: d2800382 9100f3e0 97d9be02 b5fffd60 (b9401a60)
>> ---[ end trace 0000000000000000 ]---
>>
>> This happens only on the mentioned board, other my ARM64 test boards
>> boot fine with next-20220715. Reverting this commit, together with
>> 2b0b67d55f13 ("fix up for "io_uring: support multishot in recvmsg"") and
>> a8b38c4ce724 ("io_uring: support multishot in recvmsg") due to compile
>> dependencies on top of next-20220715 fixes the issue.
>>
>> Let me know how I can help fixing this issue.
> How are you reproducing this?
This happens always during system boot on the mentioned board, when udev
starts discovering devices. The complete boot log is here:
https://pastebin.com/i8WzFzcx
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
