All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Veaceslav Falico <vfalico@redhat.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Christoph Hellwig <hch@infradead.org>,
	"Frank Ch. Eigler" <fche@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org, utrace-devel@redhat.com,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: powerpc: fork && stepping (Was: [RFC,PATCH 0/14] utrace/ptrace)
Date: Thu, 26 Nov 2009 23:37:03 +0100	[thread overview]
Message-ID: <20091126223703.GA28556@redhat.com> (raw)
In-Reply-To: <19214.63688.860929.962005@cargo.ozlabs.ibm.com>

On 11/27, Paul Mackerras wrote:
>
> 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.

Thanks! This explains everything, I think.

Could you look at this

	ptrace-copy_process-should-disable-stepping.patch
	http://marc.info/?l=linux-mm-commits&m=125789789322573

patch? It is not clear to me how we can modify the test-case to
verify it fixes the original problem for powerpc.

At least, do you think this patch is good for powerpc ?

Oleg.


  reply	other threads:[~2009-11-26 22:42 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-24 20:01 [RFC,PATCH 0/14] utrace/ptrace Oleg Nesterov
2009-11-25  8:03 ` Ananth N Mavinakayanahalli
2009-11-25 15:40   ` Oleg Nesterov
2009-11-26  7:53     ` Ananth N Mavinakayanahalli
2009-11-26 14:50       ` powerpc: fork && stepping (Was: [RFC,PATCH 0/14] utrace/ptrace) Oleg Nesterov
2009-11-26 17:25         ` Oleg Nesterov
2009-11-26 18:22           ` Veaceslav Falico
2009-11-26 20:23             ` Oleg Nesterov
2009-11-26 21:04               ` Oleg Nesterov
2009-11-26 21:53               ` Paul Mackerras
2009-11-26 22:37                 ` Oleg Nesterov [this message]
2009-11-27 17:46                   ` Veaceslav Falico
2009-11-28  7:30                     ` Ananth N Mavinakayanahalli
2009-11-29 21:07                       ` powerpc: syscall_dotrace() && retcode (Was: powerpc: fork && stepping) Oleg Nesterov
2009-11-29 23:15                         ` Benjamin Herrenschmidt
2009-11-30  0:43                           ` Benjamin Herrenschmidt
2009-11-30 20:00                             ` Oleg Nesterov
2009-11-30 20:01                           ` Oleg Nesterov
2009-12-01 19:27                             ` Roland McGrath
2009-12-01 20:17                               ` Benjamin Herrenschmidt
2009-11-26 22:40                 ` powerpc: fork && stepping (Was: [RFC,PATCH 0/14] utrace/ptrace) Andreas Schwab
2009-11-27  5:39         ` Ananth N Mavinakayanahalli
2009-11-27 15:05           ` Oleg Nesterov
2009-11-28  7:06             ` Ananth N Mavinakayanahalli
2009-11-25 21:48 ` [RFC,PATCH 0/14] utrace/ptrace Christoph Hellwig
2009-11-25 22:28   ` Oleg Nesterov
2009-11-26  7:07   ` Srikar Dronamraju
2009-11-26 12:55     ` Peter Zijlstra
2009-11-26  9:10   ` Ingo Molnar
2009-11-26 10:47     ` Christoph Hellwig
2009-11-26 12:24       ` Ingo Molnar
2009-11-27 14:04         ` Christoph Hellwig
2009-11-27 14:17           ` Oleg Nesterov
2009-11-27 19:16           ` Ingo Molnar
2009-11-26 14:27       ` Oleg Nesterov
2009-12-02  0:46         ` Roland McGrath
2009-11-29  8:59   ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091126223703.GA28556@redhat.com \
    --to=oleg@redhat.com \
    --cc=adobriyan@gmail.com \
    --cc=ananth@in.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=fche@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=roland@redhat.com \
    --cc=utrace-devel@redhat.com \
    --cc=vfalico@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.