linux-kernel - Re: [PATCH v1 1/1] printk: always output coreid in caller information

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 19 May 2021 10:25:32 +0200
From:   John Ogness <john.ogness@...utronix.de>
To:     Ruifeng Zhang <ruifeng.zhang0110@...il.com>, pmladek@...e.com,
        senozhatsky@...omium.org, rostedt@...dmis.org
Cc:     linux-kernel@...r.kernel.org, ruifeng.zhang1@...soc.com,
        nianfu.bai@...soc.com, orson.zhai@...soc.com
Subject: Re: [PATCH v1 1/1] printk: always output coreid in caller information

Hello Ruifeng,

On 2021-05-19, Ruifeng Zhang <ruifeng.zhang0110@...il.com> wrote:
> From: Ruifeng Zhang <ruifeng.zhang1@...soc.com>
>
> Sometimes we want to know which cpu the process is running
> on when the log output, rather than the thread id.  So add
> the processor id output always in the caller information.
>
> caller_id bitmap:
> [63:32] thread_id
> [31]    flags of in thread context
> [30:0]  processor id

The primary purpose of @caller_id is so that the printk-subsystem can
coordinate LOG_CONT messages.

Your patch is about logging/printing additional context attributes of
the printk-caller. This is something we have discussed before [0]. I
think this should be addressed at some point. But we need to come up
with a solution that is flexible and generic. We should not be touching
these core structures every time some new attribute needs to be printed.

Also, this patch is controversial for other reasons:

- it adds bitwise logic, when it could more easily just add a new field
  (for example, caller_cpu)

- it increases the size of all records by 4 bytes

- it changes the internal structure in a way that breaks existing crash
  tools

- for non-task contexts, the increased size is wasted

John Ogness

[0] https://lore.kernel.org/lkml/20200904082438.20707-1-changki.kim@samsung.com