Messages in this thread |  | | Date | Thu, 26 Mar 2020 23:35:42 -0500 | From | Josh Poimboeuf <> | Subject | Re: [RFC][PATCH 5/7] x86: convert arch_futex_atomic_op_inuser() to user_access_begin/user_access_end() |
| |
On Thu, Mar 26, 2020 at 09:03:41PM -0700, Linus Torvalds wrote: > On Thu, Mar 26, 2020 at 8:49 PM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > Seems to work for me. > > > > That's with the futex bug fixed. Not that it looks like it would have > > mattered except for the (unlikely) exception case, so my testing is > > meaningless. > > Hmm. Doing a "perf" run, I only noticed after-the-fact that I got this: > > WARNING: stack recursion on stack type 4 > WARNING: can't dereference registers at 0000000079a3d9c5 for ip > swapgs_restore_regs_and_return_to_usermode+0x25/0x80 > > that may not be due to any of the uaccess or futex changes, though, it > smells like just bad luck. > > Josh? > > This may also be related to the fact that I've been building my > test-boot kernels with clang for the last couple of months, > > That "swapgs_restore_regs_and_return_to_usermode+0x25" location is the > > pushq 0x28(%rdi) > > instruction. That's this: > > movq %rsp, %rdi > movq PER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp > > /* Copy the IRET frame to the trampoline stack. */ > pushq 6*8(%rdi) /* SS */ > ---> pushq 5*8(%rdi) /* RSP */ > pushq 4*8(%rdi) /* EFLAGS */ > pushq 3*8(%rdi) /* CS */ > pushq 2*8(%rdi) /* RIP */ > > and yeah, at this point the stack is obviously a mess, so I'm not > surprised that it might cause confusion for unwinding..
You did indeed get unlucky, and that's the correct diagnosis. It's pretty harmless.
https://lkml.kernel.org/r/58c05bf0a9f06ac7f2ed6df5e369d3276ccec33c.1584033751.git.jpoimboe@redhat.com
Working on a v2, I'll add you to the already excessive Reported-by list :-)
-- Josh
|  |