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]
Message-ID: <87v97ft9j7.fsf@jogness.linutronix.de>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ