Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Kiwoong Kim" <kwmad.kim@samsung.com>
To:     "'Bart Van Assche'" <bvanassche@acm.org>,
        <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <alim.akhtar@samsung.com>, <avri.altman@wdc.com>,
        <jejb@linux.ibm.com>, <martin.petersen@oracle.com>,
        <beanhuo@micron.com>, <cang@codeaurora.org>,
        <adrian.hunter@intel.com>, <sc.suh@samsung.com>,
        <hy50.seo@samsung.com>, <sh425.lee@samsung.com>,
        <bhoon95.kim@samsung.com>
In-Reply-To: <baf17040-70e8-d850-30cd-74944e41285d@acm.org>
Subject: RE: [PATCH v2 3/3] scsi: ufs: ufs-exynos: implement exynos isr
Date:   Tue, 14 Sep 2021 14:12:41 +0900
Message-ID: <000001d7a927$252e77e0$6f8b67a0$@samsung.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQFyn/7MkbxYHt33UvraYb1f3WYrLgHrEvTlAh5z/LMCMoADnqw7Jm5w
Content-Language: ko
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 102P
DLP-Filter: Pass
References: <cover.1631519695.git.kwmad.kim@samsung.com>
        <CGME20210913081152epcas2p2eac4a8dbef33164a150dccf2e282dcce@epcas2p2.samsung.com>
        <746e059782953fca6c21945297151d2bb73d3370.1631519695.git.kwmad.kim@samsung.com>
        <baf17040-70e8-d850-30cd-74944e41285d@acm.org>
Precedence: bulk

> On 9/13/21 12:55 AM, Kiwoong Kim wrote:
> > This patch is to raise recovery in some abnormal conditions using an
> > vendor specific interrupt for some cases, such as a situation that
> > some contexts of a pending request in the host isn't the same with
> > those of its corresponding UPIUs if they should have been the same
> > exactly.
> >
> > The representative case is shown like below.
> > In the case, a broken UTRD entry, for internal coherent problem or
> > whatever, that had smaller value of PRDT length than expected was
> > transferred to the host.
> > So, the host raised an interrupt of transfer complete even if device
> > didn't finish its data transfer because the host sees a fetched
> > version of UTRD to determine if data tranfer is over or not. Then the
> > application level seemed to recogize this as a sort of corruption and
> > this symptom led to boot failure.
>=20
> How can a UTRD entry be broken? Does that perhaps indicate memory
> corruption at the host side? Working around host-side memory corruption i=
n
> a driver seems wrong to me. I think the root cause of the memory
> corruption should be fixed.

For SoC internal problems, yes, of course, they should be fixed.
But I don't think the causes always come from inside the system.
They could be outside the system or a device, such as sending DATA IN
with a tag that a host has ever submitted a command with because of
some bugs of the device. You might think putting this sort of code doesn't
make sense but there could be various events that can't be understood in th=
e
point of view of the spec. And chips that is already fab-outed can't be fix=
ed.
That's why I put the details into Exynos. I'm not talking about the spec.
I think Exynos isn't required to contain only things related with the spec
and it can have realistic part.

>=20
> > +static irqreturn_t exynos_ufs_isr(struct ufs_hba *hba) =7B
> > +	struct exynos_ufs *ufs =3D ufshcd_get_variant(hba);
> > +	u32 status;
> > +	unsigned long flags;
> > +
> > +	if (=21hba->priv) return IRQ_HANDLED;
>=20
> Please verify patches with checkpatch before posting these on the linux-
> scsi mailing list. The above if-statement does not follow the Linux kerne=
l
> coding style.
>=20
> > +	if (status & RX_UPIU_HIT_ERROR) =7B
> > +		pr_err(=22%s: status: 0x%08x=5Cn=22, __func__, status);
> > +		hba->force_reset =3D true;
> > +		hba->force_requeue =3D true;
> > +		scsi_schedule_eh(hba->host);
> > +		spin_unlock_irqrestore(hba->host->host_lock, flags);
> > +		return IRQ_HANDLED;
> > +	=7D
> > +	return IRQ_NONE;
> > +=7D
>=20
> So the above code unlocks the host_lock depending on whether or not statu=
s
> & RX_UPIU_HIT_ERROR is true? Yikes ...
>=20
> Additionally, in the above code I found the following pattern:
>=20
> 	unsigned long flags;
> 	=5B ... =5D
> 	spin_unlock_irqrestore(hba->host->host_lock, flags);
>=20
> Such code is ALWAYS wrong. The value of the 'flags' argument passed to
> spin_unlock_irqrestore() must come from spin_lock_irqsave().
>=20
> Bart.

I missed for two things. Thanks, I'll look more carefully.