All of lore.kernel.org
 help / color / mirror / Atom feed
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.

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