On 12/21/18 12:22 PM, Jens Axboe wrote:
> Tell the block layer if it's a sync or async polled request, so it can
> do the right thing.
Forgot to drop this one, please disregard it as it's super ceded by the
next patch anyway...
--
Jens Axboe
For an ITER_BVEC, we can just iterate the iov and add the pages
to the bio directly. This requires that the caller doesn't releases
the pages on IO completion, we add a BIO_HOLD_PAGES flag for that.
The current two callers of bio_iov_iter_get_pages() are updated to
check if they need to release pa
Some uses cases repeatedly get and put references to the same file, but
the only exposed interface is doing these one at the time. As each of
these entail an atomic inc or dec on a shared structure, that cost can
add up.
Add fget_many(), which works just like fget(), except it takes an
argument fo
Add polled variants of PREAD/PREADV and PWRITE/PWRITEV. These act
like their non-polled counterparts, except we expect to poll for
completion of them. The polling happens at io_getevent() time, and
works just like non-polled IO.
To setup an io_context for polled IO, the application must call
io_se
We have to add each submitted polled request to the io_context
poll_submitted list, which means we have to grab the poll_lock. We
already use the block plug to batch submissions if we're doing a batch
of IO submissions, extend that to cover the poll requests internally as
well.
Signed-off-by: Jens
We don't use this at all, grab it to provide hints about the data.
The first hint we add is IORING_RES2_CACHEHIT, whether a read was
served out of the page cache, or if it hit media. This is useful
for buffered aio, O_DIRECT reads would never have this set (for
obvious reasons).
Signed-off-by: Jen
If we have fixed user buffers, we can map them into the kernel when we
setup the io_context. That avoids the need to do get_user_pages() for
each and every IO.
To utilize this feature, the application must use the SCQRING interface,
and additionally set IOCTX_FLAG_FIXEDBUFS when creating the IO co
Add support for backing the io_context with either a thread, or a
workqueue and letting those handle the submission for us. This can
be used to reduce overhead for submission, or to always make submission
async. The latter is particularly useful for buffered aio, which is
now fully async with this
The submission queue (SQ) and completion queue (CQ) rings are shared
between the application and the kernel. This eliminates the need to
copy data back and forth to submit and complete IO. We use the same
structures as the old aio interface. The SQ rings are indexes into a
struct iocb array, like w
This enables an application to do IO, without ever entering the kernel.
By using the SQ ring to fill in new events and watching for completions
on the CQ ring, we can submit and reap IOs without doing a single system
call. The kernel side thread will poll for new submissions, and in case
of HIPRI/p
Signed-off-by: Jens Axboe
---
fs/aio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/aio.c b/fs/aio.c
index a433503a2dc3..000bfa0de1ed 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -6,6 +6,7 @@
*
* Copyright 2000, 2001, 2002 Red Hat, Inc. All Rights Reserved.
* Copyright 2018 Ch
On the submission side, add file reference batching to the
aio_submit_state. We get as many references as the number of iocbs we
are submitting, and drop unused ones if we end up switching files. The
assumption here is that we're usually only dealing with one fd, and if
there are multiple, hopefuly
For the upcoming async polled IO, we can't sleep allocating requests.
If we do, then we introduce a deadlock where the submitter already
has async polled IO in-flight, but can't wait for them to complete
since polled requests must be active found and reaped.
Signed-off-by: Jens Axboe
---
include
Similarly to how we use the state->ios_left to know how many references
to get to a file, we can use it to allocate the aio_kiocb's we need in
bulk.
Signed-off-by: Jens Axboe
---
fs/aio.c | 42 --
1 file changed, 36 insertions(+), 6 deletions(-)
diff --gi
Tell the block layer if it's a sync or async polled request, so it can
do the right thing.
Signed-off-by: Jens Axboe
---
fs/block_dev.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 6de8d35f6e41..b8f574615792 100644
--- a/fs/blo
This is used for the user iocb pointer right now, but in preparation
for having iocbs not reside in userspace, unionize with a ki_index
and pass that in instead.
Signed-off-by: Jens Axboe
---
fs/aio.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/fs/ai
From: Christoph Hellwig
Store the request queue the last bio was submitted to in the iocb
private data in addition to the cookie so that we find the right block
device. Also refactor the common direct I/O bio submission code into a
nice little helper.
Signed-off-by: Christoph Hellwig
Modified
We need to treat sync and async IO differently. Use the provided helper
instead of setting it manually, then we also get the async case correct
by marking it NOWAIT.
Signed-off-by: Jens Axboe
---
fs/block_dev.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/fs/bl
In preparation from having pre-allocated requests, that we then just
need to initialize before use.
Signed-off-by: Jens Axboe
---
fs/aio.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 33d1d2c0d6fe..093e6c8e9e09 100644
--- a/fs/a
Signed-off-by: Jens Axboe
---
fs/aio.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 513ecd3fa681..d33417bee594 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1198,12 +1198,9 @@ static void aio_fill_event(struct io_event *ev, struct
ai
This is just like io_setup(), except add a flags argument to let the
caller control/define some of the io_context behavior.
Outside of the flags, we add two user pointers for future use.
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
---
Documentation/sysctl/fs.txt| 8 +-
From: Christoph Hellwig
This new methods is used to explicitly poll for I/O completion for an
iocb. It must be called for any iocb submitted asynchronously (that
is with a non-null ki_complete) which has the IOCB_HIPRI flag set.
The method is assisted by a new ki_cookie field in struct iocb to
From: Christoph Hellwig
Just call blk_poll on the iocb cookie, we can derive the block device
from the inode trivially.
Reviewed-by: Johannes Thumshirn
Signed-off-by: Christoph Hellwig
Signed-off-by: Jens Axboe
---
fs/block_dev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
Going to be out the next week or so, but I wanted to flush out the
current series first. Mainly just addressing review comments, but
also fixing a few issues and just cleaning up the comments and
changelogs in general since some of those were a little stale due
to initial churn of the series.
See
On Fri, Dec 21, 2018 at 08:26:02AM -0700, Jens Axboe wrote:
> On 12/21/18 7:54 AM, Dennis Zhou wrote:
> > I cleaned up blkg_tryget_closest() to require rcu_read_lock() earlier.
> > However, this was a subtle case too which clearly was too subtle for me.
> > The idea was the src bio should be holdin
On 12/21/18 10:02 AM, Dennis Zhou wrote:
> On Fri, Dec 21, 2018 at 08:26:02AM -0700, Jens Axboe wrote:
>> On 12/21/18 7:54 AM, Dennis Zhou wrote:
>>> I cleaned up blkg_tryget_closest() to require rcu_read_lock() earlier.
>>> However, this was a subtle case too which clearly was too subtle for me.
>
On 12/21/18 7:54 AM, Dennis Zhou wrote:
> I cleaned up blkg_tryget_closest() to require rcu_read_lock() earlier.
> However, this was a subtle case too which clearly was too subtle for me.
> The idea was the src bio should be holding a ref to the blkg so rcu
> wasn't technically needed. If it doesn'
I cleaned up blkg_tryget_closest() to require rcu_read_lock() earlier.
However, this was a subtle case too which clearly was too subtle for me.
The idea was the src bio should be holding a ref to the blkg so rcu
wasn't technically needed. If it doesn't hold a ref, it should be %NULL
and the blkg->p
Hello,
syzbot found the following crash on:
HEAD commit:340ae71f9dd4 Add linux-next specific files for 20181221
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11d9566740
kernel config: https://syzkaller.appspot.com/x/.config?x=c190b602a5d2d731
29 matches
Mail list logo
