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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Tue, 15 Dec 2020 11:11:06 -0800
From:   Andres Freund <andres@...razel.de>
To:     Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Allow use of fua to be disabled on per-device basis?

Hi,

I have a few Samsung NVMe SSDs where FUA (i.e. REQ_FUA) is a slower than
full device cache flushes (i.e. REQ_PREFLUSH). I would like to be able
to disable use of FUA for those.

As a first step, would it make sense to add write support to
/sys/block/*/queue/fua?

The biggest issue with that is that it seems like it'd be preferrable to
only allow enabling fua if the underlying device supports that, and that
that information isn't currently stored anywhere but QUEUE_FLAG_FUA.

The easiest way to deal with that would be to split QUEUE_FLAG_FUA into
QUEUE_FLAG_FUA_HW and QUEUE_FLAG_FUA_ENABLED, and have
blk_queue_write_cache() set QUEUE_FLAG_FUA_ENABLED to
QUEUE_FLAG_FUA_HW. Then the new blk-sysfs.c queue_fua_set() would only
allow setting QUEUE_FLAG_FUA_ENABLED if QUEUE_FLAG_FUA_HW is availabl.e

Does that roughly make sense?


In a second step it could be reasonable to add an nvme quirks indicating
slow FUA for those devices? But I'll leave that for later...

Greetings,

Andres Freund

Powered by blists - more mailing lists