From: Feng Tang <feng.tang@intel.com>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
<peterz@infradead.org>, <mingo@redhat.com>
Cc: <akpm@linux-foundation.org>, <bristot@redhat.com>,
<bsegall@google.com>, <dietmar.eggemann@arm.com>,
<juri.lelli@redhat.com>, <linux-kernel@vger.kernel.org>,
<mgorman@suse.de>, <mingo@redhat.com>, <peterz@infradead.org>,
<rostedt@goodmis.org>, <vbabka@suse.cz>,
<vincent.guittot@linaro.org>, <vschneid@redhat.com>,
<sparclinux@vger.kernel.org>
Subject: Re: sched/debug: Dump end of stack when detected corrupted
Date: Wed, 4 Sep 2024 10:59:44 +0800 [thread overview]
Message-ID: <ZtfNINc0hAJUtNRc@feng-clx.sh.intel.com> (raw)
In-Reply-To: <20240903163355.3187-1-glaubitz@physik.fu-berlin.de>
Hi Adrian,
On Tue, Sep 03, 2024 at 06:33:55PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Feng,
>
> > When debugging a kernel hang during suspend/resume, there are random
> > memory corruptions in different places like being detected by scheduler
> > with error message:
> >
> > "Kernel panic - not syncing: corrupted stack end detected inside scheduler"
> >
> > Dump the corrupted memory around the stack end will give more direct
> > hints about how the memory is corrupted:
> >
> > "
> > Corrupted Stack: ff11000122770000: ff ff ff ff ff ff 14 91 82 3b 78 e8 08 00 45 00 .........;x...E.
> > Corrupted Stack: ff11000122770010: 00 1d 2a ff 40 00 40 11 98 c8 0a ef 30 2c 0a ef ..*.@.@.....0,..
> > Corrupted Stack: ff11000122770020: 30 ff a2 00 22 3d 00 09 9a 95 2a 00 00 00 00 00 0..."=....*.....
> > ...
> > Kernel panic - not syncing: corrupted stack end detected inside scheduler
> > "
> >
> > And with it, the culprit was quickly identified to be an ethernet
> > driver with its DMA operations.
> >
> > Signed-off-by: Feng Tang <feng.tang@intel.com>
> > ---
> > kernel/sched/core.c | 12 +++++++++++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index a795e030678c..1280f7012bc5 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -5949,8 +5949,18 @@ static noinline void __schedule_bug(struct task_struct *prev)
> > static inline void schedule_debug(struct task_struct *prev, bool preempt)
> > {
> > #ifdef CONFIG_SCHED_STACK_END_CHECK
> > - if (task_stack_end_corrupted(prev))
> > + if (task_stack_end_corrupted(prev)) {
> > + unsigned long *ptr = end_of_stack(prev);
> > +
> > + /* Dump 16 ulong words around the corruption point */
> > +#ifdef CONFIG_STACK_GROWSUP
> > + ptr -= 15;
> > +#endif
> > + print_hex_dump(KERN_ERR, "Corrupted Stack: ",
> > + DUMP_PREFIX_ADDRESS, 16, 1, ptr, 16 * sizeof(*ptr), 1);
> > +
> > panic("corrupted stack end detected inside scheduler\n");
> > + }
> >
> > if (task_scs_end_corrupted(prev))
> > panic("corrupted shadow stack detected inside scheduler\n");
>
> Have you gotten any feedback on this? Would be nice to get this merged as we're
> seeing crashes due to stack corruption on sparc from time to time and having the
> end of the stack dumped in such cases would make debugging here a bit easier.
Thanks for the review and providing feedback! So far I haven't got response
from maintainers yet.
Hi Peter and maintainers,
Could you help to review this patch which can help debugging those naughty
memory corruption issues? Thanks!
There is a v2 version which can be applied to latest linux-next branch:
https://lore.kernel.org/lkml/20240207143523.438816-1-feng.tang@intel.com/
- Feng
next prev parent reply other threads:[~2024-09-04 3:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-19 3:22 [PATCH] " Feng Tang
2024-09-03 16:33 ` John Paul Adrian Glaubitz
2024-09-04 2:59 ` Feng Tang [this message]
2024-09-06 8:45 ` John Paul Adrian Glaubitz
2024-09-06 11:47 ` Feng Tang
2025-01-25 17:54 ` John Paul Adrian Glaubitz
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=ZtfNINc0hAJUtNRc@feng-clx.sh.intel.com \
--to=feng.tang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sparclinux@vger.kernel.org \
--cc=vbabka@suse.cz \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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®