linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Andrew Morton <akpm@osdl.org>
Cc: sekharan@us.ibm.com, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Register atomic_notifiers in atomic context
Date: Thu, 23 Feb 2006 12:15:09 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.0602231145300.5204-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <20060222182601.1d628a01.akpm@osdl.org>

On Wed, 22 Feb 2006, Andrew Morton wrote:

> See, we avoid doing down_write() if the lock is uncontended.  And x86_64's
> uncontended down_write() unconditionally enables interrupts.

Not just x86_64; that's part of the general rw-semaphore implementation in
lib/rwsem-spinlock.c.  down_write() and down_read() always enable
interrupts, whether contended or not.

>  This evaded
> notice because might_sleep() warnings are disabled early in boot due to
> various horrid things.
> 
> Maybe we should enable the might_sleep() warnings because of this nasty
> rwsem trap.  We tried to do that a couple of weeks ago but we needed a pile
> of nasty workarounds to avoid false positives.

The situation is prone to bugs.  Special-case situations (like not
allowing task switching during system start-up) are always hard to handle.

> Applying this:
> 
> --- 25/kernel/sys.c~notifier-sleep-debug-update	2006-02-22 18:23:26.000000000 -0800
> +++ 25-akpm/kernel/sys.c	2006-02-22 18:25:45.000000000 -0800
> @@ -249,6 +249,8 @@ int blocking_notifier_chain_register(str
>  {
>  	int ret;
>  
> +	if (irqs_disabled())
> +		dump_stack();
>  	if (!down_write_trylock(&nh->rwsem)) {
>  		printk(KERN_WARNING "%s\n", __FUNCTION__);
>  		dump_stack();
> @@ -276,6 +278,8 @@ int blocking_notifier_chain_unregister(s
>  {
>  	int ret;
>  
> +	if (irqs_disabled())
> +		dump_stack();
>  	if (!down_write_trylock(&nh->rwsem)) {
>  		printk(KERN_WARNING "%s\n", __FUNCTION__);
>  		dump_stack();
> @@ -310,6 +314,8 @@ int blocking_notifier_call_chain(struct 
>  {
>  	int ret;
>  
> +	if (irqs_disabled())
> +		dump_stack();
>  	if (!down_read_trylock(&nh->rwsem)) {
>  		printk(KERN_WARNING "%s\n", __FUNCTION__);
>  		dump_stack();
> _
> 
> Gives:

... a bunch of calls to register_cpu_notifier and __exit_idle ...

> We're using blocking notifier chains in places where it's really risky, such as
> __exit_idle().  Time for a rethink, methinks.

Yes, that was clearly a mistake in the notifier-chain patch.  In x86_64,
the idle_notifier chain should be atomic, not blocking.  I missed the fact
that it gets invoked during an interrupt handler.

On the other hand, nothing in the vanilla kernel uses that notifier chain, 
and there doesn't seem to be any equivalent in other architectures.  
Perhaps it should just go away entirely?

The calls to register_cpu_notifier are harder.  That chain really does 
need to be blocking, which means we can't avoid calling down_write.  The 
only solution I can think of is to use down_write_trylock in the 
blocking_notifier_chain_register and unregister routines, even though 
doing that is a crock.

Or else change __down_read and __down_write to use spin_lock_irqsave 
instead of spin_lock_irq.  What do you think would be best?

> I'd suggest that in further development, you enable might_sleep() in early
> boot - that would have caught such things..

Not a bad idea.  I presume that removing the "system_state == 
SYSTEM_RUNNING" test in __might_sleep will have that effect?

Alan Stern


  reply	other threads:[~2006-02-23 17:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-21 15:54 [PATCH] Register atomic_notifiers in atomic context Alan Stern
2006-02-21 23:28 ` Andrew Morton
2006-02-22 16:08   ` Alan Stern
2006-02-22 16:12     ` Randy.Dunlap
2006-02-23  2:26     ` Andrew Morton
2006-02-23 17:15       ` Alan Stern [this message]
2006-02-23 19:03         ` Andrew Morton
2006-02-23 22:28           ` [PATCH] The idle notifier chain should be atomic Alan Stern
2006-02-23 23:49             ` Andi Kleen
2006-02-24  3:24               ` Alan Stern
2006-02-24  3:27                 ` Andi Kleen
2006-02-24  4:04                   ` Alan Stern
2006-02-23 22:36           ` [PATCH] Avoid calling down_read and down_write during startup Alan Stern
2006-02-23 22:37             ` Benjamin LaHaise
2006-02-24  0:16               ` Andrew Morton
2006-02-24  3:18                 ` Alan Stern
2006-02-24 14:40                   ` Benjamin LaHaise
2006-02-24 15:04                     ` Alan Stern
2006-02-24 15:15                       ` Benjamin LaHaise
2006-02-24 16:44                         ` Alan Stern
2006-02-24 16:44                           ` Benjamin LaHaise
2006-02-24 17:59                             ` Alan Stern
2006-02-24 18:37                               ` Benjamin LaHaise
2006-02-24 20:21                                 ` Alan Stern
2006-02-24 14:39                 ` Benjamin LaHaise
2006-02-24 15:03                   ` Alan Stern

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=Pine.LNX.4.44L0.0602231145300.5204-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sekharan@us.ibm.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).