[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 code to ignore FUA bit in commands to targets 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>
---
v1->v2:
	- change to only ignore FUA bit set when no write cache is
	  enabled, instead of advertising DPOFUA support
---
 drivers/target/target_core_sbc.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index 21f5cb86d70c..ffd2b6c9bd23 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -754,6 +754,12 @@ sbc_check_dpofua(struct se_device *dev, struct se_cmd *cmd, unsigned char *cdb)
 	}
 	if (cdb[1] & 0x8) {
 		if (!target_check_fua(dev)) {
+			/*
+			 * Silently ignore FUA if there's no write cache.
+			 */
+			if (!target_check_wce(dev))
+				return 0;
+
 			pr_err("Got CDB: 0x%02x with FUA bit set, but device"
 			       " does not advertise support for FUA write\n",
 			       cdb[0]);
-- 
2.47.3

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Silently dropping the FUA bit when WCE=0 prevents the backend from honoring the FUA request, causing silent data loss in the fileio AIO backend.
--

commit 5cb17faff566c1313276f5a67af675e43649d8d6
Author: Stuart Hayes <stuart.w.hayes@gmail.com>

scsi: target: Allow FUA if no write cache enabled

This commit modifies the target core code to ignore the FUA bit in SCSI
commands for targets without an enabled write cache. This allows systems
with firmware that aggressively sets the FUA bit to successfully boot
without failing due to unsupported FUA write errors.

> diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
> index 21f5cb86d70c0..ffd2b6c9bd231 100644
> --- a/drivers/target/target_core_sbc.c
> +++ b/drivers/target/target_core_sbc.c
> @@ -754,6 +754,12 @@ sbc_check_dpofua(struct se_device *dev, struct se_cmd *cmd, unsigned char *cdb)
>  	}
>  	if (cdb[1] & 0x8) {
>  		if (!target_check_fua(dev)) {
> +			/*
> +			 * Silently ignore FUA if there's no write cache.
> +			 */
> +			if (!target_check_wce(dev))
> +				return 0;
> +

[Severity: Critical]
Does returning early here prevent the command from receiving the SCF_FUA flag?

By returning 0, this bypasses the cmd->se_cmd_flags |= SCF_FUA; assignment
that happens further down in sbc_check_dpofua().

While WCE=0 implies no write cache, the fileio AIO backend relies entirely
on the SCF_FUA flag to ensure synchronous writes:

drivers/target/target_core_file.c:fd_execute_rw_aio() {
...
	aio_cmd->iocb.ki_flags = IOCB_DIRECT;

	if (is_write && (cmd->se_cmd_flags & SCF_FUA))
		aio_cmd->iocb.ki_flags |= IOCB_DSYNC;
...
}

Without the SCF_FUA flag, fd_execute_rw_aio() will issue asynchronous
writes without flushing the cache, as it ignores the O_DSYNC flag set on
the underlying file descriptor.

Could this regression lead to silent data loss on power failure, since
what used to be rejected as an unsupported FUA write will now complete
asynchronously without a disk cache flush?

>  			pr_err("Got CDB: 0x%02x with FUA bit set, but device"
>  			       " does not advertise support for FUA write\n",
>  			       cdb[0]);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609202156.90700-1-stuart.w.hayes@gmail.com?part=1

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

[stuart hayes]

On 6/9/2026 3:39 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] Silently dropping the FUA bit when WCE=0 prevents the backend from honoring the FUA request, causing silent data loss in the fileio AIO backend.
> --
> 
> commit 5cb17faff566c1313276f5a67af675e43649d8d6
> Author: Stuart Hayes <stuart.w.hayes@gmail.com>
> 
> scsi: target: Allow FUA if no write cache enabled
> 
> This commit modifies the target core code to ignore the FUA bit in SCSI
> commands for targets without an enabled write cache. This allows systems
> with firmware that aggressively sets the FUA bit to successfully boot
> without failing due to unsupported FUA write errors.
> 
>> diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
>> index 21f5cb86d70c0..ffd2b6c9bd231 100644
>> --- a/drivers/target/target_core_sbc.c
>> +++ b/drivers/target/target_core_sbc.c
>> @@ -754,6 +754,12 @@ sbc_check_dpofua(struct se_device *dev, struct se_cmd *cmd, unsigned char *cdb)
>>   	}
>>   	if (cdb[1] & 0x8) {
>>   		if (!target_check_fua(dev)) {
>> +			/*
>> +			 * Silently ignore FUA if there's no write cache.
>> +			 */
>> +			if (!target_check_wce(dev))
>> +				return 0;
>> +
> 
> [Severity: Critical]
> Does returning early here prevent the command from receiving the SCF_FUA flag?
> 
> By returning 0, this bypasses the cmd->se_cmd_flags |= SCF_FUA; assignment
> that happens further down in sbc_check_dpofua().
> 
> While WCE=0 implies no write cache, the fileio AIO backend relies entirely
> on the SCF_FUA flag to ensure synchronous writes:
> 
> drivers/target/target_core_file.c:fd_execute_rw_aio() {
> ...
> 	aio_cmd->iocb.ki_flags = IOCB_DIRECT;
> 
> 	if (is_write && (cmd->se_cmd_flags & SCF_FUA))
> 		aio_cmd->iocb.ki_flags |= IOCB_DSYNC;
> ...
> }
> 
> Without the SCF_FUA flag, fd_execute_rw_aio() will issue asynchronous
> writes without flushing the cache, as it ignores the O_DSYNC flag set on
> the underlying file descriptor.
> 
> Could this regression lead to silent data loss on power failure, since
> what used to be rejected as an unsupported FUA write will now complete
> asynchronously without a disk cache flush?
> 

Valid point, yes. I will fix.

Also, I accidentally submitted this as V2 when it should have been V3, 
sorry.

>>   			pr_err("Got CDB: 0x%02x with FUA bit set, but device"
>>   			       " does not advertise support for FUA write\n",
>>   			       cdb[0]);
> 

[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

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

[stuart hayes]

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.