From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: Joonsoo Kim <js1304-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Paul Mackerras <paulus-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
Linux Memory Management List
<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
Sumit Semwal
<sumit.semwal-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Benjamin Herrenschmidt
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
Laura Abbott <labbott-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Michal Nazarewicz
<mina86-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
Joonsoo Kim <iamjoonsoo.kim-Hm3cg6mZ9cc@public.gmane.org>,
Vlastimil Babka <vbabka-AlSwsSmVLrQ@public.gmane.org>,
Chris Zankel <chris-YvXeqwSYzG2sTnJN9+BGXg@public.gmane.org>,
linuxppc-dev
<linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Martin Schwidefsky
<schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Subject: Re: [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from cma_alloc()
Date: Thu, 12 Jul 2018 09:15:36 +0200 [thread overview]
Message-ID: <20180712071536.GA15506@lst.de> (raw)
In-Reply-To: <CAAmzW4M3KADCZD9+B2h7=WsYksGtg-GzYRCJjbqK5Scceynrrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Jul 12, 2018 at 11:48:47AM +0900, Joonsoo Kim wrote:
> One of existing user is general DMA layer and it takes gfp flags that is
> provided by user. I don't check all the DMA allocation sites but how do
> you convince that none of them try to use anything other
> than GFP_KERNEL [|__GFP_NOWARN]?
They use a few others things still like __GFP_COMP, __GPF_DMA or
GFP_HUGEPAGE. But all these are bogus as we have various implementations
that can't respect them. I plan to get rid of the gfp_t argument
in the dma_map_ops alloc method in a few merge windows because of that,
but it needs further implementation consolidation first.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Joonsoo Kim <js1304@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
iommu@lists.linux-foundation.org,
Andrew Morton <akpm@linux-foundation.org>,
Michal Nazarewicz <mina86@mina86.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>, Christoph Hellwig <hch@lst.de>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Paul Mackerras <paulus@ozlabs.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Chris Zankel <chris@zankel.net>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Joerg Roedel <joro@8bytes.org>,
Sumit Semwal <sumit.semwal@linaro.org>,
Robin Murphy <robin.murphy@arm.com>,
Laura Abbott <labbott@redhat.com>,
linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from cma_alloc()
Date: Thu, 12 Jul 2018 09:15:36 +0200 [thread overview]
Message-ID: <20180712071536.GA15506@lst.de> (raw)
In-Reply-To: <CAAmzW4M3KADCZD9+B2h7=WsYksGtg-GzYRCJjbqK5Scceynrrg@mail.gmail.com>
On Thu, Jul 12, 2018 at 11:48:47AM +0900, Joonsoo Kim wrote:
> One of existing user is general DMA layer and it takes gfp flags that is
> provided by user. I don't check all the DMA allocation sites but how do
> you convince that none of them try to use anything other
> than GFP_KERNEL [|__GFP_NOWARN]?
They use a few others things still like __GFP_COMP, __GPF_DMA or
GFP_HUGEPAGE. But all these are bogus as we have various implementations
that can't respect them. I plan to get rid of the gfp_t argument
in the dma_map_ops alloc method in a few merge windows because of that,
but it needs further implementation consolidation first.
WARNING: multiple messages have this Message-ID (diff)
From: hch@lst.de (Christoph Hellwig)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from cma_alloc()
Date: Thu, 12 Jul 2018 09:15:36 +0200 [thread overview]
Message-ID: <20180712071536.GA15506@lst.de> (raw)
In-Reply-To: <CAAmzW4M3KADCZD9+B2h7=WsYksGtg-GzYRCJjbqK5Scceynrrg@mail.gmail.com>
On Thu, Jul 12, 2018 at 11:48:47AM +0900, Joonsoo Kim wrote:
> One of existing user is general DMA layer and it takes gfp flags that is
> provided by user. I don't check all the DMA allocation sites but how do
> you convince that none of them try to use anything other
> than GFP_KERNEL [|__GFP_NOWARN]?
They use a few others things still like __GFP_COMP, __GPF_DMA or
GFP_HUGEPAGE. But all these are bogus as we have various implementations
that can't respect them. I plan to get rid of the gfp_t argument
in the dma_map_ops alloc method in a few merge windows because of that,
but it needs further implementation consolidation first.
next prev parent reply other threads:[~2018-07-12 7:15 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180709122020eucas1p21a71b092975cb4a3b9954ffc63f699d1@eucas1p2.samsung.com>
[not found] ` <20180709121956.20200-1-m.szyprowski@samsung.com>
[not found] ` <CGME20180709122019eucas1p2340da484acfcc932537e6014f4fd2c29@eucas1p2.samsung.com>
[not found] ` <20180709121956.20200-1-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2018-07-09 12:19 ` [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from cma_alloc() Marek Szyprowski
2018-07-09 12:19 ` Marek Szyprowski
2018-07-09 12:19 ` Marek Szyprowski
2018-07-09 13:09 ` Michal Hocko
2018-07-09 13:09 ` Michal Hocko
2018-07-09 13:09 ` Michal Hocko
[not found] ` <20180709122019eucas1p2340da484acfcc932537e6014f4fd2c29~-sqTPJKij2939229392eucas1p2j-PmokGAFL9ItqW5MlFJXMulaTQe2KTcn/@public.gmane.org>
2018-07-09 14:23 ` Michał Nazarewicz
2018-07-09 14:23 ` Michał Nazarewicz
2018-07-09 17:27 ` Laura Abbott
2018-07-09 17:27 ` Laura Abbott
2018-07-09 17:27 ` Laura Abbott
2018-07-10 7:19 ` Joonsoo Kim
2018-07-10 7:19 ` Joonsoo Kim
2018-07-10 7:19 ` Joonsoo Kim
[not found] ` <CAAmzW4PPNYhUj_MeZox+ddq8MjXqnJs_AJ3xkayf710udD1pSg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-10 9:50 ` Michal Hocko
2018-07-10 9:50 ` Michal Hocko
2018-07-10 9:50 ` Michal Hocko
2018-07-11 7:35 ` Joonsoo Kim
2018-07-11 7:35 ` Joonsoo Kim
2018-07-11 7:35 ` Joonsoo Kim
2018-07-11 8:54 ` Michal Hocko
2018-07-11 8:54 ` Michal Hocko
2018-07-11 8:54 ` Michal Hocko
[not found] ` <20180711085407.GB20050-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-07-12 2:48 ` Joonsoo Kim
2018-07-12 2:48 ` Joonsoo Kim
2018-07-12 2:48 ` Joonsoo Kim
[not found] ` <CAAmzW4M3KADCZD9+B2h7=WsYksGtg-GzYRCJjbqK5Scceynrrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-12 7:15 ` Christoph Hellwig [this message]
2018-07-12 7:15 ` Christoph Hellwig
2018-07-12 7:15 ` Christoph Hellwig
2018-07-13 6:29 ` Joonsoo Kim
2018-07-13 6:29 ` Joonsoo Kim
2018-07-13 6:29 ` Joonsoo Kim
2018-07-16 7:45 ` Vlastimil Babka
2018-07-16 7:45 ` Vlastimil Babka
2018-07-17 15:08 ` Christoph Hellwig
2018-07-17 15:08 ` Christoph Hellwig
2018-07-17 15:08 ` Christoph Hellwig
2018-07-09 12:19 ` [PATCH 2/2] dma: remove unsupported gfp_mask parameter from dma_alloc_from_contiguous() Marek Szyprowski
2018-07-09 12:19 ` Marek Szyprowski
[not found] ` <20180709122020eucas1p21a71b092975cb4a3b9954ffc63f699d1~-sqUFoa-h2939329393eucas1p2Y-PmokGAFL9ItqW5MlFJXMulaTQe2KTcn/@public.gmane.org>
2018-07-09 14:25 ` Michał Nazarewicz
2018-07-09 14:25 ` Michał Nazarewicz
2018-07-16 7:45 ` Vlastimil Babka
2018-07-16 7:45 ` Vlastimil Babka
2018-07-16 7:45 ` Vlastimil Babka
2018-07-17 15:08 ` Christoph Hellwig
2018-07-17 15:08 ` Christoph Hellwig
2018-07-17 15:08 ` Christoph Hellwig
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=20180712071536.GA15506@lst.de \
--to=hch-jcswghmuv9g@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=chris-YvXeqwSYzG2sTnJN9+BGXg@public.gmane.org \
--cc=iamjoonsoo.kim-Hm3cg6mZ9cc@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=js1304-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=labbott-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=mina86-deATy8a+UHjQT0dZR+AlfA@public.gmane.org \
--cc=paulus-mnsaURCQ41sdnm+yROfE0A@public.gmane.org \
--cc=schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=sumit.semwal-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=vbabka-AlSwsSmVLrQ@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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.