Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Fri, 22 Sep 2023 09:47:44 +0200
From:   Petr Mladek <pmladek@suse.com>
To:     Enlin Mu <enlinmu@gmail.com>
Cc:     John Ogness <john.ogness@linutronix.de>,
        Enlin Mu <enlin.mu@outlook.com>, rostedt@goodmis.org,
        senozhatsky@chromium.org, keescook@chromium.org,
        tony.luck@intel.com, gpiccoli@igalia.com, enlin.mu@unisoc.com,
        linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] printk: add cpu id information to printk() output
Message-ID: <ZQ1GoF4LjwRM2Ec3@alley>
References: <JH0PR04MB7072A4B6946EAEEB1EB8B0BE8AF6A@JH0PR04MB7072.apcprd04.prod.outlook.com>
 <8734zfx2bo.fsf@jogness.linutronix.de>
 <CAAfh-jOnirbUjUYDhWqqUe8kPL=1FcDdZoSax5R-nGwO1CO60g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAfh-jOnirbUjUYDhWqqUe8kPL=1FcDdZoSax5R-nGwO1CO60g@mail.gmail.com>
Precedence: bulk

On Fri 2023-09-22 15:34:44, Enlin Mu wrote:
> John Ogness <john.ogness@linutronix.de> 于2023年9月15日周五 16:34写道：
> >
> > On 2023-09-15, Enlin Mu <enlin.mu@outlook.com> wrote:
> > > Sometimes we want to print cpu id of printk() messages to consoles
> > >
> > > diff --git a/include/linux/threads.h b/include/linux/threads.h
> > > index c34173e6c5f1..6700bd9a174f 100644
> > > --- a/include/linux/threads.h
> > > +++ b/include/linux/threads.h
> > > @@ -34,6 +34,9 @@
> > >  #define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \
> > >       (sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
> > >
> > > +#define CPU_ID_SHIFT 23
> > > +#define CPU_ID_MASK  0xff800000
> >
> > This only supports 256 CPUs. I think it doesn't make sense to try to
> > squish CPU and Task IDs into 32 bits.
> >
> > What about introducing a caller_id option to always only print the CPU
> > ID? Or do you really need Task _and_ CPU?
>
> Yes, I need it.
> For SOC manufacturer, sometimes cpu is not stable, we need some debug
> tools for this exceptions.
> When an exception occurs, we may not be able to detect it in a timely
> manner, but through Task _and_ CPU, we can roughly locate the CPU at
> the time of the exception.

Would frace be enough in this case? It has already been suggested
earlier.

The problem is that adding CPU into would require changes in
the metadata stored in the ring buffer. And it would require
updating userspace tools which read the log from a crash dump.
It means that such a feature would need a lot of effort.
And I would prefer to avoid it when there is another solution.

If you debug the problem by adding extra printk messages
you might also print the current CPU in the debug messages.

Best Regards,
Petr