From: Christoph Hellwig <hch@infradead.org>
To: Gabriel Krisman Bertazi <krisman@collabora.com>
Cc: linux-mm@kvack.org, labbott@redhat.com, kernel@collabora.com,
gael.portay@collabora.com, mike.kravetz@oracle.com,
m.szyprowski@samsung.com
Subject: Re: [PATCH 0/6] Improve handling of GFP flags in the CMA allocator
Date: Tue, 26 Feb 2019 06:29:41 -0800 [thread overview]
Message-ID: <20190226142941.GA13684@infradead.org> (raw)
In-Reply-To: <20190218210715.1066-1-krisman@collabora.com>
I don't think this is a good idea. The whole concept of just passing
random GFP_ flags to dma_alloc_attrs / dma_alloc_coherent can't work,
given that on many architectures we need to set up new page tables
to remap the allocated memory, and we can't use arbitrary gfp flags
for pte allocations.
So instead of trying to pass them further down again we need to instead
work to fix all callers of dma_alloc_attrs / dma_alloc_coherent
that don't just pass GFP_KERNEL.
next prev parent reply other threads:[~2019-02-26 14:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 21:07 [PATCH 0/6] Improve handling of GFP flags in the CMA allocator Gabriel Krisman Bertazi
2019-02-18 21:07 ` [PATCH 1/6] Revert "kernel/dma: remove unsupported gfp_mask parameter from dma_alloc_from_contiguous()" Gabriel Krisman Bertazi
2019-02-18 21:07 ` [PATCH 2/6] Revert "mm/cma: remove unsupported gfp_mask parameter from cma_alloc()" Gabriel Krisman Bertazi
2019-02-18 21:07 ` [PATCH 3/6] cma: Warn about callers requesting unsupported flags Gabriel Krisman Bertazi
2019-02-18 21:07 ` [PATCH 4/6] cma: Add support for GFP_ZERO Gabriel Krisman Bertazi
2019-02-18 21:07 ` [PATCH 5/6] page_isolation: Propagate temporary pageblock isolation error Gabriel Krisman Bertazi
2019-02-18 21:07 ` [PATCH 6/6] cma: Isolate pageblocks speculatively during allocation Gabriel Krisman Bertazi
2019-02-21 12:39 ` [PATCH 0/6] Improve handling of GFP flags in the CMA allocator Vlastimil Babka
2019-02-26 14:29 ` Christoph Hellwig [this message]
2019-02-28 0:12 ` Laura Abbott
2019-02-28 8:46 ` Michal Hocko
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=20190226142941.GA13684@infradead.org \
--to=hch@infradead.org \
--cc=gael.portay@collabora.com \
--cc=kernel@collabora.com \
--cc=krisman@collabora.com \
--cc=labbott@redhat.com \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mike.kravetz@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).