On Tue, Nov 21, 2017 at 7:59 AM, Andy Lutomirski <l...@kernel.org> wrote: > On Mon, Nov 20, 2017 at 11:33 PM, Ingo Molnar <mi...@kernel.org> wrote: >> >> * Andy Lutomirski <l...@kernel.org> wrote: >> >>> This sets up stack switching, including for SYSCALL. I think it's >>> in decent shape. >>> >>> Known issues: >>> - KASAN is likely to be busted. This could be fixed either by teaching >>> KASAN that cpu_entry_area contains valid stacks (I have no clue how >>> to go about doing this) or by rigging up the IST entry code to switch >>> RSP to point to the direct-mapped copy of the stacks before calling >>> into non-KASAN-excluded C code. >>> >>> - 32-bit kernels are failing the sigreturn_32 test. But they're also >>> failing without the patches, so I'm not sure this is a bug in the >>> series per se. Needs further investigation. (Off the top of my head, >>> this could be further fallout from Thomas's IDT rework.) >>> >>> - I think we're going to want a way to turn the stack switching on and >>> off either at boot time or at runtime. It should be fairly >>> straightforward >>> to make it work. >>> >>> - I think the ORC unwinder isn't so good at dealing with stack overflows. >>> It bails too early (I think), resulting in lots of ? entries. This >>> isn't a regression with this series -- it's just something that could >>> be improved. >> >> Another problem I just found: IRQ tracing appears busted on 64-bit kernels - >> with >> lockdep enabled I get this boot warning: >> >> [ 4.309026] WARNING: CPU: 10 PID: 222 at kernel/locking/lockdep.c:3924 >> check_flags.part.45+0x1a5/0x1b0 >> ... >> [ 4.309026] possible reason: unannotated irqs-off. >> >> That's on a x86-64 defconfig-ish kernel with CONFIG_PROVE_LOCKING=y, running >> on an >> AMD system. Full splat below. >> >> Thanks, >> >> Ingo >> >> [ 4.272197] LVT offset 0 assigned for vector 0x400 >> [ 4.278486] perf: AMD IBS detected (0x000000ff) >> [ 4.284786] kvm: Nested Virtualization enabled >> [ 4.289447] kvm: Nested Paging enabled >> [ 4.308496] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled) >> [ 4.308512] ------------[ cut here ]------------ >> [ 4.309026] WARNING: CPU: 10 PID: 222 at kernel/locking/lockdep.c:3924 >> check_flags.part.45+0x1a5/0x1b0 >> [ 4.309026] Modules linked in: >> [ 4.309026] CPU: 10 PID: 222 Comm: modprobe Not tainted >> 4.14.0-01345-g9490674-dirty #1 >> [ 4.309026] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 2.0b >> 03/01/2012 >> [ 4.309026] task: ffff880814b08000 task.stack: ffffc90007dcc000 >> [ 4.309026] RIP: 0010:check_flags.part.45+0x1a5/0x1b0 >> [ 4.309026] RSP: 0018:ffffc90007dcfeb0 EFLAGS: 00010082 >> [ 4.309026] RAX: 000000000000002e RBX: ffff880814b08000 RCX: >> 0000000000000000 >> [ 4.309026] RDX: 0000000000000000 RSI: 0000000000000001 RDI: >> ffffffff81152e76 >> [ 4.309026] RBP: 0000000000000000 R08: 0000000000000001 R09: >> 0000000000000000 >> [ 4.309026] R10: 0000000000000000 R11: 0000000000000000 R12: >> 0000000000000000 >> [ 4.309026] R13: 0000000000000000 R14: 0000000000000001 R15: >> 0000000000000000 >> [ 4.309026] FS: 0000000000000000(0000) GS:ffff880817c80000(0000) >> knlGS:0000000000000000 >> [ 4.309026] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 4.309026] CR2: 00007f8badc39218 CR3: 000000081584b000 CR4: >> 00000000000406e0 >> [ 4.309026] Call Trace: >> [ 4.309026] lock_acquire+0x11a/0x1d0 >> [ 4.309026] vtime_user_exit+0x3c/0xa0 >> [ 4.309026] ? __context_tracking_exit.part.4+0x45/0x130 >> [ 4.309026] __context_tracking_exit.part.4+0x45/0x130 >> [ 4.309026] do_syscall_64+0x13f/0x220 >> [ 4.309026] entry_SYSCALL64_slow_path+0x25/0x25 > > I'm not reproducing this. On quick inspection, the only potential > issue I see is that native_gs_load_index is missing IRQ tracing > annotations, but I don't see why this series would have any particular > effect on that.
Never mind, I reproduced it. > > Do you see it on my latest tree? > > --Andy
