linux-kernel - Re: [PATCH] scsi_execute_async() should add to the tail of the queue

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] [day] [month] [year] [list]

Date:	Thu, 21 Dec 2006 09:12:19 +0200
From:	Dan Aloni <da-x@...atomic.org>
To:	Steven Hayter <steven@...ter.me.uk>
CC:	Linux Kernel List <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org, Mike Christie <michaelc@...wisc.edu>,
	James.Bottomley@...eleye.com
Subject: Re: [PATCH] scsi_execute_async() should add to the tail of the queue

Steven Hayter wrote:
> Dan Aloni wrote:
>> Hello,
>>
>> scsi_execute_async() has replaced scsi_do_req() a few versions ago, 
>> but it also incurred a change of behavior. I noticed that 
>> over-queuing a SCSI device using that function causes I/Os to be 
>> starved from low-level queuing for no justified reason.
>>  
>> I think it makes much more sense to perserve the original behaviour 
>> of scsi_do_req() and add the request to the tail of the queue.
>
> As far as I'm aware the way in which scsi_do_req() was to insert at 
> the head of the queue, leading to projects like SCST to come up with 
> scsi_do_req_fifo() as queuing multiple commands using scsi_do_req() 
> with constant head insertion might lead to out of order execution.
>
> Just thought I'd throw some light on the history and what others have 
> done in the past.
>
In Linux 2.4.31 scsi_do_req() still inserts at the tail. This was also 
valid until 2.6.5.
James, is the change you inserted in Linux 2.6.5 still relevant in 2.6 
today?

<James.Bottomley@...eleye.com>
        [PATCH] add device quiescing to the SCSI API
       
        This patch adds the ability to quiesce a SCSI device.  The idea 
is that
        user issued commands (including filesystem ones) would get blocked,
        while mid-layer and device issued ones would be allowed to proceed.
        This is for things like Domain Validation which like to operate 
on an
        otherwise quiet device.
       
        There is one big change: to get all of this to happen correctly,
        scsi_do_req() has to queue on the *head* of the request queue, 
not the
        tail as it was doing previously.  The reason is that deferred 
requests
        block the queue, so anything needing executing after a deferred 
request
        has to go in front of it.  I don't think there are any untoward
        consequences of this.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il

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