linux-kernel - Re: [PATCH 1/1] scsi: ufs: core: Fix EH failure after wlun resume error

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] [day] [month] [year] [list]

Message-ID: <c4bd6532b003089fedf518db878a3843c516217c.camel@mediatek.com>
Date: Thu, 13 Nov 2025 10:06:15 +0000
From: Peter Wang (王信友) <peter.wang@...iatek.com>
To: "powenkao@...gle.com" <powenkao@...gle.com>
CC: "beanhuo@...ron.com" <beanhuo@...ron.com>, "avri.altman@....com"
	<avri.altman@....com>, "quic_nguyenb@...cinc.com" <quic_nguyenb@...cinc.com>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"bvanassche@....org" <bvanassche@....org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "alim.akhtar@...sung.com"
	<alim.akhtar@...sung.com>, "adrian.hunter@...el.com"
	<adrian.hunter@...el.com>, "mani@...nel.org" <mani@...nel.org>,
	"James.Bottomley@...senpartnership.com"
	<James.Bottomley@...senpartnership.com>, "martin.petersen@...cle.com"
	<martin.petersen@...cle.com>
Subject: Re: [PATCH 1/1] scsi: ufs: core: Fix EH failure after wlun resume
 error

On Wed, 2025-11-12 at 17:18 +0800, Brian Kao wrote:
> This log actually is triggered by fault injection when wlun is
> suspended
> echo 0xf > /sys/kernel/debug/ufshcd/3c2d0000.ufs/saved_uic_err
> 
> In a real-world scenario, this situation can occur when an error
> interrupt calls `ufshcd_check_errors()`, which schedules the error
> handler before the system reaches `ufshcd_set_dev_pwr_mode()`.

Hi Brian,

When ufshcd_suspend is called, it disables IRQs by calling
ufshcd_disable_irq. So, in a real-world scenario, it should
not be possible for the UFS to be suspended and the error
handler work to be triggered by an IRQ.

Fault injection using saved_uic_err could create this situation,
but if this cannot happen in reality, we should consider whether
this is a reasonable test case? If it is, then I think this patch
looks good to me. If not, maybe we should get the runtime PM state
in the fault injection and remove this redundant recovery code.
What do you think?

Thanks
Peter