All of lore.kernel.org
 help / color / mirror / Atom feed
From: WANG Chao <wcwxyz@gmail.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] sched: unlikely corrupted stack end
Date: Wed, 15 Jun 2016 00:55:02 +0800	[thread overview]
Message-ID: <71E4B9CB-BF33-4319-941B-85EC6640E339@gmail.com> (raw)
In-Reply-To: <20160614102638.GB13439@gmail.com>


> 在 2016年6月14日,下午6:26,Ingo Molnar <mingo@kernel.org> 写道:
> 
> 
> * WANG Chao <wcwxyz@gmail.com> wrote:
> 
>> 
>>> 在 2016年6月14日,下午4:56,Ingo Molnar <mingo@kernel.org> 写道:
>>> 
>>> 
>>> * WANG Chao <wcwxyz@gmail.com> wrote:
>>> 
>>>> unlikely() was dropped in commit ce03e4137bb2 ("sched/core: Drop
>>>> unlikely behind BUG_ON()"), but commit 29d6455178a0 ("sched: panic on
>>>> corrupted stack end") dropped BUG_ON() and called panic directly.
>>>> 
>>>> Now we should bring unlikely() back for branch prediction. While we're
>>>> at it, it's better and cleaner to turn task_stack_end_corrupted() into
>>>> inline function.
>>>> 
>>>> Signed-off-by: WANG Chao <wcwxyz@gmail.com>
>>>> ---
>>>> include/linux/sched.h | 7 +++++--
>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>>>> index 6e42ada26345..797ca1975431 100644
>>>> --- a/include/linux/sched.h
>>>> +++ b/include/linux/sched.h
>>>> @@ -2997,8 +2997,11 @@ static inline unsigned long *end_of_stack(struct task_struct *p)
>>>> }
>>>> 
>>>> #endif
>>>> -#define task_stack_end_corrupted(task) \
>>>> -		(*(end_of_stack(task)) != STACK_END_MAGIC)
>>>> +
>>>> +static inline int task_stack_end_corrupted(struct task_struct *p)
>>>> +{
>>>> +	return unlikely(*(end_of_stack(p)) != STACK_END_MAGIC);
>>>> +}
>>> 
>>> The passed in pointer should be const, and the extra parentheses around the 
>>> end_of_stack() call are not needed anymore (since it's now proper C code now).
>> 
>> end_of_stack() will discard const and cause an compiler warning.
>> Should I add const to end_of_stack()?
> 
> Yes. Also make sure ia64 still builds and such.

It seems convert task_stack_end_corrupted() into inline isn’t trivial.

In ia64, end_of_stack() is expanded to:

(unsigned long *)((void *)(p) + ((IA64_TASK_SIZE + IA64_THREAD_INFO_SIZE + 31) & ~31))

IA64_TASK_SIZE and IA64_THREAD_INFO_SIZE is defined in arch/ia64/kernel/asm-offsets.c,
which needs to include linux/sched.h.

So the problem is task_stack_end_corrupted() doesn’t compile before asm-offsets.c is compiled.
asm-offsets.c also needs to include linux/sched.h to compile. I think maybe that’s why
task_stack_end_corrupted() is introduced as marco, not inline.

Any idea?

Thanks
WANG Chao

  reply	other threads:[~2016-06-14 16:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14  6:43 [PATCH] sched: unlikely corrupted stack end WANG Chao
2016-06-14  7:43 ` Ingo Molnar
2016-06-14  8:17 ` Peter Zijlstra
2016-06-14  8:24 ` [PATCH v2] " WANG Chao
2016-06-14  8:56   ` Ingo Molnar
2016-06-14 10:17     ` WANG Chao
2016-06-14 10:26       ` Ingo Molnar
2016-06-14 16:55         ` WANG Chao [this message]
2016-06-15  8:25           ` Ingo Molnar
2016-06-15  8:53             ` [PATCH v3] " WANG Chao
2016-06-14  9:08   ` [PATCH v2] " kbuild test robot

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=71E4B9CB-BF33-4319-941B-85EC6640E339@gmail.com \
    --to=wcwxyz@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /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.