linux-kernel - Re: [PATCH] ublk: don't quiesce in ublk_ch

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]

Message-Id: <175492090390.697940.8796642091342962699.b4-ty@kernel.dk>
Date: Mon, 11 Aug 2025 08:01:43 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Ming Lei <ming.lei@...hat.com>, 
 Caleb Sander Mateos <csander@...estorage.com>, 
 Uday Shankar <ushankar@...estorage.com>
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ublk: don't quiesce in ublk_ch_release


On Fri, 08 Aug 2025 15:44:43 -0600, Uday Shankar wrote:
> ublk_ch_release currently quiesces the device's request_queue while
> setting force_abort/fail_io.  This avoids data races by preventing
> concurrent reads from the I/O path, but is not strictly needed - at this
> point, canceling is already set and guaranteed to be observed by any
> concurrently executing I/Os, so they will be handled properly even if
> the changes to force_abort/fail_io propagate to the I/O path later.
> Remove the quiesce/unquiesce calls from ublk_ch_release. This makes the
> writes to force_abort/fail_io concurrent with the reads in the I/O path,
> so make the accesses atomic.
> 
> [...]

Applied, thanks!

[1/1] ublk: don't quiesce in ublk_ch_release
      commit: 212c928d01e9ea1d1c46a114650b551da8ca823e

Best regards,
-- 
Jens Axboe