[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231108115207.791a30d8.pasic@linux.ibm.com>
Date: Wed, 8 Nov 2023 11:52:07 +0100
From: Halil Pasic <pasic@...ux.ibm.com>
To: Petr Tesařík <petr@...arici.cz>
Cc: Niklas Schnelle <schnelle@...ux.ibm.com>,
Christoph Hellwig <hch@....de>,
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>
Subject: Re: Memory corruption with CONFIG_SWIOTLB_DYNAMIC=y
On Fri, 3 Nov 2023 19:59:49 +0100
Petr Tesařík <petr@...arici.cz> wrote:
> > Not sure how to properly fix this as the different alignment
> > requirements get pretty complex quickly. So would appreciate your
> > input.
>
> I don't think it's possible to improve the allocation logic without
> modifying the page allocator and/or the DMA atomic pool allocator to
> take additional constraints into account.
I don't understand. What speaks against calculating the amount of space
needed, so that with the waste we can still fit the bounce-buffer in the
pool?
I believe alloc_size + combined_mask is a trivial upper bound, but we can
do slightly better since we know that we allocate pages.
For the sake of simplicity let us assume we only have the min_align_mask
requirement. Then I believe the worst case is that we need
(orig_addr & min_align_mask & PAGE_MASK) + (min_align_mask & ~PAGE_MASK)
extra space to fit.
Depending on how the semantics pan out one may be able to replace
min_align_mask with combined_mask.
Is your point that for large combined_mask values
_get_free_pages(GFP_NOWAIT | __GFP_NOWARN, required_order) is not
likely to complete successfully?
Regards,
Halil
Powered by blists - more mailing lists