From: Corey Minyard <minyard@acm.org>
To: Keith Owens <kaos@ocs.com.au>
Cc: Eyal Lebedinsky <eyal@eyal.emu.id.au>,
Marcelo Tosatti <marcelo@conectiva.com.br>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.4.21-rc3 - ipmi unresolved
Date: Sun, 25 May 2003 22:37:17 -0500 [thread overview]
Message-ID: <3ED18BED.40407@acm.org> (raw)
In-Reply-To: <28098.1053849441@ocs3.intra.ocs.com.au>
Keith Owens wrote:
>On Fri, 23 May 2003 23:38:53 +1000,
>Eyal Lebedinsky <eyal@eyal.emu.id.au> wrote:
>
>
>>The exports in ksyms are still necessary, and missing:
>>
>>depmod: *** Unresolved symbols in
>>/lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_msghandler.o
>>depmod: panic_notifier_list
>>depmod: *** Unresolved symbols in
>>/lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_watchdog.o
>>depmod: panic_notifier_list
>>depmod: panic_timeout
>>
>>
>
>Danger Will Robinson: panic notification to modules is racy.
>
>Registering via panic_notifier_list does not bump the module use count,
>a panic can occur while a module is being unloaded and you are dead.
>No big deal for panic, you are already dying, but it is just a symptom
>of a larger problem, yet another uncounted reference to module code.
>_ANY_ notifier callback to a module is racy, think very carefully
>before exporting any XXX_notifier_list.
>
>I would go so far as to say that no XXX_notifier_list should be
>exported, that includes notifier_chain_register() itself. If a module
>needs to be notified then it should have glue code in the main kernel
>that does try_inc_mod_count() on the module before calling any module
>functions.
>
Although, as you noted, this one is not a problem, you are probably
right in general.
However, having every modules that uses a notifier list have its own
custom code
in the kernel is probably not a very good option, either. It makes
things messy and
adds unneeded bloat to the kernel.
Would it be possible to have a notifier_chain_register_module() that did
the job
generically? Or maybe if notifier_chain_unregister() did a
synchronize_kernel()
(the RCU call to wait until everything is clear) would that be good
enough? It would
only work if all the notifier chain calls where done while the kernel
was unpreemptable,
if I understand this correctly. I realize the RCU option is not
available in 2.4, though.
-Corey
next prev parent reply other threads:[~2003-05-26 3:24 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-22 22:19 Linux 2.4.21-rc3 Marcelo Tosatti
2003-05-22 23:46 ` J.A. Magallon
2003-05-26 17:04 ` Alan Cox
2003-05-23 0:51 ` Barry K. Nathan
2003-05-23 5:32 ` Marc-Christian Petersen
2003-05-23 7:04 ` [BUG] 2.[45] ioperm fix seems broken (was Re: Linux 2.4.21-rc3) Barry K. Nathan
2003-05-23 9:00 ` Barry K. Nathan
2003-05-23 8:27 ` Linux 2.4.21-rc3 Benjamin Herrenschmidt
2003-05-23 13:38 ` Linux 2.4.21-rc3 - ipmi unresolved Eyal Lebedinsky
2003-05-23 13:41 ` Marc-Christian Petersen
2003-05-26 2:09 ` Corey Minyard
2003-05-25 7:57 ` Keith Owens
2003-05-26 3:37 ` Corey Minyard [this message]
2003-05-26 3:54 ` Keith Owens
2003-05-27 0:30 ` Corey Minyard
2003-05-27 3:09 ` Keith Owens
2003-05-27 4:45 ` Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved) Corey Minyard
2003-05-27 5:30 ` Keith Owens
2003-05-27 14:48 ` Corey Minyard
2003-05-27 16:02 ` viro
2003-05-27 17:09 ` Corey Minyard
2003-05-28 0:15 ` Keith Owens
2003-05-26 17:08 ` Linux 2.4.21-rc3 - ipmi unresolved Alan Cox
2003-05-23 21:10 ` Linux 2.4.21-rc3 [net-pf-4, devfs audio, drm radeon] Gabor Z. Papp
2003-05-25 17:36 ` Linux 2.4.21-rc3 : IDE pb on Alpha Willy Tarreau
2003-05-25 17:00 ` Willy Tarreau
2003-05-25 20:37 ` Mike Fedyk
2003-05-25 20:45 ` Bartlomiej Zolnierkiewicz
2003-05-25 20:55 ` Mike Fedyk
2003-05-25 21:23 ` Bartlomiej Zolnierkiewicz
2003-05-26 7:28 ` Linux 2.4.21-rc3: doesn't build with CONFIG_BLK_DEV_HD_ONLY=y Jerome Chantelauze
2003-05-26 13:16 ` Linux 2.4.21-rc3 Santiago Garcia Mantinan
2003-05-27 1:14 ` Jeff Chua
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=3ED18BED.40407@acm.org \
--to=minyard@acm.org \
--cc=eyal@eyal.emu.id.au \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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