From: Ingo Molnar <mingo@kernel.org>
To: Christoph Lameter <cl@linux.com>
Cc: Tejun Heo <tj@kernel.org>,
akpm@linuxfoundation.org, linux-arch@vger.kernel.org,
Steven Rostedt <srostedt@redhat.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [pchecks v2 2/2] percpu: Add preemption checks to __this_cpu ops
Date: Tue, 24 Sep 2013 19:10:29 +0200 [thread overview]
Message-ID: <20130924171029.GB10261@gmail.com> (raw)
In-Reply-To: <0000014150a21408-2d759c49-6a9e-4553-956f-2d4b53e710f8-000000@email.amazonses.com>
* Christoph Lameter <cl@linux.com> wrote:
> Index: linux/lib/smp_processor_id.c
> ===================================================================
> --- linux.orig/lib/smp_processor_id.c 2013-09-24 10:06:26.000000000 -0500
> +++ linux/lib/smp_processor_id.c 2013-09-24 10:14:19.412825970 -0500
> @@ -7,7 +7,7 @@
> #include <linux/kallsyms.h>
> #include <linux/sched.h>
>
> -notrace unsigned int debug_smp_processor_id(void)
> +notrace static unsigned int check_preemption(char *what)
> {
> unsigned long preempt_count = preempt_count();
> int this_cpu = raw_smp_processor_id();
> @@ -39,8 +39,8 @@ notrace unsigned int debug_smp_processor
> if (!printk_ratelimit())
> goto out_enable;
>
> - printk(KERN_ERR "BUG: using smp_processor_id() in preemptible [%08x] "
> - "code: %s/%d\n",
> + printk(KERN_ERR "BUG: using %s in preemptible [%08x] "
> + "code: %s/%d\n", what,
> preempt_count() - 1, current->comm, current->pid);
> print_symbol("caller is %s\n", (long)__builtin_return_address(0));
> dump_stack();
> @@ -51,5 +51,18 @@ out:
> return this_cpu;
> }
>
> +notrace unsigned int debug_smp_processor_id(void)
> +{
> + return check_preemption("smp_processor_id()");
> +
> +}
> EXPORT_SYMBOL(debug_smp_processor_id);
>
> +notrace void __this_cpu_preempt_check(void)
> +{
> +#ifdef CONFIG_THIS_CPU_PREEMPTION_CHECK
> + check_preemption("__this_cpu operation");
> +#endif
> +}
> +EXPORT_SYMBOL(__this_cpu_preempt_check);
Ok, this variant looks pretty good, modulo testing. I'd do:
s/check_preemption/check_preemption_disabled
but that's a minor detail.
> +config DEBUG_THIS_CPU_OPERATIONS
> + bool "Debug __this_cpu operations"
> + depends on DEBUG_PREEMPT
> + default n
> + help
> + Enables preemption checks for __this_cpu macros. These
> + are macros to generate single instruction operations on
> + per cpu data. The option only affects the __this_cpu variant
> + which is used when fallback to multiple instructions without
> + other synchronization is possible. A verification is then
> + done to make sure that the thread cannot be preempted.
I don't think there's a need to make this a separate preemption debug
option: smp_processor_id() is really just a subset of the checks.
So please just put it under CONFIG_DEBUG_PREEMPT, there's no need to add
yet another x2 to the kernel Kconfig space. Maybe extend the DEBUG_PREEMPT
help text to explain that it also checks __this_cpu ops.
That will remove the #ifdef from lib/smp_processor_id.c and will simplify
debugging a bit as well.
Thanks,
Ingo
next prev parent reply other threads:[~2013-09-24 17:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130924154159.855373283@linux.com>
2013-09-24 15:41 ` [pchecks v2 1/2] Subject; percpu: Add raw_cpu_ops Christoph Lameter
2013-09-24 15:41 ` Christoph Lameter
2013-09-24 15:41 ` [pchecks v2 2/2] percpu: Add preemption checks to __this_cpu ops Christoph Lameter
2013-09-24 15:41 ` Christoph Lameter
2013-09-24 17:10 ` Ingo Molnar [this message]
2013-09-25 16:40 ` Christoph Lameter
2013-09-25 18:11 ` Ingo Molnar
2013-09-27 13:54 ` Christoph Lameter
2013-09-28 8:39 ` Ingo Molnar
2013-10-02 15:11 ` Christoph Lameter
2013-10-03 7:26 ` Ingo Molnar
2013-09-28 8:44 ` Ingo Molnar
2013-10-02 15:08 ` Christoph Lameter
2013-10-03 7:21 ` Ingo Molnar
2013-10-03 13:55 ` Peter Zijlstra
2013-10-03 14:15 ` Christoph Lameter
2013-10-03 15:35 ` Ingo Molnar
2013-10-03 15:59 ` Christoph Lameter
2013-10-03 16:44 ` Ingo Molnar
[not found] <20131003182902.174251532@linux.com>
2013-10-03 18:28 ` Christoph Lameter
2013-10-04 8:27 ` Peter Zijlstra
2013-10-04 8:37 ` Ingo Molnar
2013-10-04 15:27 ` Christoph Lameter
2013-10-04 16:52 ` Peter Zijlstra
2013-10-04 17:26 ` Christoph Lameter
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=20130924171029.GB10261@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linuxfoundation.org \
--cc=cl@linux.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=srostedt@redhat.com \
--cc=tj@kernel.org \
/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.