All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@kvack.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrew Morton <akpm@osdl.org>,
	Chandra Seetharaman <sekharan@us.ibm.com>,
	Keith Owens <kaos@sgi.com>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/8] Notifier chain update
Date: Wed, 18 Jan 2006 17:15:25 -0500	[thread overview]
Message-ID: <20060118221525.GI16285@kvack.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0601181706210.14089-100000@iolanthe.rowland.org>

On Wed, Jan 18, 2006 at 05:09:10PM -0500, Alan Stern wrote:
> On Wed, 18 Jan 2006, Benjamin LaHaise wrote:
> 
> > The notifier interface is supposed to be *light weight*.
> 
> Again, where is that documented?

Read the kernel.  Notifiers are called from all sorts of hot paths, so they 
damned well better be light.

> Which is worse: overhead due to cache misses or an oops caused by code 
> being called after it was unloaded?

Given that the overhead need not be present at all, neither.

> Do you have a better proposal for a way to prevent blocking notifier 
> chains from being modified while in use?  Or would you prefer to rewrite 
> all the callout routines that currently block, so that all the notifier 
> chains can be made atomic and we don't need the blocking notifier API?

Easy: in register_notifier stuff a serial number for each entry put on 
a notifier chain.  Remember the serial number of the entry before performing 
->notifier_call in notifier_call_chain.  Upon return, if the chain has been 
modified (easy to detect by nature of the serial number changing), walk 
the chain looking for the entry following the last serial number run.  Voila, 
rcu can be used to protect the chain's contents.

		-ben
-- 
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <dont@kvack.org>.

  reply	other threads:[~2006-01-18 22:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-18 16:34 [PATCH 1/8] Notifier chain update Alan Stern
2006-01-18 18:19 ` Benjamin LaHaise
2006-01-18 20:23   ` Alan Stern
2006-01-18 21:42     ` Benjamin LaHaise
2006-01-18 21:57       ` Alan Stern
2006-01-18 22:00         ` David S. Miller
2006-01-18 22:04           ` Alan Stern
2006-01-18 23:06           ` Alan Cox
2006-01-19  3:33             ` Alan Stern
2006-01-18 22:01         ` Benjamin LaHaise
2006-01-18 22:09           ` Alan Stern
2006-01-18 22:15             ` Benjamin LaHaise [this message]
2006-01-19 10:01               ` Jes Sorensen
2006-01-18 22:18             ` David S. Miller
2006-01-18 22:18               ` Benjamin LaHaise
2006-01-18 23:07       ` Alan Cox
2006-01-19  9:55       ` Jes Sorensen

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=20060118221525.GI16285@kvack.org \
    --to=bcrl@kvack.org \
    --cc=akpm@osdl.org \
    --cc=kaos@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sekharan@us.ibm.com \
    --cc=stern@rowland.harvard.edu \
    /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.