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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/15/2016 05:33 AM, Hannes Reinecke wrote:
> 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?

Mauricio was looking at this, adding him to cc. We did have a KVM config
where we could reproduce this issue as well, I think with some PCI passthrough
adapters. Mauricio - do you have any more details about the KVM config that
reproduced this issue and did you ever try to reproduce this with an upstream
kernel?

Thanks,

Brian

-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

--
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



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux