[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231107182437.06632f6e.pasic@linux.ibm.com>
Date: Tue, 7 Nov 2023 18:24:37 +0100
From: Halil Pasic <pasic@...ux.ibm.com>
To: Christoph Hellwig <hch@....de>
Cc: Petr Tesařík <petr@...arici.cz>,
Niklas Schnelle <schnelle@...ux.ibm.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>,
Petr Tesarik <petr.tesarik1@...wei-partners.com>,
Ross Lagerwall <ross.lagerwall@...rix.com>,
linux-pci <linux-pci@...r.kernel.org>,
linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
Matthew Rosato <mjrosato@...ux.ibm.com>,
Halil Pasic <pasic@...ux.ibm.com>,
Jianxiong Gao <jxgao@...gle.com>
Subject: Re: Memory corruption with CONFIG_SWIOTLB_DYNAMIC=y
On Mon, 6 Nov 2023 08:42:43 +0100
Christoph Hellwig <hch@....de> wrote:
> > 1. hardware which cannot handle an unaligned base address (presumably
> > because the chip performs a simple OR operation to get the addresses
> > of individual fields);
>
> There's all kinds of weird encodings that discard the low bits.
> For NVMe it's the PRPs (that is actually documented in the NVMe
> spec, so it might be easiest to grasp), but except for a Mellox
> vendor extension this is also how all RDMA memory registrations
> work.
Thanks Christoph! So for NVMe in certain contexts the low
bits of addresses get discarded, but in other contexts the high bits
of addresses get discarded and the low bits need to remain the same
after the bounce (and that's why we need commits 36950f2da1ea ("driver
core: add a min_align_mask) and 1f221a0d0dbf ("swiotlb: respect
min_align_mask").
Does that sound about right?
Regards,
Halil
Powered by blists - more mailing lists