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 for Android: free password hash cracker in your pocket

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

Message-ID: <c1f69239-b289-455f-b1b4-89fd3a6ddcee@acm.org>
Date: Mon, 17 Nov 2025 08:40:59 -0800
From: Bart Van Assche <bvanassche@....org>
To: Hannes Reinecke <hare@...e.de>, Peter Wang (王信友) <peter.wang@...iatek.com>,
 "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "martin.petersen@...cle.com" <martin.petersen@...cle.com>
Subject: Re: [PATCH] UFS: Make TM command timeout configurable from host side

On 11/13/25 2:08 AM, Peter Wang (王信友) wrote:
> In the worst-case scenario (when the device is stuck), it
> may takes 1.1 seconds to abort a single task. When the queue is
> full (64), there will be noticeable lag. Aborting all
> tasks can take over a minute, which is unacceptable regardless
> of whether TM_CMD_TIMEOUT is increased or not. Under normal
> conditions, it’s very unlikely to exceed 100ms. So I think
> directly modifying TM_CMD_TIMEOUT is also acceptable,
> but I suggest keeping it within 500ms.
Hi Peter,

Aborting different commands should happen concurrently rather than
sequentially. See also the queue_delayed_work() call in the SCSI core
scsi_abort_command() function:

queue_delayed_work(shost->tmf_work_q, &scmd->abort_work, HZ / 100);

Unfortunately the max_active argument is set to 1 in the call that 
creates tmf_work_q:

shost->tmf_work_q = alloc_workqueue("scsi_tmf_%d",
				WQ_UNBOUND | WQ_MEM_RECLAIM | WQ_SYSFS,
				   1, shost->host_no);

Hannes, do you agree with increasing the max_active argument from 1 to
INT_MAX? I think the above code was introduced 12 years ago by commit
e494f6a72839 ("[SCSI] improved eh timeout handler").

Thanks,

Bart.