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

[Josh Poimboeuf <jpoimboe@redhat.com>]

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