All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Dakshaja Uppalapati <dakshaja@chelsio.com>
Cc: Christoph Hellwig <hch@lst.de>,
	eduard@hasenleithner.at, kbusch@kernel.org, sagi@grimberg.me,
	gregkh@linuxfoundation.org, nirranjan@chelsio.com,
	bharat@chelsio.com, stable@vger.kernel.org
Subject: Re: [PATCH nvme] nvme: Revert "nvme: Discard workaround for non-conformant devices"
Date: Wed, 3 Jun 2020 18:23:38 +0200	[thread overview]
Message-ID: <20200603162338.GA27240@lst.de> (raw)
In-Reply-To: <20200603161717.GA11442@chelsio.com>

On Wed, Jun 03, 2020 at 09:47:18PM +0530, Dakshaja Uppalapati wrote:
> > Err, why?  Please send an actual bug report with details of your
> > setup.
> 
> Hi Christoph,
> 
> Here is the link describing the issue initially reported for upstream 
> kernel 5.5:
> 
> https://lore.kernel.org/linux-nvme/CH2PR12MB40053A64681EFA3E6F63FDFBDD2A0@CH2PR12MB4005.namprd12.prod.outlook.com/
> 
> Issue is later fixed with upstream commit b716e688.

We are talking about two different things here.  One is the Linux NVMe
host code that can be used with lots of different controllers.  Many of
them are PCIe controller, especially cheap ones.

The other is the Linux NVMe target code.  So if a fix for very common
PCIe controller trigger a bug in the target code there is no 1:1
relationship as even if you are talking to a Linux fabrics controller
it usually runs a different kernel version on a different system.

That being said you can always backport that fix as well, which probably
is a good idea as it fixes a real bug.

Nevermind that nothing in your revert patch indicated it wasn't for
mainline.

  reply	other threads:[~2020-06-03 16:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03  9:18 [PATCH nvme] nvme: Revert "nvme: Discard workaround for non-conformant devices" Dakshaja Uppalapati
2020-06-03 13:07 ` Christoph Hellwig
2020-06-03 16:17   ` Dakshaja Uppalapati
2020-06-03 16:23     ` Christoph Hellwig [this message]
2020-06-03 21:20       ` Sagi Grimberg
2020-06-04  6:36         ` Dakshaja Uppalapati
2020-09-04 11:34           ` Greg KH
2020-06-05 13:43 ` Greg KH
2020-06-08  6:35   ` Dakshaja Uppalapati
2020-06-08 15:05     ` Keith Busch
2020-06-11 16:08       ` Dakshaja Uppalapati

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=20200603162338.GA27240@lst.de \
    --to=hch@lst.de \
    --cc=bharat@chelsio.com \
    --cc=dakshaja@chelsio.com \
    --cc=eduard@hasenleithner.at \
    --cc=gregkh@linuxfoundation.org \
    --cc=kbusch@kernel.org \
    --cc=nirranjan@chelsio.com \
    --cc=sagi@grimberg.me \
    --cc=stable@vger.kernel.org \
    /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.