All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: axboe@fb.com, hch@lst.de, sagi@grimberg.me,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
	nilskruse97@gmail.com, git@augustwikerfors.se,
	David.Chang@amd.com
Subject: Re: [PATCH] nvme: Don't fail to resume if NSIDs change
Date: Mon, 31 Jul 2023 13:10:11 -0600	[thread overview]
Message-ID: <ZMgHE2wu4T4OfrTR@kbusch-mbp> (raw)
In-Reply-To: <20230731185103.18436-1-mario.limonciello@amd.com>

On Mon, Jul 31, 2023 at 01:51:03PM -0500, Mario Limonciello wrote:
> Samsung PM9B1 has problems after resume because NSID has changed.
> This has been reported in the past on OEM varities of PM9B1 parts
> and fixed by firmware updates on 'some' of those parts.
> 
> However this same issue also happens on 'retail' PM9B1 parts which
> Samsung has not released firmware updates for.
> 
> As the check has been relaxed at startup for multiple disks with
> duplicate NSIDs with commit ac522fc6c3165 ("nvme: don't reject
> probe due to duplicate IDs for single-ported PCIe devices") also
> relax the check that runs on resume for NSIDs and mark them bogus
> if this occurs on resume.

How could the driver tell the difference between the device needing a
quirk compared to a rapid delete-create-attach namespace sequence?
Proceeding with the namespace now may get dirty writes intended for the
previous namespace, corrupting the new one.

The commit you mentioned tries to constrain allowing duplication where
we can reasonably assume the quirk is needed. If we need to do similiar
for this condition, one possible constraint might be that the device
doesn't report OACS bit 3 (Namespace Management).


  reply	other threads:[~2023-07-31 19:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-31 18:51 [PATCH] nvme: Don't fail to resume if NSIDs change Mario Limonciello
2023-07-31 19:10 ` Keith Busch [this message]
2023-07-31 19:41   ` Christoph Hellwig
2023-07-31 19:54   ` August Wikerfors
2023-07-31 20:09     ` Limonciello, Mario
2023-07-31 20:10       ` Christoph Hellwig
2023-07-31 20:14         ` Limonciello, Mario
2023-08-01 11:24           ` Christoph Hellwig
2023-08-01 11:30             ` Mario Limonciello
2023-08-01 20:29               ` Keith Busch
2023-08-01 20:34                 ` Mario Limonciello
2023-08-11 20:19                   ` August Wikerfors
2023-08-11 20:59                     ` Keith Busch
2023-08-12  5:57                       ` Greg KH
2023-08-12  5:57                     ` Greg KH
2023-07-31 19:11 ` August Wikerfors

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=ZMgHE2wu4T4OfrTR@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=David.Chang@amd.com \
    --cc=axboe@fb.com \
    --cc=git@augustwikerfors.se \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=mario.limonciello@amd.com \
    --cc=nilskruse97@gmail.com \
    --cc=sagi@grimberg.me \
    /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.