From: Robin Murphy <robin.murphy@arm.com> To: David Stevens <stevensd@chromium.org>, Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org> Cc: Sergey Senozhatsky <senozhatsky@chromium.org>, iommu@lists.linux-foundation.org, Christoph Hellwig <hch@lst.de>, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] dma-iommu: add kalloc gfp flag to alloc helper Date: Thu, 8 Jul 2021 18:22:17 +0100 [thread overview] Message-ID: <8cdbcbbb-5064-ae7f-af4a-abb0e4203b6d@arm.com> (raw) In-Reply-To: <20210707075505.2896824-2-stevensd@google.com> On 2021-07-07 08:55, David Stevens wrote: > From: David Stevens <stevensd@chromium.org> > > Add gfp flag for kalloc calls within __iommu_dma_alloc_pages, so the > function can be called from atomic contexts. Why bother? If you need GFP_ATOMIC for allocating the pages array, then you don't not need it for allocating the pages themselves. It's hardly rocket science to infer one from the other. Robin. > Signed-off-by: David Stevens <stevensd@chromium.org> > --- > drivers/iommu/dma-iommu.c | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c > index 614f0dd86b08..00993b56c977 100644 > --- a/drivers/iommu/dma-iommu.c > +++ b/drivers/iommu/dma-iommu.c > @@ -593,7 +593,8 @@ static void __iommu_dma_free_pages(struct page **pages, int count) > } > > static struct page **__iommu_dma_alloc_pages(struct device *dev, > - unsigned int count, unsigned long order_mask, gfp_t gfp) > + unsigned int count, unsigned long order_mask, > + gfp_t page_gfp, gfp_t kalloc_gfp) > { > struct page **pages; > unsigned int i = 0, nid = dev_to_node(dev); > @@ -602,15 +603,15 @@ static struct page **__iommu_dma_alloc_pages(struct device *dev, > if (!order_mask) > return NULL; > > - pages = kvzalloc(count * sizeof(*pages), GFP_KERNEL); > + pages = kvzalloc(count * sizeof(*pages), kalloc_gfp); > if (!pages) > return NULL; > > /* IOMMU can map any pages, so himem can also be used here */ > - gfp |= __GFP_NOWARN | __GFP_HIGHMEM; > + page_gfp |= __GFP_NOWARN | __GFP_HIGHMEM; > > /* It makes no sense to muck about with huge pages */ > - gfp &= ~__GFP_COMP; > + page_gfp &= ~__GFP_COMP; > > while (count) { > struct page *page = NULL; > @@ -624,7 +625,7 @@ static struct page **__iommu_dma_alloc_pages(struct device *dev, > for (order_mask &= (2U << __fls(count)) - 1; > order_mask; order_mask &= ~order_size) { > unsigned int order = __fls(order_mask); > - gfp_t alloc_flags = gfp; > + gfp_t alloc_flags = page_gfp; > > order_size = 1U << order; > if (order_mask > order_size) > @@ -680,7 +681,7 @@ static struct page **__iommu_dma_alloc_noncontiguous(struct device *dev, > > count = PAGE_ALIGN(size) >> PAGE_SHIFT; > pages = __iommu_dma_alloc_pages(dev, count, alloc_sizes >> PAGE_SHIFT, > - gfp); > + gfp, GFP_KERNEL); > if (!pages) > return NULL; > >
WARNING: multiple messages have this Message-ID
From: Robin Murphy <robin.murphy@arm.com> To: David Stevens <stevensd@chromium.org>, Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org> Cc: Sergey Senozhatsky <senozhatsky@chromium.org>, iommu@lists.linux-foundation.org, Christoph Hellwig <hch@lst.de>, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] dma-iommu: add kalloc gfp flag to alloc helper Date: Thu, 8 Jul 2021 18:22:17 +0100 [thread overview] Message-ID: <8cdbcbbb-5064-ae7f-af4a-abb0e4203b6d@arm.com> (raw) In-Reply-To: <20210707075505.2896824-2-stevensd@google.com> On 2021-07-07 08:55, David Stevens wrote: > From: David Stevens <stevensd@chromium.org> > > Add gfp flag for kalloc calls within __iommu_dma_alloc_pages, so the > function can be called from atomic contexts. Why bother? If you need GFP_ATOMIC for allocating the pages array, then you don't not need it for allocating the pages themselves. It's hardly rocket science to infer one from the other. Robin. > Signed-off-by: David Stevens <stevensd@chromium.org> > --- > drivers/iommu/dma-iommu.c | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c > index 614f0dd86b08..00993b56c977 100644 > --- a/drivers/iommu/dma-iommu.c > +++ b/drivers/iommu/dma-iommu.c > @@ -593,7 +593,8 @@ static void __iommu_dma_free_pages(struct page **pages, int count) > } > > static struct page **__iommu_dma_alloc_pages(struct device *dev, > - unsigned int count, unsigned long order_mask, gfp_t gfp) > + unsigned int count, unsigned long order_mask, > + gfp_t page_gfp, gfp_t kalloc_gfp) > { > struct page **pages; > unsigned int i = 0, nid = dev_to_node(dev); > @@ -602,15 +603,15 @@ static struct page **__iommu_dma_alloc_pages(struct device *dev, > if (!order_mask) > return NULL; > > - pages = kvzalloc(count * sizeof(*pages), GFP_KERNEL); > + pages = kvzalloc(count * sizeof(*pages), kalloc_gfp); > if (!pages) > return NULL; > > /* IOMMU can map any pages, so himem can also be used here */ > - gfp |= __GFP_NOWARN | __GFP_HIGHMEM; > + page_gfp |= __GFP_NOWARN | __GFP_HIGHMEM; > > /* It makes no sense to muck about with huge pages */ > - gfp &= ~__GFP_COMP; > + page_gfp &= ~__GFP_COMP; > > while (count) { > struct page *page = NULL; > @@ -624,7 +625,7 @@ static struct page **__iommu_dma_alloc_pages(struct device *dev, > for (order_mask &= (2U << __fls(count)) - 1; > order_mask; order_mask &= ~order_size) { > unsigned int order = __fls(order_mask); > - gfp_t alloc_flags = gfp; > + gfp_t alloc_flags = page_gfp; > > order_size = 1U << order; > if (order_mask > order_size) > @@ -680,7 +681,7 @@ static struct page **__iommu_dma_alloc_noncontiguous(struct device *dev, > > count = PAGE_ALIGN(size) >> PAGE_SHIFT; > pages = __iommu_dma_alloc_pages(dev, count, alloc_sizes >> PAGE_SHIFT, > - gfp); > + gfp, GFP_KERNEL); > if (!pages) > return NULL; > > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-07-08 17:22 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-07 7:55 [PATCH 0/4] Add dynamic iommu backed bounce buffers David Stevens 2021-07-07 7:55 ` David Stevens 2021-07-07 7:55 ` [PATCH 1/4] dma-iommu: add kalloc gfp flag to alloc helper David Stevens 2021-07-07 7:55 ` David Stevens 2021-07-08 17:22 ` Robin Murphy [this message] 2021-07-08 17:22 ` Robin Murphy 2021-07-07 7:55 ` [PATCH 2/4] dma-iommu: replace device arguments David Stevens 2021-07-07 7:55 ` David Stevens 2021-07-07 7:55 ` [PATCH 3/4] dma-iommu: expose a few helper functions to module David Stevens 2021-07-07 7:55 ` David Stevens 2021-07-07 7:55 ` [PATCH 4/4] dma-iommu: Add iommu bounce buffers to dma-iommu api David Stevens 2021-07-07 7:55 ` David Stevens 2021-07-08 9:29 ` [PATCH 0/4] Add dynamic iommu backed bounce buffers Joerg Roedel 2021-07-08 9:29 ` Joerg Roedel 2021-07-08 17:14 ` Robin Murphy 2021-07-08 17:14 ` Robin Murphy 2021-07-09 7:25 ` David Stevens 2021-07-09 7:25 ` David Stevens 2021-07-08 13:38 ` Lu Baolu 2021-07-08 13:38 ` Lu Baolu 2021-07-09 6:04 ` David Stevens 2021-07-09 6:04 ` David Stevens
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=8cdbcbbb-5064-ae7f-af4a-abb0e4203b6d@arm.com \ --to=robin.murphy@arm.com \ --cc=hch@lst.de \ --cc=iommu@lists.linux-foundation.org \ --cc=joro@8bytes.org \ --cc=linux-kernel@vger.kernel.org \ --cc=senozhatsky@chromium.org \ --cc=stevensd@chromium.org \ --cc=will@kernel.org \ --subject='Re: [PATCH 1/4] dma-iommu: add kalloc gfp flag to alloc helper' \ /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
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.