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

[sashiko-bot@kernel.org]

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