Re: block: don't check request size in blk_cloned_rq_check_limits()

[Hannes Reinecke <hare@suse.de>]

On 06/15/2016 12:03 PM, Jens Axboe wrote:
> On 06/15/2016 08:33 AM, Hannes Reinecke wrote:
>> And as I've mentioned before: what is the purpose of this check?
>>
>> 'max_sectors' and 'max_hw_sectors' are checked during request assembly,
>> and those limits are not changed even after calling
>> blk_recalc_rq_segments(). And if we go over any device-imposed
>> restrictions we'll be getting an I/O error from the driver anyway.
>> So why have it at all?
> 
> You don't know that to be the case. The driver asked for certain limits,
> the core MUST obey them. The driver should not need to check for these
> limits, outside of in a BUG_ON() like manner.
> 
Okay.
But again, what is the purpose of this check?
I do agree that we need to do a sanity check after we're recalculated
the sg elements, but we never recalculate the overall size of the request.
So why do we check only max_sector_size?
Why not max_segment_size?
Surely the queue limits can be different for that, too?

>> Especially as the system boots happily with this check removed...
> 
> That's the case for you, but you can't assume this to be the case in
> general.
> 
> There's a _lot_ of hand waving in this thread, Hannes. How do we
> reproduce this? We need to get this fixed for real, not just delete some
> check that triggers for you and that it just happens to work without.
> That's not how you fix problems.
> 
Well. Yes, I know.
This issue is ATM only ever reproduced on ppc64le running on ibmvfc. And
has been reported by a customer to us.
So there is not much I can do with reproducing here, sadly.

Maybe Brian King has some ideas/possibilities for this.
Brian, can you reproduce this with latest upstream kernel?
If so, can you file a bug at kernel.org?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N�rnberg
GF: F. Imend�rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG N�rnberg)