linux-kernel - Re: [PATCH 2/2] scsi: ufs: Document NOP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <74b7ed8e-2de3-4498-9add-5b50d010d496@acm.org>
Date: Tue, 17 Jun 2025 08:59:08 -0700
From: Bart Van Assche <bvanassche@....org>
To: Avri Altman <avri.altman@...disk.com>,
 "Martin K . Petersen" <martin.petersen@...cle.com>
Cc: linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] scsi: ufs: Document NOP_OUT transaction code

On 6/17/25 2:56 AM, Avri Altman wrote:
> UPIU_TRANSACTION_NOP_OUT is 0x0, which is the default value after
> memset. Comment out the explicit assignment and leave it as
> documentation.

This description is based on the assumption that the compiler only
initializes the data structure members that have been mentioned 
explicitly. That is wrong. There is no partial initialization in the
C programming language. Structure members that have not been mentioned
explicitly are zero-initialized. All structure members, including those
that have not been mentioned explicitly, are copied when performing
structure assignment.

> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index c2048aca09fc..84165b45467d 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -2835,7 +2835,7 @@ static inline void ufshcd_prepare_utp_nop_upiu(struct ufshcd_lrb *lrbp)
>   	memset(ucd_req_ptr, 0, sizeof(struct utp_upiu_req));
>   
>   	ucd_req_ptr->header = (struct utp_upiu_header){
> -		.transaction_code = UPIU_TRANSACTION_NOP_OUT,
> +		/* .transaction_code = UPIU_TRANSACTION_NOP_OUT = 0x0, */
>   		.task_tag = lrbp->task_tag,
>   	};
>   }

This patch probably doesn't change the generated assembly code. So I
don't think that it is useful.

Bart.