linux-kernel - Re: [RFC PATCH 0/5] module: Remove stop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <540686FF.4060907@hitachi.com>
Date:	Wed, 03 Sep 2014 12:11:59 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Lucas De Marchi <lucas.demarchi@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [RFC PATCH 0/5] module: Remove stop_machine from module unloading

Ping? :)

(2014/08/25 19:55), Masami Hiramatsu wrote:
> Hi,
> 
> Here is a series of patches which remove stop_machine() from
> module unloading.
> 
> Currently, each module unloading calls stop_machine()s 2 times.
> One is for safely removing module from lists and one is to
> check the reference counter. However, both are not necessary
> for those purposes (required by current implementation).
> 
> First, we can use RCU for the list operation, we just need
> a synchronize_rcu right before cleaning up.
> Second, the reference counter can be checked atomically by
> using atomic_t, instead of per-cpu module_ref. Of course,
> for BIG SMP machines, atomic operation is not efficient.
> However, they usually don't need to remove most of modules too.
> 
> In this series, I just fixed to use RCU for the module(and
> bugs) list for the first stop_machine.
> And for the second one, I replaced module_ref with atomic_t
> and introduced a "module lockup" module load option, which
> makes a module un-removable (lock up the module in kernel).
> The lockup modules can not be removed except forced, and the
> kernel skips module refcounting on those modules. Thus we
> can minimize the performance impact on the BIG SMP machines.
> 
> BTW, of course this requires to update libkmod to support
> new MODULE_INIT_LOCKUP_MODULE flag. I'm not sure where is
> good to send the patches I have. Sould I better sending
> kmod patches on LKML?
> 
> Thank you,
> 
> ---
> 
> Masami Hiramatsu (5):
>       module: Wait for RCU synchronizing before releasing a module
>       module: Unlink module with RCU synchronizing instead of stop_machine
>       lib/bug: Use RCU list ops for module_bug_list
>       module: Lock up a module when loading with a LOCLUP flag
>       module: Remove stop_machine from module unloading
> 
> 
>  include/linux/module.h        |   22 ++----
>  include/trace/events/module.h |    2 -
>  include/uapi/linux/module.h   |    1 
>  kernel/module.c               |  147 +++++++++++++++++------------------------
>  lib/bug.c                     |   20 ++++--
>  5 files changed, 85 insertions(+), 107 deletions(-)
> 
> --
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/