All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Christoph Hellwig <hch@lst.de>
Cc: xen-devel@lists.xenproject.org, Jens Axboe <axboe@kernel.dk>,
	Keith Busch <kbusch@kernel.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
	Sagi Grimberg <sagi@grimberg.me>
Subject: Re: [PATCH] nvme-pci: fix parameter order in nvme_free_sgls() call
Date: Wed, 28 Jan 2026 10:10:08 +0100	[thread overview]
Message-ID: <aXnScGiFkX7ZFFdE@Mac.lan> (raw)
In-Reply-To: <20260128084958.GB9373@lst.de>

On Wed, Jan 28, 2026 at 09:49:58AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 27, 2026 at 08:59:06PM +0100, Roger Pau Monne wrote:
> > The call to nvme_free_sgls() in nvme_unmap_data() has the sg_list and sge
> > parameters swapped.  This wasn't noticed by the compiler because both share
> > the same type.  On a Xen PV hardware domain, and possibly any other
> > architectures that takes that path, this leads to corruption of the NVMe
> > contents.
> > 
> > Fixes: f0887e2a52d4 ("nvme-pci: create common sgl unmapping helper")
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > If possible it would be good for this to go in 6.19.0-rc8, as corruption of
> > the root device as part of a kernel update is unexpected. Sadly 6.18
> > already contained this issue, and no-one noticed, so its impact is limited?
> 
> This only affects non-IOMMU paths with a non-noop dma_unmap_phys.
> So it is a very common setup, but very severe for those.  Because of

Do you mean a "not very common setup"?  Otherwise I can't parse the
sentence.

> that we should get into 6.19-rc and -stable ASAP.
> 
> The fix looks good:
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>

Thanks.

> but maybe we can reword the subject to sound less harmless, e.g.:
> 
> nvme-pci: DMA unmap the correct regions in nvme_free_sgls

Fine with me.  I think I was more focused on describing the logical
change rather that the actual effect of it.  Can you adjust it when
picking up?

Regards, Roger.


  reply	other threads:[~2026-01-28  9:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27 19:59 [PATCH] nvme-pci: fix parameter order in nvme_free_sgls() call Roger Pau Monne
2026-01-28  8:49 ` Christoph Hellwig
2026-01-28  9:10   ` Roger Pau Monné [this message]
2026-01-28 14:22     ` Christoph Hellwig
2026-01-28 14:59 ` Keith Busch

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=aXnScGiFkX7ZFFdE@Mac.lan \
    --to=roger.pau@citrix.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=martin.petersen@oracle.com \
    --cc=sagi@grimberg.me \
    --cc=xen-devel@lists.xenproject.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.