[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250711120600.fIZo17WG@linutronix.de>
Date: Fri, 11 Jul 2025 14:06:00 +0200
From: Nam Cao <namcao@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
John Ogness <john.ogness@...utronix.de>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Gabriele Monaco <gmonaco@...hat.com>,
linux-trace-kernel@...r.kernel.org,
Josh Poimboeuf <jpoimboe@...nel.org>,
Petr Mladek <pmladek@...e.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Fix up build issues with vpanic
On Fri, Jul 11, 2025 at 01:28:44PM +0200, Peter Zijlstra wrote:
> On Fri, Jul 11, 2025 at 01:20:41PM +0200, Nam Cao wrote:
> > Hi,
> >
> > The newly introduced vpanic() has some build issues. This series fix them
> > up.
> >
> > As the vpanic() is only in ftrace tree for now, it is probably best to let
> > this series goes to ftrace tree, if everyone is okay with that.
>
> Does it make sense to make panic a static inline?
I think no, code size increases by a few K:
text data bss dec hex filename
12222627 6097658 479669 18799954 11edd52 vmlinux.before
12226703 6098618 479669 18804990 11ef0fe vmlinux.after
(it's riscv64, I had issue converting on x86 because there's another
definition of panic())
Maybe faster? But panic() doesn't need to be fast, it's not called in
normal circumstances anyway.
Best regards,
Nam
Powered by blists - more mailing lists