-by: Jens Axboe
---
block/bio.c | 6 --
include/linux/blk_types.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 06760543ec81..3e45e5650265 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1636,7 +1636,8 @@ static void bio_dirty_fn
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 | 47 +++
1 file changed, 39 insertions(+), 8 deleti
to enter the
kernel to do IO.
Sample application: http://brick.kernel.dk/snaps/aio-ring.c
Signed-off-by: Jens Axboe
---
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
fs/aio.c | 435 +++--
include/linux/syscalls.h | 4 +-
include/uapi
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 fd323b3ba499..de48faeab0fd 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1218,12 +1218,9 @@ static void aio_fill_event(struct io_event *ev, struct
for how many references to get on the file. Ditto fput_many(),
which can drop an arbitrary number of references to a file.
Signed-off-by: Jens Axboe
---
fs/file.c| 15 ++-
fs/file_table.c | 10 --
include/linux/file.h | 2 ++
include/linux/fs.h | 3 ++-
4
, hopefuly they are at least somewhat ordered. Could
trivially be extended to cover multiple fds, if needed.
On the completion side we do the same thing, except this is trivially
done just locally in aio_iopoll_reap().
Signed-off-by: Jens Axboe
---
fs/aio.c | 106
change for how to utilize this feature:
http://git.kernel.dk/cgit/fio/commit/?id=2041bd343da1c1e955253f62374588718c64f0f3
Signed-off-by: Jens Axboe
---
fs/aio.c | 193 ---
include/uapi/linux/aio_abi.h | 1 +
2 files changed, 177 insertions
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 3c07cc9cb11a..51c7159f09bf 100644
--- a/fs
This adds support for sync/async O_DIRECT to make a bvec type iter
for bdev access, as well as iomap.
Signed-off-by: Jens Axboe
---
fs/block_dev.c | 16
fs/iomap.c | 10 +++---
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/fs/block_dev.c b/fs
For an ITER_BVEC, we can just iterate the iov and add the pages
to the bio directly.
Signed-off-by: Jens Axboe
---
block/bio.c | 27 +++
include/linux/bio.h | 1 +
2 files changed, 28 insertions(+)
diff --git a/block/bio.c b/block/bio.c
index 3e45e5650265
-by: Jens Axboe
---
fs/aio.c | 136 +--
1 file changed, 113 insertions(+), 23 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index cc8763b395c1..5e840396f6d8 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -240,6 +240,21 @@ struct aio_kiocb
Signed-off-by: Jens Axboe
---
fs/aio.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 06c8bcc72496..173f1f79dc8f 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1063,6 +1063,15 @@ static inline void iocb_put(struct aio_kiocb *iocb
?id=3c3168e91329c83880c91e5abc28b9d6b940fd95
Signed-off-by: Jens Axboe
---
fs/aio.c | 126 +++
include/uapi/linux/aio_abi.h | 2 +
2 files changed, 116 insertions(+), 12 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 26631d6872d2..bb6f07ca6940 100644
--- a/fs/ai
In preparation of handing in iocbs in a different fashion as well. Also
make it clear that the iocb being passed in isn't modified, by marking
it const throughout.
Signed-off-by: Jens Axboe
---
fs/aio.c | 68 +++-
1 file changed, 38 insertions
It's 192 bytes, fairly substantial. Most items don't need to be cleared,
especially not upfront. Clear the ones we do need to clear, and leave
the other ones for setup when the iocb is prepared and submitted.
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
---
fs/aio.c | 9
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 an iocb array and two user pointers for
future use.
Signed-off-by: Jens Axboe
---
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
fs/aio.c
to support completion reaping
from userspace by just looking at the ring. The application itself
is the one that pulls completion entries.
Signed-off-by: Jens Axboe
---
fs/aio.c | 396 +++
include/uapi/linux/aio_abi.h | 3 +
2 files changed, 363
From: Christoph Hellwig
This is in preparation for certain types of IO not needing a ring
reserveration.
Signed-off-by: Christoph Hellwig
Signed-off-by: Jens Axboe
---
fs/aio.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/fs/aio.c b/fs
Modified to use REQ_HIPRI_ASYNC for async polled IO.
Signed-off-by: Jens Axboe
---
fs/gfs2/file.c| 2 ++
fs/iomap.c| 47 +--
fs/xfs/xfs_file.c | 1 +
include/linux/iomap.h | 1 +
4 files changed, 36 insertions(+), 15 deletions(-)
diff
Plugging is meant to optimize submission of a string of IOs, if we don't
have more than 2 being submitted, don't bother setting up a plug.
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
---
fs/aio.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git
Replace the percpu_ref_put() + kmem_cache_free() with a call to
iocb_put() instead.
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
---
fs/aio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index ed6c3914477a..cf93b92bfb1e 100644
--- a/fs
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
We know this is a read/write request, but in preparation for
having different kinds of those, ensure that we call the assigned
handler instead of assuming it's aio_complete_rq().
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
---
fs/aio.c | 2 +-
1 file changed, 1 insertion(+), 1
to store
the polling cookie.
TODO: we can probably union ki_cookie with the existing hint and I/O
priority fields to avoid struct kiocb growth.
Reviewed-by: Johannes Thumshirn
Signed-off-by: Christoph Hellwig
Signed-off-by: Jens Axboe
---
Documentation/filesystems/vfs.txt | 3 +++
include/linux
files changed, 1552 insertions(+), 197 deletions(-)
--
Jens Axboe
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
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
On 12/7/18 3:00 PM, Jens Axboe wrote:
> On 12/7/18 2:59 PM, Jens Axboe wrote:
>> On 12/7/18 2:58 PM, Jens Axboe wrote:
>>> On 12/7/18 12:35 PM, Jens Axboe wrote:
>>>> On 12/7/18 12:34 PM, Jeff Moyer wrote:
>>>>> Jens Axboe writes:
>>>>
On 12/7/18 2:59 PM, Jens Axboe wrote:
> On 12/7/18 2:58 PM, Jens Axboe wrote:
>> On 12/7/18 12:35 PM, Jens Axboe wrote:
>>> On 12/7/18 12:34 PM, Jeff Moyer wrote:
>>>> Jens Axboe writes:
>>>>
>>>>> BTW, quick guess is that it doesn't wor
On 12/7/18 2:58 PM, Jens Axboe wrote:
> On 12/7/18 12:35 PM, Jens Axboe wrote:
>> On 12/7/18 12:34 PM, Jeff Moyer wrote:
>>> Jens Axboe writes:
>>>
>>>> BTW, quick guess is that it doesn't work so well with fixed buffers, as
>>>> tha
On 12/7/18 12:35 PM, Jens Axboe wrote:
> On 12/7/18 12:34 PM, Jeff Moyer wrote:
>> Jens Axboe writes:
>>
>>> BTW, quick guess is that it doesn't work so well with fixed buffers, as that
>>> hasn't been tested. You could try and remove IOCTX_FLAG_FIXEDBUFS
t; drivers/nvme/target/nvmet.h | 53 +++++---
> drivers/nvme/target/rdma.c| 2 +-
> include/linux/nvme-fc-driver.h| 16 -
> include/linux/nvme.h | 51 +--
> 18 files changed, 514 insertions(+), 287 deletions(-)
Pulled, thanks.
--
Jens Axboe
On 12/7/18 12:34 PM, Jeff Moyer wrote:
> Jens Axboe writes:
>
>> BTW, quick guess is that it doesn't work so well with fixed buffers, as that
>> hasn't been tested. You could try and remove IOCTX_FLAG_FIXEDBUFS from the
>> test program and see if that works.
>
>
On 12/7/18 11:52 AM, Jens Axboe wrote:
> On 12/7/18 11:48 AM, Jeff Moyer wrote:
>> Hi, Jens,
>>
>> Jens Axboe writes:
>>
>>> You can also find the patches in my aio-poll branch:
>>>
>>> http://git.kernel.dk/cgit/linux-block/log/?h=aio-poll
&g
On 12/7/18 11:48 AM, Jeff Moyer wrote:
> Hi, Jens,
>
> Jens Axboe writes:
>
>> You can also find the patches in my aio-poll branch:
>>
>> http://git.kernel.dk/cgit/linux-block/log/?h=aio-poll
>>
>> or by cloning:
>>
>> git://git.kernel.
use after free
James Smart (1):
nvme: validate controller state before rescheduling keep alive
Jens Axboe (2):
blk-mq: punt failed direct issue to dispatch list
Merge branch 'nvme-4.20' of git://git.infradead.org/nvme into for-linus
Paolo Valente (1):
block, bfq: fix
On 12/7/18 9:41 AM, Bart Van Assche wrote:
> On Fri, 2018-12-07 at 09:35 -0700, Jens Axboe wrote:
>> diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
>> index 29bfe8017a2d..9e5bda8800f8 100644
>> --- a/block/blk-mq-sched.c
>> +++ b/block/blk-mq-sched.c
&
On 12/7/18 9:24 AM, Jens Axboe wrote:
> On 12/7/18 9:19 AM, Bart Van Assche wrote:
>> On Thu, 2018-12-06 at 22:17 -0700, Jens Axboe wrote:
>>> Instead of making special cases for what we can direct issue, and now
>>> having to deal with DM solving the livelock w
On 12/7/18 9:19 AM, Bart Van Assche wrote:
> On Thu, 2018-12-06 at 22:17 -0700, Jens Axboe wrote:
>> Instead of making special cases for what we can direct issue, and now
>> having to deal with DM solving the livelock while still retaining a BUSY
>> condition feedback
nvmet-rdma: fix response use after free
>
> James Smart (1):
> nvme: validate controller state before rescheduling keep alive
>
> drivers/nvme/host/core.c | 10 +-
> drivers/nvme/target/rdma.c | 3 ++-
> 2 files changed, 11 insertions(+), 2 deletions(-)
Pulled, thanks.
--
Jens Axboe
virtio_scsi
> ip_tables
> [4.489428] Dumping ftrace buffer:
> [4.489939](ftrace buffer empty)
> [4.490492] CR2: 0098
> [4.491052] ---[ end trace 03cd268ad5a86ff7 ]---
Works for me, tested various configs and stubbed out the kdump check.
Thanks for fixing this, applied to 4.21.
--
Jens Axboe
uot;)
Cc: sta...@vger.kernel.org
Suggested-by: Ming Lei
Reported-by: Bart Van Assche
Signed-off-by: Jens Axboe
---
I've thrown the initial hang test reported by Bart at it, works fine.
My reproducer for the corruption case is also happy, as expected.
I'm running blktests and xfstests on
On 12/6/18 9:18 PM, Mike Snitzer wrote:
> On Thu, Dec 06 2018 at 11:06pm -0500,
> Jens Axboe wrote:
>
>> On 12/6/18 8:54 PM, Mike Snitzer wrote:
>>> On Thu, Dec 06 2018 at 9:49pm -0500,
>>> Jens Axboe wrote:
>>>
>>>> After the direct d
On 12/6/18 8:54 PM, Mike Snitzer wrote:
> On Thu, Dec 06 2018 at 9:49pm -0500,
> Jens Axboe wrote:
>
>> After the direct dispatch corruption fix, we permanently disallow direct
>> dispatch of non read/write requests. This works fine off the normal IO
>> path, as th
prep next time again. Otherwise I fear the direct
dispatch isn't going to be super useful, if a failed direct dispatch
prevents future merging.
This would be a lot less error prone as well for other cases.
--
Jens Axboe
q.c
> @@ -38,6 +38,11 @@
> #include "blk-mq-sched.h"
> #include "blk-rq-qos.h"
>
> +static inline bool blk_mq_kdump_kernel(void)
> +{
> + return !!is_kdump_kernel();
> +}
Let's drop the redundant !! here, and the wrapper? I would imagine the
wrapper is handy for testing outside of kdump, but I don't think we
should include it in the final.
Otherwise this looks fine, I can test it here too.
--
Jens Axboe
don't over-dispatch to the lower level queue and mess up
opportunities for merging on the DM queue.
Fixes: ffe81d45322c ("blk-mq: fix corruption with direct issue")
Reported-by: Bart Van Assche
Cc: sta...@vger.kernel.org
Signed-off-by: Jens Axboe
---
This passes my testing as
On 12/6/18 7:16 PM, Jens Axboe wrote:
> On 12/6/18 7:06 PM, Jens Axboe wrote:
>> On 12/6/18 6:58 PM, Mike Snitzer wrote:
>>>> There is another way to fix this - still do the direct dispatch, but have
>>>> dm track if it failed and do bypass insert in that case. I
On 12/6/18 7:06 PM, Jens Axboe wrote:
> On 12/6/18 6:58 PM, Mike Snitzer wrote:
>>> There is another way to fix this - still do the direct dispatch, but have
>>> dm track if it failed and do bypass insert in that case. I didn't want do
>>> to that since it's
On 12/6/18 5:33 PM, Jens Axboe wrote:
> On 12/6/18 5:31 PM, Bart Van Assche wrote:
>> On Thu, 2018-12-06 at 17:26 -0700, Jens Axboe wrote:
>>> On 12/6/18 5:20 PM, Bart Van Assche wrote:
>>>> Which branch does that tag correspond to? Even after having run git fetch
>
struct request *rq, bool force_insert);
extern int blk_rq_append_bio(struct request *rq, struct bio **bio);
extern void blk_delay_queue(struct request_queue *, unsigned long);
extern void blk_queue_split(struct request_queue *, struct bio **);
--
Jens Axboe
On 12/6/18 6:22 PM, jianchao.wang wrote:
>
>
> On 12/7/18 9:13 AM, Jens Axboe wrote:
>> On 12/6/18 6:04 PM, jianchao.wang wrote:
>>>
>>>
>>> On 12/7/18 6:20 AM, Jens Axboe wrote:
>>>> After the direct dispatch corruption fix, we perma
On 12/6/18 6:04 PM, jianchao.wang wrote:
>
>
> On 12/7/18 6:20 AM, Jens Axboe wrote:
>> After the direct dispatch corruption fix, we permanently disallow direct
>> dispatch of non read/write requests. This works fine off the normal IO
>> path, as they will be retried l
On 12/6/18 5:31 PM, Bart Van Assche wrote:
> On Thu, 2018-12-06 at 17:26 -0700, Jens Axboe wrote:
>> On 12/6/18 5:20 PM, Bart Van Assche wrote:
>>> Which branch does that tag correspond to? Even after having run git fetch
>>> --tags I can't find that tag in your
On 12/6/18 5:20 PM, Bart Van Assche wrote:
> On Thu, 2018-12-06 at 16:59 -0700, Jens Axboe wrote:
>> Just a single followup fix to the corruption fix from yesterday. We have
>> an exported interface that does direct dispatch, with DM being the sole
>> user of it. Change tha
.
Additionally, it gets rid of any exported user of direct dispatch, and
enables DM to drop any BUSY handling from using the interface.
Please pull!
git://git.kernel.dk/linux-block.git tags/for-linus-20181206
Jens Axboe (1):
block
On 12/6/18 3:28 PM, Mike Snitzer wrote:
> On Thu, Dec 06 2018 at 5:20pm -0500,
> Jens Axboe wrote:
>
>> After the direct dispatch corruption fix, we permanently disallow direct
>> dispatch of non read/write requests. This works fine off the normal IO
>> path, as th
On 12/6/18 3:20 PM, Jens Axboe wrote:
> After the direct dispatch corruption fix, we permanently disallow direct
> dispatch of non read/write requests. This works fine off the normal IO
> path, as they will be retried like any other failed direct dispatch
scheduler, which is
what DM wants.
Fixes: ffe81d45322c ("blk-mq: fix corruption with direct issue")
Signed-off-by: Jens Axboe
---
diff --git a/block/blk-core.c b/block/blk-core.c
index deb56932f8c4..4c44e6fa0d08 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2637,7 +2637,8 @@ bl
On 12/6/18 2:04 PM, Jens Axboe wrote:
> On 12/6/18 1:56 PM, Bart Van Assche wrote:
>> On Thu, 2018-12-06 at 08:47 -0800, Bart Van Assche wrote:
>>> If I merge Jens' for-next branch with Linus' master branch, boot the
>>> resulting kernel in a VM and run blktests/t
spin_lock_irqsave(q->queue_lock, flags);
it works fine. Well, at least this regression is less serious, I'll bang
out a fix for it and ensure we make -rc6. I'm guessing it's the bypassin
of non-read/write, which your top of dispatch also shows to be a
non-read/write. But there should be no new failure case here that wasn't
possible before, only it's easier to hit now.
--
Jens Axboe
On 12/6/18 12:38 PM, Jeff Moyer wrote:
> Jens Axboe writes:
>
>> On 12/6/18 12:27 PM, Jeff Moyer wrote:
>>> Jens Axboe writes:
>>>
>>>> It's 192 bytes, fairly substantial. Most items don't need to be cleared,
>>>> especially not
On 12/6/18 12:29 PM, Jeff Moyer wrote:
> Jens Axboe writes:
>
>> Plugging is meant to optimize submission of a string of IOs, if we don't
>> have more than 2 being submitted, don't bother setting up a plug.
>
> Is there really that much overhead in blk_{start|fini
On 12/6/18 12:27 PM, Jeff Moyer wrote:
> Jens Axboe writes:
>
>> It's 192 bytes, fairly substantial. Most items don't need to be cleared,
>> especially not upfront. Clear the ones we do need to clear, and leave
>> the other ones for setup when the iocb is prepared
On 12/6/18 12:15 PM, Christoph Hellwig wrote:
> On Thu, Dec 06, 2018 at 12:14:29PM -0700, Jens Axboe wrote:
>> On 12/6/18 12:11 PM, Jeff Moyer wrote:
>>> Jens Axboe writes:
>>>
>>>> From: Christoph Hellwig
>>>>
>>>> Just call blk_po
On 12/6/18 12:11 PM, Jeff Moyer wrote:
> Jens Axboe writes:
>
>> From: Christoph Hellwig
>>
>> Just call blk_poll on the iocb cookie, we can derive the block device
>> from the inode trivially.
>
> Does this work for multi-device file systems?
It should
On 12/6/18 11:10 AM, Bart Van Assche wrote:
> On Thu, 2018-12-06 at 10:02 -0800, Bart Van Assche wrote:
>> On Thu, 2018-12-06 at 10:48 -0700, Jens Axboe wrote:
>>> which would result in a non-zero exit, which should be expected for this
>>> test?
>>
>> Test s
On 12/6/18 11:02 AM, Bart Van Assche wrote:
> On Thu, 2018-12-06 at 10:48 -0700, Jens Axboe wrote:
>> which would result in a non-zero exit, which should be expected for this
>> test?
>
> Hi Jens,
>
> Test srp/002 simulates network failures while running fio
On 12/6/18 10:28 AM, Jens Axboe wrote:
> On 12/6/18 10:19 AM, Bart Van Assche wrote:
>> On Thu, 2018-12-06 at 10:00 -0700, Jens Axboe wrote:
>>> On 12/6/18 9:47 AM, Bart Van Assche wrote:
>>>> If I merge Jens' for-next branch with Linus' master branch, boot the
On 12/6/18 10:19 AM, Bart Van Assche wrote:
> On Thu, 2018-12-06 at 10:00 -0700, Jens Axboe wrote:
>> On 12/6/18 9:47 AM, Bart Van Assche wrote:
>>> If I merge Jens' for-next branch with Linus' master branch, boot the
>>> resulting kernel in a VM and run blktests/t
is is a regression. The following appears in the system log if
> I run that test:
You are running that test on a dm device? Can you shed some light on
how that dm device is setup?
--
Jens Axboe
ainted 4.20.0-rc5-dbg+ #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1
> 04/01/2014
> RIP: 0010:blk_throtl_bio+0xc00/0x1120
It's some over-zealous rcu removal, simple fix is coming. CC Dennis.
--
Jens Axboe
Jens Axboe (1):
blk-mq: fix corruption with direct issue
Juha-Matti Tilli (1):
libata: whitelist all SAMSUNG MZ7KM* solid-state disks
block/blk-mq.c| 26 +-
drivers/ata/libata-core.c
On 12/5/18 12:09 PM, Guenter Roeck wrote:
> On Wed, Dec 05, 2018 at 10:59:21AM -0700, Jens Axboe wrote:
> [ ... ]
>>
>>> Also, it seems to me that even with this problem fixed, blk-mq may not
>>> be ready for primetime after all. With that in mind, maybe commit
On 12/5/18 10:55 AM, Guenter Roeck wrote:
> On Tue, Dec 04, 2018 at 07:25:05PM -0700, Jens Axboe wrote:
>> On 12/4/18 6:38 PM, Guenter Roeck wrote:
>>> On Tue, Dec 04, 2018 at 03:47:46PM -0700, Jens Axboe wrote:
>>>> If we attempt a direct issue to a SCSI device, and
this with my blktests test. Thanks,
Applies fine to for-4.21/block, which is what I care about. Looks good to me,
applied, thanks.
--
Jens Axboe
On 12/5/18 7:41 AM, Christoph Hellwig wrote:
> On Tue, Dec 04, 2018 at 03:47:46PM -0700, Jens Axboe wrote:
>> If we attempt a direct issue to a SCSI device, and it returns BUSY, then
>> we queue the request up normally. However, the SCSI layer may have
>> alread
!*nr_events || !need_resched()) {
>> +int tmin = 0;
>> +
>> +if (*nr_events < min_nr)
>> +tmin = min_nr - *nr_events;
>
> Otherwise, shouldn't the function just return 0?
>
> Or perhaps you explicitly want to go through the tmin==0 case
> in aio_iopoll_getevents if *nr_events == min_nr (or min_nr==0)?
No, we need to go through poll, if min_nr == 0, but only if min_nr == 0
and !nr_events. But we only get here for nr_events != 0, so should be
fine as-is.
Thanks for your review, very useful! I'll make the above changes right
now.
--
Jens Axboe
On 12/4/18 8:03 PM, Ming Lei wrote:
> On Wed, Dec 05, 2018 at 10:58:02AM +0800, Ming Lei wrote:
>> On Tue, Dec 04, 2018 at 07:30:24PM -0700, Jens Axboe wrote:
>>> On 12/4/18 7:27 PM, Ming Lei wrote:
>>>> On Tue, Dec 04, 2018 at 07:16:11PM -0700, Jens Axboe wrote:
>
On 12/4/18 7:58 PM, Ming Lei wrote:
> On Tue, Dec 04, 2018 at 07:30:24PM -0700, Jens Axboe wrote:
>> On 12/4/18 7:27 PM, Ming Lei wrote:
>>> On Tue, Dec 04, 2018 at 07:16:11PM -0700, Jens Axboe wrote:
>>>> On 12/4/18 6:37 PM, Ming Lei wrote:
>>>>> O
On 12/4/18 7:27 PM, Ming Lei wrote:
> On Tue, Dec 04, 2018 at 07:16:11PM -0700, Jens Axboe wrote:
>> On 12/4/18 6:37 PM, Ming Lei wrote:
>>> On Tue, Dec 04, 2018 at 03:47:46PM -0700, Jens Axboe wrote:
>>>> If we attempt a direct issue to a SCSI device, and it re
On 12/4/18 6:38 PM, Guenter Roeck wrote:
> On Tue, Dec 04, 2018 at 03:47:46PM -0700, Jens Axboe wrote:
>> If we attempt a direct issue to a SCSI device, and it returns BUSY, then
>> we queue the request up normally. However, the SCSI layer may have
>> alread
On 12/4/18 7:16 PM, Jens Axboe wrote:
> On 12/4/18 6:37 PM, Ming Lei wrote:
>> On Tue, Dec 04, 2018 at 03:47:46PM -0700, Jens Axboe wrote:
>>> If we attempt a direct issue to a SCSI device, and it returns BUSY, then
>>> we queue the request up normally. However, the SCSI
On 12/4/18 6:37 PM, Ming Lei wrote:
> On Tue, Dec 04, 2018 at 03:47:46PM -0700, Jens Axboe wrote:
>> If we attempt a direct issue to a SCSI device, and it returns BUSY, then
>> we queue the request up normally. However, the SCSI layer may have
>> already setup SG tables et
to enter the
kernel to do IO.
Sample application: http://brick.kernel.dk/snaps/aio-ring.c
Signed-off-by: Jens Axboe
---
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
fs/aio.c | 312 +++--
include/linux/syscalls.h | 4 +-
include/uapi
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 1c8a8bb631a9..39aaffd6d436 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1218,12 +1218,9 @@ static void aio_fill_event(struct io_event *ev, struct
This adds support for sync/async O_DIRECT to make a bvec type iter
for bdev access, as well as iomap.
Signed-off-by: Jens Axboe
---
fs/block_dev.c | 16
fs/iomap.c | 5 -
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
change for how to utilize this feature:
http://git.kernel.dk/cgit/fio/commit/?id=2041bd343da1c1e955253f62374588718c64f0f3
Signed-off-by: Jens Axboe
---
fs/aio.c | 193 ---
include/uapi/linux/aio_abi.h | 1 +
2 files changed, 177 insertions
-by: Jens Axboe
---
block/bio.c | 6 --
include/linux/blk_types.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 03895cc0d74a..ab174bce5436 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1635,7 +1635,8 @@ static void bio_dirty_fn
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 634b540b0c92..416bb2e365e0 100644
--- a/fs
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
to support completion reaping
from userspace by just looking at the ring. The application itself
is the one that pulls completion entries.
Signed-off-by: Jens Axboe
---
fs/aio.c | 393 +++
include/uapi/linux/aio_abi.h | 3 +
2 files changed, 360
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
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
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 | 47 +++
1 file changed, 39 insertions(+), 8 deleti
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 an iocb array and two user pointers for
future use.
Signed-off-by: Jens Axboe
---
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
fs/aio.c
In preparation of handing in iocbs in a different fashion as well. Also
make it clear that the iocb being passed in isn't modified, by marking
it const throughout.
Signed-off-by: Jens Axboe
---
fs/aio.c | 68 +++-
1 file changed, 38 insertions
?id=3c3168e91329c83880c91e5abc28b9d6b940fd95
Signed-off-by: Jens Axboe
---
fs/aio.c | 126 +++
include/uapi/linux/aio_abi.h | 2 +
2 files changed, 116 insertions(+), 12 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 26631d6872d2..bb6f07ca6940 100644
--- a/fs/ai
-by: Jens Axboe
---
fs/aio.c | 136 +--
1 file changed, 113 insertions(+), 23 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 5d34317c2929..ae0805dc814c 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -240,6 +240,21 @@ struct aio_kiocb
to store
the polling cookie.
TODO: we can probably union ki_cookie with the existing hint and I/O
priority fields to avoid struct kiocb growth.
Reviewed-by: Johannes Thumshirn
Signed-off-by: Christoph Hellwig
Signed-off-by: Jens Axboe
---
Documentation/filesystems/vfs.txt | 3 +++
include/linux
1 - 100 of 2704 matches
Mail list logo
