All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Christoph Lameter <cl@linux.com>
Cc: Tejun Heo <tj@kernel.org>,
	akpm@linuxfoundation.org, Steven Rostedt <srostedt@redhat.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [pchecks v2 2/2] percpu: Add preemption checks to __this_cpu ops
Date: Fri, 4 Oct 2013 18:52:22 +0200	[thread overview]
Message-ID: <20131004165222.GS3081@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <0000014184145d57-7481d88a-649c-4016-8c59-5da2c822efec-000000@email.amazonses.com>

On Fri, Oct 04, 2013 at 03:27:15PM +0000, Christoph Lameter wrote:
> On Fri, 4 Oct 2013, Peter Zijlstra wrote:
> 
> > > -# define __this_cpu_read(pcp)	__pcpu_size_call_return(__this_cpu_read_, (pcp))
> > > +# define __this_cpu_read(pcp) \
> > > +	(__this_cpu_preempt_check(),__pcpu_size_call_return(__this_cpu_read_, (pcp)))
> > >  #endif
> >
> > Would it not be move convenient to implement it in terms of the
> > raw_this_cpu*() thingies? That way you're sure they actually do the same
> > thing and there's only 1 site to change when changing the
> > implementation.
> 
> The __this_cpu_read_xxx() are asm primitives provided by various arches.
> __this_cpu_read() is currently not overriden by any arches. That is why
> the approach here of replicating only the higher level for raw_cpu_ops
> works. Renaming the __this_cpu_xxx primitives would be a significant
> change.

This isn't about read; this is about all of them. Make sure the raw_*
implementation is the actual real implementation; then implement the
checking variant in terms of those.

> > >  	if (!printk_ratelimit())
> > >  		goto out_enable;
> > >
> > > -	printk(KERN_ERR "BUG: using smp_processor_id() in preemptible [%08x] "
> > > -			"code: %s/%d\n",
> > > +	printk(KERN_ERR "%s in preemptible [%08x] "
> > > +			"code: %s/%d\n", what,
> > >  			preempt_count() - 1, current->comm, current->pid);
> >
> > I would argue for keeping the "BUG" string intact and in front of the
> > %s.
> 
> Most of the place that I have seen are not bugs but there was a
> reason for the code to run a __this_cpu op without preemption disabled.

No; it is an actual BUG; it means that whoemever wrote the code didn't
think straight and forgot to use the right primitive and comments.

  reply	other threads:[~2013-10-04 16:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20131003182902.174251532@linux.com>
2013-10-03 18:28 ` [pchecks v2 2/2] percpu: Add preemption checks to __this_cpu ops 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 [this message]
2013-10-04 17:26         ` Christoph Lameter
2013-10-03 18:28 ` [pchecks v2 1/2] percpu: Add raw_cpu_ops Christoph Lameter
     [not found] <20130924154159.855373283@linux.com>
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
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

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=20131004165222.GS3081@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=akpm@linuxfoundation.org \
    --cc=cl@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=srostedt@redhat.com \
    --cc=tglx@linutronix.de \
    --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.