[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120522214633.GB30024@home.goodmis.org>
Date: Tue, 22 May 2012 17:46:33 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc: Ingo Molnar <mingo@...e.hu>,
Masami Hiramatsu <mhiramat@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Use test_and_clear_bit() instead atomic_dec_and_test()
for stop_machine
On Wed, May 23, 2012 at 03:11:48AM +0900, OGAWA Hirofumi wrote:
> [forgot to Cc: lkml, resend]
>
> Hi,
>
> Maybe, nobody using debug patch in atomic_dec_and_test()... Well,
> anyway, how about this?
What debug patch?
>
>
>
> stop_machine_first is just to see if it is first one or not. So, there
> is no reason to use atomic_dec_and_test(), and makes the value below 0.
>
> I think it is not desirable, because this usage only triggers
> atomic_dec_and_test() underflow debug patch. (the patch tests result
> of atomic_dec_and_test() is < 0)
Well it should only underflow if you have a box with more than 2 billion
CPUs.
>
> So, this uses test_and_clear_bit() instead.
>
> Signed-off-by: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
> ---
>
> arch/x86/kernel/alternative.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff -puN arch/x86/kernel/alternative.c~stop_machine-use-test_and_set_bit arch/x86/kernel/alternative.c
> --- linux/arch/x86/kernel/alternative.c~stop_machine-use-test_and_set_bit 2012-05-23 02:48:01.000000000 +0900
> +++ linux-hirofumi/arch/x86/kernel/alternative.c 2012-05-23 02:48:01.000000000 +0900
> @@ -650,7 +650,7 @@ void *__kprobes text_poke(void *addr, co
> * Cross-modifying kernel text with stop_machine().
> * This code originally comes from immediate value.
> */
> -static atomic_t stop_machine_first;
> +static unsigned long stop_machine_first;
The down side to this is that it adds 4 more bytes on a 64bit
machine. (sizeof(unsigned log) == 8 and sizeof(atomic_t) == 4)
You could probably also set it to -1, and do a atomic_inc_and_test(),
would that also cause the debug to trigger too?
-- Steve
> static int wrote_text;
>
> struct text_poke_params {
> @@ -664,7 +664,7 @@ static int __kprobes stop_machine_text_p
> struct text_poke_param *p;
> int i;
>
> - if (atomic_dec_and_test(&stop_machine_first)) {
> + if (test_and_clear_bit(0, &stop_machine_first)) {
> for (i = 0; i < tpp->nparams; i++) {
> p = &tpp->params[i];
> text_poke(p->addr, p->opcode, p->len);
> @@ -714,7 +714,7 @@ void *__kprobes text_poke_smp(void *addr
> p.len = len;
> tpp.params = &p;
> tpp.nparams = 1;
> - atomic_set(&stop_machine_first, 1);
> + stop_machine_first = 1;
> wrote_text = 0;
> /* Use __stop_machine() because the caller already got online_cpus. */
> __stop_machine(stop_machine_text_poke, (void *)&tpp, cpu_online_mask);
> @@ -736,7 +736,7 @@ void __kprobes text_poke_smp_batch(struc
> {
> struct text_poke_params tpp = {.params = params, .nparams = n};
>
> - atomic_set(&stop_machine_first, 1);
> + stop_machine_first = 1;
> wrote_text = 0;
> __stop_machine(stop_machine_text_poke, (void *)&tpp, cpu_online_mask);
> }
--
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/
Powered by blists - more mailing lists