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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ