From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Tony Luck <tony.luck@intel.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Helge Deller <deller@gmx.de>,
linux-parisc@vger.kernel.org, linux-ia64@vger.kernel.org,
Fengguang Wu <fengguang.wu@intel.com>
Subject: Re: [PATCH] debug: Do not permit CONFIG_DEBUG_STACK_USAGE=y on IA64 or PARISC
Date: Sat, 28 Jul 2012 09:12:31 +0100 [thread overview]
Message-ID: <1343463151.3328.4.camel@dabdike.int.hansenpartnership.com> (raw)
In-Reply-To: <4a613b26cc402fb3ed8130cd07a37e76f4c133ef.1342634029.git.tony.luck@intel.com>
On Wed, 2012-07-18 at 10:35 -0700, Tony Luck wrote:
> The stack_not_used() function in <linux/sched.h> assumes that stacks
> grow downwards. This is not true on IA64 or PARISC, so this function
> would walk off in the wrong direction and into the weeds.
OK, so looking at all of this, that statement's not quite true ... at
least for parisc, we begin the stack where end_of_stack() says the end
should be and so the walker will likely find the next word after the
canary skip occupied and terminate there, so we think the stack is
larger than it really is. It gets the wrong value, but it will never
even walk out of the stack area.
> Found on IA64 because of a compilation failure with recursive dependencies
> on IA64_TASKSIZE and IA64_THREAD_INFO_SIZE.
>
> Fixing the code is possible, but should be combined with other
> infrastructure additions to set up the "canary" at the end of the stack.
I agree with this. Most of it looks easily fixable, but how would I
enable the fix for ia64? For PA it's simple: I'll just use
CONFIG_STACK_GROWSUP, but that won't work for you.
James
next prev parent reply other threads:[~2012-07-28 8:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-18 17:35 Tony Luck
2012-07-25 7:45 ` Ingo Molnar
2012-07-25 8:02 ` James Bottomley
2012-07-25 18:23 ` Luck, Tony
2012-07-26 12:01 ` Ingo Molnar
2012-07-26 22:17 ` Peter Chubb
2012-07-28 8:12 ` James Bottomley [this message]
2012-07-28 21:43 ` Luck, Tony
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=1343463151.3328.4.camel@dabdike.int.hansenpartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=deller@gmx.de \
--cc=fengguang.wu@intel.com \
--cc=jejb@parisc-linux.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tony.luck@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®