From: Rusty Russell <rusty@rustcorp.com.au>
To: Daniel Phillips <phillips@arcor.de>
Cc: Roman Zippel <zippel@linux-m68k.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] In-kernel module loader 1/7
Date: Wed, 16 Oct 2002 09:53:26 +1000 [thread overview]
Message-ID: <20021016021949.DB2A92C2C1@lists.samba.org> (raw)
In-Reply-To: Your message of "Tue, 15 Oct 2002 17:28:33 +0200." <E181Tcc-0003k0-00@starship>
In message <E181Tcc-0003k0-00@starship> you write:
> On Tuesday 15 October 2002 05:25, Rusty Russell wrote:
> > 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.
This is basically the same technique used in my current patch. We set
module->live = 0, sychronize_kernel(), then look at reference count.
In this case, instead of setting a flag, try_inc_mod_count (aka
try_module_get()) bumps the refcount, to similar effect to the flag.
> > 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?
Definitely. We could simply allow schedule() to be called when
preempt is disabled, but it's a useful debugging tool to not do that.
And, of course, disabling preemption widely kind of defeats the point
of having a preemptive kernel 8(
I really wish the security guys had gone down the macro path, with
something like
#define security_check(func, default_val, ...)
({ if (try_inc_mod_count(security_ops->owner))
security_ops->func(__VA_ARGS__);
else
default_val;
})
This also allows the whole thing to vanish if
CONFIG_SECURITY_CAPABILITIES=n, and allows more flexibility for
schemes like "always run with preemption disabled around security ops"
or whatever, rather than having to search for all the references to
security_ops.
Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2002-10-16 2:13 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-18 2:05 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
2002-10-15 23:53 ` Rusty Russell [this message]
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=20021016021949.DB2A92C2C1@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@arcor.de \
--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
Powered by JetHome