Re: [heiko.carstens@de.ibm.com: Re: [PATCH] kprobes for s390 architecture]

[Michael Grundy <grundym@us.ibm.com>]

Heiko Carstens <heiko.carstens@de.ibm.com> wrote on 06/23/2006 08:03:44 AM:

> This won't solve anything. What Martin probably meant is something like a
poor
> man's stop_machine_run() implemented by using smp_call_function(). This
way
> you synchronize all cpus and when all cpus are in a known state, you
change
> the instruction in question and make sure that serialization happens
before
> cpus leave the handler again... Except for the cpu that called
> smp_call_function() you get the serialization for free, since the last
> instruction of the handler is always an lpsw/lpswe instruction.
>
> Otherwise there is still the possibility that a different cpu is fetching
the
> instruction concurrently while you change it. This doesn't sound very
good,
> especially if you take this paragraph of the Principles of Operation into
> account (p.5-89 of SA22-7832-04):
>
> "It is possible, if another CPU or a channel program concurrently
modifies
> the instruction, for one CPU to recognize the changes to some but not all
bit
> positions of an instruction."

(link to doc for anyone following along at home:
 http://publibz.boulder.ibm.com/epubs/pdf/a2278324.pdf)

On the same page it says "All copies of a prefetched instruction are
discarded
when: * A serializing function is performed" Would something like this in a
smp_call_function do it? :

bcr 15,0

if (*p->addr != breakpoint_instruction)
      *p->addr = breakpoint_instruction;


Alternatively, if we did a compare and swap on that location (serializing
instruction) would that be acceptable?

Thanks
Michael

=========================================
If at first you don't succeed, call in an air strike.

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