From: Michael Kerrisk <michael.kerrisk@googlemail.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: linux-aio <linux-aio@kvack.org>,
michael.kerrisk@gmail.com, zach.brown@oracle.com, bcrl@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [patch] man-pages: add documentation about the memlock implications of io_setup
Date: Tue, 10 Mar 2009 05:45:00 +1300 [thread overview]
Message-ID: <c49095e30903090945k1cf3c418sb3fd33946625da45@mail.gmail.com> (raw)
In-Reply-To: <x49zlfud6w7.fsf@segfault.boston.devel.redhat.com>
[CC+=Vegard Nossum]
Hi Jeff,
Note that my address for man-pages is mtk.manpages@gmail.com.
On Tue, Mar 10, 2009 at 4:59 AM, Jeff Moyer <jmoyer@redhat.com> wrote:
> Hi,
>
> This patch, against man-pages-3.19, adds verbiage surrounding the newly
> proposed accounting of pinned aio completion ring pages against the
> memlock rlimit. It also fixes up a few references to aio_context_t
> (which should be io_context_t). Sorry for conflating the two, I can
> break it apart if needed.
Breaking apart really would be better. Could you resubmit (to
mtk.manpages@, and CC linux-man@vger) please?
When you resubmit, could you please clarify the following:
1. For the "proposed accounting of pinned aio completion ring pages
against the memlock rlimit", can you tell me which mainline kernel
version this change (will) appear(s) in. (You say "proposed", so that
it's not clear when/if the change will be merged into mainline. A git
commit reference could be useful to me here.)
2. Regarding aio_context_t vs io_context_t, Vegard Nossum also raised
this issue a while back, and I replied that the aio_context_t type is
used because:
[[
These pages attempt to document the bare syscall API.
Take a look at the kernel sources: there the type *is*
aio_context_t.
]]
Perhaps I am/was being muddle-headed here, since, after all, the pages
do say "Link with -laio." (Once upon a time the pages actually *did*
use "io_context_t", but I changed that during a big clean-up of the
io_*.2 pages a year or two back.) Your thoughts? (Why do we even
have aio_context_t in the kernel versus io_context_t in libaio?)
Cheers,
Michael
> diff -up man-pages-3.19/man2/io_cancel.2.orig man-pages-3.19/man2/io_cancel.2
> --- man-pages-3.19/man2/io_cancel.2.orig 2009-03-08 11:57:50.000000000 -0400
> +++ man-pages-3.19/man2/io_cancel.2 2009-03-08 11:58:01.000000000 -0400
> @@ -32,7 +32,7 @@ io_cancel \- cancel an outstanding async
> .\"#include <linux/aio.h>
> .sp
> .\" .HP 16
> -.BI "int io_cancel(aio_context_t " ctx_id ", struct iocb *" iocb ,
> +.BI "int io_cancel(io_context_t " ctx_id ", struct iocb *" iocb ,
> .BI " struct io_event *" result );
> .\" .ad
> .\" .hy
> diff -up man-pages-3.19/man2/io_destroy.2.orig man-pages-3.19/man2/io_destroy.2
> --- man-pages-3.19/man2/io_destroy.2.orig 2009-03-08 11:58:08.000000000 -0400
> +++ man-pages-3.19/man2/io_destroy.2 2009-03-08 11:58:16.000000000 -0400
> @@ -31,7 +31,7 @@ io_destroy \- destroy an asynchronous I/
> .\" #include <linux/aio.h>
> .sp
> .\" .HP 17
> -.BI "int io_destroy(aio_context_t " ctx );
> +.BI "int io_destroy(io_context_t " ctx );
> .\" .ad
> .\" .hy
> .sp
> diff -up man-pages-3.19/man2/io_setup.2.orig man-pages-3.19/man2/io_setup.2
> --- man-pages-3.19/man2/io_setup.2.orig 2009-03-08 11:53:39.000000000 -0400
> +++ man-pages-3.19/man2/io_setup.2 2009-03-08 11:57:09.000000000 -0400
> @@ -31,7 +31,7 @@ io_setup \- create an asynchronous I/O c
> .\" #include <linux/aio.h>
> .sp
> .\" .HP 15
> -.BI "int io_setup(unsigned " nr_events ", aio_context_t *" ctxp );
> +.BI "int io_setup(unsigned " nr_events ", io_context_t *" ctxp );
> .\" .ad
> .\" .hy
> .sp
> @@ -45,7 +45,9 @@ at least \fInr_events\fP.
> \fIctxp\fP must not point to an AIO context that already exists, and must
> be initialized to 0 prior to the call.
> On successful creation of the AIO context, \fI*ctxp\fP is filled in
> -with the resulting handle.
> +with the resulting handle. Memory is reserved by the kernel for the completion
> +ring and, because this memory is pinned, it will be charged against the
> +process's memlock rlimit.
> .SH "RETURN VALUE"
> On success,
> .BR io_setup ()
> @@ -54,7 +56,8 @@ For the failure return, see NOTES.
> .SH "ERRORS"
> .TP
> .B EAGAIN
> -The specified \fInr_events\fP exceeds the user's limit of available events.
> +The specified \fInr_events\fP exceeds the process's limit of available events.
> +Try increasing the memlock rlimit for the process.
> .TP
> .B EFAULT
> An invalid pointer is passed for \fIctxp\fP.
> diff -up man-pages-3.19/man2/io_submit.2.orig man-pages-3.19/man2/io_submit.2
> --- man-pages-3.19/man2/io_submit.2.orig 2009-03-08 11:58:26.000000000 -0400
> +++ man-pages-3.19/man2/io_submit.2 2009-03-08 11:58:34.000000000 -0400
> @@ -31,7 +31,7 @@ io_submit \- submit asynchronous I/O blo
> .\" #include <linux/aio.h>
> .sp
> .\" .HP 16
> -.BI "int io_submit(aio_context_t " ctx_id ", long " nr \
> +.BI "int io_submit(io_context_t " ctx_id ", long " nr \
> ", struct iocb **" iocbpp );
> .\" .ad
> .\" .hy
> @@ -63,7 +63,7 @@ The file descriptor specified in the fir
> One of the data structures points to invalid data.
> .TP
> .B EINVAL
> -The \fIaio_context\fP specified by \fIctx_id\fP is invalid.
> +The \fIio_context\fP specified by \fIctx_id\fP is invalid.
> \fInr\fP is less than 0.
> The \fIiocb\fP at *iocbpp[0] is not properly initialized,
> or the operation specified is invalid for the file descriptor
> diff -up man-pages-3.19/man7/capabilities.7.orig man-pages-3.19/man7/capabilities.7
> --- man-pages-3.19/man7/capabilities.7.orig 2009-03-08 11:52:56.000000000 -0400
> +++ man-pages-3.19/man7/capabilities.7 2009-03-08 11:53:14.000000000 -0400
> @@ -129,7 +129,8 @@ Lock memory
> .RB ( mlock (2),
> .BR mlockall (2),
> .BR mmap (2),
> -.BR shmctl (2)).
> +.BR shmctl (2),
> +.BR io_setup (2)).
> .TP
> .B CAP_IPC_OWNER
> Bypass permission checks for operations on System V IPC objects.
>
next prev parent reply other threads:[~2009-03-09 16:45 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-09 15:49 [patch] aio: remove aio-max-nr and instead use the memlock rlimit to limit the number of pages pinned for the aio completion ring Jeff Moyer
2009-03-09 15:54 ` [patch] factor out checks against the memlock rlimit Jeff Moyer
2009-03-09 15:59 ` [patch] man-pages: add documentation about the memlock implications of io_setup Jeff Moyer
2009-03-09 16:45 ` Michael Kerrisk [this message]
2009-03-09 16:48 ` Michael Kerrisk
2009-03-09 20:44 ` Jeff Moyer
2009-03-09 16:18 ` [patch] aio: remove aio-max-nr and instead use the memlock rlimit to limit the number of pages pinned for the aio completion ring Avi Kivity
2009-03-09 17:57 ` Jeff Moyer
2009-03-09 19:45 ` Avi Kivity
2009-03-09 20:36 ` Jamie Lokier
2009-03-10 8:36 ` Avi Kivity
2009-03-09 20:31 ` Eric Dumazet
2009-03-12 2:39 ` Eric Dumazet
2009-03-12 2:44 ` Benjamin LaHaise
2009-03-12 3:24 ` Eric Dumazet
2009-03-12 3:29 ` Benjamin LaHaise
2009-03-12 3:33 ` Eric Dumazet
2009-03-12 3:36 ` Benjamin LaHaise
2009-03-12 3:40 ` Eric Dumazet
2009-03-12 3:09 ` Eric Dumazet
2009-03-12 5:18 ` [PATCH] fs: fput() can be called from interrupt context Eric Dumazet
2009-03-12 5:42 ` [PATCH] aio: " Eric Dumazet
2009-03-12 5:47 ` [PATCH] fs: " Andrew Morton
2009-03-12 6:10 ` Eric Dumazet
2009-03-12 6:39 ` Andrew Morton
2009-03-12 13:39 ` Davide Libenzi
2009-03-13 22:34 ` Davide Libenzi
2009-03-13 22:43 ` Eric Dumazet
2009-03-13 23:28 ` Trond Myklebust
2009-03-14 1:40 ` Davide Libenzi
2009-03-14 4:02 ` Trond Myklebust
2009-03-14 14:32 ` Davide Libenzi
2009-03-15 1:36 ` [patch] eventfd - remove fput() call from possible IRQ context Davide Libenzi
2009-03-15 17:44 ` Benjamin LaHaise
2009-03-15 20:08 ` [patch] eventfd - remove fput() call from possible IRQ context (2nd rev) Davide Libenzi
2009-03-16 17:25 ` Jamie Lokier
2009-03-16 18:36 ` Davide Libenzi
2009-03-18 14:22 ` Jeff Moyer
2009-03-18 14:46 ` Davide Libenzi
2009-03-18 14:55 ` Eric Dumazet
2009-03-18 15:25 ` Jeff Moyer
2009-03-18 15:43 ` Eric Dumazet
2009-03-18 16:13 ` Jeff Moyer
2009-03-18 17:25 ` [patch] eventfd - remove fput() call from possible IRQ context (3rd rev) Davide Libenzi
2009-03-18 17:34 ` Jeff Moyer
2009-03-12 19:22 ` [PATCH] fs: fput() can be called from interrupt context Eric Dumazet
2009-03-12 20:21 ` Andrew Morton
2009-03-09 22:36 ` [patch] aio: remove aio-max-nr and instead use the memlock rlimit to limit the number of pages pinned for the aio completion ring Andrew Morton
2009-03-10 13:43 ` Jeff Moyer
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=c49095e30903090945k1cf3c418sb3fd33946625da45@mail.gmail.com \
--to=michael.kerrisk@googlemail.com \
--cc=akpm@linux-foundation.org \
--cc=bcrl@kvack.org \
--cc=jmoyer@redhat.com \
--cc=linux-aio@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.kerrisk@gmail.com \
--cc=zach.brown@oracle.com \
/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
all inboxes | Powered by JetHome®