[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <0875D539-4B35-402D-9CCA-09BBA8DDB46E@gmail.com>
Date: Thu, 31 May 2018 18:34:45 -0700
From: Nadav Amit <nadav.amit@...il.com>
To: Jia-Ju Bai <baijiaju1990@...il.com>
Cc: Christopher Lameter <cl@...ux.com>,
Matthew Wilcox <willy@...radead.org>, penberg@...nel.org,
rientjes@...gle.com, iamjoonsoo.kim@....com,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Can kfree() sleep at runtime?
Jia-Ju Bai <baijiaju1990@...il.com> wrote:
>
>
> On 2018/5/31 22:30, Christopher Lameter wrote:
>> On Thu, 31 May 2018, Matthew Wilcox wrote:
>>
>>>> Freeing a page in the page allocator also was traditionally not sleeping.
>>>> That has changed?
>>> No. "Your bug" being "The bug in your static analysis tool". It probably
>>> isn't following the data flow correctly (or deeply enough).
>> Well ok this is not going to trigger for kfree(), this is x86 specific and
>> requires CONFIG_DEBUG_PAGEALLOC and a free of a page in a huge page.
>>
>> Ok that is a very contorted situation but how would a static checker deal
>> with that?
>
> I admit that my tool does not follow the data flow well, and I need to improve it.
> In this case of kfree(), I want know how the data flow leads to my mistake.
Note that is only enabled in debug mode:
static inline void
kernel_map_pages(struct page *page, int numpages, int enable)
{
if (!debug_pagealloc_enabled())
return;
__kernel_map_pages(page, numpages, enable);
}
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists