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
