Re: [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from cma_alloc()

On Wed 11-07-18 16:35:28, Joonsoo Kim wrote:

2018-07-10 18:50 GMT+09:00 Michal Hocko [off-list ref]:

quoted

On Tue 10-07-18 16:19:32, Joonsoo Kim wrote:

quoted

Hello, Marek.

2018-07-09 21:19 GMT+09:00 Marek Szyprowski [off-list ref]:

quoted

cma_alloc() function doesn't really support gfp flags other than
__GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.

Although gfp_mask isn't used in cma_alloc() except no_warn, it can be used
in alloc_contig_range(). For example, if passed gfp mask has no __GFP_FS,
compaction(isolation) would work differently. Do you have considered
such a case?

Does any of cma_alloc users actually care about GFP_NO{FS,IO}?

I don't know. My guess is that cma_alloc() is used for DMA allocation so
block device would use it, too. If fs/block subsystem initiates the
request for the device,
it would be possible that cma_alloc() is called with such a flag.
Again, I don't know
much about those subsystem so I would be wrong.

The patch converts existing users and none of them really tries to use
anything other than GFP_KERNEL [|__GFP_NOWARN] so this doesn't seem to
be the case. Should there be a new user requiring more restricted
gfp_mask we should carefuly re-evaluate and think how to support it.

Until then I would simply stick with the proposed approach because my
experience tells me that a wrong gfp mask usage is way too easy so the
simpler the api is the less likely we will see an abuse.
-- 
Michal Hocko
SUSE Labs