linux-kernel - Re: [PATCH 6/7] mpt2sas: store scsi io tracker data in the scsi command / request

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:	Tue, 7 Apr 2015 18:18:23 +0200
From:	Christoph Hellwig <hch@....de>
To:	Jens Axboe <axboe@...nel.dk>
Cc:	Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH 6/7] mpt2sas: store scsi io tracker data in the scsi
	command / request

On Tue, Apr 07, 2015 at 10:13:23AM -0600, Jens Axboe wrote:
>> The mq case will also work for the !mq case when you call
>> scsi_host_find_tag and scsi_cmd_priv.   In general all the mq-specific
>> codepathes you add should become the default and only one, even if this
>> requires a lit bit of additional core work.
>
> For the core code, I definitely agree. But for this case, in scsi-mq mode, 
> we know that tag == smid - 1. That's not the case if we are not using 
> scsi-mq.

It is if you use the old block tagging code with host-wide tags.
I guess you'll need to tell mpt2 and mpt3 to use that firs, though.

> In general, it'd be great if we could "convert" drivers and not have to 
> support both scsi-mq and legacy mode. Then I could just rip the old code.

Well, the whole point is that you should be able to write a driver like
your mq version and it should just work. Even better would be if we
could get rid of the old case entirely for scsi, but for that we need
a I/O scheduler for blk-mq first :)

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