Re: [PATCH v5 0/6] compat: remove compat_alloc_user_space

Heiko Carstens
2021-07-30T09:51:50Z

On Tue, Jul 27, 2021 at 04:48:53PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Going through compat_alloc_user_space() to convert indirect system call
> arguments tends to add complexity compared to handling the native and
> compat logic in the same code.
>
> Out of the other remaining callers, the linux-media series went into
> v5.14, and the network ioctl handling is now fixed in net-next, so
> these are the last remaining users, and I now include the final
> patch to remove the definitions as well.
>
> Since these patches are now all that remains, it would be nice to
> merge it all through Andrew's Linux-mm tree, which is already based
> on top of linux-next.
...
>
> Arnd Bergmann (6):
> kexec: move locking into do_kexec_load
> kexec: avoid compat_alloc_user_space
> mm: simplify compat_sys_move_pages
> mm: simplify compat numa syscalls
> compat: remove some compat entry points
> arch: remove compat_alloc_user_space

Our CI reports this with linux-next and running strace selftest in
compat mode:

Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 0000038003e7c000 TEID: 0000038003e7c803
Fault in home space mode while using kernel ASCE.
AS:00000001fb388007 R3:000000008021c007 S:0000000082142000 P:0000000000000400
Oops: 0011 ilc:3 [#1] SMP
CPU: 0 PID: 1017495 Comm: get_mempolicy Tainted: G OE 5.14.0-20210730.rc3.git0.4ccc9e2db7ac.300.fc34.s390x+next #1
Hardware name: IBM 2827 H66 708 (LPAR)
Krnl PSW : 0704e00180000000 00000001f9f11000 (compat_put_bitmap+0x48/0xd0)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000810000 0000000000000000 000000007d9df1c0 0000038003e7c008
0000000000000004 000000007d9df1c4 0000038003e7be40 0000000000010000
0000000000008000 0000000000000000 0000000000000390 00000000000001c8
000000020d6ea000 000002aa00401a48 00000001fa0a85fa 0000038003e7bd50
Krnl Code: 00000001f9f10ff4: a7bb0001 aghi %r11,1
00000001f9f10ff8: 41303008 la %r3,8(%r3)
#00000001f9f10ffc: 41502004 la %r5,4(%r2)
>00000001f9f11000: e3103ff8ff04 lg %r1,-8(%r3)
00000001f9f11006: 5010f0a4 st %r1,164(%r15)
00000001f9f1100a: a50e0081 llilh %r0,129
00000001f9f1100e: c8402000f0a4 mvcos 0(%r2),164(%r15),%r4
00000001f9f11014: 1799 xr %r9,%r9
Call Trace:
[<00000001f9f11000>] compat_put_bitmap+0x48/0xd0
[<00000001fa0a85fa>] kernel_get_mempolicy+0x102/0x178
[<00000001fa0a86b0>] __s390_sys_get_mempolicy+0x40/0x50
[<00000001fa92be30>] __do_syscall+0x1c0/0x1e8
[<00000001fa939148>] system_call+0x78/0xa0
Last Breaking-Event-Address:
[<0000038003e7bc00>] 0x38003e7bc00
Kernel panic - not syncing: Fatal exception: panic_on_oops

Note: I did not try to bisect this, since it looks to me like this
patch series causes the problem. Also, please don't get confused with
the kernel version name. The date encoded is the build date, not the
linux-next version.
linux-next commit 4ccc9e2db7ac ("Add linux-next specific files for
20210729") was used to build the kernel (s390 defconfig).