On 02/01/2017 03:05 PM, Michal Hocko wrote:
From: Michal Hocko <mhocko@xxxxxxxx> __vmalloc* allows users to provide gfp flags for the underlying allocation. This API is quite popular $ git grep "=[[:space:]]__vmalloc\|return[[:space:]]*__vmalloc" | wc -l 77 the only problem is that many people are not aware that they really want to give __GFP_HIGHMEM along with other flags because there is really no reason to consume precious lowmemory on CONFIG_HIGHMEM systems for pages which are mapped to the kernel vmalloc space. About half of users don't use this flag, though. This signals that we make the API unnecessarily too complex. This patch simply uses __GFP_HIGHMEM implicitly when allocating pages to be mapped to the vmalloc space. Current users which add __GFP_HIGHMEM are simplified and drop the flag. Signed-off-by: Michal Hocko <mhocko@xxxxxxxx> --- Hi, this is based on top of [1]. I believe it was Al who has brought this up quite some time ago (or maybe I just misremember). The explicit usage of __GFP_HIGHMEM in __vmalloc* seems to be too much to ask from users. I believe there is no user which doesn't want vmalloc pages be in the highmem but I might be missing something. There is vmalloc_32* API but that uses GFP_DMA* explicitly which overrides __GFP_HIGHMEM. So all current users _should_ be safe to use __GFP_HIGHMEM unconditionally. This patch should simplify things and fix many users which consume lowmem for no good reason. I am sending this as an RFC to get some feedback, I even haven't compile tested it yet. Any comments are welcome.
The idea sounds good. What are the potential dangers? That somebody of the current callers without __GFP_HIGHMEM would take a physical address of the page and then tried to access it via direct mapping?
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
