On 06/11/2016 01:06 PM, Martin K. Petersen wrote:
"Hannes" == Hannes Reinecke <hare@xxxxxxx> writes:
Hannes> Because we're checking the wrong limit.
The original code checked that the request was smaller than both
max_sectors and max_hw_sectors so it would have failed here as well.
Hannes> blk_queue_get_max_sectors() is checking limits.max_sectors(),
Hannes> but the requests are already fully formed and can extend up to
Hannes> limits.max_hw_sectors().
We should not be issuing REQ_TYPE_FS requests larger than max_sectors.
How did we get here?
Well, the primary issue is that 'blk_cloned_rq_check_limits()' doesn't
check for BLOCK_PC, so this particular check would be applied for every
request.
But as it turns out, even adding a check for BLOCK_PC doesn't help, so
we're indeed seeing REQ_TYPE_FS requests with larger max_sector counts.
As to _why_ this happens I frankly have no idea. I have been staring at
this particular code for over a year now (I've got another bug pending
where we hit the _other_ if clause), but to no avail.
So I've resolved to drop the check altogether, seeing that max_sector
size is _not_ something which gets changed during failover.
Therefore if the max_sector count is wrong for the cloned request it was
already wrong for the original request, and we should've errored it out
far earlier.
The max_segments count, OTOH, _might_ change during failover (different
hardware has different max_segments setting, and this is being changed
during sg mapping), so there is some value to be had from testing it here.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
