Jia-Ju Bai <baijiaju1990@xxxxxxxxx> 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);
}
Attachment:
signature.asc
Description: Message signed with OpenPGP
