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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <19214.63688.860929.962005@cargo.ozlabs.ibm.com>
Date:	Fri, 27 Nov 2009 08:53:12 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Veaceslav Falico <vfalico@...hat.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	"Frank Ch. Eigler" <fche@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org, utrace-devel@...hat.com,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: powerpc: fork && stepping (Was: [RFC,PATCH 0/14] utrace/ptrace)

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/