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:
 <SA2PR16MB4251343F5F595B101950F5E8F4A62@SA2PR16MB4251.namprd16.prod.outlook.com>
Date: Wed, 26 Mar 2025 07:30:17 +0000
From: Arthur Simchaev <Arthur.Simchaev@...disk.com>
To: "Bao D. Nguyen" <quic_nguyenb@...cinc.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

> 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.
If you think the structure should be packaged, you can fix "struct utp_upiu_query" and 
"struct utp_upiu_query_v4_0".

Regards
Arthur

> -----Original Message-----
> From: Bao D. Nguyen <quic_nguyenb@...cinc.com>
> Sent: Wednesday, March 26, 2025 12:16 AM
> To: Arthur Simchaev <Arthur.Simchaev@...disk.com>;
> quic_cang@...cinc.com; quic_nitirawa@...cinc.com; bvanassche@....org;
> avri.altman@....com; peter.wang@...iatek.com;
> manivannan.sadhasivam@...aro.org; minwoo.im@...sung.com;
> adrian.hunter@...el.com; martin.petersen@...cle.com
> Cc: 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/25/2025 9:33 AM, Arthur Simchaev wrote:
> > Hi Bao
> >
> > I think adding "struct utp_upiu_query_response_v4_0" is redundant and not
> correct for flags upiu response .
> > You can use "struct utp_upiu_query_v4_0"
> >
> 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.
> 
> Thanks, Bao