Date: Fri, 24 Feb 2006 12:59:18 -0500 (EST)
From: Alan Stern <stern@rowland.harvard.edu>
To: Benjamin LaHaise <bcrl@kvack.org>
cc: Andrew Morton <akpm@osdl.org>, <sekharan@us.ibm.com>,
       Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Avoid calling down_read and down_write during startup
In-Reply-To: <20060224164415.GA7999@kvack.org>
Message-ID: <Pine.LNX.4.44L0.0602241255240.5177-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1409
Lines: 33

On Fri, 24 Feb 2006, Benjamin LaHaise wrote:

> On Fri, Feb 24, 2006 at 11:44:23AM -0500, Alan Stern wrote:
> > In that case you should be worried not about acquiring and releasing the 
> > rwsem at the beginning and end of blocking_notifier_call_chain; you should 
> > be worried about all the RCU serialization in the core 
> > notifier_call_chain routine.
> 
> RCU doesn't synchronize readers.

It does on architectures where smp_read_barrier_depends() expands into
something nontrivial.  Maybe that doesn't include any of the machines
you're interested in.

> > The atomic chains are a different matter.  The ones that don't run in NMI 
> > context could use an rw-spinlock for protection, allowing them also to 
> > avoid memory barriers while going through the list.  The notifier chains 
> > that do run in NMI don't have this luxury.  Fortunately I don't think 
> > there are very many of them.
> 
> A read lock is a memory barrier.  That's why I'm opposed to using non-rcu 
> style locking for them.

But RCU-style locking can't be used in situations where the reader may 
block.  So it's not possible to use it with blocking notifier chains.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/