linux-kernel - Re: [REGRESSION 3.17] scsi (uas) disks no longer using tagged command queuing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54134E50.6040805@redhat.com>
Date:	Fri, 12 Sep 2014 21:49:36 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
CC:	linux-usb <linux-usb@...r.kernel.org>,
	SCSI development list <linux-scsi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [REGRESSION 3.17] scsi (uas) disks no longer using tagged command
 queuing

Hi,

On 09/11/2014 06:13 PM, Christoph Hellwig wrote:
> On Thu, Sep 11, 2014 at 12:01:13PM +0200, Hans de Goede wrote:
>>> So we're initializing the tag map, but scsi_activate_tcq doesn't pick it
>>> up.  I can't really come up with a good explanation for it, but there
>>> even without that there is an elephant in the room:  as part of the
>>> scsi-mq series I moved the bqt field used for this into a union with the
>>> new blk_mq_tag_set.  Below is a patch to get rid of that union, can you
>>> try if that fixes it?
>>
>> Unfortunately that does not fix it :|
> 
> Alright, I guess we need the big bisect hammer unfortunately.
> 
> We should be able to start with trying the first and last commit
> of the big SCSI merge:
> 
>  start:		fcc95a763444017288b318d48367098850c23c0d
>  end:		c21a2c1a4973c8dde32557970fdb44eaa9489aeb

The bisect points to:

[hans@...lem linux]$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[d285203cf647d7c97db3a1c33794315c9008593f] scsi: add support for a blk-mq
based I/O path.

I've double checked that that commit is bad, and one commit earlier in the
history is good, so that really is the one.

I've tried again to fix the union thing you spotted, which is introduced
by that commit, and again it does not help.

I've taken a quick look at the commit, and my guess with be this has
something to do with the changes surrounding __scsi_alloc_queue .

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/