[Request for review] Revised delete_module(2) manual page

[Request for review] Revised delete_module(2) manual page

[Michael Kerrisk (man-pages)]

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?

Thanks,

Michael



.\" Copyright (C) 1996 Free Software Foundation, Inc.
.\" and Copyright (C) 2012 Michael Kerrisk <mtk.manpages@gmail.com>
.\" This file is distributed according to the GNU General Public License.
.\" See the file COPYING in the top level source directory for details.
.\"
.\" 2006-02-09, some reformatting by Luc Van Oostenryck; some
.\" reformatting and rewordings by mtk
.\"
.TH DELETE_MODULE 2 2012-10-09 "Linux" "Linux Programmer's Manual"
.SH NAME
delete_module \- unload a kernel module
.SH SYNOPSIS
.nf
.BI "int delete_module(const char *" name ", int " flags );
.fi

.IR Note :
There is no glibc wrapper for this system call; see NOTES.
.SH DESCRIPTION
.BR delete_module ()
attempts to remove the unused loadable module entry
identified by
.IR name .
This system call requires privilege.

If there are other loaded modules that depend on
(i.e., refer to symbols defined in) this module,
then the call fails.
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.
When the module is unloaded, the kernel executes its
.I exit
function.

The
.IR flags
argument can be used to modify the behavior of the system call.
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.
See the description of
.BR O_NONBLOCK .
.RE
.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.
.TP
.B O_NONBLOCK
.\"  	KMOD_REMOVE_NOWAIT in kmod library
If both
.B O_NONBLOCK
and
.B O_TRUNC
are specified in
.IR flags
(and the kernel was built with
.BR CONFIG_MODULE_FORCE_UNLOAD ),
then the module is unloaded immediately,
regardless of whether it has a nonzero reference count.
If
.B O_NONBLOCK
was specified, but
.B O_TRUNC
was not, then an error is returned
if the module has a nonzero reference count.
.SH "RETURN VALUE"
On success, zero is returned.
On error, \-1 is returned and
.I errno
is set appropriately.
.SH ERRORS
.TP
.B EBUSY
The module is not "live"
(i.e., it is still being initialized or is already marked for removal);
or, the module has no
.I exit
function and
.B O_TRUNC
was not specified in
.IR flags .

.TP
.B EFAULT
.I name
is outside the program's accessible address space.
.TP
.B EINVAL
.I name
was an empty string.
.TP
.B ENOENT
No module by that name exists.
.TP
.B EPERM
The caller was not privileged
(did not have the
.B CAP_SYS_MODULE
capability),
or module unloading is disabled
(see
.IR /proc/sys/kernel/modules_disabled
in
.BR proc (5)).
.TP
.B EWOULDBLOCK
Other modules depend on this module;
or,
.BR O_NONBLOCK
was specified in
.IR flags ,
but the reference count of this module is nonzero and
.B O_TRUNC
was not specified in
.IR flags .
.SH "CONFORMING TO"
.BR delete_module ()
is Linux-specific.
.SH NOTES
Glibc does not provide a wrapper for this system call; call it using
.BR syscall (2).

See the Linux kernel source file
.I include/linux/module.h
for some useful background information.

.SS Linux 2.4 and earlier
In Linux 2.4 and earlier, the system call took only one argument:

.BI "   int delete_module(const char *" name );

If
.I name
is NULL, all unused modules marked auto-clean are removed.

Some further details of differences in the behavior of
.BR delete_module ()
in Linux 2.4 and earlier are
.I not
currently explained in this manual page.
.SH "SEE ALSO"
.BR create_module (2),
.BR init_module (2),
.BR query_module (2),
.BR rmmod (8)

Re: [Request for review] Revised delete_module(2) manual page

[Rusty Russell]

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.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.

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

Cheers,
Rusty.

Re: [Request for review] Revised delete_module(2) manual page

[Lucas De Marchi]

Hi,

On Thu, Oct 11, 2012 at 12:02 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.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

Re: [Request for review] Revised delete_module(2) manual page

[Rusty Russell]

Lucas De Marchi <lucas.demarchi@profusion.mobi> writes:
> What do you think? Mark as deprecated now and remove when kernel
> removes it? Or remove now?

Complain now, and I'll queue the removal in two merge windows.

Thats gives us a chance just in case someone actually uses this; if so I
want to talk to them about what it is they want!

Thanks,
Rusty.

Re: [Request for review] Revised delete_module(2) manual page

[Michael Kerrisk (man-pages)]

[-- Attachment #1: Type: text/plain, Size: 7637 bytes --]

Hi Rusty,

Thanks for taking a look at this page. In the light of your comments,
I've substantially reworked the page, and further review would not go
amiss, in case I made a misstep along the way.

On Thu, Oct 11, 2012 at 5:02 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.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.

Okay -- I've substantially reworked the page to reflect these idea.

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

Got it. See my reworked text.

[...]

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

I've added some text under NOTES.

Okay, below (and attached) is the new version of the page. Let me know
of any concerns.

Cheers,

Michael


.\" Copyright (C) 2012 Michael Kerrisk <mtk.manpages@gmail.com>
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.TH DELETE_MODULE 2 2012-10-12 "Linux" "Linux Programmer's Manual"
.SH NAME
delete_module \- unload a kernel module
.SH SYNOPSIS
.nf
.BI "int delete_module(const char *" name ", int " flags );
.fi

.IR Note :
There is no glibc wrapper for this system call; see NOTES.
.SH DESCRIPTION
The
.BR delete_module ()
system call attempts to remove the unused loadable module entry
identified by
.IR name .
If the module has an
.I exit
function, then that function is executed before unloading the module.
The
.IR flags
argument is used to modify the behavior of the system call,
as described below.
This system call requires privilege.

Module removal is attempted according to the following rules:
.IP 1. 4
If there are other loaded modules that depend on
(i.e., refer to symbols defined in) this module,
then the call fails.
.IP 2.
Otherwise, if the reference count for the module
(i.e., the  number  of processes currently using the module)
is zero, then the module is immediately unloaded.
.IP 3.
If a module has a nonzero reference count,
then the behavior depends on the bits set in
.IR flags .
In normal usage (see NOTES), the
.BR O_NONBLOCK
flag is always specified, and the
.BR O_TRUNC
flag may additionally be specified.
.\"  	O_TRUNC == KMOD_REMOVE_FORCE in kmod library
.\"  	O_NONBLOCK == KMOD_REMOVE_NOWAIT in kmod library
The various combinations for
.I flags
have the following effect:
.RS 4
.TP
.B flags == O_NONBLOCK
The call returns immediately, with an error.
.TP
.B flags == (O_NONBLOCK | O_TRUNC)
The module is unloaded immediately,
regardless of whether it has a nonzero reference count.
.TP
.B flags == 0
If
.I flags
does not specify
.BR O_NONBLOCK ,
the following steps occur:
.RS
.IP * 3
The module is marked so that no new references are permitted.
.IP *
If the module's reference count is nonzero,
the caller is placed in an uninterruptible sleep state
.RB ( TASK_UNINTERRUPTIBLE )
until the reference count is zero, at which point the call unblocks.
.IP *
The module is unloaded in the usual way.
.RE
.RE
.PP
The
.B O_TRUNC
flag has one further effect on the rules described above.
By default,
attempting to remove a module that has an
.I init
function but no
.I exit
function fails.
However, if
.BR O_TRUNC
was specified, this requirement is bypassed.
.PP
Using the
.B O_TRUNC
flag is dangerous!
If the kernel was not built with
.BR CONFIG_MODULE_FORCE_UNLOAD ,
this flag is silently ignored.
(Normally ,
.BR CONFIG_MODULE_FORCE_UNLOAD
is enabled.)
Using this flag taints the kernel (TAINT_FORCED_RMMOD).
.SH "RETURN VALUE"
On success, zero is returned.
On error, \-1 is returned and
.I errno
is set appropriately.
.SH ERRORS
.TP
.B EBUSY
The module is not "live"
(i.e., it is still being initialized or is already marked for removal);
or, the module has
an
.I init
function but has no
.I exit
function, and
.B O_TRUNC
was not specified in
.IR flags .

.TP
.B EFAULT
.I name
refers to a location outside the process's accessible address space.
.TP
.B ENOENT
No module by that name exists.
.TP
.B EPERM
The caller was not privileged
(did not have the
.B CAP_SYS_MODULE
capability),
or module unloading is disabled
(see
.IR /proc/sys/kernel/modules_disabled
in
.BR proc (5)).
.TP
.B EWOULDBLOCK
Other modules depend on this module;
or,
.BR O_NONBLOCK
was specified in
.IR flags ,
but the reference count of this module is nonzero and
.B O_TRUNC
was not specified in
.IR flags .
.SH "CONFORMING TO"
.BR delete_module ()
is Linux-specific.
.SH NOTES
Glibc does not provide a wrapper for this system call; call it using
.BR syscall (2).

The unininterruptible sleep that may occur if
.BR O_NONBLOCK
is omitted from
.IR flags
is considered undesirable, because the sleeping process is left
in an unkillable state.
As at Linux 3.7, specifying
.BR O_NONBLOCK
is optional, but in future kernels it is likely to become mandatory.
.SS Linux 2.4 and earlier
In Linux 2.4 and earlier, the system call took only one argument:

.BI "   int delete_module(const char *" name );

If
.I name
is NULL, all unused modules marked auto-clean are removed.

Some further details of differences in the behavior of
.BR delete_module ()
in Linux 2.4 and earlier are
.I not
currently explained in this manual page.
.SH "SEE ALSO"
.BR create_module (2),
.BR init_module (2),
.BR query_module (2),
.BR lsmod (8),
.BR rmmod (8)

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

[-- Attachment #2: delete_module.2 --]
[-- Type: application/octet-stream, Size: 5434 bytes --]

.\" Copyright (C) 2012 Michael Kerrisk <mtk.manpages@gmail.com>
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.TH DELETE_MODULE 2 2012-10-12 "Linux" "Linux Programmer's Manual"
.SH NAME
delete_module \- unload a kernel module
.SH SYNOPSIS
.nf
.BI "int delete_module(const char *" name ", int " flags );
.fi

.IR Note :
There is no glibc wrapper for this system call; see NOTES.
.SH DESCRIPTION
The
.BR delete_module ()
system call attempts to remove the unused loadable module entry
identified by
.IR name .
If the module has an
.I exit
function, then that function is executed before unloading the module.
The
.IR flags
argument is used to modify the behavior of the system call,
as described below.
This system call requires privilege.

Module removal is attempted according to the following rules:
.IP 1. 4
If there are other loaded modules that depend on
(i.e., refer to symbols defined in) this module,
then the call fails.
.IP 2.
Otherwise, if the reference count for the module
(i.e., the  number  of processes currently using the module)
is zero, then the module is immediately unloaded.
.IP 3.
If a module has a nonzero reference count,
then the behavior depends on the bits set in
.IR flags .
In normal usage (see NOTES), the
.BR O_NONBLOCK
flag is always specified, and the
.BR O_TRUNC
flag may additionally be specified.
.\"  	O_TRUNC == KMOD_REMOVE_FORCE in kmod library
.\"  	O_NONBLOCK == KMOD_REMOVE_NOWAIT in kmod library
The various combinations for
.I flags
have the following effect:
.RS 4
.TP
.B flags == O_NONBLOCK
The call returns immediately, with an error.
.TP
.B flags == (O_NONBLOCK | O_TRUNC)
The module is unloaded immediately,
regardless of whether it has a nonzero reference count.
.TP
.B flags == 0
If
.I flags
does not specify
.BR O_NONBLOCK ,
the following steps occur:
.RS
.IP * 3
The module is marked so that no new references are permitted.
.IP *
If the module's reference count is nonzero,
the caller is placed in an uninterruptible sleep state
.RB ( TASK_UNINTERRUPTIBLE )
until the reference count is zero, at which point the call unblocks.
.IP *
The module is unloaded in the usual way.
.RE
.RE
.PP
The
.B O_TRUNC
flag has one further effect on the rules described above.
By default,
attempting to remove a module that has an
.I init
function but no
.I exit 
function fails.
However, if
.BR O_TRUNC
was specified, this requirement is bypassed.
.PP
Using the 
.B O_TRUNC
flag is dangerous!
If the kernel was not built with
.BR CONFIG_MODULE_FORCE_UNLOAD ,
this flag is silently ignored.
(Normally ,
.BR CONFIG_MODULE_FORCE_UNLOAD
is enabled.)
Using this flag taints the kernel (TAINT_FORCED_RMMOD).
.SH "RETURN VALUE"
On success, zero is returned.
On error, \-1 is returned and
.I errno
is set appropriately.
.SH ERRORS
.TP
.B EBUSY
The module is not "live"
(i.e., it is still being initialized or is already marked for removal);
or, the module has
an
.I init
function but has no
.I exit
function, and
.B O_TRUNC
was not specified in
.IR flags .

.TP
.B EFAULT
.I name
refers to a location outside the process's accessible address space.
.TP
.B ENOENT
No module by that name exists.
.TP
.B EPERM
The caller was not privileged
(did not have the
.B CAP_SYS_MODULE
capability),
or module unloading is disabled
(see
.IR /proc/sys/kernel/modules_disabled
in
.BR proc (5)).
.TP
.B EWOULDBLOCK
Other modules depend on this module;
or,
.BR O_NONBLOCK
was specified in
.IR flags ,
but the reference count of this module is nonzero and 
.B O_TRUNC
was not specified in
.IR flags .
.SH "CONFORMING TO"
.BR delete_module ()
is Linux-specific.
.SH NOTES
Glibc does not provide a wrapper for this system call; call it using
.BR syscall (2).

The unininterruptible sleep that may occur if
.BR O_NONBLOCK
is omitted from
.IR flags
is considered undesirable, because the sleeping process is left
in an unkillable state.
As at Linux 3.7, specifying
.BR O_NONBLOCK
is optional, but in future kernels it is likely to become mandatory.
.SS Linux 2.4 and earlier
In Linux 2.4 and earlier, the system call took only one argument:

.BI "   int delete_module(const char *" name );

If
.I name
is NULL, all unused modules marked auto-clean are removed.

Some further details of differences in the behavior of
.BR delete_module ()
in Linux 2.4 and earlier are
.I not
currently explained in this manual page.
.SH "SEE ALSO"
.BR create_module (2),
.BR init_module (2),
.BR query_module (2),
.BR lsmod (8),
.BR rmmod (8)

Re: [Request for review] Revised delete_module(2) manual page

[Michael Kerrisk (man-pages)]

[-- Attachment #1: Type: text/plain, Size: 7831 bytes --]

Ping!

Rusty (et al.) I'm pretty sure the new page text is okay, but I would
like someone knowledgeable to confirm.

Thanks,

Michael

---------- Forwarded message ----------
From: Michael Kerrisk (man-pages) <mtk.manpages@gmail.com>
Date: Fri, Oct 12, 2012 at 10:47 AM
Subject: Re: [Request for review] Revised delete_module(2) manual page


Hi Rusty,

Thanks for taking a look at this page. In the light of your comments,
I've substantially reworked the page, and further review would not go
amiss, in case I made a misstep along the way.

On Thu, Oct 11, 2012 at 5:02 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.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.

Okay -- I've substantially reworked the page to reflect these idea.

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

Got it. See my reworked text.

[...]

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

I've added some text under NOTES.

Okay, below (and attached) is the new version of the page. Let me know
of any concerns.

Cheers,

Michael


.\" Copyright (C) 2012 Michael Kerrisk <mtk.manpages@gmail.com>
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.TH DELETE_MODULE 2 2012-10-12 "Linux" "Linux Programmer's Manual"
.SH NAME
delete_module \- unload a kernel module
.SH SYNOPSIS
.nf
.BI "int delete_module(const char *" name ", int " flags );
.fi

.IR Note :
There is no glibc wrapper for this system call; see NOTES.
.SH DESCRIPTION
The
.BR delete_module ()
system call attempts to remove the unused loadable module entry
identified by
.IR name .
If the module has an
.I exit
function, then that function is executed before unloading the module.
The
.IR flags
argument is used to modify the behavior of the system call,
as described below.
This system call requires privilege.

Module removal is attempted according to the following rules:
.IP 1. 4
If there are other loaded modules that depend on
(i.e., refer to symbols defined in) this module,
then the call fails.
.IP 2.
Otherwise, if the reference count for the module
(i.e., the  number  of processes currently using the module)
is zero, then the module is immediately unloaded.
.IP 3.
If a module has a nonzero reference count,
then the behavior depends on the bits set in
.IR flags .
In normal usage (see NOTES), the
.BR O_NONBLOCK
flag is always specified, and the
.BR O_TRUNC
flag may additionally be specified.
.\"     O_TRUNC == KMOD_REMOVE_FORCE in kmod library
.\"     O_NONBLOCK == KMOD_REMOVE_NOWAIT in kmod library
The various combinations for
.I flags
have the following effect:
.RS 4
.TP
.B flags == O_NONBLOCK
The call returns immediately, with an error.
.TP
.B flags == (O_NONBLOCK | O_TRUNC)
The module is unloaded immediately,
regardless of whether it has a nonzero reference count.
.TP
.B flags == 0
If
.I flags
does not specify
.BR O_NONBLOCK ,
the following steps occur:
.RS
.IP * 3
The module is marked so that no new references are permitted.
.IP *
If the module's reference count is nonzero,
the caller is placed in an uninterruptible sleep state
.RB ( TASK_UNINTERRUPTIBLE )
until the reference count is zero, at which point the call unblocks.
.IP *
The module is unloaded in the usual way.
.RE
.RE
.PP
The
.B O_TRUNC
flag has one further effect on the rules described above.
By default,
attempting to remove a module that has an
.I init
function but no
.I exit
function fails.
However, if
.BR O_TRUNC
was specified, this requirement is bypassed.
.PP
Using the
.B O_TRUNC
flag is dangerous!
If the kernel was not built with
.BR CONFIG_MODULE_FORCE_UNLOAD ,
this flag is silently ignored.
(Normally ,
.BR CONFIG_MODULE_FORCE_UNLOAD
is enabled.)
Using this flag taints the kernel (TAINT_FORCED_RMMOD).
.SH "RETURN VALUE"
On success, zero is returned.
On error, \-1 is returned and
.I errno
is set appropriately.
.SH ERRORS
.TP
.B EBUSY
The module is not "live"
(i.e., it is still being initialized or is already marked for removal);
or, the module has
an
.I init
function but has no
.I exit
function, and
.B O_TRUNC
was not specified in
.IR flags .

.TP
.B EFAULT
.I name
refers to a location outside the process's accessible address space.
.TP
.B ENOENT
No module by that name exists.
.TP
.B EPERM
The caller was not privileged
(did not have the
.B CAP_SYS_MODULE
capability),
or module unloading is disabled
(see
.IR /proc/sys/kernel/modules_disabled
in
.BR proc (5)).
.TP
.B EWOULDBLOCK
Other modules depend on this module;
or,
.BR O_NONBLOCK
was specified in
.IR flags ,
but the reference count of this module is nonzero and
.B O_TRUNC
was not specified in
.IR flags .
.SH "CONFORMING TO"
.BR delete_module ()
is Linux-specific.
.SH NOTES
Glibc does not provide a wrapper for this system call; call it using
.BR syscall (2).

The unininterruptible sleep that may occur if
.BR O_NONBLOCK
is omitted from
.IR flags
is considered undesirable, because the sleeping process is left
in an unkillable state.
As at Linux 3.7, specifying
.BR O_NONBLOCK
is optional, but in future kernels it is likely to become mandatory.
.SS Linux 2.4 and earlier
In Linux 2.4 and earlier, the system call took only one argument:

.BI "   int delete_module(const char *" name );

If
.I name
is NULL, all unused modules marked auto-clean are removed.

Some further details of differences in the behavior of
.BR delete_module ()
in Linux 2.4 and earlier are
.I not
currently explained in this manual page.
.SH "SEE ALSO"
.BR create_module (2),
.BR init_module (2),
.BR query_module (2),
.BR lsmod (8),
.BR rmmod (8)

[-- Attachment #2: delete_module.2 --]
[-- Type: application/octet-stream, Size: 5450 bytes --]

.\" Copyright (C) 2012 Michael Kerrisk <mtk.manpages@gmail.com>
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.TH DELETE_MODULE 2 2012-10-18 "Linux" "Linux Programmer's Manual"
.SH NAME
delete_module \- unload a kernel module
.SH SYNOPSIS
.nf
.BI "int delete_module(const char *" name ", int " flags );
.fi

.IR Note :
There is no glibc wrapper for this system call; see NOTES.
.SH DESCRIPTION
The
.BR delete_module ()
system call attempts to remove the unused loadable module entry
identified by
.IR name .
If the module has an
.I exit
function, then that function is executed before unloading the module.
The
.IR flags
argument is used to modify the behavior of the system call,
as described below.
This system call requires privilege.

Module removal is attempted according to the following rules:
.IP 1. 4
If there are other loaded modules that depend on
(i.e., refer to symbols defined in) this module,
then the call fails.
.IP 2.
Otherwise, if the reference count for the module
(i.e., the  number  of processes currently using the module)
is zero, then the module is immediately unloaded.
.IP 3.
If a module has a nonzero reference count,
then the behavior depends on the bits set in
.IR flags .
In normal usage (see NOTES), the
.BR O_NONBLOCK
flag is always specified, and the
.BR O_TRUNC
flag may additionally be specified.
.\"  	O_TRUNC == KMOD_REMOVE_FORCE in kmod library
.\"  	O_NONBLOCK == KMOD_REMOVE_NOWAIT in kmod library

The various combinations for
.I flags
have the following effect:
.RS 4
.TP
.B flags == O_NONBLOCK
The call returns immediately, with an error.
.TP
.B flags == (O_NONBLOCK | O_TRUNC)
The module is unloaded immediately,
regardless of whether it has a nonzero reference count.
.TP
.B (flags & O_NONBLOCK) == 0
If
.I flags
does not specify
.BR O_NONBLOCK ,
the following steps occur:
.RS
.IP * 3
The module is marked so that no new references are permitted.
.IP *
If the module's reference count is nonzero,
the caller is placed in an uninterruptible sleep state
.RB ( TASK_UNINTERRUPTIBLE )
until the reference count is zero, at which point the call unblocks.
.IP *
The module is unloaded in the usual way.
.RE
.RE
.PP
The
.B O_TRUNC
flag has one further effect on the rules described above.
By default,
attempting to remove a module that has an
.I init
function but no
.I exit 
function fails.
However, if
.BR O_TRUNC
was specified, this requirement is bypassed.
.PP
Using the 
.B O_TRUNC
flag is dangerous!
If the kernel was not built with
.BR CONFIG_MODULE_FORCE_UNLOAD ,
this flag is silently ignored.
(Normally ,
.BR CONFIG_MODULE_FORCE_UNLOAD
is enabled.)
Using this flag taints the kernel (TAINT_FORCED_RMMOD).
.SH "RETURN VALUE"
On success, zero is returned.
On error, \-1 is returned and
.I errno
is set appropriately.
.SH ERRORS
.TP
.B EBUSY
The module is not "live"
(i.e., it is still being initialized or is already marked for removal);
or, the module has
an
.I init
function but has no
.I exit
function, and
.B O_TRUNC
was not specified in
.IR flags .

.TP
.B EFAULT
.I name
refers to a location outside the process's accessible address space.
.TP
.B ENOENT
No module by that name exists.
.TP
.B EPERM
The caller was not privileged
(did not have the
.B CAP_SYS_MODULE
capability),
or module unloading is disabled
(see
.IR /proc/sys/kernel/modules_disabled
in
.BR proc (5)).
.TP
.B EWOULDBLOCK
Other modules depend on this module;
or,
.BR O_NONBLOCK
was specified in
.IR flags ,
but the reference count of this module is nonzero and 
.B O_TRUNC
was not specified in
.IR flags .
.SH "CONFORMING TO"
.BR delete_module ()
is Linux-specific.
.SH NOTES
Glibc does not provide a wrapper for this system call; call it using
.BR syscall (2).

The unininterruptible sleep that may occur if
.BR O_NONBLOCK
is omitted from
.IR flags
is considered undesirable, because the sleeping process is left
in an unkillable state.
As at Linux 3.7, specifying
.BR O_NONBLOCK
is optional, but in future kernels it is likely to become mandatory.
.SS Linux 2.4 and earlier
In Linux 2.4 and earlier, the system call took only one argument:

.BI "   int delete_module(const char *" name );

If
.I name
is NULL, all unused modules marked auto-clean are removed.

Some further details of differences in the behavior of
.BR delete_module ()
in Linux 2.4 and earlier are
.I not
currently explained in this manual page.
.SH "SEE ALSO"
.BR create_module (2),
.BR init_module (2),
.BR query_module (2),
.BR lsmod (8),
.BR rmmod (8)

Re: [Request for review] Revised delete_module(2) manual page

[Rusty Russell]

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> Ping!
>
> Rusty (et al.) I'm pretty sure the new page text is okay, but I would
> like someone knowledgeable to confirm.

Yes, sorry, I did read it, and had nothing to add.

Ack,
Rusty.

Re: [Request for review] Revised delete_module(2) manual page

[Lucas De Marchi]

Hi Michael,


On Sun, Oct 21, 2012 at 5:36 AM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> Ping!
>
> Rusty (et al.) I'm pretty sure the new page text is okay, but I would
> like someone knowledgeable to confirm.

One more thing:

> .SH "SEE ALSO"
> .BR create_module (2),
> .BR init_module (2),
> .BR query_module (2),
> .BR lsmod (8),
> .BR rmmod (8)

Shouldn't we remove the reference to query_module(2) and
create_module(2)? They don't exist anymore (and I miss a bigger
warning on their man pages).

Last, I think there should be a ref here to modprobe (because of -r
flag), not lsmod. The rest looks good.


Lucas De Marchi

Re: [Request for review] Revised delete_module(2) manual page

[Michael Kerrisk (man-pages)]

Lucas,

On Wed, Oct 24, 2012 at 7:27 AM, Lucas De Marchi
<lucas.de.marchi@gmail.com> wrote:
> Hi Michael,
>
>
> On Sun, Oct 21, 2012 at 5:36 AM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> Ping!
>>
>> Rusty (et al.) I'm pretty sure the new page text is okay, but I would
>> like someone knowledgeable to confirm.
>
> One more thing:
>
>> .SH "SEE ALSO"
>> .BR create_module (2),
>> .BR init_module (2),
>> .BR query_module (2),
>> .BR lsmod (8),
>> .BR rmmod (8)
>
> Shouldn't we remove the reference to query_module(2) and
> create_module(2)? They don't exist anymore (and I miss a bigger
> warning on their man pages).

I think the SEE ALSO links should be kept, but you are right that the
warnings that query_module(2) and create_module(2) no longer exist
should be more prominent on those pages. By chance, I'd already made
that change.

> Last, I think there should be a ref here to modprobe (because of -r
> flag), not lsmod. The rest looks good.

I'll add modprobe(8); I think lsmod(8) is worth keeping.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

Re: [Request for review] Revised delete_module(2) manual page

[Michael Kerrisk (man-pages)]

On Wed, Oct 24, 2012 at 2:18 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>
>> Ping!
>>
>> Rusty (et al.) I'm pretty sure the new page text is okay, but I would
>> like someone knowledgeable to confirm.
>
> Yes, sorry, I did read it, and had nothing to add.
>
> Ack,

Thanks Rusty.