Re: [PATCH -tip v3&10 07/18] x86: Add text_poke_smp for SMP cross modifying code

From: Masami Hiramatsu
Date: Thu Feb 25 2010 - 22:52:53 EST


Mathieu Desnoyers wrote:
> * Masami Hiramatsu (mhiramat@xxxxxxxxxx) wrote:
[...]
>> +
>> +/*
>> + * Cross-modifying kernel text with stop_machine().
>> + * This code originally comes from immediate value.
>> + */
>> +static atomic_t stop_machine_first;
>> +static int wrote_text;
>> +
>> +struct text_poke_params {
>> + void *addr;
>> + const void *opcode;
>> + size_t len;
>> +};
>> +
>> +static int __kprobes stop_machine_text_poke(void *data)
>> +{
>> + struct text_poke_params *tpp = data;
>> +
>> + if (atomic_dec_and_test(&stop_machine_first)) {
>> + text_poke(tpp->addr, tpp->opcode, tpp->len);
>> + smp_wmb(); /* Make sure other cpus see that this has run */
>> + wrote_text = 1;
>> + } else {
>> + while (!wrote_text)
>> + smp_rmb();
>> + sync_core();
>
> Hrm, there is a problem in there. The last loop, when wrote_text becomes
> true, does not perform any smp_mb(), so you end up in a situation where
> cpus in the "else" branch may never issue any memory barrier. I'd rather
> do:

Hmm, so how about this? :)
---
} else {
do {
smp_rmb();
while (!wrote_text);
sync_core();
}
---

>
> +static volatile int wrote_text;
>
> ...
>
> +static int __kprobes stop_machine_text_poke(void *data)
> +{
> + struct text_poke_params *tpp = data;
> +
> + if (atomic_dec_and_test(&stop_machine_first)) {
> + text_poke(tpp->addr, tpp->opcode, tpp->len);
> + smp_wmb(); /* order text_poke stores before store to wrote_text */
> + wrote_text = 1;
> + } else {
> + while (!wrote_text)
> + cpu_relax();
> + smp_mb(); /* order wrote_text load before following execution */
> + }
>
> If you don't like the "volatile int" definition of wrote_text, then we
> should probably use the ACCESS_ONCE() macro instead.

hm, yeah, volatile will be required.

Thank you,


--
Masami Hiramatsu
e-mail: mhiramat@xxxxxxxxxx



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