LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org> To: 王贇 <yun.wang@linux.alibaba.com> Cc: Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>, John Fastabend <john.fastabend@gmail.com>, KP Singh <kpsingh@kernel.org>, "open list:PERFORMANCE EVENTS SUBSYSTEM" <linux-perf-users@vger.kernel.org>, "open list:PERFORMANCE EVENTS SUBSYSTEM" <linux-kernel@vger.kernel.org>, "open list:BPF (Safe dynamic programs and tools)" <netdev@vger.kernel.org>, "open list:BPF (Safe dynamic programs and tools)" <bpf@vger.kernel.org>, jroedel@suse.de, x86@kernel.org Subject: Re: [PATCH] x86/dumpstack/64: Add guard pages to stack_info Date: Thu, 16 Sep 2021 10:00:15 +0200 [thread overview] Message-ID: <YUL5j/lY0mtx4NMq@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <76de02b7-4d87-4a3a-e4d4-048829749887@linux.alibaba.com> On Thu, Sep 16, 2021 at 11:47:49AM +0800, 王贇 wrote: > I did some debug and found the issue, we are missing: > > @@ -122,7 +137,10 @@ static __always_inline bool in_exception_stack(unsigned long *stack, struct stac > info->type = ep->type; > info->begin = (unsigned long *)begin; > info->end = (unsigned long *)end; > - info->next_sp = (unsigned long *)regs->sp; > + > + if (!(ep->type & STACK_TYPE_GUARD)) > + info->next_sp = (unsigned long *)regs->sp; > + > return true; > } > > as the guard page are not working as real stack I guess? Correct, but I thought I put if (type & GUARD) terminators in all paths that ended up caring about ->next_sp. Clearly I seem to have missed one :/ Let me try and figure out where that happens. > With that one things going on correctly, and some trivials below. > > enum stack_type { > > - STACK_TYPE_UNKNOWN, > > + STACK_TYPE_UNKNOWN = 0, > > Is this necessary? No, but it makes it more explicit we care about the value. > > STACK_TYPE_TASK, > > STACK_TYPE_IRQ, > > STACK_TYPE_SOFTIRQ, > > STACK_TYPE_ENTRY, > > STACK_TYPE_EXCEPTION, > > STACK_TYPE_EXCEPTION_LAST = STACK_TYPE_EXCEPTION + N_EXCEPTION_STACKS-1, > > + STACK_TYPE_GUARD = 0x80, Note that this is a flag. > > }; > > > > struct stack_info { > > --- a/arch/x86/kernel/dumpstack_64.c > > +++ b/arch/x86/kernel/dumpstack_64.c > > @@ -32,9 +32,15 @@ const char *stack_type_name(enum stack_t > > { > > BUILD_BUG_ON(N_EXCEPTION_STACKS != 6); > > > > + if (type == STACK_TYPE_TASK) > > + return "TASK"; > > + > > if (type == STACK_TYPE_IRQ) > > return "IRQ"; > > > > + if (type == STACK_TYPE_SOFTIRQ) > > + return "SOFTIRQ"; > > + > > Do we need one for GUARD too? No, GUARD is not a single type but a flag. The caller can trivially do something like: "%s %s", stack_type_name(type & ~GUARD), (type & GUARD) ? "GUARD" : "" > > if (type == STACK_TYPE_ENTRY) { > > /* > > * On 64-bit, we have a generic entry stack that we > > @@ -111,10 +122,11 @@ static __always_inline bool in_exception > > k = (stk - begin) >> PAGE_SHIFT; > > /* Lookup the page descriptor */ > > ep = &estack_pages[k]; > > - /* Guard page? */ > > + /* unknown entry */ > > if (!ep->size) > > return false; > > > > + > > Extra line? Gone now, thanks!
next prev parent reply other threads:[~2021-09-16 8:00 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-09 3:13 [RFC PATCH] perf: fix panic by mark recursion inside perf_log_throttle 王贇 2021-09-09 6:10 ` 王贇 2021-09-10 15:38 ` Peter Zijlstra 2021-09-13 3:00 ` 王贇 2021-09-13 3:21 ` 王贇 2021-09-13 10:24 ` Peter Zijlstra 2021-09-13 10:36 ` Peter Zijlstra 2021-09-14 2:02 ` 王贇 2021-09-14 1:58 ` 王贇 2021-09-14 10:28 ` Peter Zijlstra 2021-09-15 1:51 ` 王贇 2021-09-15 15:17 ` [PATCH] x86/dumpstack/64: Add guard pages to stack_info Peter Zijlstra 2021-09-16 3:34 ` 王贇 2021-09-16 3:47 ` 王贇 2021-09-16 8:00 ` Peter Zijlstra [this message] 2021-09-16 8:03 ` Peter Zijlstra 2021-09-16 10:02 ` Peter Zijlstra 2021-09-17 2:15 ` 王贇 2021-09-17 3:02 ` 王贇 2021-09-17 10:21 ` Peter Zijlstra 2021-09-17 16:40 ` Peter Zijlstra 2021-09-18 2:30 ` 王贇 2021-09-18 6:56 ` Peter Zijlstra 2021-09-18 2:38 ` 王贇 2021-09-13 3:30 ` [PATCH] perf: fix panic by disable ftrace on fault.c 王贇 2021-09-13 14:49 ` Dave Hansen 2021-09-14 1:52 ` 王贇 2021-09-14 3:02 ` 王贇 2021-09-14 7:23 ` 王贇 2021-09-14 16:16 ` Dave Hansen 2021-09-15 1:56 ` 王贇 2021-09-15 3:27 ` Dave Hansen 2021-09-15 7:22 ` 王贇 2021-09-15 7:34 ` 王贇 2021-09-15 15:19 ` [PATCH] x86: Increase exception stack sizes Peter Zijlstra 2021-09-16 3:42 ` 王贇 2021-09-21 7:28 ` [tip: x86/core] " tip-bot2 for Peter Zijlstra 2021-09-21 12:41 ` tip-bot2 for Peter Zijlstra 2021-09-14 2:08 ` [PATCH] perf: fix panic by disable ftrace on fault.c 王贇
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=YUL5j/lY0mtx4NMq@hirez.programming.kicks-ass.net \ --to=peterz@infradead.org \ --cc=acme@kernel.org \ --cc=alexander.shishkin@linux.intel.com \ --cc=andrii@kernel.org \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=john.fastabend@gmail.com \ --cc=jolsa@redhat.com \ --cc=jroedel@suse.de \ --cc=kafai@fb.com \ --cc=kpsingh@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-perf-users@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mingo@redhat.com \ --cc=namhyung@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=songliubraving@fb.com \ --cc=x86@kernel.org \ --cc=yhs@fb.com \ --cc=yun.wang@linux.alibaba.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: linkBe 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; as well as URLs for NNTP newsgroup(s).