All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Kiwoong Kim <kwmad.kim@samsung.com>,
	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
Subject: Re: [PATCH v2 3/3] scsi: ufs: ufs-exynos: implement exynos isr
Date: Mon, 13 Sep 2021 09:23:07 -0700	[thread overview]
Message-ID: <baf17040-70e8-d850-30cd-74944e41285d@acm.org> (raw)
In-Reply-To: <746e059782953fca6c21945297151d2bb73d3370.1631519695.git.kwmad.kim@samsung.com>

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.

How can a UTRD entry be broken? Does that perhaps indicate memory
corruption at the host side? Working around host-side memory
corruption in a driver seems wrong to me. I think the root cause
of the memory corruption should be fixed.

> +static irqreturn_t exynos_ufs_isr(struct ufs_hba *hba)
> +{
> +	struct exynos_ufs *ufs = ufshcd_get_variant(hba);
> +	u32 status;
> +	unsigned long flags;
> +
> +	if (!hba->priv) return IRQ_HANDLED;

Please verify patches with checkpatch before posting these on the
linux-scsi mailing list. The above if-statement does not follow the
Linux kernel coding style.

> +	if (status & RX_UPIU_HIT_ERROR) {
> +		pr_err("%s: status: 0x%08x\n", __func__, status);
> +		hba->force_reset = true;
> +		hba->force_requeue = true;
> +		scsi_schedule_eh(hba->host);
> +		spin_unlock_irqrestore(hba->host->host_lock, flags);
> +		return IRQ_HANDLED;
> +	}
> +	return IRQ_NONE;
> +}

So the above code unlocks the host_lock depending on whether or not
status & RX_UPIU_HIT_ERROR is true? Yikes ...

Additionally, in the above code I found the following pattern:

	unsigned long flags;
	[ ... ]
	spin_unlock_irqrestore(hba->host->host_lock, flags);

Such code is ALWAYS wrong. The value of the 'flags' argument passed to
spin_unlock_irqrestore() must come from spin_lock_irqsave().

Bart.

  reply	other threads:[~2021-09-13 16:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210913081148epcas2p21c23ca6a745f40083ee7d6e7da4d7c00@epcas2p2.samsung.com>
2021-09-13  7:55 ` [PATCH v2 0/3] scsi: ufs: introduce vendor isr Kiwoong Kim
     [not found]   ` <CGME20210913081150epcas2p11f98eed5939bf082981e2a4d6fd9a059@epcas2p1.samsung.com>
2021-09-13  7:55     ` [PATCH v2 1/3] " Kiwoong Kim
2021-09-14  3:30       ` Bart Van Assche
2021-09-14  5:13         ` Kiwoong Kim
2021-09-14 11:53         ` Avri Altman
2021-09-14 16:29           ` Bart Van Assche
     [not found]   ` <CGME20210913081151epcas2p453eb6c6de01466060724d1445b443572@epcas2p4.samsung.com>
2021-09-13  7:55     ` [PATCH v2 2/3] scsi: ufs: introduce force requeue Kiwoong Kim
     [not found]   ` <CGME20210913081152epcas2p2eac4a8dbef33164a150dccf2e282dcce@epcas2p2.samsung.com>
2021-09-13  7:55     ` [PATCH v2 3/3] scsi: ufs: ufs-exynos: implement exynos isr Kiwoong Kim
2021-09-13 16:23       ` Bart Van Assche [this message]
2021-09-14  5:12         ` Kiwoong Kim
2021-09-17 19:59       ` Avri Altman
2021-09-13 16:09   ` [PATCH v2 0/3] scsi: ufs: introduce vendor isr Bart Van Assche
2021-09-13 17:26     ` Alim Akhtar
2021-09-14  3:23       ` Bart Van Assche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=baf17040-70e8-d850-30cd-74944e41285d@acm.org \
    --to=bvanassche@acm.org \
    --cc=adrian.hunter@intel.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bhoon95.kim@samsung.com \
    --cc=cang@codeaurora.org \
    --cc=hy50.seo@samsung.com \
    --cc=jejb@linux.ibm.com \
    --cc=kwmad.kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=sc.suh@samsung.com \
    --cc=sh425.lee@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.