linux-kernel - Re: [PATCH V4] mm: fix kernel crash in khugepaged thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5645BFAA.1070004@suse.cz>
Date:	Fri, 13 Nov 2015 11:47:06 +0100
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Steven Rostedt <rostedt@...dmis.org>,
	yalin wang <yalin.wang2010@...il.com>
Cc:	mingo@...hat.com, akpm@...ux-foundation.org,
	ebru.akagunduz@...il.com, riel@...hat.com,
	kirill.shutemov@...ux.intel.com, jmarchan@...hat.com,
	mgorman@...hsingularity.net, willy@...ux.intel.com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH V4] mm: fix kernel crash in khugepaged thread

On 11/12/2015 03:29 PM, Steven Rostedt wrote:
> On Thu, 12 Nov 2015 16:21:02 +0800
> yalin wang <yalin.wang2010@...il.com> wrote:
>
>> This crash is caused by NULL pointer deference, in page_to_pfn() marco,
>> when page == NULL :
>>
>> [  182.639154 ] Unable to handle kernel NULL pointer dereference at virtual address 00000000
>
>
>> add the trace point with TP_CONDITION(page),
>
> I wonder if we still want to trace even if page is NULL?

I'd say we want to. There's even a "SCAN_PAGE_NULL" result defined for 
that case, and otherwise we would only have to guess why collapsing 
failed, which is the thing that the tracepoint should help us find out 
in the first place :)

>> avoid trace NULL page.
>>
>> Signed-off-by: yalin wang <yalin.wang2010@...il.com>
>> ---
>>   include/trace/events/huge_memory.h | 20 ++++++++++++--------
>>   mm/huge_memory.c                   |  6 +++---
>>   2 files changed, 15 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/trace/events/huge_memory.h b/include/trace/events/huge_memory.h
>> index 11c59ca..727647b 100644
>> --- a/include/trace/events/huge_memory.h
>> +++ b/include/trace/events/huge_memory.h
>> @@ -45,12 +45,14 @@ SCAN_STATUS
>>   #define EM(a, b)	{a, b},
>>   #define EMe(a, b)	{a, b}
>>
>> -TRACE_EVENT(mm_khugepaged_scan_pmd,
>> +TRACE_EVENT_CONDITION(mm_khugepaged_scan_pmd,
>>
>> -	TP_PROTO(struct mm_struct *mm, unsigned long pfn, bool writable,
>> +	TP_PROTO(struct mm_struct *mm, struct page *page, bool writable,
>>   		 bool referenced, int none_or_zero, int status, int unmapped),
>>
>> -	TP_ARGS(mm, pfn, writable, referenced, none_or_zero, status, unmapped),
>> +	TP_ARGS(mm, page, writable, referenced, none_or_zero, status, unmapped),
>> +
>> +	TP_CONDITION(page),
>>
>>   	TP_STRUCT__entry(
>>   		__field(struct mm_struct *, mm)
>> @@ -64,7 +66,7 @@ TRACE_EVENT(mm_khugepaged_scan_pmd,
>>
>>   	TP_fast_assign(
>>   		__entry->mm = mm;
>> -		__entry->pfn = pfn;
>> +		__entry->pfn = page_to_pfn(page);
>
> Instead of the condition, we could have:
>
> 	__entry->pfn = page ? page_to_pfn(page) : -1;

I agree. Please do it like this.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/