On 04/28/2015 04:43 AM, Christoph Hellwig wrote:
> This seems to lack support for QUEUE_FLAG_SG_GAPS to work around
> the retarded PPR format in the NVMe driver.  I'm actually not
> sure we have a way to reproduce them for BLOCK_PC requests, but I think
> we should make sure to properly handle them.

How about below incremental patch?

 block/bio.c       | 8 --------
 block/blk-merge.c | 8 ++++++++
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index ae31cdb..3f6bd9a 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -743,14 +743,6 @@ int bio_add_pc_page(struct request_queue *q, struct bio 
*bio, struct page
                        bio->bi_iter.bi_size += len;
                        goto done;
                }
-
-               /*
-                * If the queue doesn't support SG gaps and adding this
-                * offset would create a gap, disallow it.
-                */
-               if (q->queue_flags & (1 << QUEUE_FLAG_SG_GAPS) &&
-                   bvec_gap_to_prev(prev, offset))
-                       return 0;
        }
 
        if (bio->bi_vcnt >= bio->bi_max_vecs)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 9d565a0..32f6d6c 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -78,6 +78,14 @@ static struct bio *blk_bio_segment_split(struct 
request_queue *q,
                if (sectors > queue_max_sectors(q))
                        goto split;
 
+               /*
+                * If the queue doesn't support SG gaps and adding this
+                * offset would create a gap, disallow it.
+                */
+               if (q->queue_flags & (1 << QUEUE_FLAG_SG_GAPS) &&
+                   prev && bvec_gap_to_prev(&bvprv, bv.bv_offset))
+                       goto split;
+
                if (prev && blk_queue_cluster(q)) {
                        if (seg_size + bv.bv_len > queue_max_segment_size(q))
                                goto new_segment;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to