linux-kernel - Re: Device or HBA level QD throttling creates randomness in sequetial workload

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 for Android: free password hash cracker in your pocket

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

Message-ID: <22a9792c-098d-eb8d-b7d4-87a79cf1d31f@kernel.dk>
Date:   Mon, 30 Jan 2017 09:32:33 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Bart Van Assche <Bart.VanAssche@...disk.com>,
        "osandov@...ndov.com" <osandov@...ndov.com>,
        "kashyap.desai@...adcom.com" <kashyap.desai@...adcom.com>
Cc:     "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "hch@...radead.org" <hch@...radead.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "paolo.valente@...aro.org" <paolo.valente@...aro.org>
Subject: Re: Device or HBA level QD throttling creates randomness in sequetial
 workload

On 01/30/2017 09:30 AM, Bart Van Assche wrote:
> On Mon, 2017-01-30 at 19:22 +0530, Kashyap Desai wrote:
>> -   if (atomic_inc_return(&instance->fw_outstanding) >
>> -           instance->host->can_queue) {
>> -       atomic_dec(&instance->fw_outstanding);
>> -       return SCSI_MLQUEUE_HOST_BUSY;
>> -   }
>> +   if (atomic_inc_return(&instance->fw_outstanding) > safe_can_queue) {
>> +       is_nonrot = blk_queue_nonrot(scmd->device->request_queue);
>> +       /* For rotational device wait for sometime to get fusion command
>> from pool.
>> +        * This is just to reduce proactive re-queue at mid layer which is
>> not
>> +        * sending sorted IO in SCSI.MQ mode.
>> +        */
>> +       if (!is_nonrot)
>> +           udelay(100);
>> +   }
> 
> The SCSI core does not allow to sleep inside the queuecommand() callback
> function.

udelay() is a busy loop, so it's not sleeping. That said, it's obviously
NOT a great idea. We want to fix the reordering due to requeues, not
introduce random busy delays to work around it.

-- 
Jens Axboe