All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Michael Grundy <grundym@us.ibm.com>,
	Jan Glauber <jan.glauber@de.ibm.com>,
	linux-kernel@vger.kernel.org, systemtap@sources.redhat.com
Subject: Re: [PATCH] kprobes for s390 architecture
Date: Tue, 27 Jun 2006 17:23:09 +0200	[thread overview]
Message-ID: <1151421789.5390.65.camel@localhost> (raw)
In-Reply-To: <20060624113641.GB10403@osiris.ibm.com>

On Sat, 2006-06-24 at 13:36 +0200, Heiko Carstens wrote:
> > At least this is something that could work... completely untested and might
> > have some problems that I didn't think of ;)
> > 
> > struct capture_data {
> > 	atomic_t cpus;
> > 	atomic_t done;
> > };
> > 
> > void capture_wait(void *data)
> > { 
> > 	struct capture_data *cap = data;
> > 
> > 	atomic_inc(&cap->cpus);
> > 	while(!atomic_read(&cap->done))
> > 		cpu_relax();
> > 	atomic_dec(&cap->cpus);
> > }
> > 
> > void replace_instr(int *a)
> > {
> > 	struct capture_data cap;
> > 
> > 	preempt_disable();
> > 	atomic_set(&cap.cpus, 0);
> > 	atomic_set(&cap.done, 0);
> > 	smp_call_function(capture_wait, (void *)&cap, 0, 0);
> > 	while (atomic_read(&cap.cpus) != num_online_cpus() - 1)
> > 		cpu_relax();
> > 	*a = 0x42;
> > 	atomic_inc(&cap.done);
> > 	while (atomic_read(&cap.cpus))
> > 		cpu_relax();
> > 	preempt_enable();
> > }
> 
> Forget this crap. It can easily cause deadlocks with more than two cpus.

It is not that bad. Instead of preempt_disable/preempt_enable we need a
spinlock. Then only one cpu can do this particular smp_call_function
which will "stop" all other cpus until cap->done has been set.

> Just do a compare and swap operation on the instruction you want to replace,
> then do an smp_call_function() with the wait parameter set to 1 and passing
> a pointer to a function that does nothing but return.

Not good enough. An instruction can be fetched multiple times for a
single execution (see the other mail). So you have a half executed
instruction, the cache line is invalidated, a new instruction is written
and the cache line is recreated to finished the half executed
instruction. That can easiliy happen on millicoded instructions.

> The cs/csg instruction will make sure that your cpu has exclusive access
> to the memory region in question and will invalidate the cache lines on all
> other cpus.

That the cache line is invalidated does not mean that you are safe..

> With the following smp_call_function() you can make sure that all other
> cpus discard everything they have prefetched. Hence there is only a small
> window between the cs/csg and the return of smp_call_function() where you
> do not know if other cpus are executing the old or the new instruction.

The serialization is indeed done by the smp_call_function(). No need to
have a "bcr 15,0" in the called function, the lpsw at the end of the
interrupt already does the serialization.

-- 
blue skies,
  Martin.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

"Reality continues to ruin my life." - Calvin.



  parent reply	other threads:[~2006-06-27 15:23 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060623150344.GL9446@osiris.boeblingen.de.ibm.com>
2006-06-23 22:53 ` [heiko.carstens@de.ibm.com: Re: [PATCH] kprobes for s390 architecture] Michael Grundy
2006-06-23 22:21   ` [PATCH] kprobes for s390 architecture Heiko Carstens
2006-06-24 11:36     ` Heiko Carstens
2006-06-24 12:15       ` Heiko Carstens
2006-06-25 13:31         ` Mike Grundy
2006-06-26  8:09           ` Heiko Carstens
2006-06-26 10:49             ` Mike Grundy
2006-06-26 11:19               ` Heiko Carstens
2006-06-27 15:23       ` Martin Schwidefsky [this message]
2006-06-28  5:58         ` Heiko Carstens
2006-07-07 17:23           ` Mike Grundy
2006-07-07 17:25             ` Heiko Carstens
2006-07-08 18:54               ` Mike Grundy
2006-07-08 19:58                 ` Mike Grundy
2006-07-10  9:28                   ` Heiko Carstens
2006-07-10 22:20                     ` Mike Grundy
2006-07-11 13:54               ` Mike Grundy
2006-07-11 14:13                 ` Martin Schwidefsky
2006-06-12 13:15 Mike Grundy
2006-06-12 19:40 ` Martin Schwidefsky
2006-06-21  4:28   ` Mike Grundy
2006-06-21 16:38     ` Martin Schwidefsky
2006-06-21 17:15       ` Mike Grundy
2006-06-27 11:56         ` Martin Schwidefsky
2006-06-21 17:34       ` Mike Grundy
2006-06-22 11:28         ` Jan Glauber
2006-06-22 16:36           ` Mike Grundy
2006-06-23  8:50             ` Jan Glauber
2006-06-23 14:38             ` Heiko Carstens
2006-06-22  1:38       ` Mike Grundy
2006-06-21  9:40   ` Jan Glauber
2006-06-21 16:23 ` Jan Glauber

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=1151421789.5390.65.camel@localhost \
    --to=schwidefsky@de.ibm.com \
    --cc=grundym@us.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jan.glauber@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=systemtap@sources.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.