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 [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
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 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.