linux-kernel - Re: [PATCH v4 1/1] scsi: ufs: core: add device level exception support

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: <d1989803-9573-0458-c9e3-93d04846f664@quicinc.com>
Date: Wed, 26 Mar 2025 16:28:02 -0700
From: "Bao D. Nguyen" <quic_nguyenb@...cinc.com>
To: Arthur Simchaev <Arthur.Simchaev@...disk.com>,
        "quic_cang@...cinc.com"
	<quic_cang@...cinc.com>,
        "quic_nitirawa@...cinc.com"
	<quic_nitirawa@...cinc.com>,
        "bvanassche@....org" <bvanassche@....org>,
        "avri.altman@....com" <avri.altman@....com>,
        "peter.wang@...iatek.com"
	<peter.wang@...iatek.com>,
        "manivannan.sadhasivam@...aro.org"
	<manivannan.sadhasivam@...aro.org>,
        "minwoo.im@...sung.com"
	<minwoo.im@...sung.com>,
        "adrian.hunter@...el.com" <adrian.hunter@...el.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>
CC: "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        Alim Akhtar
	<alim.akhtar@...sung.com>,
        "James E.J. Bottomley"
	<James.Bottomley@...senPartnership.com>,
        Matthias Brugger
	<matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno
	<angelogioacchino.delregno@...labora.com>,
        Bean Huo <beanhuo@...ron.com>,
        Keoseong Park <keosung.park@...sung.com>,
        Ziqi Chen
	<quic_ziqichen@...cinc.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "Gwendal
 Grignou" <gwendal@...omium.org>,
        Eric Biggers <ebiggers@...gle.com>,
        open
 list <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/Mediatek SoC
 support:Keyword:mediatek" <linux-arm-kernel@...ts.infradead.org>,
        "moderated
 list:ARM/Mediatek SoC support:Keyword:mediatek"
	<linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH v4 1/1] scsi: ufs: core: add device level exception
 support

On 3/26/2025 12:30 AM, Arthur Simchaev wrote:
>> Hi Arthur,
>> This is not a flags attribute. This is for a Query Read 64-bit Attribute data. In
>> the existing code, we do not have a read 64-bit attribute, so adding this new
>> code would also allow future re-use.
>>
>> The new "struct utp_upiu_query_response_v4_0" would improve readability
>> because it is formatted exactly as how the jedec standard defines for Attribute
>> Read. We won't need to use type cast to get the 64-bit value.
>> There would be no issue with efficiency because the same machine code
>> would be generated.
>>
>> The existing "struct utp_upiu_query_v4_0" probably has a bug in it. It does
>> not use the  __attribute__((__packed__)) attribute. The compiler is free to add
>> padding in this structure, resulting in the read attribute value being incorrect. I
>> plan to provide a separate patch to fix this issue.
> 
> Hi Bao
> 
> Upiu_query can be used for all device management command (descriptions, attributes, flags)
> See section 10.7.9 UPIU QUERY RESPONSE in the UFS 4.1 specification.
> If "struct utp_upiu_query" was properly defined, according to the UFS specification  (by OSF's),
> we would not need to add additional "struct utp_upiu_query_v4_0" structures.
Section 10.7.9 of the device spec v4.0 and v4.1 define the QUERY 
RESPONSE mostly as OSFs (Opcode Specific Field). If the driver used OSFs 
as defined by section 10.7.9, it would not be very readable. Instead, 
the driver tries its best to map these OSFs to meaningful names 
depending on the type of the QUERY command. In my opinion, there is a 
good reason to introduce "struct utp_upiu_query_v4_0". For example, in 
the spec v4.0, Write Attribute only supports up to 32-bit attribute 
size. However, v4.1 supports up to  64-bit attribute size. The "struct 
utp_upiu_query_v4_0" renamed the "__be16 reserved_osf" to "__u8 osf3" 
and "__u8 osf4" which would be better for code readability.

> If you think the structure should be packaged, you can fix "struct utp_upiu_query" and
> "struct utp_upiu_query_v4_0".
That's a fair request. I would like to fix it in a separate patch if 
that works.

Thanks, Bao