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

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

On 4/30/2026 10:43 AM, Martin K. Petersen wrote:
> 
> 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?
> 
I've gone through SBC and SPC, and I can't find anything that would 
suggest that this is a spec violation.

And, not that what I think makes any difference, but I don't see the 
point in requiring an initiator to check DPOFUA before setting FUA on a 
write that needs to go straight to media... why not just set FUA 
whenever needed, and if the FUA bit wasn't strictly required to ensure 
that the write went straight to media, who cares, if the requested 
behavior is still provided?

> Also, wrt. the patch itself, please see:
> 
> https://sashiko.dev/#/patchset/20260428203938.9738-1-stuart.w.hayes%40gmail.com
> 
The AI review suggests moving this fix to sbc_check_dpofua(), so that 
DPOFUA behavior in the mode page is unchanged, and it just silently 
allows writes with FUA set even if DPOFUA isn't set.

If there's no objection, I'll submit a new patch that does that. The 
reason I didn't do that the first time around is that it breaks some of 
the blktests that specifically check to make sure a command fails if FUA 
is set when DPOFUA isn't.