On 06/16/2016 11:59 PM, Mauricio Faria de Oliveira wrote:
On 06/16/2016 09:35 AM, Mauricio Faria de Oliveira wrote:
On 06/15/2016 01:34 PM, Brian King wrote:
[...] did you ever try to reproduce this with an
upstream
kernel?
Now that the topic is under discussion, I've asked for some time
Hey,
On 06/15/2016 01:34 PM, Brian King wrote:
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
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
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
>>
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
On 06/15/2016 03:39 AM, Martin K. Petersen wrote:
>> "Hannes" == Hannes Reinecke writes:
>
> Hannes> Well, the primary issue is that 'blk_cloned_rq_check_limits()'
> Hannes> doesn't check for BLOCK_PC,
>
> Yes it does. It calls blk_rq_get_max_sectors() which has an explicit
>
> "Mike" == Mike Snitzer writes:
>> Oh, this happens during failover? Are you sure it's not because DM is
>> temporarily resetting the queue limits? max_sectors is going to be a
>> single page in that case. I just discussed a backport regression in
>> this department with
On Tue, Jun 14 2016 at 9:39pm -0400,
Martin K. Petersen wrote:
> > "Hannes" == Hannes Reinecke writes:
>
> Hannes> Well, the primary issue is that 'blk_cloned_rq_check_limits()'
> Hannes> doesn't check for BLOCK_PC,
>
> Yes it does. It calls
> "Hannes" == Hannes Reinecke writes:
Hannes> Well, the primary issue is that 'blk_cloned_rq_check_limits()'
Hannes> doesn't check for BLOCK_PC,
Yes it does. It calls blk_rq_get_max_sectors() which has an explicit
check for this:
static inline unsigned int
On Sat, Jun 11, 2016 at 03:10:06PM +0200, Hannes Reinecke wrote:
> 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.
So fix it..
> But as it turns out, even adding a check for BLOCK_PC doesn't
On 06/11/2016 01:06 PM, Martin K. Petersen wrote:
"Hannes" == Hannes Reinecke 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>
> "Hannes" == Hannes Reinecke 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
On 06/10/2016 04:18 PM, Mike Snitzer wrote:
On Fri, Jun 10 2016 at 9:30am -0400,
Hannes Reinecke wrote:
On 06/10/2016 03:19 PM, Mike Snitzer wrote:
On Mon, May 30 2016 at 3:24am -0400,
Hannes Reinecke wrote:
When checking a cloned request there is no need to
On 06/11/2016 04:22 AM, Martin K. Petersen wrote:
"Mike" == Mike Snitzer writes:
When checking a cloned request there is no need to check the overall
request size; this won't have changed even when resubmitting to
another queue. Without this patch ppc64le on ibmvfc fails
> "Mike" == Mike Snitzer writes:
>> When checking a cloned request there is no need to check the overall
>> request size; this won't have changed even when resubmitting to
>> another queue. Without this patch ppc64le on ibmvfc fails to boot.
Why is the number of sectors
On Fri, Jun 10 2016 at 9:30am -0400,
Hannes Reinecke wrote:
> On 06/10/2016 03:19 PM, Mike Snitzer wrote:
> > On Mon, May 30 2016 at 3:24am -0400,
> > Hannes Reinecke wrote:
> >
> >> When checking a cloned request there is no need to check
> >> the overall request
On 06/10/2016 03:19 PM, Mike Snitzer wrote:
> On Mon, May 30 2016 at 3:24am -0400,
> Hannes Reinecke wrote:
>
>> When checking a cloned request there is no need to check
>> the overall request size; this won't have changed even
>> when resubmitting to another queue.
>> Without
On Mon, May 30 2016 at 3:24am -0400,
Hannes Reinecke wrote:
> When checking a cloned request there is no need to check
> the overall request size; this won't have changed even
> when resubmitting to another queue.
> Without this patch ppc64le on ibmvfc fails to boot.
By simply
When checking a cloned request there is no need to check
the overall request size; this won't have changed even
when resubmitting to another queue.
Without this patch ppc64le on ibmvfc fails to boot.
Signed-off-by: Hannes Reinecke
---
block/blk-core.c | 5 -
1 file changed, 5
When checking a cloned request there is no need to check
the overall request size; this won't have changed even
when resubmitting to another queue.
Without this patch ppc64le on ibmvfc fails to boot.
Signed-off-by: Hannes Reinecke
---
block/blk-core.c | 5 -
1 file changed, 5
20 matches
Mail list logo