On Thu, Oct 27, 2016 at 03:32:10PM -0400, Joe Korty wrote: > Hi Al, > I don't know if this is worth fixing or not, but I thought > I would mention it in case it was. > > A git bisect search shows that the commit: > > commit 319fe11519401e8a5db191a0a93aa2c1d7bb59f4 > Author: Al Viro <v...@zeniv.linux.org.uk> > Date: Thu Sep 15 02:35:29 2016 +0100 > > causes some malformed rt_sigqueueinfo syscalls, executed under > x86_64 kernels running compat mode programs, to oops with > the following message: > > [ 66.054786] BUG: unable to handle kernel paging request at 00000000020573eb > [ 66.061793] IP: [<00000000020573eb>] 0x20573eb > [ 66.066251] PGD 122263067 PUD 120a0c067 PMD 0 > [ 66.070745] Oops: 0010 [#1] PREEMPT SMP > [ 66.074717] Modules linked in: > [ 66.077789] CPU: 7 PID: 5496 Comm: cc Not tainted 4.1.35 #1 > [ 66.083365] Hardware name: Supermicro H8DM8-2/H8DM8-2, BIOS 080014 > 10/22/2009 > [ 66.090582] task: ffff88006b044400 ti: ffff88006b300000 task.ti: > ffff88006b300000 > [ 66.098067] RIP: 0010:[<00000000020573eb>] [<00000000020573eb>] 0x20573eb > [ 66.104961] RSP: 0018:ffff88006b303e98 EFLAGS: 00010246 > [ 66.110269] RAX: 00007fffffffef80 RBX: 0000000000000000 RCX: > 0000000000000000 > [ 66.117399] RDX: ffff88006b304000 RSI: 0000000000000000 RDI: > ffff88006b303ea8 > [ 66.124528] RBP: ffff88006b303e98 R08: 0000000000000000 R09: > 0000000000000000 > [ 66.131667] R10: 0000000000000000 R11: 0000000000000246 R12: > 0000000000000000 > [ 66.138805] R13: ffff88006b303ea8 R14: 0000000000000000 R15: > 0000000000000000 > [ 66.145935] FS: 00007ffff7fca740(0000) GS:ffff880127d80000(0063) > knlGS:00000000f7df06c0 > [ 66.154027] CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b > [ 66.159777] CR2: 00000000020573eb CR3: 000000011f874000 CR4: > 00000000000006e0 > [ 66.166906] Stack: > [ 66.168919] ffff88006b303f48 ffffffff8107c4b5 0000000000000000 > 0000000000000000 > [ 66.176403] 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > [ 66.183872] 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > [ 66.191341] Call Trace: > [ 66.193802] [<ffffffff8107c4b5>] compat_SyS_rt_sigqueueinfo+0x45/0x70 > [ 66.200340] [<ffffffff8205648c>] cstar_dispatch+0x7/0x2a > [ 66.205755] Code: Bad RIP value. > [ 66.209103] RIP [<00000000020573eb>] 0x20573eb > [ 66.213648] RSP <ffff88006b303e98> > [ 66.217134] CR2: 00000000020573eb > [ 66.220505] ---[ end trace 4f88266d7fd7e6d7 ]--- > The following test program can be used to trigger the problem: > > /* gcc -m32 c.c -o c */ > #define _GNU_SOURCE > #include <stdio.h> > #include <stdlib.h> > #include <unistd.h> > #include <errno.h> > #include <sys/syscall.h> > > #define rt_sigqueueinfo 178 > > int main(int argc, char **argv) { > int stat = syscall(rt_sigqueueinfo, 0, 0, 0, 0, 0, 0); > printf("syscall(%d): stat: %d, errno: %d\n", > rt_sigqueueinfo, stat, errno); > return 0; > } > > This is under 4.1.35 on x86_64.
AFAICS, it steps on _ASM_EXTABLE_EX being more brittle in 4.1 - it pretty much has to have the handler on the next insn after the faulting one, or the resulting extable entry won't be recognized. This "x86/mm: Expand the exception table logic to allow new handling options" in mainline is where that requirement has disappeared. I think we ought to use the plain _ASM_EXTABLE and just call something that would set current_thread_info()->uaccess_err directly from the fixup code there. That, or backport the commit switching to less brittle extables.