[PATCH] block: fix get_max_io_size()

[PATCH] block: fix get_max_io_size()

[Keith Busch]

A previous commit aligning splits to physical block sizes inadvertently
modified one return case such that that it now returns 0 length splits
when the number of sectors doesn't exceed the physical offset. This
later hits a BUG in bio_split(). Restore the previous working behavior.

Reported-by: Eric Deal <eric.deal@wdc.com>
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: stable@vger.kernel.org
Fixes: 9cc5169cd478b ("block: Improve physical block alignment of split bios")
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
 block/blk-merge.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 5196dc145270..d7fef954d42f 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -154,7 +154,7 @@ static inline unsigned get_max_io_size(struct request_queue *q,
 	if (max_sectors > start_offset)
 		return max_sectors - start_offset;
 
-	return sectors & (lbs - 1);
+	return sectors & ~(lbs - 1);
 }
 
 static inline unsigned get_max_segment_size(const struct request_queue *q,
-- 
2.24.1

Re: [PATCH] block: fix get_max_io_size()

[Jens Axboe]

On 8/6/20 3:58 PM, Keith Busch wrote:
> A previous commit aligning splits to physical block sizes inadvertently
> modified one return case such that that it now returns 0 length splits
> when the number of sectors doesn't exceed the physical offset. This
> later hits a BUG in bio_split(). Restore the previous working behavior.

Yikes! I wonder how that lived so long... Applied.

-- 
Jens Axboe

Re: [PATCH] block: fix get_max_io_size()

[Bart Van Assche]

On 2020-08-06 14:58, Keith Busch wrote:
> A previous commit aligning splits to physical block sizes inadvertently
> modified one return case such that that it now returns 0 length splits
> when the number of sectors doesn't exceed the physical offset. This
> later hits a BUG in bio_split(). Restore the previous working behavior.
> 
> Reported-by: Eric Deal <eric.deal@wdc.com>
> Cc: Bart Van Assche <bvanassche@acm.org>
> Cc: stable@vger.kernel.org
> Fixes: 9cc5169cd478b ("block: Improve physical block alignment of split bios")
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> ---
>  block/blk-merge.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 5196dc145270..d7fef954d42f 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -154,7 +154,7 @@ static inline unsigned get_max_io_size(struct request_queue *q,
>  	if (max_sectors > start_offset)
>  		return max_sectors - start_offset;
>  
> -	return sectors & (lbs - 1);
> +	return sectors & ~(lbs - 1);
>  }

I think we agree that get_max_io_size() should never return zero. However, the above
change seems wrong to me because it will cause get_max_io_size() to return zero if
the logical block size is larger than 512 bytes and if sectors < lbs. How about
changing the return statement as follows (untested):

	return max(sectors & (lbs - 1), sectors);

Thanks,

Bart.

Re: [PATCH] block: fix get_max_io_size()

[Bart Van Assche]

On 2020-08-06 17:28, Bart Van Assche wrote:
> On 2020-08-06 14:58, Keith Busch wrote:
>> A previous commit aligning splits to physical block sizes inadvertently
>> modified one return case such that that it now returns 0 length splits
>> when the number of sectors doesn't exceed the physical offset. This
>> later hits a BUG in bio_split(). Restore the previous working behavior.
>>
>> Reported-by: Eric Deal <eric.deal@wdc.com>
>> Cc: Bart Van Assche <bvanassche@acm.org>
>> Cc: stable@vger.kernel.org
>> Fixes: 9cc5169cd478b ("block: Improve physical block alignment of split bios")
>> Signed-off-by: Keith Busch <kbusch@kernel.org>
>> ---
>>  block/blk-merge.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/block/blk-merge.c b/block/blk-merge.c
>> index 5196dc145270..d7fef954d42f 100644
>> --- a/block/blk-merge.c
>> +++ b/block/blk-merge.c
>> @@ -154,7 +154,7 @@ static inline unsigned get_max_io_size(struct request_queue *q,
>>  	if (max_sectors > start_offset)
>>  		return max_sectors - start_offset;
>>  
>> -	return sectors & (lbs - 1);
>> +	return sectors & ~(lbs - 1);
>>  }
> 
> I think we agree that get_max_io_size() should never return zero. However, the above
> change seems wrong to me because it will cause get_max_io_size() to return zero if
> the logical block size is larger than 512 bytes and if sectors < lbs. How about
> changing the return statement as follows (untested):

This should work better than what was mentioned in my previous email:

-	return sectors & (lbs - 1);
+	return sectors;

Thanks,

Bart.

Re: [PATCH] block: fix get_max_io_size()

[Keith Busch]

On Thu, Aug 06, 2020 at 05:28:17PM -0700, Bart Van Assche wrote:
> I think we agree that get_max_io_size() should never return zero. However, the above
> change seems wrong to me because it will cause get_max_io_size() to return zero if
> the logical block size is larger than 512 bytes and if sectors < lbs. 

I'm pretty sure we have more problems if 'sectors' isn't a multiple
of the logical block size.

Re: [PATCH] block: fix get_max_io_size()

[Keith Busch]

On Thu, Aug 06, 2020 at 06:25:50PM -0700, Bart Van Assche wrote:
> This should work better than what was mentioned in my previous email:
> 
> -	return sectors & (lbs - 1);
> +	return sectors;

It used to be something like that. There were some situations where it
didn't work, which brought d0e5fbb01a67e, but I think the real problem
was from mismatched queue_limits, which I think I addressed with
5f009d3f8e668, so maybe this is okay now.

Re: [PATCH] block: fix get_max_io_size()

[Bart Van Assche]

On 2020-08-06 20:24, Keith Busch wrote:
> On Thu, Aug 06, 2020 at 06:25:50PM -0700, Bart Van Assche wrote:
>> This should work better than what was mentioned in my previous email:
>>
>> -	return sectors & (lbs - 1);
>> +	return sectors;
> 
> It used to be something like that. There were some situations where it
> didn't work, which brought d0e5fbb01a67e, but I think the real problem
> was from mismatched queue_limits, which I think I addressed with
> 5f009d3f8e668, so maybe this is okay now.

Hi Keith,

How about replacing your patch with the (untested) patch below?

Thanks,

Bart.


diff --git a/block/blk-merge.c b/block/blk-merge.c
index 5196dc145270..2d10fa3768a3 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -135,10 +135,9 @@ static struct bio *blk_bio_write_same_split(struct request_queue *q,
 /*
  * Return the maximum number of sectors from the start of a bio that may be
  * submitted as a single request to a block device. If enough sectors remain,
- * align the end to the physical block size. Otherwise align the end to the
- * logical block size. This approach minimizes the number of non-aligned
- * requests that are submitted to a block device if the start of a bio is not
- * aligned to a physical block boundary.
+ * align the end to the physical block size. This approach minimizes the
+ * number of non-aligned requests that are submitted to a block device if the
+ * start of a bio is not aligned to a physical block boundary.
  */
 static inline unsigned get_max_io_size(struct request_queue *q,
 				       struct bio *bio)
@@ -146,7 +145,6 @@ static inline unsigned get_max_io_size(struct request_queue *q,
 	unsigned sectors = blk_max_size_offset(q, bio->bi_iter.bi_sector);
 	unsigned max_sectors = sectors;
 	unsigned pbs = queue_physical_block_size(q) >> SECTOR_SHIFT;
-	unsigned lbs = queue_logical_block_size(q) >> SECTOR_SHIFT;
 	unsigned start_offset = bio->bi_iter.bi_sector & (pbs - 1);

 	max_sectors += start_offset;
@@ -154,7 +152,7 @@ static inline unsigned get_max_io_size(struct request_queue *q,
 	if (max_sectors > start_offset)
 		return max_sectors - start_offset;

-	return sectors & (lbs - 1);
+	return sectors;
 }

 static inline unsigned get_max_segment_size(const struct request_queue *q,

Re: [PATCH] block: fix get_max_io_size()

[Keith Busch]

On Fri, Aug 07, 2020 at 07:18:49AM -0700, Bart Van Assche wrote:
> Hi Keith,
> 
> How about replacing your patch with the (untested) patch below?


I believe that should be fine, but I broke the kernel last time I did
something like that. I still think it was from incorrect queue_limits,
but Linus disagreed.

 * http://lkml.iu.edu/hypermail/linux/kernel/1601.2/03994.html

Re: [PATCH] block: fix get_max_io_size()

[Bart Van Assche]

On 2020-08-07 10:10, Keith Busch wrote:
> On Fri, Aug 07, 2020 at 07:18:49AM -0700, Bart Van Assche wrote:
>> Hi Keith,
>>
>> How about replacing your patch with the (untested) patch below?
> 
> 
> I believe that should be fine, but I broke the kernel last time I did
> something like that. I still think it was from incorrect queue_limits,
> but Linus disagreed.
> 
>  * http://lkml.iu.edu/hypermail/linux/kernel/1601.2/03994.html

Hi Keith,

Thanks for the interesting link. Regarding Linus' comments about bio
splitting: if the last return statement in get_max_io_size() is reached
then it is guaranteed that sectors < pbs (physical block size). So I think
that Linus' comment applies to the previous return statement instead of to
the last ("return max_sectors - start_offset;"). However, I think it is
already guaranteed that that value is a multiple of the logical block size
because start_offset is a multiple of the logical block size and because
of the following statement: "max_sectors &= ~(pbs - 1);".

Bart.

Re: [PATCH] block: fix get_max_io_size()

[Keith Busch]

On Fri, Aug 07, 2020 at 12:02:30PM -0700, Bart Van Assche wrote:
> On 2020-08-07 10:10, Keith Busch wrote:
> > On Fri, Aug 07, 2020 at 07:18:49AM -0700, Bart Van Assche wrote:
> >> Hi Keith,
> >>
> >> How about replacing your patch with the (untested) patch below?
> > 
> > 
> > I believe that should be fine, but I broke the kernel last time I did
> > something like that. I still think it was from incorrect queue_limits,
> > but Linus disagreed.
> > 
> >  * http://lkml.iu.edu/hypermail/linux/kernel/1601.2/03994.html
> 
> Hi Keith,
> 
> Thanks for the interesting link. Regarding Linus' comments about bio
> splitting: if the last return statement in get_max_io_size() is reached
> then it is guaranteed that sectors < pbs (physical block size). So I think
> that Linus' comment applies to the previous return statement instead of to
> the last ("return max_sectors - start_offset;"). However, I think it is
> already guaranteed that that value is a multiple of the logical block size
> because start_offset is a multiple of the logical block size and because
> of the following statement: "max_sectors &= ~(pbs - 1);".

This breaks if limits.max_sectors is not a multiple of the queue's
logical block size and the physical block size is larger than
max_sectors.

Re: [PATCH] block: fix get_max_io_size()

[Keith Busch]

Hi Jens,

The proposed alternatives continue to break with allowable (however
unlikely) queue limits, where this should be safe for any possible
settings. I think this should be okay to go as-is.

On Thu, Aug 06, 2020 at 02:58:37PM -0700, Keith Busch wrote:
> A previous commit aligning splits to physical block sizes inadvertently
> modified one return case such that that it now returns 0 length splits
> when the number of sectors doesn't exceed the physical offset. This
> later hits a BUG in bio_split(). Restore the previous working behavior.
> 
> Reported-by: Eric Deal <eric.deal@wdc.com>
> Cc: Bart Van Assche <bvanassche@acm.org>
> Cc: stable@vger.kernel.org
> Fixes: 9cc5169cd478b ("block: Improve physical block alignment of split bios")
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> ---
>  block/blk-merge.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 5196dc145270..d7fef954d42f 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -154,7 +154,7 @@ static inline unsigned get_max_io_size(struct request_queue *q,
>  	if (max_sectors > start_offset)
>  		return max_sectors - start_offset;
>  
> -	return sectors & (lbs - 1);
> +	return sectors & ~(lbs - 1);
>  }
>  
>  static inline unsigned get_max_segment_size(const struct request_queue *q,
> -- 

Re: [PATCH] block: fix get_max_io_size()

[Jens Axboe]

On 8/18/20 9:39 AM, Keith Busch wrote:
> Hi Jens,
> 
> The proposed alternatives continue to break with allowable (however
> unlikely) queue limits, where this should be safe for any possible
> settings. I think this should be okay to go as-is.

OK, let's try this again then. Queued up for 5.9.

-- 
Jens Axboe