[PATCH v4 0/2] block, iomap: disable iopoll for split bio

[PATCH v4 0/2] block, iomap: disable iopoll for split bio

[Jeffle Xu]

This patchset is to fix the potential hang occurred in sync polling.

Please refer the following link for background info and the v1 patch:
https://patchwork.kernel.org/project/linux-block/patch/20201013084051.27255-1-jefflexu@linux.alibaba.com/

The first patch disables iopoll for split bio in block layer, which is
suggested by Ming Lei.


The second patch disables iopoll when one dio need to be split into
multiple bios. As for this patch, Ming Lei had ever asked what's the
expected behaviour of upper layers when simply clear IOCB_HIPRI in
the direct routine of blkdev fs, iomap-based fs. Currently there are
two parts concerning IOCB_HIPRI (or io polling). One is the sync
polling logic embedded in the direct IO routine. In this case, sync
polling won't be executed any more since IOCB_HIPRI flag has been
cleared from iocb->ki_flags. Consider the following code snippet:

fs/block_dev.c: __blkdev_direct_IO
	for (;;) {
		...
		if (!(iocb->ki_flags & IOCB_HIPRI) ||
		    !blk_poll(bdev_get_queue(bdev), qc, true))
			blk_io_schedule();
	}

fs/iomap/direct-io.c: __iomap_dio_rw
	for (;;) {
		...
		if (!(iocb->ki_flags & IOCB_HIPRI) ||
		    !dio->submit.last_queue ||
		    !blk_poll(dio->submit.last_queue,
				 dio->submit.cookie, true))
			blk_io_schedule();
	}


The other part is io_uring. 

fs/io_uring.c: 
io_iopoll_getevents
  io_do_iopoll
    list_for_each_entry_safe(...) {
      ret = kiocb->ki_filp->f_op->iopoll(kiocb, spin);
    }

In this case, though the split bios have been enqueued into DEFAULT
hw queues, io_uring will still poll POLL hw queues. When polling on
the cookie returned by split bio, blk_poll() will return 0 immediately
since the hw queue type check added in patch 1. If there's no other
bio in the POLL hw queues, io_do_iopoll() will loop indefinitely
until the split bio is completed by interrupt of DEFAULT queue. Indeed
there may be a pulse of high CPU sys in this time window here, but it
is no worse than before. After all io_do_iopoll() will still get stuck
in this loop when there's only one bio (that we are polling on) in POLL
hw queue, before this patch applied.

The situation described above may be less impossible. As long as there
are other bios in POLL hw queue, work of io_do_iopoll() is still
meaningful as it *helps* reap these other bios in POLL hw queue, while
the split bios are still completed by interrupt of DEFAULT hw queue.


changes since v3:
- patch 1: add hw queue type check in blk_poll(), so that cookie returned
  by split bio won't get into the real polling routine

changes since v2:
- tune the line length of patch 1
- fix the condition checking whether split needed in patch 2

changes since v1:
- adopt the fix suggested by Ming Lei, to disable iopoll for split bio directly
- disable iopoll in direct IO routine of blkdev fs and iomap

Jeffle Xu (2):
  block: disable iopoll for split bio
  block,iomap: disable iopoll when split needed

 block/blk-merge.c    |  7 +++++++
 block/blk-mq.c       |  6 ++++--
 fs/block_dev.c       |  9 +++++++++
 fs/iomap/direct-io.c | 10 ++++++++++
 4 files changed, 30 insertions(+), 2 deletions(-)

-- 
2.27.0

[PATCH v4 1/2] block: disable iopoll for split bio

[Jeffle Xu]

iopoll is initially for small size, latency sensitive IO. It doesn't
work well for big IO, especially when it needs to be split to multiple
bios. In this case, the returned cookie of __submit_bio_noacct_mq() is
indeed the cookie of the last split bio. The completion of *this* last
split bio done by iopoll doesn't mean the whole original bio has
completed. Callers of iopoll still need to wait for completion of other
split bios.

Besides bio splitting may cause more trouble for iopoll which isn't
supposed to be used in case of big IO.

iopoll for split bio may cause potential race if CPU migration happens
during bio submission. Since the returned cookie is that of the last
split bio, polling on the corresponding hardware queue doesn't help
complete other split bios, if these split bios are enqueued into
different hardware queues. Since interrupts are disabled for polling
queues, the completion of these other split bios depends on timeout
mechanism, thus causing a potential hang.

iopoll for split bio may also cause hang for sync polling. Currently
both the blkdev and iomap-based fs (ext4/xfs, etc) support sync polling
in direct IO routine. These routines will submit bio without REQ_NOWAIT
flag set, and then start sync polling in current process context. The
process may hang in blk_mq_get_tag() if the submitted bio has to be
split into multiple bios and can rapidly exhaust the queue depth. The
process are waiting for the completion of the previously allocated
requests, which should be reaped by the following polling, and thus
causing a deadlock.

To avoid these subtle trouble described above, just disable iopoll for
split bio.

Suggested-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
---
 block/blk-merge.c | 7 +++++++
 block/blk-mq.c    | 6 ++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index bcf5e4580603..53ad781917a2 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -279,6 +279,13 @@ static struct bio *blk_bio_segment_split(struct request_queue *q,
 	return NULL;
 split:
 	*segs = nsegs;
+
+	/*
+	 * bio splitting may cause subtle trouble such as hang when doing iopoll,
+	 * not to mention iopoll isn't supposed to be used in case of big IO.
+	 */
+	bio->bi_opf &= ~REQ_HIPRI;
+
 	return bio_split(bio, sectors, GFP_NOIO, bs);
 }
 
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 55bcee5dc032..6d10652a7ed0 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -3853,11 +3853,13 @@ int blk_poll(struct request_queue *q, blk_qc_t cookie, bool spin)
 	    !test_bit(QUEUE_FLAG_POLL, &q->queue_flags))
 		return 0;
 
+	hctx = q->queue_hw_ctx[blk_qc_t_to_queue_num(cookie)];
+	if (hctx->type != HCTX_TYPE_POLL)
+		return 0;
+
 	if (current->plug)
 		blk_flush_plug_list(current->plug, false);
 
-	hctx = q->queue_hw_ctx[blk_qc_t_to_queue_num(cookie)];
-
 	/*
 	 * If we sleep, have the caller restart the poll loop to reset
 	 * the state. Like for the other success return cases, the
-- 
2.27.0

Re: [PATCH v4 1/2] block: disable iopoll for split bio

[JeffleXu]

Hi Jens,

Would you mind giving a glance at this, at least patch 1?


Patch 1 could fix the potential deadlock may be triggered by sync io polling

in direct IO routine.


Actually this patch could alleviate another potential hang in io_uring. The

returned cookie of submit_bio() is actually the cookie of the last split bio

if splitting happened. If the returned cookie is BLK_QC_T_NONE ( the

last split bio get merged into another request, or queue depth exhausted

and REQ_NOWAIT set by io_uring), then iocb->ki_cookie is BLK_QC_T_NONE.


If there's only this one IO (though split to several bios) in the 
polling hw queue,

then io_do_iopoll() will get stuck in indefinite calling of blk_poll(), 
while blk_poll()

will return 0 immediately because of BLK_QC_T_NONE, without reaping any

former completed requests.


This hang rarly happened, maybe because as long as there's other IO, polling

of these other IOs will help reap completed requests of the stuck IO 
described

above.


Of course we could refactor the problematic logic of returning cookie in 
submit_bio(),

But this patch 1 could also fix this issue. Besides this patch 1 is also 
needed to fix

the potential deadlock triggered by sync io polling described above.


Thanks,

Jeffle



On 11/17/20 3:56 PM, Jeffle Xu wrote:
> iopoll is initially for small size, latency sensitive IO. It doesn't
> work well for big IO, especially when it needs to be split to multiple
> bios. In this case, the returned cookie of __submit_bio_noacct_mq() is
> indeed the cookie of the last split bio. The completion of *this* last
> split bio done by iopoll doesn't mean the whole original bio has
> completed. Callers of iopoll still need to wait for completion of other
> split bios.
>
> Besides bio splitting may cause more trouble for iopoll which isn't
> supposed to be used in case of big IO.
>
> iopoll for split bio may cause potential race if CPU migration happens
> during bio submission. Since the returned cookie is that of the last
> split bio, polling on the corresponding hardware queue doesn't help
> complete other split bios, if these split bios are enqueued into
> different hardware queues. Since interrupts are disabled for polling
> queues, the completion of these other split bios depends on timeout
> mechanism, thus causing a potential hang.
>
> iopoll for split bio may also cause hang for sync polling. Currently
> both the blkdev and iomap-based fs (ext4/xfs, etc) support sync polling
> in direct IO routine. These routines will submit bio without REQ_NOWAIT
> flag set, and then start sync polling in current process context. The
> process may hang in blk_mq_get_tag() if the submitted bio has to be
> split into multiple bios and can rapidly exhaust the queue depth. The
> process are waiting for the completion of the previously allocated
> requests, which should be reaped by the following polling, and thus
> causing a deadlock.
>
> To avoid these subtle trouble described above, just disable iopoll for
> split bio.
>
> Suggested-by: Ming Lei <ming.lei@redhat.com>
> Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
> ---
>   block/blk-merge.c | 7 +++++++
>   block/blk-mq.c    | 6 ++++--
>   2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index bcf5e4580603..53ad781917a2 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -279,6 +279,13 @@ static struct bio *blk_bio_segment_split(struct request_queue *q,
>   	return NULL;
>   split:
>   	*segs = nsegs;
> +
> +	/*
> +	 * bio splitting may cause subtle trouble such as hang when doing iopoll,
> +	 * not to mention iopoll isn't supposed to be used in case of big IO.
> +	 */
> +	bio->bi_opf &= ~REQ_HIPRI;
> +
>   	return bio_split(bio, sectors, GFP_NOIO, bs);
>   }
>   
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 55bcee5dc032..6d10652a7ed0 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -3853,11 +3853,13 @@ int blk_poll(struct request_queue *q, blk_qc_t cookie, bool spin)
>   	    !test_bit(QUEUE_FLAG_POLL, &q->queue_flags))
>   		return 0;
>   
> +	hctx = q->queue_hw_ctx[blk_qc_t_to_queue_num(cookie)];
> +	if (hctx->type != HCTX_TYPE_POLL)
> +		return 0;
> +
>   	if (current->plug)
>   		blk_flush_plug_list(current->plug, false);
>   
> -	hctx = q->queue_hw_ctx[blk_qc_t_to_queue_num(cookie)];
> -
>   	/*
>   	 * If we sleep, have the caller restart the poll loop to reset
>   	 * the state. Like for the other success return cases, the

-- 
Thanks,
Jeffle

Re: [PATCH v4 1/2] block: disable iopoll for split bio

[Christoph Hellwig]

On Tue, Nov 17, 2020 at 03:56:24PM +0800, Jeffle Xu wrote:
> iopoll is initially for small size, latency sensitive IO. It doesn't
> work well for big IO, especially when it needs to be split to multiple
> bios. In this case, the returned cookie of __submit_bio_noacct_mq() is
> indeed the cookie of the last split bio. The completion of *this* last
> split bio done by iopoll doesn't mean the whole original bio has
> completed. Callers of iopoll still need to wait for completion of other
> split bios.
> 
> Besides bio splitting may cause more trouble for iopoll which isn't
> supposed to be used in case of big IO.
> 
> iopoll for split bio may cause potential race if CPU migration happens
> during bio submission. Since the returned cookie is that of the last
> split bio, polling on the corresponding hardware queue doesn't help
> complete other split bios, if these split bios are enqueued into
> different hardware queues. Since interrupts are disabled for polling
> queues, the completion of these other split bios depends on timeout
> mechanism, thus causing a potential hang.
> 
> iopoll for split bio may also cause hang for sync polling. Currently
> both the blkdev and iomap-based fs (ext4/xfs, etc) support sync polling
> in direct IO routine. These routines will submit bio without REQ_NOWAIT
> flag set, and then start sync polling in current process context. The
> process may hang in blk_mq_get_tag() if the submitted bio has to be
> split into multiple bios and can rapidly exhaust the queue depth. The
> process are waiting for the completion of the previously allocated
> requests, which should be reaped by the following polling, and thus
> causing a deadlock.
> 
> To avoid these subtle trouble described above, just disable iopoll for
> split bio.
> 
> Suggested-by: Ming Lei <ming.lei@redhat.com>
> Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
> ---
>  block/blk-merge.c | 7 +++++++
>  block/blk-mq.c    | 6 ++++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index bcf5e4580603..53ad781917a2 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -279,6 +279,13 @@ static struct bio *blk_bio_segment_split(struct request_queue *q,
>  	return NULL;
>  split:
>  	*segs = nsegs;
> +
> +	/*
> +	 * bio splitting may cause subtle trouble such as hang when doing iopoll,

Please capitalize the first character of a multi-line comments.  Also
this adds an overly long line.

> +	hctx = q->queue_hw_ctx[blk_qc_t_to_queue_num(cookie)];
> +	if (hctx->type != HCTX_TYPE_POLL)
> +		return 0;

I think this is good as a sanity check, but shouldn't we be able to
avoid even hitting this patch if we ensure that BLK_QC_T_NONE is
returned after a bio is split?

Re: [PATCH v4 1/2] block: disable iopoll for split bio

[JeffleXu]

On 11/20/20 1:52 AM, Christoph Hellwig wrote:
> On Tue, Nov 17, 2020 at 03:56:24PM +0800, Jeffle Xu wrote:
>> iopoll is initially for small size, latency sensitive IO. It doesn't
>> work well for big IO, especially when it needs to be split to multiple
>> bios. In this case, the returned cookie of __submit_bio_noacct_mq() is
>> indeed the cookie of the last split bio. The completion of *this* last
>> split bio done by iopoll doesn't mean the whole original bio has
>> completed. Callers of iopoll still need to wait for completion of other
>> split bios.
>>
>> Besides bio splitting may cause more trouble for iopoll which isn't
>> supposed to be used in case of big IO.
>>
>> iopoll for split bio may cause potential race if CPU migration happens
>> during bio submission. Since the returned cookie is that of the last
>> split bio, polling on the corresponding hardware queue doesn't help
>> complete other split bios, if these split bios are enqueued into
>> different hardware queues. Since interrupts are disabled for polling
>> queues, the completion of these other split bios depends on timeout
>> mechanism, thus causing a potential hang.
>>
>> iopoll for split bio may also cause hang for sync polling. Currently
>> both the blkdev and iomap-based fs (ext4/xfs, etc) support sync polling
>> in direct IO routine. These routines will submit bio without REQ_NOWAIT
>> flag set, and then start sync polling in current process context. The
>> process may hang in blk_mq_get_tag() if the submitted bio has to be
>> split into multiple bios and can rapidly exhaust the queue depth. The
>> process are waiting for the completion of the previously allocated
>> requests, which should be reaped by the following polling, and thus
>> causing a deadlock.
>>
>> To avoid these subtle trouble described above, just disable iopoll for
>> split bio.
>>
>> Suggested-by: Ming Lei <ming.lei@redhat.com>
>> Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
>> ---
>>   block/blk-merge.c | 7 +++++++
>>   block/blk-mq.c    | 6 ++++--
>>   2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/block/blk-merge.c b/block/blk-merge.c
>> index bcf5e4580603..53ad781917a2 100644
>> --- a/block/blk-merge.c
>> +++ b/block/blk-merge.c
>> @@ -279,6 +279,13 @@ static struct bio *blk_bio_segment_split(struct request_queue *q,
>>   	return NULL;
>>   split:
>>   	*segs = nsegs;
>> +
>> +	/*
>> +	 * bio splitting may cause subtle trouble such as hang when doing iopoll,
> Please capitalize the first character of a multi-line comments.  Also
> this adds an overly long line.

Regards.


>
>> +	hctx = q->queue_hw_ctx[blk_qc_t_to_queue_num(cookie)];
>> +	if (hctx->type != HCTX_TYPE_POLL)
>> +		return 0;
> I think this is good as a sanity check, but shouldn't we be able to
> avoid even hitting this patch if we ensure that BLK_QC_T_NONE is
> returned after a bio is split?

Actually I had thought about returning  BLK_QC_T_NONE for split bio, but 
got blocked.


At the beginning, I want to identify split bio by checking if @split is 
NULL in __blk_queue_split().

```

                 split = blk_bio_segment_split(q, *bio, &q->bio_split, 
nr_segs);
                 break;
         }

         if (split) {

             /* bio got split */

```

But it's not the case. Even if @split is NULL, the input @bio may be the 
*last* split bio.


Then I want to identify split bio by checking loop times in 
__submit_bio_noacct_mq().

--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1008,12 +1008,15 @@ static blk_qc_t __submit_bio_noacct_mq(struct 
bio *bio)
  {
         struct bio_list bio_list[2] = { };
         blk_qc_t ret = BLK_QC_T_NONE;
+       int split = -1;

         current->bio_list = bio_list;

         do {
                 struct gendisk *disk = bio->bi_disk;

+               split = min(split + 1, 1)
+
                 if (unlikely(bio_queue_enter(bio) != 0))
                         continue;

@@ -1027,7 +1030,7 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio 
*bio)
         } while ((bio = bio_list_pop(&bio_list[0])));

         current->bio_list = NULL;
-       return ret;
+       return split ? BLK_QC_T_NONE : ret;
  }

But the bio-based routine will call blk_mq_submit_bio() directly, bypassing

__submit_bio_noacct_mq().


It seems that we have to add one specific flag to identify split bio.


Or we could use BIO_CHAIN to identify the *last* split bio from normal 
bio, since the

last split bio is always marked with BIO_CHAIN. Then we can identify the 
last split

bio by BIO_CHAIN, and the others by checking if @split is NULL in 
__blk_queue_split().


-- 
Thanks,
Jeffle

[PATCH v4 2/2] block,iomap: disable iopoll when split needed

[Jeffle Xu]

Both blkdev fs and iomap-based fs (ext4, xfs, etc.) currently support
sync iopoll. One single bio can contain at most BIO_MAX_PAGES, i.e. 256
bio_vec. If the input iov_iter contains more than 256 segments, then
one dio will be split into multiple bios, which may cause potential
deadlock for sync iopoll.

When it comes to sync iopoll, the bio is submitted without REQ_NOWAIT
flag set and the process may hang in blk_mq_get_tag() if the dio needs
to be split into multiple bios and thus can rapidly exhausts the queue
depth. The process has to wait for the completion of the previously
allocated requests, which should be reaped by the following sync
polling, and thus causing a potential deadlock.

In fact there's a subtle difference of handling of HIPRI IO between
blkdev fs and iomap-based fs, when dio need to be split into multiple
bios. blkdev fs will set REQ_HIPRI for only the last split bio, leaving
the previous bios queued into normal hardware queues, and not causing
the trouble described above. iomap-based fs will set REQ_HIPRI for all
split bios, and thus may cause the potential deadlock described above.

Noted that though the analysis described above, currently blkdev fs and
iomap-based fs won't trigger this potential deadlock. Because only
preadv2(2)/pwritev2(2) are capable of *sync* polling as only these two
can set RWF_NOWAIT. Currently the maximum number of iovecs of one single
preadv2(2)/pwritev2(2) call is UIO_MAXIOV, i.e. 1024, while the minimum
queue depth is BLKDEV_MIN_RQ i.e. 4. That means one
preadv2(2)/pwritev2(2) call can submit at most 4 bios, which will fill
up the queue depth *exactly* and thus there's no deadlock in this case.

However this constraint can be fragile. Disable iopoll when one dio need
to be split into multiple bios.Though blkdev fs may not suffer this issue,
still it may not make much sense to iopoll for big IO, since iopoll is
initially for small size, latency sensitive IO.

Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
---
 fs/block_dev.c       |  9 +++++++++
 fs/iomap/direct-io.c | 10 ++++++++++
 2 files changed, 19 insertions(+)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 9e84b1928b94..ed3f46e8fa91 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -436,6 +436,15 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter, int nr_pages)
 			break;
 		}
 
+		/*
+		 * The current dio needs to be split into multiple bios here.
+		 * iopoll for split bio will cause subtle trouble such as
+		 * hang when doing sync polling, while iopoll is initially
+		 * for small size, latency sensitive IO. Thus disable iopoll
+		 * if split needed.
+		 */
+		iocb->ki_flags &= ~IOCB_HIPRI;
+
 		if (!dio->multi_bio) {
 			/*
 			 * AIO needs an extra reference to ensure the dio
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index 933f234d5bec..396ac0f91a43 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -309,6 +309,16 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
 		copied += n;
 
 		nr_pages = iov_iter_npages(dio->submit.iter, BIO_MAX_PAGES);
+		/*
+		 * The current dio needs to be split into multiple bios here.
+		 * iopoll for split bio will cause subtle trouble such as
+		 * hang when doing sync polling, while iopoll is initially
+		 * for small size, latency sensitive IO. Thus disable iopoll
+		 * if split needed.
+		 */
+		if (nr_pages)
+			dio->iocb->ki_flags &= ~IOCB_HIPRI;
+
 		iomap_dio_submit_bio(dio, iomap, bio, pos);
 		pos += n;
 	} while (nr_pages);
-- 
2.27.0

Re: [PATCH v4 2/2] block,iomap: disable iopoll when split needed

[Darrick J. Wong]

On Tue, Nov 17, 2020 at 03:56:25PM +0800, Jeffle Xu wrote:
> Both blkdev fs and iomap-based fs (ext4, xfs, etc.) currently support

$ ./scripts/get_maintainer.pl fs/iomap/direct-io.c
Christoph Hellwig <hch@infradead.org> (supporter:IOMAP FILESYSTEM LIBRARY)
"Darrick J. Wong" <darrick.wong@oracle.com> (supporter:IOMAP FILESYSTEM LIBRARY)
linux-xfs@vger.kernel.org (supporter:IOMAP FILESYSTEM LIBRARY)
linux-fsdevel@vger.kernel.org (supporter:IOMAP FILESYSTEM LIBRARY)
linux-kernel@vger.kernel.org (open list)

Please cc both iomap maintainers and the appropriate lists when you
propose changes to fs/iomap/.  At a bare minimum cc linux-fsdevel for
changes under fs/.

> sync iopoll. One single bio can contain at most BIO_MAX_PAGES, i.e. 256
> bio_vec. If the input iov_iter contains more than 256 segments, then
> one dio will be split into multiple bios, which may cause potential
> deadlock for sync iopoll.
> 
> When it comes to sync iopoll, the bio is submitted without REQ_NOWAIT
> flag set and the process may hang in blk_mq_get_tag() if the dio needs
> to be split into multiple bios and thus can rapidly exhausts the queue
> depth. The process has to wait for the completion of the previously
> allocated requests, which should be reaped by the following sync
> polling, and thus causing a potential deadlock.
> 
> In fact there's a subtle difference of handling of HIPRI IO between
> blkdev fs and iomap-based fs, when dio need to be split into multiple
> bios. blkdev fs will set REQ_HIPRI for only the last split bio, leaving
> the previous bios queued into normal hardware queues, and not causing
> the trouble described above. iomap-based fs will set REQ_HIPRI for all
> split bios, and thus may cause the potential deadlock described above.
> 
> Noted that though the analysis described above, currently blkdev fs and
> iomap-based fs won't trigger this potential deadlock. Because only
> preadv2(2)/pwritev2(2) are capable of *sync* polling as only these two
> can set RWF_NOWAIT. Currently the maximum number of iovecs of one single
> preadv2(2)/pwritev2(2) call is UIO_MAXIOV, i.e. 1024, while the minimum
> queue depth is BLKDEV_MIN_RQ i.e. 4. That means one
> preadv2(2)/pwritev2(2) call can submit at most 4 bios, which will fill
> up the queue depth *exactly* and thus there's no deadlock in this case.
> 
> However this constraint can be fragile. Disable iopoll when one dio need
> to be split into multiple bios.Though blkdev fs may not suffer this issue,
> still it may not make much sense to iopoll for big IO, since iopoll is
> initially for small size, latency sensitive IO.
> 
> Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
> ---
>  fs/block_dev.c       |  9 +++++++++
>  fs/iomap/direct-io.c | 10 ++++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/fs/block_dev.c b/fs/block_dev.c
> index 9e84b1928b94..ed3f46e8fa91 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -436,6 +436,15 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter, int nr_pages)
>  			break;
>  		}
>  
> +		/*
> +		 * The current dio needs to be split into multiple bios here.
> +		 * iopoll for split bio will cause subtle trouble such as
> +		 * hang when doing sync polling, while iopoll is initially
> +		 * for small size, latency sensitive IO. Thus disable iopoll
> +		 * if split needed.
> +		 */
> +		iocb->ki_flags &= ~IOCB_HIPRI;
> +
>  		if (!dio->multi_bio) {
>  			/*
>  			 * AIO needs an extra reference to ensure the dio
> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> index 933f234d5bec..396ac0f91a43 100644
> --- a/fs/iomap/direct-io.c
> +++ b/fs/iomap/direct-io.c
> @@ -309,6 +309,16 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
>  		copied += n;
>  
>  		nr_pages = iov_iter_npages(dio->submit.iter, BIO_MAX_PAGES);
> +		/*
> +		 * The current dio needs to be split into multiple bios here.
> +		 * iopoll for split bio will cause subtle trouble such as
> +		 * hang when doing sync polling, while iopoll is initially
> +		 * for small size, latency sensitive IO. Thus disable iopoll
> +		 * if split needed.
> +		 */
> +		if (nr_pages)
> +			dio->iocb->ki_flags &= ~IOCB_HIPRI;

Hmm, I was about to ask what happens if the user's HIPRI request gets
downgraded from polling mode, but the manpage doesn't say anything about
the kernel having to return an error if it can't use polling mode, so I
guess downgrading is...fine?

Well, maybe it isn't, since this also results in a downgrade when I send
a 1MB polled pwrite to my otherwise idle MegaSSD that has thousands of
queue depth.  I think?  <shrug> I'm not the one who uses polling mode,
fwiw.

--D

> +
>  		iomap_dio_submit_bio(dio, iomap, bio, pos);
>  		pos += n;
>  	} while (nr_pages);
> -- 
> 2.27.0
> 

Re: [PATCH v4 2/2] block,iomap: disable iopoll when split needed

[JeffleXu]

On 11/18/20 1:37 AM, Darrick J. Wong wrote:
> On Tue, Nov 17, 2020 at 03:56:25PM +0800, Jeffle Xu wrote:
>> Both blkdev fs and iomap-based fs (ext4, xfs, etc.) currently support
> $ ./scripts/get_maintainer.pl fs/iomap/direct-io.c
> Christoph Hellwig <hch@infradead.org> (supporter:IOMAP FILESYSTEM LIBRARY)
> "Darrick J. Wong" <darrick.wong@oracle.com> (supporter:IOMAP FILESYSTEM LIBRARY)
> linux-xfs@vger.kernel.org (supporter:IOMAP FILESYSTEM LIBRARY)
> linux-fsdevel@vger.kernel.org (supporter:IOMAP FILESYSTEM LIBRARY)
> linux-kernel@vger.kernel.org (open list)
>
> Please cc both iomap maintainers and the appropriate lists when you
> propose changes to fs/iomap/.  At a bare minimum cc linux-fsdevel for
> changes under fs/.
Got it.
>
>> sync iopoll. One single bio can contain at most BIO_MAX_PAGES, i.e. 256
>> bio_vec. If the input iov_iter contains more than 256 segments, then
>> one dio will be split into multiple bios, which may cause potential
>> deadlock for sync iopoll.
>>
>> When it comes to sync iopoll, the bio is submitted without REQ_NOWAIT
>> flag set and the process may hang in blk_mq_get_tag() if the dio needs
>> to be split into multiple bios and thus can rapidly exhausts the queue
>> depth. The process has to wait for the completion of the previously
>> allocated requests, which should be reaped by the following sync
>> polling, and thus causing a potential deadlock.
>>
>> In fact there's a subtle difference of handling of HIPRI IO between
>> blkdev fs and iomap-based fs, when dio need to be split into multiple
>> bios. blkdev fs will set REQ_HIPRI for only the last split bio, leaving
>> the previous bios queued into normal hardware queues, and not causing
>> the trouble described above. iomap-based fs will set REQ_HIPRI for all
>> split bios, and thus may cause the potential deadlock described above.
>>
>> Noted that though the analysis described above, currently blkdev fs and
>> iomap-based fs won't trigger this potential deadlock. Because only
>> preadv2(2)/pwritev2(2) are capable of *sync* polling as only these two
>> can set RWF_NOWAIT.

s/RWF_NOWAIT/RWF_HIPRI


>>   Currently the maximum number of iovecs of one single
>> preadv2(2)/pwritev2(2) call is UIO_MAXIOV, i.e. 1024, while the minimum
>> queue depth is BLKDEV_MIN_RQ i.e. 4. That means one
>> preadv2(2)/pwritev2(2) call can submit at most 4 bios, which will fill
>> up the queue depth *exactly* and thus there's no deadlock in this case.
>>
>> However this constraint can be fragile. Disable iopoll when one dio need
>> to be split into multiple bios.Though blkdev fs may not suffer this issue,
>> still it may not make much sense to iopoll for big IO, since iopoll is
>> initially for small size, latency sensitive IO.
>>
>> Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
>> ---
>>   fs/block_dev.c       |  9 +++++++++
>>   fs/iomap/direct-io.c | 10 ++++++++++
>>   2 files changed, 19 insertions(+)
>>
>> diff --git a/fs/block_dev.c b/fs/block_dev.c
>> index 9e84b1928b94..ed3f46e8fa91 100644
>> --- a/fs/block_dev.c
>> +++ b/fs/block_dev.c
>> @@ -436,6 +436,15 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter, int nr_pages)
>>   			break;
>>   		}
>>   
>> +		/*
>> +		 * The current dio needs to be split into multiple bios here.
>> +		 * iopoll for split bio will cause subtle trouble such as
>> +		 * hang when doing sync polling, while iopoll is initially
>> +		 * for small size, latency sensitive IO. Thus disable iopoll
>> +		 * if split needed.
>> +		 */
>> +		iocb->ki_flags &= ~IOCB_HIPRI;
>> +
>>   		if (!dio->multi_bio) {
>>   			/*
>>   			 * AIO needs an extra reference to ensure the dio
>> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
>> index 933f234d5bec..396ac0f91a43 100644
>> --- a/fs/iomap/direct-io.c
>> +++ b/fs/iomap/direct-io.c
>> @@ -309,6 +309,16 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
>>   		copied += n;
>>   
>>   		nr_pages = iov_iter_npages(dio->submit.iter, BIO_MAX_PAGES);
>> +		/*
>> +		 * The current dio needs to be split into multiple bios here.
>> +		 * iopoll for split bio will cause subtle trouble such as
>> +		 * hang when doing sync polling, while iopoll is initially
>> +		 * for small size, latency sensitive IO. Thus disable iopoll
>> +		 * if split needed.
>> +		 */
>> +		if (nr_pages)
>> +			dio->iocb->ki_flags &= ~IOCB_HIPRI;
> Hmm, I was about to ask what happens if the user's HIPRI request gets
> downgraded from polling mode, but the manpage doesn't say anything about
> the kernel having to return an error if it can't use polling mode, so I
> guess downgrading is...fine?

Yes if the block device doesn't support iopoll, then HIPRI pread/pwrite 
will automatically

gets downgraded from polling mode.


> Well, maybe it isn't, since this also results in a downgrade when I send
> a 1MB polled pwrite to my otherwise idle MegaSSD that has thousands of
> queue depth.  I think?  <shrug> I'm not the one who uses polling mode,
> fwiw.

Indeed that's true. iopoll gets disabled once the dio gets split,
even though the block device has thousands of queue depth. This
design is chose just because it is the simplest one..., though
this one should have no big problem.

As I described in the comment, iopoll is initially for small size
IO. We have ever tested the latency of Optane SSD

bs | latency (us)

---- | ----

read 4k | 14

read 128k | 68

write 4k | 17

write 128k | 75


The overhead of interrupt is about several (under 10) microseconds. The 
overhead of

interrupt when doing 128k IO may not be as important as that of small 
size IO, thus

the performance gain of iopoll will decreased a lot at least for 128k IO.


In my computer, @max_sectors of one nvme SSD is 128k, so the split bio 
is much

likely larger than 128k, in which case the performance loss should be 
acceptable

(though I have not test it).


>
>> +
>>   		iomap_dio_submit_bio(dio, iomap, bio, pos);
>>   		pos += n;
>>   	} while (nr_pages);
>> -- 
>> 2.27.0
>>
-- 
Thanks,
Jeffle

Re: [PATCH v4 2/2] block,iomap: disable iopoll when split needed

[Christoph Hellwig]

> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> index 933f234d5bec..396ac0f91a43 100644
> --- a/fs/iomap/direct-io.c
> +++ b/fs/iomap/direct-io.c
> @@ -309,6 +309,16 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
>  		copied += n;
>  
>  		nr_pages = iov_iter_npages(dio->submit.iter, BIO_MAX_PAGES);
> +		/*
> +		 * The current dio needs to be split into multiple bios here.
> +		 * iopoll for split bio will cause subtle trouble such as
> +		 * hang when doing sync polling, while iopoll is initially
> +		 * for small size, latency sensitive IO. Thus disable iopoll
> +		 * if split needed.
> +		 */
> +		if (nr_pages)
> +			dio->iocb->ki_flags &= ~IOCB_HIPRI;

I think this is confusing two things.  One is that we don't handle
polling well when there are multiple bios.  For this I think we should
only call bio_set_polled when we know there is a single bio.  But it
has nothing to do with a bio being split, as we can't know that at this
level.

Re: [PATCH v4 2/2] block,iomap: disable iopoll when split needed

[JeffleXu]

On 11/20/20 1:55 AM, Christoph Hellwig wrote:
>> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
>> index 933f234d5bec..396ac0f91a43 100644
>> --- a/fs/iomap/direct-io.c
>> +++ b/fs/iomap/direct-io.c
>> @@ -309,6 +309,16 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
>>   		copied += n;
>>   
>>   		nr_pages = iov_iter_npages(dio->submit.iter, BIO_MAX_PAGES);
>> +		/*
>> +		 * The current dio needs to be split into multiple bios here.
>> +		 * iopoll for split bio will cause subtle trouble such as
>> +		 * hang when doing sync polling, while iopoll is initially
>> +		 * for small size, latency sensitive IO. Thus disable iopoll
>> +		 * if split needed.
>> +		 */
>> +		if (nr_pages)
>> +			dio->iocb->ki_flags &= ~IOCB_HIPRI;
> I think this is confusing two things.

Indeed there's two level of split concerning this issue when doing sync 
iopoll.


The first is that one bio got split in block-core, and patch 1 of this 
patch set just fixes this.


Second is that one dio got split into multiple bios in fs layer, and 
patch 2 fixes this.


>   One is that we don't handle
> polling well when there are multiple bios.  For this I think we should
> only call bio_set_polled when we know there is a single bio.


How about the following patch:


--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -60,12 +60,12 @@ int iomap_dio_iopoll(struct kiocb *kiocb, bool spin)
  EXPORT_SYMBOL_GPL(iomap_dio_iopoll);

  static void iomap_dio_submit_bio(struct iomap_dio *dio, struct iomap 
*iomap,
-               struct bio *bio, loff_t pos)
+               struct bio *bio, loff_t pos, bool split)
  {
         atomic_inc(&dio->ref);

         if (dio->iocb->ki_flags & IOCB_HIPRI)
-               bio_set_polled(bio, dio->iocb);
+               bio_set_polled(bio, dio->iocb, split);

         dio->submit.last_queue = bdev_get_queue(iomap->bdev);
         if (dio->dops && dio->dops->submit_io)
@@ -214,6 +214,7 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, 
loff_t length,
         int nr_pages, ret = 0;
         size_t copied = 0;
         size_t orig_count;
+       bool split = false;

         if ((pos | length | align) & ((1 << blkbits) - 1))
                 return -EINVAL;
@@ -309,7 +310,17 @@ iomap_dio_bio_actor(struct inode *inode, loff_t 
pos, loff_t length,
                 copied += n;

                 nr_pages = iov_iter_npages(dio->submit.iter, 
BIO_MAX_PAGES);
-               iomap_dio_submit_bio(dio, iomap, bio, pos);
+               /*
+                * The current dio needs to be split into multiple bios 
here.
+                * iopoll for split bio will cause subtle trouble such as
+                * hang when doing sync polling, while iopoll is initially
+                * for small size, latency sensitive IO. Thus disable iopoll
+                * if split needed.
+                */
+               if (nr_pages)
+                       split = true;
+
+               iomap_dio_submit_bio(dio, iomap, bio, pos, split);
                 pos += n;
         } while (nr_pages);

diff --git a/include/linux/bio.h b/include/linux/bio.h
index c6d765382926..21f772f98878 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -806,9 +806,11 @@ static inline int bio_integrity_add_page(struct bio 
*bio, struct page *page,
   * must be found by the caller. This is different than IRQ driven IO, 
where
   * it's safe to wait for IO to complete.
   */
-static inline void bio_set_polled(struct bio *bio, struct kiocb *kiocb)
+static inline void bio_set_polled(struct bio *bio, struct kiocb *kiocb, 
bool split)
  {
-       bio->bi_opf |= REQ_HIPRI;
+       if (!split)
+               bio->bi_opf |= REQ_HIPRI;
+
         if (!is_sync_kiocb(kiocb))
                 bio->bi_opf |= REQ_NOWAIT;
  }


After this patch, bio will be polled only one dio maps to one single bio.

Noted that this change applies to both sync and async IO, though async 
routine doesn't

suffer the hang described in this patch set. Since the performance gain 
of iopoll may be

trivial when one dio got split, also disable iopoll for async routine.


We need keep REQ_NOWAIT for async routine even when the dio split happened,

because io_uring doesn't expect blocking. Though the original REQ_NOWAIT

should gets from iocb->ki_flags & IOCB_NOWAIT. Currently iomap doesn't 
inherit

bio->bi_opf's REQ_NOWAIT from iocb->ki_flags's IOCB_NOWAI. This bug should

be fixed by 
https://lore.kernel.org/linux-fsdevel/1605685931-207023-1-git-send-email-haoxu@linux.alibaba.com/T/#t


Maybe we could include this fix (of missing inheritance of IOCB_NOWAI) 
into this patch

set and then refactor the fix I mentioned in this patch?


-- 
Thanks,
Jeffle

Re: [PATCH v4 2/2] block,iomap: disable iopoll when split needed

[Christoph Hellwig]

On Fri, Nov 20, 2020 at 06:06:54PM +0800, JeffleXu wrote:
> 
> On 11/20/20 1:55 AM, Christoph Hellwig wrote:
> > > diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> > > index 933f234d5bec..396ac0f91a43 100644
> > > --- a/fs/iomap/direct-io.c
> > > +++ b/fs/iomap/direct-io.c
> > > @@ -309,6 +309,16 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
> > >   		copied += n;
> > >   		nr_pages = iov_iter_npages(dio->submit.iter, BIO_MAX_PAGES);
> > > +		/*
> > > +		 * The current dio needs to be split into multiple bios here.
> > > +		 * iopoll for split bio will cause subtle trouble such as
> > > +		 * hang when doing sync polling, while iopoll is initially
> > > +		 * for small size, latency sensitive IO. Thus disable iopoll
> > > +		 * if split needed.
> > > +		 */
> > > +		if (nr_pages)
> > > +			dio->iocb->ki_flags &= ~IOCB_HIPRI;
> > I think this is confusing two things.
> 
> Indeed there's two level of split concerning this issue when doing sync
> iopoll.
> 
> 
> The first is that one bio got split in block-core, and patch 1 of this patch
> set just fixes this.
> 
> 
> Second is that one dio got split into multiple bios in fs layer, and patch 2
> fixes this.
> 
> 
> >   One is that we don't handle
> > polling well when there are multiple bios.  For this I think we should
> > only call bio_set_polled when we know there is a single bio.
> 
> 
> How about the following patch:
> 
> 
> --- a/fs/iomap/direct-io.c
> +++ b/fs/iomap/direct-io.c
> @@ -60,12 +60,12 @@ int iomap_dio_iopoll(struct kiocb *kiocb, bool spin)
> ??EXPORT_SYMBOL_GPL(iomap_dio_iopoll);
> 
> ??static void iomap_dio_submit_bio(struct iomap_dio *dio, struct iomap
> *iomap,
> -???????????????????????????? struct bio *bio, loff_t pos)
> +???????????????????????????? struct bio *bio, loff_t pos, bool split)

This seems pretty messed up by your mailer and I have a hard time
reading it.  Can you resend it?

Re: [PATCH v4 2/2] block,iomap: disable iopoll when split needed

[JeffleXu]

Sorry for that, I will send a new version later.

On 11/24/20 7:25 PM, Christoph Hellwig wrote:
> On Fri, Nov 20, 2020 at 06:06:54PM +0800, JeffleXu wrote:
>>
>> On 11/20/20 1:55 AM, Christoph Hellwig wrote:
>>>> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
>>>> index 933f234d5bec..396ac0f91a43 100644
>>>> --- a/fs/iomap/direct-io.c
>>>> +++ b/fs/iomap/direct-io.c
>>>> @@ -309,6 +309,16 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
>>>>   		copied += n;
>>>>   		nr_pages = iov_iter_npages(dio->submit.iter, BIO_MAX_PAGES);
>>>> +		/*
>>>> +		 * The current dio needs to be split into multiple bios here.
>>>> +		 * iopoll for split bio will cause subtle trouble such as
>>>> +		 * hang when doing sync polling, while iopoll is initially
>>>> +		 * for small size, latency sensitive IO. Thus disable iopoll
>>>> +		 * if split needed.
>>>> +		 */
>>>> +		if (nr_pages)
>>>> +			dio->iocb->ki_flags &= ~IOCB_HIPRI;
>>> I think this is confusing two things.
>>
>> Indeed there's two level of split concerning this issue when doing sync
>> iopoll.
>>
>>
>> The first is that one bio got split in block-core, and patch 1 of this patch
>> set just fixes this.
>>
>>
>> Second is that one dio got split into multiple bios in fs layer, and patch 2
>> fixes this.
>>
>>
>>>   One is that we don't handle
>>> polling well when there are multiple bios.  For this I think we should
>>> only call bio_set_polled when we know there is a single bio.
>>
>>
>> How about the following patch:
>>
>>
>> --- a/fs/iomap/direct-io.c
>> +++ b/fs/iomap/direct-io.c
>> @@ -60,12 +60,12 @@ int iomap_dio_iopoll(struct kiocb *kiocb, bool spin)
>> ??EXPORT_SYMBOL_GPL(iomap_dio_iopoll);
>>
>> ??static void iomap_dio_submit_bio(struct iomap_dio *dio, struct iomap
>> *iomap,
>> -???????????????????????????? struct bio *bio, loff_t pos)
>> +???????????????????????????? struct bio *bio, loff_t pos, bool split)
> 
> This seems pretty messed up by your mailer and I have a hard time
> reading it.  Can you resend it?
> 

-- 
Thanks,
Jeffle

Re: [PATCH v4 0/2] block, iomap: disable iopoll for split bio

[JeffleXu]

On 11/17/20 3:56 PM, Jeffle Xu wrote:
> This patchset is to fix the potential hang occurred in sync polling.
>
> Please refer the following link for background info and the v1 patch:
> https://patchwork.kernel.org/project/linux-block/patch/20201013084051.27255-1-jefflexu@linux.alibaba.com/
>
> The first patch disables iopoll for split bio in block layer, which is
> suggested by Ming Lei.
>
>
> The second patch disables iopoll when one dio need to be split into
> multiple bios. As for this patch, Ming Lei had ever asked what's the
> expected behaviour of upper layers when simply clear IOCB_HIPRI in
> the direct routine of blkdev fs, iomap-based fs. Currently there are
> two parts concerning IOCB_HIPRI (or io polling). One is the sync
> polling logic embedded in the direct IO routine. In this case, sync
> polling won't be executed any more since IOCB_HIPRI flag has been
> cleared from iocb->ki_flags. Consider the following code snippet:
>
> fs/block_dev.c: __blkdev_direct_IO
> 	for (;;) {
> 		...
> 		if (!(iocb->ki_flags & IOCB_HIPRI) ||
> 		    !blk_poll(bdev_get_queue(bdev), qc, true))
> 			blk_io_schedule();
> 	}
>
> fs/iomap/direct-io.c: __iomap_dio_rw
> 	for (;;) {
> 		...
> 		if (!(iocb->ki_flags & IOCB_HIPRI) ||
> 		    !dio->submit.last_queue ||
> 		    !blk_poll(dio->submit.last_queue,
> 				 dio->submit.cookie, true))
> 			blk_io_schedule();
> 	}
>
>
> The other part is io_uring.
>
> fs/io_uring.c:
> io_iopoll_getevents
>    io_do_iopoll
>      list_for_each_entry_safe(...) {
>        ret = kiocb->ki_filp->f_op->iopoll(kiocb, spin);
>      }
>
> In this case, though the split bios have been enqueued into DEFAULT
> hw queues, io_uring will still poll POLL hw queues. When polling on
> the cookie returned by split bio, blk_poll() will return 0 immediately
> since the hw queue type check added in patch 1. If there's no other
> bio in the POLL hw queues, io_do_iopoll() will loop indefinitely
> until the split bio is completed by interrupt of DEFAULT queue. Indeed
> there may be a pulse of high CPU sys in this time window here, but it
> is no worse than before. After all io_do_iopoll() will still get stuck
> in this loop when there's only one bio (that we are polling on) in POLL
> hw queue, before this patch applied.
>
> The situation described above may be less impossible. As long as there
> are other bios in POLL hw queue, work of io_do_iopoll() is still
> meaningful as it *helps* reap these other bios in POLL hw queue, while
> the split bios are still completed by interrupt of DEFAULT hw queue.

ops, this design could still be problematic. Once the cookie of split 
bio is iterated in io_do_iopoll(),

io_do_iopoll() will get stuck in indefinite loop doing nothing until the 
split bio is completed by the interrupt of

DEFAULT hw queue, even when there may be other bios in POLL hw queue 
waiting to be reaped.


I need other design to fix this issue. By the way, do we need to fix the 
issue since currently this issue

won't be triggered, though by a relatively fragile constraint 
(BLKDEV_MIN_RQ/UIO_MAXIOV)?


-- 
Thanks,
Jeffle

Re: [PATCH v4 0/2] block, iomap: disable iopoll for split bio

[JeffleXu]

On 11/17/20 8:51 PM, JeffleXu wrote:
>
> On 11/17/20 3:56 PM, Jeffle Xu wrote:
>> This patchset is to fix the potential hang occurred in sync polling.
>>
>> Please refer the following link for background info and the v1 patch:
>> https://patchwork.kernel.org/project/linux-block/patch/20201013084051.27255-1-jefflexu@linux.alibaba.com/ 
>>
>>
>> The first patch disables iopoll for split bio in block layer, which is
>> suggested by Ming Lei.
>>
>>
>> The second patch disables iopoll when one dio need to be split into
>> multiple bios. As for this patch, Ming Lei had ever asked what's the
>> expected behaviour of upper layers when simply clear IOCB_HIPRI in
>> the direct routine of blkdev fs, iomap-based fs. Currently there are
>> two parts concerning IOCB_HIPRI (or io polling). One is the sync
>> polling logic embedded in the direct IO routine. In this case, sync
>> polling won't be executed any more since IOCB_HIPRI flag has been
>> cleared from iocb->ki_flags. Consider the following code snippet:
>>
>> fs/block_dev.c: __blkdev_direct_IO
>>     for (;;) {
>>         ...
>>         if (!(iocb->ki_flags & IOCB_HIPRI) ||
>>             !blk_poll(bdev_get_queue(bdev), qc, true))
>>             blk_io_schedule();
>>     }
>>
>> fs/iomap/direct-io.c: __iomap_dio_rw
>>     for (;;) {
>>         ...
>>         if (!(iocb->ki_flags & IOCB_HIPRI) ||
>>             !dio->submit.last_queue ||
>>             !blk_poll(dio->submit.last_queue,
>>                  dio->submit.cookie, true))
>>             blk_io_schedule();
>>     }
>>
>>
>> The other part is io_uring.
>>
>> fs/io_uring.c:
>> io_iopoll_getevents
>>    io_do_iopoll
>>      list_for_each_entry_safe(...) {
>>        ret = kiocb->ki_filp->f_op->iopoll(kiocb, spin);
>>      }
>>
>> In this case, though the split bios have been enqueued into DEFAULT
>> hw queues, io_uring will still poll POLL hw queues. When polling on
>> the cookie returned by split bio, blk_poll() will return 0 immediately
>> since the hw queue type check added in patch 1. If there's no other
>> bio in the POLL hw queues, io_do_iopoll() will loop indefinitely
>> until the split bio is completed by interrupt of DEFAULT queue. Indeed
>> there may be a pulse of high CPU sys in this time window here, but it
>> is no worse than before. After all io_do_iopoll() will still get stuck
>> in this loop when there's only one bio (that we are polling on) in POLL
>> hw queue, before this patch applied.
>>
>> The situation described above may be less impossible. As long as there
>> are other bios in POLL hw queue, work of io_do_iopoll() is still
>> meaningful as it *helps* reap these other bios in POLL hw queue, while
>> the split bios are still completed by interrupt of DEFAULT hw queue.
>
> ops, this design could still be problematic. Once the cookie of split 
> bio is iterated in io_do_iopoll(),
>
> io_do_iopoll() will get stuck in indefinite loop doing nothing until 
> the split bio is completed by the interrupt of
>
> DEFAULT hw queue, even when there may be other bios in POLL hw queue 
> waiting to be reaped.

This shouldn't be a problem. After this patch applied, blk_poll() will 
return 0 immediately

since the hw queue type check added in patch 1, and thus io_do_iopoll() 
will iterate next

kiocb in @iopoll_list. There will be no indefinite loop. Sorry for the 
noise...

-- 
Thanks,
Jeffle