linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Michael Buesch <mb@bu3sch.de>,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	David Brownell <david-b@pacbell.net>,
	Richard Purdie <rpurdie@rpsys.net>,
	<linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	<netdev@vger.kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	<linux-usb@vger.kernel.org>, <linux-wireless@vger.kernel.org>,
	<video4linux-list@redhat.com>,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	<lm-sensors@lm-sensors.org>
Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c
Date: Thu, 20 Mar 2008 20:17:23 -0700	[thread overview]
Message-ID: <20080320201723.b87b3732.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0803202301140.16520-100000@netrider.rowland.org>

On Thu, 20 Mar 2008 23:07:16 -0400 (EDT) Alan Stern <stern@rowland.harvard.edu> wrote:

> On Thu, 20 Mar 2008, Andrew Morton wrote:
> 
> > > > > Now, it happens that in_atomic() returns true on non-preemtible kernels
> > > > > when running in interrupt or softirq context.  But if the above code really
> > > > > is using in_atomic() to detect am-i-called-from-interrupt and NOT
> > > > > am-i-called-from-inside-spinlock, they should be using in_irq(),
> > > > > in_softirq() or in_interrupt().
> > > > 
> > > > Presumably most of these places are actually trying to detect 
> > > > am-i-allowed-to-sleep.  Isn't that what in_atomic() is supposed to do?  
> > > 
> > > No, I think there is no such check in the kernel. Most likely for performance
> > > reasons, as it would require a global flag that is set on each spinlock.
> > 
> > Yup.  non-preemptible kernels avoid the inc/dec of
> > current_thread_info->preempt_count on spin_lock/spin_unlock
> 
> So then what's the point of having in_atomic() at all?  Is it nothing 
> more than a shorthand form of (in_irq() | in_softirq() | 
> in_interrupt())?

in_atomic() is for core kernel use only.  Because in special circumstances
(ie: kmap_atomic()) we run inc_preempt_count() even on non-preemptible
kernels to tell the per-arch fault handler that it was invoked by
copy_*_user() inside kmap_atomic(), and it must fail.

> In short, you are saying that there is _no_ reliable way to determine
> am-i-called-from-inside-spinlock.

That's correct.

>  Well, why isn't there?

The reasons I identified: it adds additional overhead and it encourages
poorly-thought-out design.

Now we _could_ change kernel design principles from
caller-knows-whats-going-on over to callee-works-out-whats-going-on.  But
that would affect more than this particular thing.

>  Would it be 
> so terrible if non-preemptible kernels did adjust preempt_count on 
> spin_lock/unlock?

The vast, vast majority of kernel code has managed to get through life
without needing this hidden-argument-passing.  The handful of errant
callsites should be able to do so as well...


  reply	other threads:[~2008-03-21  3:20 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-16 18:43 use of preempt_count instead of in_atomic() at leds-gpio.c Henrique de Moraes Holschuh
2008-03-16 19:46 ` David Brownell
2008-03-18  7:14   ` Andrew Morton
2008-03-18 19:06     ` David Brownell
2008-03-18 20:07       ` Andrew Morton
2008-03-20 22:56     ` Henrique de Moraes Holschuh
2008-03-20 23:47       ` Andrew Morton
2008-03-21  0:36         ` Henrique de Moraes Holschuh
2008-03-21  1:08           ` Andrew Morton
2008-03-21  1:31             ` Alan Stern
2008-03-21  1:36               ` Michael Buesch
2008-03-21  2:27                 ` Andrew Morton
2008-03-21  3:07                   ` Alan Stern
2008-03-21  3:17                     ` Andrew Morton [this message]
2008-03-21  9:53                       ` Jean Delvare
2008-03-21 17:37                         ` Andrew Morton
2008-03-21 18:05                           ` Alan Stern
2008-03-24 19:34                             ` Jonathan Corbet
2008-03-24 19:42                               ` Andrew Morton
2008-03-24 19:53                                 ` Jonathan Corbet
2008-03-25  8:52                                   ` Junio C Hamano
2008-03-25 10:39                                     ` Jean Delvare
2008-03-25 13:44                                     ` Jonathan Corbet
2008-03-25 23:20                                       ` David Brownell
2008-03-26 14:28                                         ` Alan Stern
2008-03-26 16:17                                           ` Henrique de Moraes Holschuh
2008-03-26 16:46                                             ` Richard Purdie
2008-03-27 18:51                                             ` David Brownell
2008-03-21 15:11                       ` Tetsuo Handa
2008-03-21 16:54                         ` Stefan Richter
2008-03-21 17:02                           ` Stefan Richter
2008-03-23  5:53                             ` Tetsuo Handa
2008-03-21 13:47                   ` Heiko Carstens
2008-03-21 16:54                     ` Greg KH
2008-03-21 19:59                       ` Andrew Morton
2008-03-21 20:16                         ` Michael Buesch
2008-03-21 20:20                           ` Michael Buesch
2008-03-21  9:21             ` Stefan Richter
2008-03-21  9:27               ` Stefan Richter
2008-03-21 12:37               ` Henrique de Moraes Holschuh
2008-03-21 13:16                 ` Stefan Richter
2008-03-22 11:29                   ` Stefan Richter
2008-03-21 17:04             ` David Brownell
2008-03-21  0:56         ` Richard Purdie
2008-03-21  2:10           ` Henrique de Moraes Holschuh

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=20080320201723.b87b3732.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=david-b@pacbell.net \
    --cc=geert@linux-m68k.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hmh@hmh.eng.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=mb@bu3sch.de \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.org \
    --cc=rpurdie@rpsys.net \
    --cc=schwidefsky@de.ibm.com \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=stern@rowland.harvard.edu \
    --cc=video4linux-list@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).