From: Brian King <brking@linux.vnet.ibm.com>
To: Hannes Reinecke <hare@suse.de>, Jens Axboe <axboe@kernel.dk>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Mike Snitzer <snitzer@redhat.com>, Brian King <brking@us.ibm.com>,
linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
mark.bergman@uphs.upenn.edu,
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Subject: Re: block: don't check request size in blk_cloned_rq_check_limits()
Date: Wed, 15 Jun 2016 11:34:22 -0500 [thread overview]
Message-ID: <5761838E.1000106@linux.vnet.ibm.com> (raw)
In-Reply-To: <57612F12.5070505@suse.de>
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
next prev parent reply other threads:[~2016-06-15 16:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-30 7:24 [PATCH] block: don't check request size in blk_cloned_rq_check_limits() Hannes Reinecke
2016-06-10 13:19 ` Mike Snitzer
2016-06-10 13:30 ` Hannes Reinecke
2016-06-10 13:30 ` Hannes Reinecke
2016-06-10 14:18 ` Mike Snitzer
2016-06-11 10:05 ` Hannes Reinecke
2016-06-11 10:05 ` Hannes Reinecke
2016-06-11 2:22 ` Martin K. Petersen
2016-06-11 10:01 ` Hannes Reinecke
2016-06-11 10:01 ` Hannes Reinecke
2016-06-11 11:06 ` Martin K. Petersen
2016-06-11 13:10 ` Hannes Reinecke
2016-06-11 13:10 ` Hannes Reinecke
2016-06-13 8:07 ` Christoph Hellwig
2016-06-15 1:39 ` Martin K. Petersen
2016-06-15 2:29 ` Mike Snitzer
2016-06-15 2:32 ` Martin K. Petersen
2016-06-15 6:33 ` Hannes Reinecke
2016-06-15 6:33 ` Hannes Reinecke
2016-06-15 10:03 ` Jens Axboe
2016-06-15 10:33 ` Hannes Reinecke
2016-06-15 10:33 ` Hannes Reinecke
2016-06-15 16:34 ` Brian King [this message]
2016-06-16 12:35 ` Mauricio Faria de Oliveira
2016-06-16 21:59 ` Mauricio Faria de Oliveira
2016-06-17 6:59 ` Hannes Reinecke
2016-06-17 6:59 ` Hannes Reinecke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5761838E.1000106@linux.vnet.ibm.com \
--to=brking@linux.vnet.ibm.com \
--cc=axboe@kernel.dk \
--cc=brking@us.ibm.com \
--cc=hare@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mark.bergman@uphs.upenn.edu \
--cc=martin.petersen@oracle.com \
--cc=mauricfo@linux.vnet.ibm.com \
--cc=snitzer@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.