linux-kernel - Re: SCSI TMF processing; tag allocation

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:	Mon, 15 Nov 2010 10:28:04 +0100
From:	Jens Axboe <jaxboe@...ionio.com>
To:	Matthew Wilcox <matthew@....cx>
CC:	Luben Tuikov <ltuikov@...oo.com>, Greg KH <greg@...ah.com>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tj@...nel.org" <tj@...nel.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>
Subject: Re: SCSI TMF processing; tag allocation

>> Third, and most importantly, tags should form an increasing sequence and should not be reused until all other tags after it and before it have been reused. This for example can be accomplished if one were to use
>> find_next_zero_bit() with non-zero "offset", it being the last allocated
>> tag in a modulo the number of tags manner. That is, find_next_zero_bit()
>> could wrap as well as starting from an offset or the caller could implement
>> that via two calls to this function, in blk_queue_start_tag().

Care to explain your reasoning? For starvation issues? At least I'm not
aware of any correctness issues in that regard, but doing tag cycling in
this fashion seems like a good idea just to prevent starvation alone by
an ill behaving device.

-- 
Jens Axboe

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