All of lore.kernel.org
 help / color / mirror / Atom feed
From: yalin wang <yalin.wang2010@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ebru Akagunduz <ebru.akagunduz@gmail.com>,
	Rik van Riel <riel@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	jmarchan@redhat.com, mgorman@techsingularity.net,
	willy@linux.intel.com,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH V4] mm: fix kernel crash in khugepaged thread
Date: Fri, 13 Nov 2015 19:54:11 +0800	[thread overview]
Message-ID: <D7E480F5-D879-4016-B530-5A4D7CB05675@gmail.com> (raw)
In-Reply-To: <5645BFAA.1070004@suse.cz>


> On Nov 13, 2015, at 18:47, Vlastimil Babka <vbabka@suse.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@gmail.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@gmail.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 .

WARNING: multiple messages have this Message-ID (diff)
From: yalin wang <yalin.wang2010@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ebru Akagunduz <ebru.akagunduz@gmail.com>,
	Rik van Riel <riel@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	jmarchan@redhat.com, mgorman@techsingularity.net,
	willy@linux.intel.com,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH V4] mm: fix kernel crash in khugepaged thread
Date: Fri, 13 Nov 2015 19:54:11 +0800	[thread overview]
Message-ID: <D7E480F5-D879-4016-B530-5A4D7CB05675@gmail.com> (raw)
In-Reply-To: <5645BFAA.1070004@suse.cz>


> On Nov 13, 2015, at 18:47, Vlastimil Babka <vbabka@suse.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@gmail.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@gmail.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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2015-11-13 11:54 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12  8:21 [PATCH V4] mm: fix kernel crash in khugepaged thread yalin wang
2015-11-12  8:21 ` yalin wang
2015-11-12 14:29 ` Steven Rostedt
2015-11-12 14:29   ` Steven Rostedt
2015-11-13 10:47   ` Vlastimil Babka
2015-11-13 10:47     ` Vlastimil Babka
2015-11-13 11:54     ` yalin wang [this message]
2015-11-13 11:54       ` yalin wang
2015-11-13 14:01       ` Steven Rostedt
2015-11-13 14:01         ` Steven Rostedt
2015-11-16  1:35         ` yalin wang
2015-11-16  1:35           ` yalin wang
2015-11-16 10:16           ` Vlastimil Babka
2015-11-16 10:16             ` Vlastimil Babka
2015-11-16 14:25             ` Steven Rostedt
2015-11-16 14:25               ` Steven Rostedt
2015-11-17  2:21               ` yalin wang
2015-11-17  2:21                 ` yalin wang
2015-11-17  2:43                 ` Steven Rostedt
2015-11-17  2:43                   ` Steven Rostedt
2015-11-17  3:58                   ` yalin wang
2015-11-17  3:58                     ` yalin wang
2015-11-17  7:43                     ` Vlastimil Babka
2015-11-17  7:43                       ` Vlastimil Babka
2015-11-16 14:22           ` Steven Rostedt
2015-11-16 14:22             ` Steven Rostedt
2015-11-13  8:41 Hillf Danton
2015-11-13  8:41 ` Hillf Danton
2015-11-13 10:24 ` yalin wang
2015-11-13 10:24   ` yalin wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D7E480F5-D879-4016-B530-5A4D7CB05675@gmail.com \
    --to=yalin.wang2010@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebru.akagunduz@gmail.com \
    --cc=jmarchan@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=riel@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=vbabka@suse.cz \
    --cc=willy@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.