Re: powerpc: fork && stepping (Was: [RFC,PATCH 0/14] utrace/ptrace)

[Paul Mackerras <paulus@samba.org>]

Oleg Nesterov writes:

> 	0xfeacd24
> 	0xfeacd28
> 	0xfeacd2c
> 	0xfeacd30
> 	0xfeacd34
> 	...
> 
> and so on forever,
...
> beg->	0x0feacd24 <__GI__IO_list_lock+68>:	lwarx   r0,0,r31
> 	0x0feacd28 <__GI__IO_list_lock+72>:	cmpw    r0,r11
> 	0x0feacd2c <__GI__IO_list_lock+76>:	bne-    0xfeacd38 <__GI__IO_list_lock+88>
> 	0x0feacd30 <__GI__IO_list_lock+80>:	stwcx.  r9,0,r31
> end->	0x0feacd34 <__GI__IO_list_lock+84>:	bne+    0xfeacd24 <__GI__IO_list_lock+68>
> 
> I don't even know whether this is user-space bug or kernel bug,
> the asm above is the black magic for me.

The lwarx and stwcx. work together to do an atomic update to the word
whose address is in r31.  They are like LL (load-linked) and SC
(store-conditional) on other architectures such as alpha.  Basically
the lwarx creates an internal "reservation" on the word pointed to by
r31 and loads its value into r0.  The stwcx. stores into that word but
only if the reservation still exists.  The reservation gets cleared
(in hardware) if any other cpu writes to that word in the meantime.
If the reservation did get cleared, the bne (branch if not equal)
instruction will be taken and we loop around to try again.

There is a difficulty when single-stepping through such a sequence
because the process of taking the single-step exception and returning
will clear the reservation.  Thus if you single-step through that
sequence it will never succeed.  I believe gdb has code to recognize
this kind of sequence and run through it without stopping until after
the bne, precisely to avoid this problem.

Paul.