RE: futex_wake_op deadlock?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ralf Baechle wrote:
>         __asm__ __volatile__(
>         "       .set    push                            \n"
>         "       .set    noat                            \n"
>         "       .set    mips3                           \n"
>         "1:     ll      %1, %4  # __futex_atomic_op     \n"
>         "       .set    mips0                           \n"
>         "       " insn  "                               \n"
>         "       .set    mips3                           \n"
>         "2:     sc      $1, %2                          \n"
>         "       beqz    $1, 1b                          \n"        
>         __WEAK_LLSC_MB "3:                                           
>         \n" "       .set    pop                             \n"
>         "       .set    mips0                           \n"
>         "       .section .fixup,\"ax\"                  \n"
>         "4:     li      %0, %6                          \n"
>         "       j       2b                              \n"	<-----
>         "       .previous                               \n"
>         "       .section __ex_table,\"a\"               \n"
>         "       "__UA_ADDR "\t1b, 4b                    \n"
>         "       "__UA_ADDR "\t2b, 4b                    \n"
>         "       .previous                               \n"
>         : "=r" (ret), "=&r" (oldval), "=R" (*uaddr)
>         : "0" (0), "R" (*uaddr), "Jr" (oparg), "i" (-EFAULT)        
> : "memory"); 
> 
> Notice the branch at the end of the fixup code, it goes back to the
> SC instruction. 

Hi Ralf,

I had gone through all that code, but didn't see it!

The problem is I didn't pay enough attention because I didn't suspect it
enough.

I was misled by the backtrace address in the soft lockup dump, which
points to one instruction /before/ the ll instruction. So I thought that
the lockup is somewhere outside of that loop, right?

Does the backward branch on MIPS set up the instruction pointer in such
a way that if an interrupt goes off, it can be pointing to the previous
instruction? I thought about that possibility.


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux