From: Thomas Gleixner <tglx@linutronix.de> To: LKML <linux-kernel@vger.kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com>, x86@kernel.org, Andy Lutomirski <luto@kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Alexander Potapenko <glider@google.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, linux-arm-kernel@lists.infradead.org Subject: [RFC patch 07/41] arm64/stacktrace: Remove the pointless ULONG_MAX marker Date: Wed, 10 Apr 2019 12:28:01 +0200 [thread overview] Message-ID: <20190410103644.220247845@linutronix.de> (raw) In-Reply-To: 20190410102754.387743324@linutronix.de Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org --- arch/arm64/kernel/stacktrace.c | 4 ---- 1 file changed, 4 deletions(-) --- a/arch/arm64/kernel/stacktrace.c +++ b/arch/arm64/kernel/stacktrace.c @@ -140,8 +140,6 @@ void save_stack_trace_regs(struct pt_reg #endif walk_stackframe(current, &frame, save_trace, &data); - if (trace->nr_entries < trace->max_entries) - trace->entries[trace->nr_entries++] = ULONG_MAX; } EXPORT_SYMBOL_GPL(save_stack_trace_regs); @@ -172,8 +170,6 @@ static noinline void __save_stack_trace( #endif walk_stackframe(tsk, &frame, save_trace, &data); - if (trace->nr_entries < trace->max_entries) - trace->entries[trace->nr_entries++] = ULONG_MAX; put_task_stack(tsk); }
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de> To: LKML <linux-kernel@vger.kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com>, x86@kernel.org, Will Deacon <will.deacon@arm.com>, Steven Rostedt <rostedt@goodmis.org>, Alexander Potapenko <glider@google.com>, Andy Lutomirski <luto@kernel.org>, Josh Poimboeuf <jpoimboe@redhat.com>, linux-arm-kernel@lists.infradead.org Subject: [RFC patch 07/41] arm64/stacktrace: Remove the pointless ULONG_MAX marker Date: Wed, 10 Apr 2019 12:28:01 +0200 [thread overview] Message-ID: <20190410103644.220247845@linutronix.de> (raw) In-Reply-To: 20190410102754.387743324@linutronix.de Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org --- arch/arm64/kernel/stacktrace.c | 4 ---- 1 file changed, 4 deletions(-) --- a/arch/arm64/kernel/stacktrace.c +++ b/arch/arm64/kernel/stacktrace.c @@ -140,8 +140,6 @@ void save_stack_trace_regs(struct pt_reg #endif walk_stackframe(current, &frame, save_trace, &data); - if (trace->nr_entries < trace->max_entries) - trace->entries[trace->nr_entries++] = ULONG_MAX; } EXPORT_SYMBOL_GPL(save_stack_trace_regs); @@ -172,8 +170,6 @@ static noinline void __save_stack_trace( #endif walk_stackframe(tsk, &frame, save_trace, &data); - if (trace->nr_entries < trace->max_entries) - trace->entries[trace->nr_entries++] = ULONG_MAX; put_task_stack(tsk); } _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-04-10 11:09 UTC|newest] Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-10 10:27 [RFC patch 00/41] stacktrace: Avoid the pointless redirection through struct stack_trace Thomas Gleixner 2019-04-10 10:27 ` [RFC patch 01/41] um/stacktrace: Remove the pointless ULONG_MAX marker Thomas Gleixner 2019-04-10 10:27 ` Thomas Gleixner 2019-04-14 20:34 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:27 ` [RFC patch 02/41] x86/stacktrace: " Thomas Gleixner 2019-04-14 20:34 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:27 ` [RFC patch 03/41] arm/stacktrace: " Thomas Gleixner 2019-04-10 10:27 ` Thomas Gleixner 2019-04-14 20:35 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:27 ` [RFC patch 04/41] sh/stacktrace: " Thomas Gleixner 2019-04-10 10:27 ` Thomas Gleixner 2019-04-14 20:36 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:27 ` [RFC patch 05/41] unicore32/stacktrace: " Thomas Gleixner 2019-04-14 20:36 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 06/41] riscv/stacktrace: " Thomas Gleixner 2019-04-10 10:28 ` Thomas Gleixner 2019-04-14 20:37 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` Thomas Gleixner [this message] 2019-04-10 10:28 ` [RFC patch 07/41] arm64/stacktrace: " Thomas Gleixner 2019-04-14 20:38 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 08/41] parisc/stacktrace: " Thomas Gleixner 2019-04-14 20:38 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 09/41] s390/stacktrace: " Thomas Gleixner 2019-04-14 20:39 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 10/41] lockdep: Remove the ULONG_MAX stack trace hackery Thomas Gleixner 2019-04-14 20:40 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 11/41] mm/slub: " Thomas Gleixner 2019-04-14 20:40 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 12/41] mm/page_owner: " Thomas Gleixner 2019-04-14 20:41 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 13/41] mm/kasan: " Thomas Gleixner 2019-04-10 11:31 ` Dmitry Vyukov 2019-04-10 11:31 ` Dmitry Vyukov 2019-04-14 20:42 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 14/41] latency_top: " Thomas Gleixner 2019-04-14 20:42 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 15/41] drm: " Thomas Gleixner 2019-04-14 20:43 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 16/41] tracing: " Thomas Gleixner 2019-04-11 2:34 ` Josh Poimboeuf 2019-04-11 3:07 ` Steven Rostedt 2019-04-14 20:44 ` [tip:core/stacktrace] " tip-bot for Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 17/41] tracing: Make stack_trace_print() static and rename it Thomas Gleixner 2019-04-10 12:47 ` Steven Rostedt 2019-04-11 0:19 ` AKASHI Takahiro 2019-04-10 10:28 ` [RFC patch 18/41] stacktrace: Provide helpers for common stack trace operations Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 19/41] lib/stackdepot: Provide functions which operate on plain storage arrays Thomas Gleixner 2019-04-10 13:39 ` Alexander Potapenko 2019-04-10 10:28 ` [RFC patch 20/41] backtrace-test: Simplify stack trace handling Thomas Gleixner 2019-04-11 2:47 ` Josh Poimboeuf 2019-04-10 10:28 ` [RFC patch 21/41] proc: Simplify task stack retrieval Thomas Gleixner 2019-04-14 14:49 ` Alexey Dobriyan 2019-04-10 10:28 ` [RFC patch 22/41] latency_top: Simplify stack trace handling Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 23/41] mm/slub: Simplify stack trace retrieval Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 24/41] mm/kmemleak: Simplify stacktrace handling Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 25/41] mm/kasan: " Thomas Gleixner 2019-04-10 11:33 ` Dmitry Vyukov 2019-04-10 11:33 ` Dmitry Vyukov 2019-04-11 2:55 ` Josh Poimboeuf 2019-04-14 16:54 ` Thomas Gleixner 2019-04-14 16:54 ` Thomas Gleixner 2019-04-14 17:00 ` Thomas Gleixner 2019-04-14 17:00 ` Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 26/41] mm/page_owner: Simplify stack trace handling Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 27/41] fault-inject: Simplify stacktrace retrieval Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 28/41] dma/debug: Simplify stracktrace retrieval Thomas Gleixner 2019-04-10 10:28 ` Thomas Gleixner 2019-04-10 11:08 ` Christoph Hellwig 2019-04-10 11:08 ` Christoph Hellwig 2019-04-10 12:08 ` Thomas Gleixner 2019-04-10 12:08 ` Thomas Gleixner 2019-04-10 12:25 ` Steven Rostedt 2019-04-10 12:25 ` Steven Rostedt 2019-04-11 17:21 ` Christoph Hellwig 2019-04-11 17:21 ` Christoph Hellwig 2019-04-11 17:36 ` Steven Rostedt 2019-04-11 17:36 ` Steven Rostedt 2019-04-11 17:44 ` Christoph Hellwig 2019-04-11 17:44 ` Christoph Hellwig 2019-04-11 3:02 ` Josh Poimboeuf 2019-04-11 3:02 ` Josh Poimboeuf 2019-04-11 3:09 ` Steven Rostedt 2019-04-11 3:09 ` Steven Rostedt 2019-04-10 10:28 ` [RFC patch 29/41] btrfs: ref-verify: Simplify stack trace retrieval Thomas Gleixner 2019-04-10 11:31 ` Johannes Thumshirn 2019-04-10 12:05 ` Thomas Gleixner 2019-04-10 12:38 ` Johannes Thumshirn 2019-04-10 12:50 ` David Sterba 2019-04-10 13:47 ` Alexander Potapenko 2019-04-10 10:28 ` [RFC patch 30/41] dm bufio: " Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 31/41] dm persistent data: Simplify stack trace handling Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 32/41] drm: Simplify stacktrace handling Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 33/41] lockdep: Remove unused trace argument from print_circular_bug() Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 34/41] lockdep: Move stack trace logic into check_prev_add() Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 35/41] lockdep: Simplify stack trace handling Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 36/41] tracing: Simplify stacktrace retrieval in histograms Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 37/41] tracing: Use percpu stack trace buffer more intelligently Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 38/41] tracing: Make ftrace_trace_userstack() static and conditional Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 39/41] tracing: Simplify stack trace retrieval Thomas Gleixner 2019-04-10 10:28 ` [RFC patch 40/41] stacktrace: Remove obsolete functions Thomas Gleixner 2019-04-11 3:33 ` Josh Poimboeuf 2019-04-11 9:13 ` Peter Zijlstra 2019-04-11 13:00 ` Josh Poimboeuf 2019-04-10 10:28 ` [RFC patch 41/41] lib/stackdepot: " Thomas Gleixner 2019-04-10 13:49 ` Alexander Potapenko 2019-04-10 11:49 ` [RFC patch 00/41] stacktrace: Avoid the pointless redirection through struct stack_trace Peter Zijlstra
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=20190410103644.220247845@linutronix.de \ --to=tglx@linutronix.de \ --cc=catalin.marinas@arm.com \ --cc=glider@google.com \ --cc=jpoimboe@redhat.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=rostedt@goodmis.org \ --cc=will.deacon@arm.com \ --cc=x86@kernel.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: linkBe 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.