Re: [RFC][PATCH 5/7] x86: convert arch_futex_atomic_op_inuser() to user_access_begin/user_access_end()

Josh Poimboeuf
2020-03-27T04:35:55Z

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