linux-kernel - Re: [PATCH] tracing: Add bitmask-list option for human-readable bitmask display

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] [day] [month] [year] [list]

Message-ID: <20251226112054.44b2e440@gandalf.local.home>
Date: Fri, 26 Dec 2025 11:20:54 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Aaron Tomlin <atomlin@...mlin.com>
Cc: mhiramat@...nel.org, mark.rutland@....com,
 mathieu.desnoyers@...icios.com, corbet@....net, sean@...e.io,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, Valentin Schneider <vschneid@...hat.com>
Subject: Re: [PATCH] tracing: Add bitmask-list option for human-readable
 bitmask display

On Thu, 25 Dec 2025 02:38:03 -0500
Aaron Tomlin <atomlin@...mlin.com> wrote:

> On Wed, Dec 24, 2025 at 08:58:48AM -0500, Steven Rostedt wrote:
> > Should we just make all cpu bitmask range lists instead?  
> 
> Hi Steve,
> 
> I am somewhat hesitant to adopt that suggestion as I would prefer to avoid
> breaking any existing tooling that relies upon the default hexadecimal
> bitmask format.

I am too. But the "do not break user space" rule is basically, "it's only
broken if user space notices". If people complain about the change, we can
always revert it ;-)

> 
> Whilst range lists are undoubtedly superior for human interpretation, the
> hexadecimal output is a well-established standard throughout the kernel.
> For instance, the hexadecimal format is still strictly adhered to for
> "Cpus_allowed:" within /proc/[pid]/status. Introducing a global change to
> ftrace defaults could disrupt parsers and scripts that expect this
> consistency across the system.

Really, any scripts that parse the ASCII output is broken by design, as
things change there all the time, and it can be really slow to read.
There's a binary interface for such things. Heck, I bet this change would
probably make the scripts simpler, as searching ranges is easier to parse
than a hex number.

> 
> By leveraging the existing bitmask-list trace option via
> trace_print_bitmask_seq(), we offer users the requisite flexibility for
> high-core-count systems whilst preserving backward compatibility for the
> wider ecosystem.

Perhaps it should only be cpumask-list, and only touch bitmasks that are
CPU lists. Although, right now I only see one user of the bitmask code, and
it's using it on a cpumask. Perhaps we should change it to use the cpumask.

There's not many users of the bitmask in tracepoints, and it is mostly with
the new IPI tracepoints (Cc'ing Valentin to get his throughts).

> 
> I shall send a new version of the patch shortly. This version incorporates
> the use of iter->tmp_seq to ensure the implementation is robust,
> instance-aware, and free from buffer contention or duplication issues.

Thanks,

-- Steve