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]
Date:	Thu, 11 Oct 2012 10:43:38 -0300
From:	Lucas De Marchi <lucas.demarchi@...fusion.mobi>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	mtk.manpages@...il.com, Kees Cook <keescook@...omium.org>,
	linux-kernel@...r.kernel.org,
	linux-man <linux-man@...r.kernel.org>,
	Jon Masters <jonathan@...masters.org>
Subject: Re: [Request for review] Revised delete_module(2) manual page

Hi,

On Thu, Oct 11, 2012 at 12:02 AM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> writes:
>
>> Hello Kees, Rusty,
>>
>> The current delete_module(2) page is severely out of date (basically,
>> its content corresponds to 2.4 days, and was even pretty thin in
>> covering that). So, I took a shot at revising the page to Linux 2.6+
>> reality. Would it be possible that you could review it?
>
> OK.  Main suggestion is that I discussed with Lucas removing the
> !O_NONBLOCK case.  It's not supported by modprobe -r, and almost
> unheard-of for rmmod (it's --wait).
>
> In practice, people want the unload-or-fail semantics, or the
> force-unload semantics.


I'm all for removing this option. My idea was to complain loudly if
user tries to use it:
http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;h=8447b865aaac9139485dccdcc576725ddec2e7fa

But maybe it's good to just remove it altogether


>
>> Otherwise, by default,
>> .BR delete_module ()
>> marks a module so that no new references are permitted.
>> If the module's reference count
>> (i.e., the number of processes currently using the module) is nonzero,
>> it then places the caller in an uninterruptible sleep
>> state until all reference count is zero,
>> at which point the call unblocks.
>> When the reference count reaches zero, the module is unloaded.
>
> So this should be inverted:
>
>         Otherwise (assuming O_NONBLOCK, see flags below), if the
>         module's reference count (i.e., the number of processes
>         currently using the module) is nonzero, the call fails.
>
>> The
>> .IR flags
>> argument can be used to modify the behavior of the system call.
>
> It is usually set to O_NONBLOCK, which may be required in future kernel
> versions (see NOTES).
>
>> The following values can be ORed in this argument:
>> .TP
>> .B O_TRUNC
>> .\"   KMOD_REMOVE_FORCE in kmod library
>> Force unloading of the module, even if the following conditions are true:
>> .RS
>> .IP * 3
>> The module has no
>> .I exit
>> function.
>> By default, attempting to unload a module that has no
>> .I exit
>> function fails.
>> .IP *
>> The reference count for (i.e., the number of processes currently using)
>> this module is nonzero.
> ...
>> .IP
>> Using this flag taints the kernel (TAINT_FORCED_RMMOD).
>> .IP
>> .IR "Using this flag is dangerous!"
>> If the kernel was not built with
>> .BR CONFIG_MODULE_FORCE_UNLOAD ,
>> this flag is silently ignored.
>
> NOTES:
>
> If O_NONBLOCK is not set, then the kernel may enter uninterruptible
> sleep until the module reference count reaches zero.  This is not
> generally desirable, so this flag may be compulsory in future kernel
> configurations.

What do you think? Mark as deprecated now and remove when kernel
removes it? Or remove now?


Lucas De Marchi
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ