linux-kernel - RE: [PATCH] UFS: Make TM command timeout configurable from host side

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: <000001dc53b1$540988a0$fc1c99e0$@samsung.com>
Date: Wed, 12 Nov 2025 17:49:59 +0900
From: "Seunghui Lee" <sh043.lee@...sung.com>
To: 'Peter Wang (王信友)'
	<peter.wang@...iatek.com>, <beanhuo@...ron.com>, <avri.altman@....com>,
	<storage.sec@...sung.com>, <linux-scsi@...r.kernel.org>,
	<bvanassche@....org>, <linux-kernel@...r.kernel.org>,
	<alim.akhtar@...sung.com>, <adrian.hunter@...el.com>,
	<martin.petersen@...cle.com>
Subject: RE: [PATCH] UFS: Make TM command timeout configurable from host
 side

> -----Original Message-----
> From: Peter Wang (王信友) <peter.wang@...iatek.com>
> Sent: Wednesday, November 12, 2025 11:58 AM
> To: beanhuo@...ron.com; sh043.lee@...sung.com; avri.altman@....com;
> storage.sec@...sung.com; linux-scsi@...r.kernel.org; bvanassche@....org;
> linux-kernel@...r.kernel.org; alim.akhtar@...sung.com;
> adrian.hunter@...el.com; martin.petersen@...cle.com
> Subject: Re: [PATCH] UFS: Make TM command timeout configurable from host
> side
> 
> On Tue, 2025-11-11 at 08:37 -0800, Bart Van Assche wrote:
> >
> > Why a quirk? A quirk will select a single specific timeout. The
> > approach of this patch lets the host driver set the timeout. This
> > seems more flexible to me than introducing a new quirk. Additionally,
> > I think this is a better solution than a new kernel module parameter.
> >
> > Thanks,
> >
> > Bart.
> 
> Hi Bart,
> 
> It is not reasonable because the timeout value does not depend on the host,
> it depends on the device. It could set a large timoeut value for those
> devices.
> 
> By the way, this patch also doesn't change any host timeout value if you
> insist that the timeout value depends on the host.
> 
> Using a module parameter is a flexible method if the customer is using a
> device that may require an extended timeout value.
> Moreover, this approach would help maintain consistency.
> Otherwise, with so many different timeouts (uic/dev/tm), it would be quite
> chaotic if each is handled in a different way.
> 
> Thanks
> Peter

Hi Peter,

Currently, the modification is about changing it in the same way as nop_out_timeout.
The tm_cmd_timeout value is not read from the device.
Also, if the UFS can read the tm_cmd_timeout value and requires a longer timeout period than the specified value, dev quirks would also be acceptable.

However, for now, it seems fine to set it on the host.
When we checked on our side, it wasn't that the tm timeout value was insufficient for specific devices, but rather some vendors needed to increase it.
We plan to appropriately increase and use it. Also, since the current modification maintains the default value and allows an appropriate value to be adjusted according to each vendor, the current method also seems acceptable.

Thank you,
Seunghui Lee.