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.
