[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <01000163b6883743-79e003fa-71c2-4e9d-aa4a-35fcd08bb0d8-000000@email.amazonses.com>
Date: Thu, 31 May 2018 14:09:30 +0000
From: Christopher Lameter <cl@...ux.com>
To: Jia-Ju Bai <baijiaju1990@...il.com>
cc: Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
akpm@...ux-foundation.org, linux-mm@...ck.org,
Mel Gorman <mgorman@...hsingularity.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Can kfree() sleep at runtime?
On Thu, 31 May 2018, Jia-Ju Bai wrote:
> I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
That should not happen.
> Here is the call path for kfree().
> Please look at it *from the bottom up*.
>
> [FUNC] alloc_pages(GFP_KERNEL)
> arch/x86/mm/pageattr.c, 756: alloc_pages in split_large_page
> arch/x86/mm/pageattr.c, 1283: split_large_page in __change_page_attr
> arch/x86/mm/pageattr.c, 1391: __change_page_attr in __change_page_attr_set_clr
> arch/x86/mm/pageattr.c, 2014: __change_page_attr_set_clr in __set_pages_np
> arch/x86/mm/pageattr.c, 2034: __set_pages_np in __kernel_map_pages
> ./include/linux/mm.h, 2488: __kernel_map_pages in kernel_map_pages
> mm/page_alloc.c, 1074: kernel_map_pages in free_pages_prepare
mapping pages in the page allocator can cause allocations?? How did that
get in there?
> mm/page_alloc.c, 1264: free_pages_prepare in __free_pages_ok
> mm/page_alloc.c, 4312: __free_pages_ok in __free_pages
> mm/slub.c, 3914: __free_pages in kfree
>
> I always have an impression that kfree() never sleeps, so I feel confused
> here.
Correct.
Powered by blists - more mailing lists