[PATCH v2] scsi: target: Allow FUA if no write cache enabled

[PATCH v2] scsi: target: Allow FUA if no write cache enabled

[Stuart Hayes]

Modify target_check_fua() to allow FUA support for devices with no write
cache enabled.

Without this patch, accesses with FUA set will be rejected, even though
they always go directly to the media when there's no write cache.

This is needed because EDK2 FAT filesystem code sets the FUA bit when
writing, regardless of whether the device advertises support of DPOFUA. If
a UEFI pre-boot write fails, the filesystem can become inaccessible until a
reboot.  This can cause linux installs to iSCSI to be unbootable, because
some systems have firmware that will try to write a file in a
vendor-specific directory under /boot/EFI (such as /boot/EFI/Dell) before
attempting to boot to a UEFI boot entry pointing to a file in the FAT
filesystem.

Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
---
v2: rebased to latest upstream

 drivers/target/target_core_transport.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index fad03a15c969..0e07b224c4d0 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -3722,5 +3722,6 @@ target_check_wce(struct se_device *dev)
 bool
 target_check_fua(struct se_device *dev)
 {
-	return target_check_wce(dev) && dev->dev_attrib.emulate_fua_write > 0;
+	/* Allow FUA if there's no write cache */
+	return target_check_wce(dev) ? dev->dev_attrib.emulate_fua_write > 0 : 1;
 }
-- 
2.47.3

Re: [PATCH v2] scsi: target: Allow FUA if no write cache enabled

[Martin K. Petersen]

Stuart,

> Without this patch, accesses with FUA set will be rejected, even
> though they always go directly to the media when there's no write
> cache.

The spec allows this. However, ...

> This is needed because EDK2 FAT filesystem code sets the FUA bit when
> writing, regardless of whether the device advertises support of
> DPOFUA.

^^^ that is clearly a spec violation. What is being done to address this
issue?

Also, wrt. the patch itself, please see:

https://sashiko.dev/#/patchset/20260428203938.9738-1-stuart.w.hayes%40gmail.com

-- 
Martin K. Petersen