From: Daniel Phillips <phillips@arcor.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Roman Zippel <zippel@linux-m68k.org>,
Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] In-kernel module loader 1/7
Date: Tue, 15 Oct 2002 17:28:33 +0200 [thread overview]
Message-ID: <E181Tcc-0003k0-00@starship> (raw)
In-Reply-To: <20021015052656.5ED272C18E@lists.samba.org>
On Tuesday 15 October 2002 05:25, Rusty Russell wrote:
> In message <E17w2XF-0005oW-00@starship> you write:
> > Not being able to unload LSM would suck enormously. At last count, we
> > knew how to do this:
> >
> > 1) Unhook the function hooks (using a call table simplifies this)
> > 2) Schedule on each CPU to ensure all tasks are out of the module
> > 3) A schedule where the module count is incremented doesn't count
> >
> > and we rely on the rule that and module code that could sleep must be
> > bracketed by inc/dec of the module count.
> >
> > Did somebody come up with a reason why this will not work?
>
> It won't quite work if the hooks can sleep. You can say "don't sleep"
> or have a wedge which does the "try_inc_mod_count()" then calls into
> the module (and returns some default if it can't inc the module count).
Right. By coincidence, I found myself thinking about this very problem
as I re-materialized this morning. If TRY_INC_MOD_COUNT also ors a flag
(which it does now, for other reasons) then:
1) Clear the mod_inc flag
2) Unhook the function hooks
3) Schedule on each CPU
4) If the mod_inc flag is set, repeat from (1)
This should perform acceptably well, and would only be done in cases
where the existing TRY_INC_MOD_COUNT strategy can't be used.
> You can't disable preemption before calling in, because there is no
> way to sleep with preemption disabled. 8(
Why is that harder than bumping a counter that makes preempt_schedule
return without doing anything?
--
Daniel
next prev parent reply other threads:[~2002-10-15 15:22 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-18 2:05 [PATCH] In-kernel module loader 1/7 Rusty Russell
2002-09-18 22:59 ` Roman Zippel
2002-09-19 1:00 ` Rusty Russell
2002-09-19 2:19 ` Daniel Jacobowitz
2002-09-19 3:57 ` Rusty Russell
2002-09-19 10:44 ` Roman Zippel
2002-09-19 12:51 ` Rusty Russell
2002-09-19 13:54 ` Roman Zippel
2002-09-19 18:38 ` Greg KH
2002-09-19 18:58 ` Alan Cox
2002-09-19 20:11 ` Greg KH
2002-09-19 20:42 ` Roman Zippel
2002-09-30 15:32 ` Daniel Phillips
2002-10-03 18:53 ` Rob Landley
2002-10-04 0:10 ` Daniel Phillips
2002-10-15 3:25 ` Rusty Russell
2002-10-15 15:28 ` Daniel Phillips [this message]
2002-10-15 23:53 ` Rusty Russell
2002-10-16 2:59 ` Daniel Phillips
2002-10-16 6:11 ` Rusty Russell
2002-10-16 17:33 ` Daniel Phillips
2002-10-16 22:48 ` Rusty Russell
2002-10-17 1:57 ` Daniel Phillips
2002-10-17 7:41 ` Rusty Russell
2002-10-17 14:49 ` Roman Zippel
2002-10-17 14:56 ` your mail Kai Germaschewski
2002-10-18 2:47 ` Rusty Russell
2002-10-18 21:50 ` Kai Germaschewski
2002-10-17 17:20 ` [RFC] change format of LSM hooks Daniel Phillips
2002-10-18 2:04 ` Rusty Russell
2002-10-17 17:25 ` Daniel Phillips
2002-10-16 8:15 ` [PATCH] In-kernel module loader 1/7 Chris Wright
2002-09-19 20:10 ` Roman Zippel
2002-09-20 1:22 ` Rusty Russell
2002-09-20 4:32 ` Greg KH
2002-09-20 9:25 ` Rusty Russell
2002-09-21 7:38 ` Kevin O'Connor
2002-09-22 23:31 ` Rusty Russell
2002-09-19 23:44 ` Rusty Russell
2002-09-20 9:32 ` Roman Zippel
2002-09-21 4:17 ` Rusty Russell
2002-09-21 17:09 ` Roman Zippel
2002-09-23 0:20 ` Rusty Russell
2002-09-24 10:16 ` Roman Zippel
2002-09-24 14:54 ` Rusty Russell
2002-09-25 0:46 ` Roman Zippel
2002-09-25 5:50 ` Rusty Russell
2002-09-25 11:36 ` Roman Zippel
2002-09-25 12:53 ` Rusty Russell
2002-09-25 21:28 ` Roman Zippel
2002-09-26 1:49 ` Rusty Russell
2002-09-26 23:38 ` Roman Zippel
2002-09-27 1:11 ` Scott Murray
2002-09-27 1:34 ` Roman Zippel
2002-09-28 0:48 ` David Lang
2002-10-15 4:53 ` Rusty Russell
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=E181Tcc-0003k0-00@starship \
--to=phillips@arcor.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=zippel@linux-m68k.org \
/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).