| Message ID | 20210727144859.4150043-1-arnd@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | compat: remove compat_alloc_user_space | expand |
On Tue, Jul 27, 2021 at 04:48:53PM +0200, Arnd Bergmann wrote: > 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. Is it?
On Tue, 27 Jul 2021 15:59:55 +0100 Christoph Hellwig <hch@infradead.org> wrote: > On Tue, Jul 27, 2021 at 04:48:53PM +0200, Arnd Bergmann wrote: > > 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. > > Is it? the -mm tree is structured as <90% of stuff> linux-next.patch <the other 10% of stuff> So things like Arnd's series which have a dependency on linux-next material get added to the "other 10%" and are merged behind the linux-next material and all is good. If possible I'll queue things ahead of linux-next.patch. Those few things which have dependencies on linux-next material get sent to Linus after the required linux-next material is merged into mainline.
On Tue, Jul 27, 2021 at 10:11 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Tue, 27 Jul 2021 15:59:55 +0100 Christoph Hellwig <hch@infradead.org> wrote: > > > On Tue, Jul 27, 2021 at 04:48:53PM +0200, Arnd Bergmann wrote: > > > 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. > > > > Is it? > > the -mm tree is structured as > > <90% of stuff> > linux-next.patch > <the other 10% of stuff> > > So things like Arnd's series which have a dependency on linux-next > material get added to the "other 10%" and are merged behind the > linux-next material and all is good. > > If possible I'll queue things ahead of linux-next.patch. Those few > things which have dependencies on linux-next material get sent to Linus > after the required linux-next material is merged into mainline. The first five patches in my series should apply cleanly on mainline kernels and make sense by themselves, the last patch is the one that depends on this series as well as another series in the netdev tree, so that has to go behind linux-next. I suppose I could also merge the first five through my asm-generic tree and send you the last one if you prefer, but then again two of the patches are actually memory management stuff. Arnd
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).
On Fri, Jul 30, 2021 at 11:49 AM Heiko Carstens <hca@linux.ibm.com> wrote: > On Tue, Jul 27, 2021 at 04:48:53PM +0200, Arnd Bergmann wrote: > > Our CI reports this with linux-next and running strace selftest in > compat mode: Thanks a lot for the report! I managed track it down based on your output, it turns out that I end up copying data from the stack according to how much the user asked for, and in this case that was much more than the 8 byte nodemask_t, copying all of the kernel stack all the way into the guard page with CONFIG_VMAP_STACK, where it crashed. Without CONFIG_VMAP_STACK, or with user space that asks for less data, it would just be an information leak, so others probably haven't noticed the problem. The change below should fix that, I'll double-check the other callers as well before sending a proper fixup patch to Andrew. Arnd diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 4fabf2dddbc0..0d1f3be32723 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -1438,6 +1438,7 @@ static int copy_nodes_to_user(unsigned long __user *mask, unsigned long maxnode, if (clear_user((char __user *)mask + nbytes, copy - nbytes)) return -EFAULT; copy = nbytes; + maxnode = nr_node_ids; } if (compat)
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 --- Changes in v4: - Rebase on top of net-next - Split up and improve the kexec patch based on Christoph's suggestions - Include final patch to remove compat_alloc_user_space - Cc compat architecture maintainers Link: https://lore.kernel.org/lkml/20210720150950.3669610-1-arnd@kernel.org/ Changes in v3: - fix whitespace as pointed out by Christoph Hellwig - minor build fixes - rebase to v5.13-rc1 Link: https://lore.kernel.org/lkml/20210517203343.3941777-1-arnd@kernel.org/ Changes in v2: - address review comments from Christoph Hellwig - split syscall removal into a separate patch - replace __X32_COND_SYSCALL() with individual macros for x32 Link: https://lore.kernel.org/lkml/20201208150614.GA15765@infradead.org/ 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 arch/arm64/include/asm/compat.h | 5 - arch/arm64/include/asm/uaccess.h | 11 -- arch/arm64/include/asm/unistd32.h | 10 +- arch/arm64/lib/Makefile | 2 +- arch/arm64/lib/copy_in_user.S | 77 --------- arch/mips/cavium-octeon/octeon-memcpy.S | 2 - arch/mips/include/asm/compat.h | 8 - arch/mips/include/asm/uaccess.h | 26 --- arch/mips/kernel/syscalls/syscall_n32.tbl | 10 +- arch/mips/kernel/syscalls/syscall_o32.tbl | 10 +- arch/mips/lib/memcpy.S | 11 -- arch/parisc/include/asm/compat.h | 6 - arch/parisc/include/asm/uaccess.h | 2 - arch/parisc/kernel/syscalls/syscall.tbl | 8 +- arch/parisc/lib/memcpy.c | 9 - arch/powerpc/include/asm/compat.h | 16 -- arch/powerpc/kernel/syscalls/syscall.tbl | 10 +- arch/s390/include/asm/compat.h | 10 -- arch/s390/include/asm/uaccess.h | 3 - arch/s390/kernel/syscalls/syscall.tbl | 10 +- arch/s390/lib/uaccess.c | 63 ------- arch/sparc/include/asm/compat.h | 19 --- arch/sparc/kernel/process_64.c | 2 +- arch/sparc/kernel/signal32.c | 12 +- arch/sparc/kernel/signal_64.c | 8 +- arch/sparc/kernel/syscalls/syscall.tbl | 10 +- arch/x86/entry/syscalls/syscall_32.tbl | 4 +- arch/x86/entry/syscalls/syscall_64.tbl | 2 +- arch/x86/include/asm/compat.h | 13 -- arch/x86/include/asm/uaccess_64.h | 7 - include/linux/compat.h | 39 +---- include/linux/uaccess.h | 10 -- include/uapi/asm-generic/unistd.h | 10 +- kernel/compat.c | 21 --- kernel/kexec.c | 103 +++++------- kernel/sys_ni.c | 5 - mm/mempolicy.c | 196 +++++----------------- mm/migrate.c | 50 +++--- 38 files changed, 175 insertions(+), 645 deletions(-) delete mode 100644 arch/arm64/lib/copy_in_user.S