From: Rusty Russell <rusty@rustcorp.com.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ionut Alexa <ionut.m.alexa@gmail.com>,
Kees Cook <keescook@chromium.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PULL] modules-next
Date: Mon, 22 Dec 2014 11:51:10 +1030 [thread overview]
Message-ID: <87zjagv5rt.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CA+55aFxS_JuFE+RM8cjeLx5tXu8XJVznfyrD4MSUqV85gPfx0w@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, Dec 18, 2014 at 4:55 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>
>> The exciting thing here is the getting rid of stop_machine on module
>> removal. This is possible by using a simple atomic_t for the counter,
>> rather than our fancy per-cpu counter: it turns out that no one is doing
>> a module increment per net packet, so the slowdown should be in the noise.
>
> Famous last words. It may not happen per-packet, but I see
> module_get() in various block drivers and in netfilter code etc, and
> some of them may be pretty bad.
>
> Let's see how it all works out.
Indeed. The general pattern is "get on open/init"; get-on-every-use was
most useful combined with blocking rmmod, which we removed a few kernels
ago (because no one used it).
I did a random audit until I got bored, and I put a printk-on-module-get
in my kernels for a while, and none of my usecases flood my logs. But
it's definitely a risk...
Cheers,
Rusty.
next prev parent reply other threads:[~2014-12-23 0:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-19 0:55 [PULL] modules-next Rusty Russell
2014-12-19 5:01 ` Linus Torvalds
2014-12-22 1:21 ` Rusty Russell [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-08-01 1:02 Rusty Russell
2016-08-01 1:44 ` Linus Torvalds
2016-08-01 19:11 ` Ben Hutchings
2016-08-02 0:10 ` Rusty Russell
2016-08-04 0:50 ` Rusty Russell
2015-11-08 23:42 Rusty Russell
2015-06-30 2:47 Rusty Russell
2015-02-13 6:43 Rusty Russell
2014-09-16 15:48 Rusty Russell
2014-08-11 2:32 Rusty Russell
2014-06-11 5:33 Rusty Russell
2014-06-11 10:55 ` Mark Brown
2014-06-12 1:25 ` Rusty Russell
2014-06-12 11:27 ` Mark Brown
2014-06-13 1:03 ` Rusty Russell
2014-06-13 9:24 ` Mark Brown
2014-06-13 10:04 ` Geert Uytterhoeven
2013-07-10 3:55 Rusty Russell
2013-02-19 23:14 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=87zjagv5rt.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=ionut.m.alexa@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=torvalds@linux-foundation.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).