From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 07:32:40
Hi all,
this patch adds workqueue based fsync offload. Version of this
patch have been floating around for a couple years, but we now
have a user with seastar used by ScyllaDB (who sponsored this
work) that really wants this in addition to the aio poll support.
More details are in the patch itself.
Because the iocb types have been defined sine day one (and probably
were supported by RHEL3) libaio already supports these calls as-is.
This also pulls in the aio cleanups and io_pgetevents support previously
submitted and review as part of the aio poll series. The aio poll
series will be resubmitted on top of this series
A git tree is available here:
git://git.infradead.org/users/hch/vfs.git aio-fsync.2
Gitweb:
http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/aio-fsync.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 07:32:24
The page size is in no way related to the aio code, and printing it in
the (debug) dmesg at every boot serves no purpose.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Reviewed-by: Darrick J. Wong <redacted>
---
fs/aio.c | 3 ---
1 file changed, 3 deletions(-)
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 07:32:29
One we cancel an iocb there is no reason to keep it on the active_reqs
list, given that the list is only used to look for cancelation candidates.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
---
fs/aio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 07:32:45
These days we don't treat sync iocbs special in the aio completion code as
they never use it. Remove the old comment, and move the BUG_ON for a sync
iocb to the top of the function.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Reviewed-by: Darrick J. Wong <redacted>
---
fs/aio.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
@@ -1088,6 +1088,8 @@ static void aio_complete(struct kiocb *kiocb, long res, long res2)unsignedtail,pos,head;unsignedlongflags;+BUG_ON(is_sync_kiocb(kiocb));+if(kiocb->ki_flags&IOCB_WRITE){structfile*file=kiocb->ki_filp;
@@ -1100,15 +1102,6 @@ static void aio_complete(struct kiocb *kiocb, long res, long res2)file_end_write(file);}-/*-*Specialcasehandlingforsynciocbs:-*-eventsgodirectlyintotheiocbforfasthandling-*-thesynctaskwiththeiocbinitsstackholdsthesingleiocb-*ref,nootherpathshaveawaytogetanotherref-*-thesynctaskhelpfullyleftareferencetoitselfintheiocb-*/-BUG_ON(is_sync_kiocb(kiocb));-if(iocb->ki_list.next){unsignedlongflags;
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 07:32:49
Don't reference the kiocb structure from the common aio code, and move
any use of it into helper specific to the read/write path. This is in
preparation for aio_poll support that wants to use the space for different
fields.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Reviewed-by: Darrick J. Wong <redacted>
---
fs/aio.c | 171 ++++++++++++++++++++++++++++++++++++---------------------------
1 file changed, 97 insertions(+), 74 deletions(-)
@@ -1163,11 +1141,12 @@ static void aio_complete(struct kiocb *kiocb, long res, long res2)*eventfd.Theeventfd_signal()functionissafetobecalled*fromIRQcontext.*/-if(iocb->ki_eventfd!=NULL)+if(iocb->ki_eventfd){eventfd_signal(iocb->ki_eventfd,1);+eventfd_ctx_put(iocb->ki_eventfd);+}-/* everything turned out well, dispose of the aiocb. */-kiocb_free(iocb);+kmem_cache_free(kiocb_cachep,iocb);/**Wehavetoorderourring_infotailstoreaboveandtest
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 07:32:53
Instead of handcoded non-null checks always initialize ki_list to an
empty list and use list_empty / list_empty_careful on it. While we're
at it also error out on a double call to kiocb_set_cancel_fn instead
of ignoring it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Reviewed-by: Darrick J. Wong <redacted>
---
fs/aio.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
@@ -1080,7 +1079,7 @@ static void aio_complete(struct aio_kiocb *iocb, long res, long res2)unsignedtail,pos,head;unsignedlongflags;-if(iocb->ki_list.next){+if(!list_empty_careful(iocb->ki_list.next)){unsignedlongflags;spin_lock_irqsave(&ctx->ctx_lock,flags);
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 07:32:56
With the current aio code there is no need for the magic KIOCB_CANCELLED
value, as a cancelation just kicks the driver to queue the completion
ASAP, with all actual completion handling done in another thread. Given
that both the completion path and cancelation take the context lock there
is no need for magic cmpxchg loops either.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
---
fs/aio.c | 37 +++++++++----------------------------
1 file changed, 9 insertions(+), 28 deletions(-)
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 07:33:05
The upcoming aio poll support would like to be able to complete the
iocb inline from the cancellation context, but that would cause
a lock order reversal. Add support for optionally moving the cancelation
outside the context lock to avoid this reversal.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
---
fs/aio.c | 49 ++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 38 insertions(+), 11 deletions(-)
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 07:33:09
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
fs/aio.c | 114 ++++++++++++++++++++++++++++++---
include/linux/compat.h | 7 ++
include/linux/syscalls.h | 6 ++
include/uapi/asm-generic/unistd.h | 4 +-
include/uapi/linux/aio_abi.h | 6 ++
kernel/sys_ni.c | 2 +
8 files changed, 130 insertions(+), 11 deletions(-)
@@ -339,6 +339,7 @@ 330 common pkey_alloc sys_pkey_alloc 331 common pkey_free sys_pkey_free 332 common statx sys_statx+333 common io_pgetevents sys_io_pgetevents # # x32-specific system call numbers start at 512 to avoid cache impact
@@ -1291,10 +1291,6 @@ static long read_events(struct kioctx *ctx, long min_nr, long nr,wait_event_interruptible_hrtimeout(ctx->wait,aio_read_events(ctx,min_nr,nr,event,&ret),until);--if(!ret&&signal_pending(current))-ret=-EINTR;-returnret;}
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 07:33:13
Simple workqueue offload for now, but prepared for adding a real aio_fsync
method if the need arises. Based on an earlier patch from Dave Chinner.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/aio.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
On Wed, Mar 21, 2018 at 08:32:24AM +0100, Christoph Hellwig wrote:
The page size is in no way related to the aio code, and printing it in
the (debug) dmesg at every boot serves no purpose.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Reviewed-by: Darrick J. Wong <redacted>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
On Wed, Mar 21, 2018 at 08:32:25AM +0100, Christoph Hellwig wrote:
quoted hunk
These days we don't treat sync iocbs special in the aio completion code as
they never use it. Remove the old comment, and move the BUG_ON for a sync
iocb to the top of the function.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Reviewed-by: Darrick J. Wong <redacted>
---
fs/aio.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
@@ -1088,6 +1088,8 @@ static void aio_complete(struct kiocb *kiocb, long res, long res2)unsignedtail,pos,head;unsignedlongflags;+BUG_ON(is_sync_kiocb(kiocb));
Is this BUG_ON even needed anymore? Does it ever trip in any "regular"
use, or is it only there for when a developer does something dumb? If
"dumb", then we should keep it, otherwise we might be able to just drop
it.
Either way, this patch is fine:
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
On Wed, Mar 21, 2018 at 08:32:26AM +0100, Christoph Hellwig wrote:
quoted hunk
Don't reference the kiocb structure from the common aio code, and move
any use of it into helper specific to the read/write path. This is in
preparation for aio_poll support that wants to use the space for different
fields.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Reviewed-by: Darrick J. Wong <redacted>
---
fs/aio.c | 171 ++++++++++++++++++++++++++++++++++++---------------------------
1 file changed, 97 insertions(+), 74 deletions(-)
That's nicer, thanks.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
On Wed, Mar 21, 2018 at 08:32:27AM +0100, Christoph Hellwig wrote:
quoted hunk
Instead of handcoded non-null checks always initialize ki_list to an
empty list and use list_empty / list_empty_careful on it. While we're
at it also error out on a double call to kiocb_set_cancel_fn instead
of ignoring it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Reviewed-by: Darrick J. Wong <redacted>
---
fs/aio.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
Will be fun to see if the syzkaller code ends up tripping on this one,
their use of panic-on-warn always is "interesting"...
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@@ -1080,7 +1079,7 @@ static void aio_complete(struct aio_kiocb *iocb, long res, long res2) unsigned tail, pos, head; unsigned long flags;- if (iocb->ki_list.next) {+ if (!list_empty_careful(iocb->ki_list.next)) { unsigned long flags; spin_lock_irqsave(&ctx->ctx_lock, flags);
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
On Wed, Mar 21, 2018 at 08:32:28AM +0100, Christoph Hellwig wrote:
With the current aio code there is no need for the magic KIOCB_CANCELLED
value, as a cancelation just kicks the driver to queue the completion
ASAP, with all actual completion handling done in another thread. Given
that both the completion path and cancelation take the context lock there
is no need for magic cmpxchg loops either.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
On Wed, Mar 21, 2018 at 08:32:29AM +0100, Christoph Hellwig wrote:
One we cancel an iocb there is no reason to keep it on the active_reqs
list, given that the list is only used to look for cancelation candidates.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
@@ -1088,6 +1088,8 @@ static void aio_complete(struct kiocb *kiocb, long res, long res2)unsignedtail,pos,head;unsignedlongflags;+BUG_ON(is_sync_kiocb(kiocb));
Is this BUG_ON even needed anymore? Does it ever trip in any "regular"
use, or is it only there for when a developer does something dumb? If
"dumb", then we should keep it, otherwise we might be able to just drop
it.
Probably not event needed anymore. is_sync_kiocb checks that
ki_complete is non-NULL, and aio_complete is static in aio.c now, so
it is almost impossibly to hit.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
On Wed, Mar 21, 2018 at 08:32:30AM +0100, Christoph Hellwig wrote:
quoted hunk
The upcoming aio poll support would like to be able to complete the
iocb inline from the cancellation context, but that would cause
a lock order reversal. Add support for optionally moving the cancelation
outside the context lock to avoid this reversal.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
---
fs/aio.c | 49 ++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 38 insertions(+), 11 deletions(-)
BIT(0) and BIT(1)?
Anyway, not a big deal...
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
On Wed, Mar 21, 2018 at 08:32:31AM +0100, Christoph Hellwig wrote:
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Do we have a manpage for this new syscall and maybe a test program for
it so we can exercise it as part of the kselftests?
And do we really need a compat thunk for a new syscall? Ugh, I guess
it's needed due to the long mess, right? No way to just define it the
same way for both arch sizes?
Anyway, the code seems sane to me:
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
On Wed, Mar 21, 2018 at 08:32:32AM +0100, Christoph Hellwig wrote:
quoted hunk
Simple workqueue offload for now, but prepared for adding a real aio_fsync
method if the need arises. Based on an earlier patch from Dave Chinner.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/aio.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
I hate the "bool" arguments to functions as you always need to go back
and look them up. A "wrapper" of "aio_fsync_datasync()" and
"aio_fsync_nodatasync()" around this maybe?
Anyway, very tiny nit, not a big deal, it's your code, you can maintain
it as-is :)
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 09:29:27
On Wed, Mar 21, 2018 at 10:24:43AM +0100, Greg KH wrote:
On Wed, Mar 21, 2018 at 08:32:31AM +0100, Christoph Hellwig wrote:
quoted
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Do we have a manpage for this new syscall and maybe a test program for
it so we can exercise it as part of the kselftests?
And do we really need a compat thunk for a new syscall? Ugh, I guess
it's needed due to the long mess, right? No way to just define it the
same way for both arch sizes?
Not without making it a pain to use. It should be a drop-in enhancement
to the existing aio abis, which all work on these types.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-21 09:30:51
On Wed, Mar 21, 2018 at 10:27:13AM +0100, Greg KH wrote:
I hate the "bool" arguments to functions as you always need to go back
and look them up. A "wrapper" of "aio_fsync_datasync()" and
"aio_fsync_nodatasync()" around this maybe?
This is how the fsync API works. Wrappers really don't help anything,
although flags would certainly be nicer. Next time I need to touch
->fsync for one reason or another that is high on the todo list.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
On Wed, Mar 21, 2018 at 10:29:26AM +0100, Christoph Hellwig wrote:
On Wed, Mar 21, 2018 at 10:24:43AM +0100, Greg KH wrote:
quoted
On Wed, Mar 21, 2018 at 08:32:31AM +0100, Christoph Hellwig wrote:
quoted
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Do we have a manpage for this new syscall and maybe a test program for
it so we can exercise it as part of the kselftests?
And do we really need a compat thunk for a new syscall? Ugh, I guess
it's needed due to the long mess, right? No way to just define it the
same way for both arch sizes?
Not without making it a pain to use. It should be a drop-in enhancement
to the existing aio abis, which all work on these types.
Ok, make sense, thanks.
greg k-h
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Darrick J. Wong <hidden> Date: 2018-03-21 16:23:10
On Wed, Mar 21, 2018 at 08:32:28AM +0100, Christoph Hellwig wrote:
quoted hunk
With the current aio code there is no need for the magic KIOCB_CANCELLED
value, as a cancelation just kicks the driver to queue the completion
ASAP, with all actual completion handling done in another thread. Given
that both the completion path and cancelation take the context lock there
is no need for magic cmpxchg loops either.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
---
fs/aio.c | 37 +++++++++----------------------------
1 file changed, 9 insertions(+), 28 deletions(-)
^^^ ^^^^^^^^^^^^^
I have the same complaint about how/who confusion and the spelling error
in this comment, but otherwise looks fine...
Reviewed-by: Darrick J. Wong <redacted>
--D
+ * cancel calls).
+ */
static int kiocb_cancel(struct aio_kiocb *kiocb)
{
- kiocb_cancel_fn *old, *cancel;
-
- /*
- * Don't want to set kiocb->ki_cancel = KIOCB_CANCELLED unless it
- * actually has a cancel function, hence the cmpxchg()
- */
-
- cancel = READ_ONCE(kiocb->ki_cancel);
- do {
- if (!cancel || cancel == KIOCB_CANCELLED)
- return -EINVAL;
-
- old = cancel;
- cancel = cmpxchg(&kiocb->ki_cancel, old, KIOCB_CANCELLED);
- } while (cancel != old);
+ kiocb_cancel_fn *cancel = kiocb->ki_cancel;
+ if (!cancel)
+ return -EINVAL;
+ kiocb->ki_cancel = NULL;
return cancel(&kiocb->rw);
}
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Darrick J. Wong <hidden> Date: 2018-03-21 16:23:48
On Wed, Mar 21, 2018 at 08:32:30AM +0100, Christoph Hellwig wrote:
The upcoming aio poll support would like to be able to complete the
iocb inline from the cancellation context, but that would cause
a lock order reversal. Add support for optionally moving the cancelation
outside the context lock to avoid this reversal.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Looks ok,
Reviewed-by: Darrick J. Wong <redacted>
--D
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Darrick J. Wong <hidden> Date: 2018-03-21 16:32:38
On Wed, Mar 21, 2018 at 08:32:31AM +0100, Christoph Hellwig wrote:
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks ok,
Reviewed-by: Darrick J. Wong <redacted>
--D
@@ -339,6 +339,7 @@ 330 common pkey_alloc sys_pkey_alloc 331 common pkey_free sys_pkey_free 332 common statx sys_statx+333 common io_pgetevents sys_io_pgetevents # # x32-specific system call numbers start at 512 to avoid cache impact
@@ -1291,10 +1291,6 @@ static long read_events(struct kioctx *ctx, long min_nr, long nr,wait_event_interruptible_hrtimeout(ctx->wait,aio_read_events(ctx,min_nr,nr,event,&ret),until);--if(!ret&&signal_pending(current))-ret=-EINTR;-returnret;}
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Darrick J. Wong <hidden> Date: 2018-03-21 16:32:59
On Wed, Mar 21, 2018 at 08:32:32AM +0100, Christoph Hellwig wrote:
Simple workqueue offload for now, but prepared for adding a real aio_fsync
method if the need arises. Based on an earlier patch from Dave Chinner.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks ok,
Reviewed-by: Darrick J. Wong <redacted>
--D
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Darrick J. Wong <hidden> Date: 2018-03-21 16:37:28
On Wed, Mar 21, 2018 at 08:32:29AM +0100, Christoph Hellwig wrote:
One we cancel an iocb there is no reason to keep it on the active_reqs
list, given that the list is only used to look for cancelation candidates.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <redacted>
Looks ok,
Reviewed-by: Darrick J. Wong <redacted>
--D
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-03-22 15:24:14
On Wed, Mar 21, 2018 at 08:32:27AM +0100, Christoph Hellwig wrote:
- if (iocb->ki_list.next) {
+ if (!list_empty_careful(iocb->ki_list.next)) {
Umm... Why not list_empty_careful(&iocb->ki_list)?
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-03-22 16:34:00
On Wed, Mar 21, 2018 at 08:32:30AM +0100, Christoph Hellwig wrote:
The upcoming aio poll support would like to be able to complete the
iocb inline from the cancellation context, but that would cause
a lock order reversal. Add support for optionally moving the cancelation
outside the context lock to avoid this reversal.
Ouch... Seeing that you've just taken out cmpxchg loop out of kiocb_cancel()
with "serialized on ->ctx_lock" for explanation of safety... Let me check
the aio_poll side of it; this commit might be better off in the poll series,
*if* it is actually correct.
What's to prevent double completions there? Suppose we have iocb sitting on
the wait queue; cancellation callback set, so's "delayed cancel" flag.
Now, somebody tries to cancel the fucker on CPU1. With ctx->lock held the
sucker is found on the list and, just as we mark it "cancelled", driver sends
a wakeup, executing (on CPU2) aio_poll_wake(), calling aio_complete_poll()
(without ctx->lock, so no exclusion with io_cancel(2) on CPU1), which checks
AIO_IOCB_CANCELLED and does not notice the flag being set on CPU1, then
proceeds to __aio_complete_poll() and fput() in there.
In the meanwhile, CPU1 has taken the sucker off the list, dropped the
lock and called kiocb_cancel() on it. Now we get aio_poll_cancel()
and __aio_complete_poll() on CPU1, with *another* fput().
What am I missing here that would prevent such a race?
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-03-22 16:36:07
On Wed, Mar 21, 2018 at 08:32:23AM +0100, Christoph Hellwig wrote:
Hi all,
this patch adds workqueue based fsync offload. Version of this
patch have been floating around for a couple years, but we now
have a user with seastar used by ScyllaDB (who sponsored this
work) that really wants this in addition to the aio poll support.
More details are in the patch itself.
Because the iocb types have been defined sine day one (and probably
were supported by RHEL3) libaio already supports these calls as-is.
This also pulls in the aio cleanups and io_pgetevents support previously
submitted and review as part of the aio poll series. The aio poll
series will be resubmitted on top of this series
Everything other than 6/9 looks sane; 6/9 belongs in aio poll series
and AFAICS its user in there is actually broken.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-03-22 16:36:57
On Thu, Mar 22, 2018 at 04:36:05PM +0000, Al Viro wrote:
On Wed, Mar 21, 2018 at 08:32:23AM +0100, Christoph Hellwig wrote:
quoted
Hi all,
this patch adds workqueue based fsync offload. Version of this
patch have been floating around for a couple years, but we now
have a user with seastar used by ScyllaDB (who sponsored this
work) that really wants this in addition to the aio poll support.
More details are in the patch itself.
Because the iocb types have been defined sine day one (and probably
were supported by RHEL3) libaio already supports these calls as-is.
This also pulls in the aio cleanups and io_pgetevents support previously
submitted and review as part of the aio poll series. The aio poll
series will be resubmitted on top of this series
Everything other than 6/9 looks sane; 6/9 belongs in aio poll series
and AFAICS its user in there is actually broken.
Gyah... 7/9, that is.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
From: Christoph Hellwig <hch@lst.de> Date: 2018-03-22 17:04:06
On Thu, Mar 22, 2018 at 03:24:14PM +0000, Al Viro wrote:
On Wed, Mar 21, 2018 at 08:32:27AM +0100, Christoph Hellwig wrote:
quoted
- if (iocb->ki_list.next) {
+ if (!list_empty_careful(iocb->ki_list.next)) {
Umm... Why not list_empty_careful(&iocb->ki_list)?
Yes, that makes a lot more sense.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>