From: Hans de Goede <hdegoede@redhat.com>
To: SCSI development list <linux-scsi@vger.kernel.org>
Cc: Hans de Goede <hdegoede@redhat.com>,
Sarah Sharp <sarah.a.sharp@linux.intel.com>
Subject: blk-tag.c: 89 BUG() triggering + initial analysis
Date: Thu, 14 Nov 2013 12:09:12 +0100 [thread overview]
Message-ID: <5284AF58.5070901@redhat.com> (raw)
Hi All,
I hope linux-scsi is the right list for this, if not let me know.
I've been working on getting the uas (Usb Attached Scsi) driver into
working shape for the last 3 weeks, so that it can be enabled in 3.14 .
My latest tests where performed on top of 3.11 + a bunch of xhci and
of course uas fixes.
I can reliable trigger the BUG() in blk-tag.c line 89:
void blk_free_tags(struct blk_queue_tag *bqt)
{
if (unlikely(!__blk_free_tags(bqt)))
BUG();
}
I believe this is not an uas driver bug, but rather a bug which
any scsi host which uses scsi_init_shared_tag_map() can trigger,
which is likely not seen before because almost no hosts actually
use scsi_init_shared_tag_map().
The above test triggering the BUG() assumes that blk_free_tags()
caller holds the last reference to the bqt. For scsi hosts using
scsi_init_shared_tag_map() this assumes that the release of the
block_queue through blk-sysfs.c: blk_release_queue() happens before
the release of the host through scsi/hosts.c: scsi_host_dev_release()
I've added some strategic debug printk-s to debug this problem
(and removed the BUG()) and in some cases this is not true.
Here is the output of my debug scripts on a normal unplug of
the uas usb-device:
[ 7678.202540] blk-sysfs.c: blk_release_queue queue_tags ffff88022d4d59e0
[ 7678.202551] blk-tag.c: __blk_queue_free_tags bqt ffff88022d4d59e0
[ 7678.202553] blk-tag.c: __blk_free_tags refcnt before dec: 2
[ 7678.202626] scsi/hosts.c: scsi_host_dev_release bqt ffff88022d4d59e0
[ 7678.202654] blk-tag.c: blk_free_tags bqt ffff88022d4d59e0
[ 7678.202655] blk-tag.c: __blk_free_tags refcnt before dec: 1
[ 7678.202657] blk-tag.c: __blk_free_tags free-ed: ffff88022d4d59e0
Which does not trigger the BUG().
If however I do the following:
1) plug in uas usb-device
2) let udisks auto-mount it under:
/run/media/hans/4e82585c-3c40-48ac-81ad-11d2a7bad0fc
3) cd into that dir to keep it busy
4) unplug
5) cd out of the directory, at which points udisks will umount it
Then with an unpatched kernel I hit the BUG() at step 5, and with
a kernel with the BUG() removed I get the following debug trace:
[ 9089.808021] scsi/hosts.c: scsi_host_dev_release bqt ffff88022c02ae40
[ 9089.808040] blk-tag.c: blk_free_tags bqt ffff88022c02ae40
[ 9089.808041] blk-tag.c: __blk_free_tags refcnt before dec: 2
[ 9089.808046] blk-sysfs.c: blk_release_queue queue_tags ffff88022c02ae40
[ 9089.808057] blk-tag.c: __blk_queue_free_tags bqt ffff88022c02ae40
[ 9089.808058] blk-tag.c: __blk_free_tags refcnt before dec: 1
[ 9089.808059] blk-tag.c: __blk_free_tags free-ed: ffff88022c02ae40
Notice how in this case scsi_host_dev_release() runs before
blk_release_queue(), breaking the assumption the BUG() tests for.
I think this may be caused by userspace holding a reference to the
kobj which has blk_release_queue as release callback when doing the
umount. But I simply don't know the code in question well enough to do
a more detailed analysis of the problem.
A naive fix, which seems to work, would be to simply remove the BUG()
but I'm not sure if that is the right solution...
Regards,
Hans
next reply other threads:[~2013-11-14 11:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 11:09 Hans de Goede [this message]
2013-12-13 20:32 ` blk-tag.c: 89 BUG() triggering + initial analysis James Bottomley
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=5284AF58.5070901@redhat.com \
--to=hdegoede@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=sarah.a.sharp@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).