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: <D7E480F5-D879-4016-B530-5A4D7CB05675@gmail.com>
Date:	Fri, 13 Nov 2015 19:54:11 +0800
From:	yalin wang <yalin.wang2010@...il.com>
To:	Vlastimil Babka <vbabka@...e.cz>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ebru Akagunduz <ebru.akagunduz@...il.com>,
	Rik van Riel <riel@...hat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	jmarchan@...hat.com, mgorman@...hsingularity.net,
	willy@...ux.intel.com, linux-kernel <linux-kernel@...r.kernel.org>,
	linux-mm@...ck.org
Subject: Re: [PATCH V4] mm: fix kernel crash in khugepaged thread


> On Nov 13, 2015, at 18:47, Vlastimil Babka <vbabka@...e.cz> wrote:
> 
> 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.
ok ,  i will send V5 patch .--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ