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]
Message-ID: <20200409012430.GC369792@localhost.localdomain>
Date:   Thu, 9 Apr 2020 09:24:30 +0800
From:   Ming Lei <ming.lei@...hat.com>
To:     Douglas Anderson <dianders@...omium.org>
Cc:     axboe@...nel.dk, jejb@...ux.ibm.com, martin.petersen@...cle.com,
        paolo.valente@...aro.org, groeck@...omium.org,
        Gwendal Grignou <gwendal@...omium.org>,
        linux-scsi@...r.kernel.org, linux-block@...r.kernel.org,
        sqazi@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 4/4] Revert "scsi: core: run queue if SCSI device
 queue isn't ready and queue is idle"

On Wed, Apr 08, 2020 at 08:04:02AM -0700, Douglas Anderson wrote:
> This reverts commit 7e70aa789d4a0c89dbfbd2c8a974a4df717475ec.
> 
> Now that we have the patches ("blk-mq: In blk_mq_dispatch_rq_list()
> "no budget" is a reason to kick") and ("blk-mq: Rerun dispatching in
> the case of budget contention") we should no longer need the fix in
> the SCSI code.  Revert it, resolving conflicts with other patches that
> have touched this code.
> 
> With this revert (and the two new patches) I can run the script that
> was in commit 7e70aa789d4a ("scsi: core: run queue if SCSI device
> queue isn't ready and queue is idle") in a loop with no failure.  If I
> do this revert without the two new patches I can easily get a failure.
> 
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> ---
> I don't know for sure that we can revert this patch, but in the very
> least the original test case now passes.  If there is any question
> about this, we can just drop this patch.

I think it is safe to revert this patch.

This patch should have been one workaround in case of dispatch from hctx->dispatch,
since there is one race. When dispatch from scheduler queue, any
IO completion will re-run all hctxs, so no need to do the trick.

Reviewed-by: Ming Lei <ming.lei@...hat.com>


thanks,
Ming

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ