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

[stuart hayes <stuart.w.hayes@gmail.com>]

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]);
>