All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Tao Ma <tm@tao.ma>,
	linux-kernel@vger.kernel.org,
	linux-scsi <linux-scsi@vger.kernel.org>,
	"edmund.nadolski" <edmund.nadolski@intel.com>,
	mroos@ut.ee
Subject: Re: [PATCH RESEND] block: warn if tag is greater than real_max_depth.
Date: Tue, 20 Dec 2011 14:56:29 +0100	[thread overview]
Message-ID: <4EF0940D.7070304@kernel.dk> (raw)
In-Reply-To: <CAA9_cmfRXgwsamx2Q+Wccyfqnz3ePt60Z950pPippJuOnooJLA@mail.gmail.com>

On 2011-12-20 02:45, Dan Williams wrote:
> On Mon, Dec 19, 2011 at 5:11 PM, Tao Ma <tm@tao.ma> wrote:
>>>> Looks good, better than what we had. Applied.
>>>
>>> This appears to interact badly with scsi_adjust_queue_depth() when the
>>> tag space shrinks.  I can reproduce a similar crash as reported in
>>> "3.2-rc2+git: kernel BUG at block/blk-core.c:1000!
>>> (__scsi_queue_insert)" [1].
>>>
>>> I can hit "kernel BUG at block/blk-core.c:2268!" which is the same
>>> BUG_ON(blk_queued_rq(rq)) check reliably with:
>>> # for i in $(seq 0 10); do dd if=/dev/zero of=/dev/sdX & done
>>> # echo 4 > /sys/class/block/sdX/device/queue_depth
>>>
>>> The following fixes it for me, if this looks ok (versus reverting
>>> commit 5e081591) I'll roll it into a formal patch with Ed and Meelis'
>>> Reported-by.
>> Interesting. If I read the code correctly, real_max_depth is the maximum
>> queue depth we ever have and max_depth is the current depth.
>>
>> In your fix, we never resize the tag size to be smaller than max_depth.
>> So I think this patch does expose some problem, but not lead to the BUG.
> 
> Yes, if we keep the "if (unlikely(tag >= bqt->max_depth))" check in
> blk_queue_end_tag() then the side effect is that we can never shrink
> the tag depth, which I don't think was intended.
> 
>> And in your new comment, you mentioned that "request between new_depth
>> and max_depth can be in-flight", but max_depth <= real_max_depth, so
>> what's wrong with the comment? Sorry, but am I missing something here?
> 
> Prior to the change blk_queue_end_tag() would continue to complete
> requests with a tag > max_depth, now it silently drops them on the
> floor leaving BUG_ON(blk_queued_rq(rq)) to trigger when we try to end
> the request

Yeah, that's just wrong. Tao Ma, which bug was the original fix intended
to fix?

The reason we have these two ceilings is exactly for shrinking depth
situations. It's quite legal to have an inflight request with a tag
inbetween max_depth and real_max_depth.

-- 
Jens Axboe


  reply	other threads:[~2011-12-20 13:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-14  7:23 [PATCH RESEND] block: warn if tag is greater than real_max_depth Tao Ma
2011-09-14  7:23 ` [PATCH RESEND] block: Don't check QUEUE_FLAG_SAME_COMP in __blk_complete_request Tao Ma
2011-09-15  1:05   ` Shaohua Li
2011-09-15  2:16     ` Tao Ma
2011-09-15 11:17       ` Christoph Hellwig
2011-09-15 11:28         ` Jens Axboe
2011-09-15 14:48           ` Tao Ma
2011-10-24 15:03 ` [PATCH RESEND] block: warn if tag is greater than real_max_depth Tao Ma
2011-10-25  8:19   ` Jens Axboe
2011-12-20  0:07     ` Dan Williams
2011-12-20  1:11       ` Tao Ma
2011-12-20  1:45         ` Dan Williams
2011-12-20 13:56           ` Jens Axboe [this message]
2011-12-20 15:21             ` Tao Ma
2011-12-20 15:58             ` [PATCH] block: warn the wrong tag only if it " Tao Ma
2011-12-20 17:31               ` Williams, Dan J
2011-12-20 17:31                 ` Williams, Dan J

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=4EF0940D.7070304@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=dan.j.williams@intel.com \
    --cc=edmund.nadolski@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mroos@ut.ee \
    --cc=tm@tao.ma \
    /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.