| Message ID | e287dbe69aa0933abafd97c80631940fd188ddd1.1599132844.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | iommu/dma: Remove broken huge page handling | expand |
On Thu, Sep 03, 2020 at 12:34:04PM +0100, Robin Murphy wrote: > The attempt to handle huge page allocations was originally added since > the comments around stripping __GFP_COMP in other implementations were > nonsensical, and we naively assumed that split_huge_page() could simply > be called equivalently to split_page(). It turns out that this doesn't > actually work correctly, so just get rid of it - there's little point > going to the effort of allocating huge pages if we're only going to > split them anyway. > > Reported-by: Roman Gushchin <guro@fb.com> > Signed-off-by: Robin Murphy <robin.murphy@arm.com> This looks sensibe. We really need to clear it in generic code, but last time I checked there were one or two buggy drivers that assumed __GFP_COMP works and actually gives a compound page (iirc legacy drm stuff). All that stuff really needs fixing.. Reviewed-by: Christoph Hellwig <hch@lst.de>
On Thu, Sep 03, 2020 at 12:34:04PM +0100, Robin Murphy wrote: > The attempt to handle huge page allocations was originally added since > the comments around stripping __GFP_COMP in other implementations were > nonsensical, and we naively assumed that split_huge_page() could simply > be called equivalently to split_page(). It turns out that this doesn't > actually work correctly, so just get rid of it - there's little point > going to the effort of allocating huge pages if we're only going to > split them anyway. > > Reported-by: Roman Gushchin <guro@fb.com> > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > --- > drivers/iommu/dma-iommu.c | 13 +++++-------- > 1 file changed, 5 insertions(+), 8 deletions(-) Applied, thanks.
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 4959f5df21bd..9194088b088f 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -524,6 +524,9 @@ static struct page **__iommu_dma_alloc_pages(struct device *dev, /* IOMMU can map any pages, so himem can also be used here */ gfp |= __GFP_NOWARN | __GFP_HIGHMEM; + /* It makes no sense to muck about with huge pages */ + gfp &= ~__GFP_COMP; + while (count) { struct page *page = NULL; unsigned int order_size; @@ -544,15 +547,9 @@ static struct page **__iommu_dma_alloc_pages(struct device *dev, page = alloc_pages_node(nid, alloc_flags, order); if (!page) continue; - if (!order) - break; - if (!PageCompound(page)) { + if (order) split_page(page, order); - break; - } else if (!split_huge_page(page)) { - break; - } - __free_pages(page, order); + break; } if (!page) { __iommu_dma_free_pages(pages, i);
The attempt to handle huge page allocations was originally added since the comments around stripping __GFP_COMP in other implementations were nonsensical, and we naively assumed that split_huge_page() could simply be called equivalently to split_page(). It turns out that this doesn't actually work correctly, so just get rid of it - there's little point going to the effort of allocating huge pages if we're only going to split them anyway. Reported-by: Roman Gushchin <guro@fb.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- drivers/iommu/dma-iommu.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-)