Hi Steve,

This patch adds support for displaying bitmasks in human-readable list
format (e.g., 0,2-5,7) in addition to the default hexadecimal bitmap
representation. This is particularly useful when tracing CPU masks and
other large bitmasks where individual bit positions are more meaningful
than their hexadecimal encoding.

When the "bitmask-list" option is enabled, the printk "%*pbl" format
specifier is used to render bitmasks as comma-separated ranges, making
trace output easier to interpret for complex CPU configurations and
large bitmask values.

This iteration incorporates the use of iter->tmp_seq to ensure the
implementation is robust, instance-aware, and free from buffer contention
or duplication issues.

Please let me know your thoughts.


Changes since v2 [1]:
 - Fix build error by correcting redundant and missing stubs in the
   !CONFIG_TRACING block (0-DAY CI Kernel Test Service)

Changes since v1 [2]:
 - Introduce new helper trace_seq_bitmask_list() (Steven Rostedt)
 - Use iter->tmp_seq as a scratchpad to prevent buffer collisions and
   duplication
 - Update trace_print_bitmask_seq() signature to accept trace_iterator
   instead of trace_seq
 - Add declaration for trace_seq_bitmask_list() and provide necessary stub
   definitions
 - Update __get_bitmask and __get_rel_bitmask macros to pass iter to the
   bitmask helper
 - Implement instance-aware bitmask formatting using iter->tmp_seq as a
   scratchpad to prevent buffer collisions and duplication

[1]: https://lore.kernel.org/lkml/20251225080216.2196411-2-atomlin@atomlin.com/
[2]: https://lore.kernel.org/lkml/20251223035622.2084081-1-atomlin@atomlin.com/

Aaron Tomlin (1):
  tracing: Add bitmask-list option for human-readable bitmask display

 Documentation/trace/ftrace.rst             |  9 +++++++
 include/linux/trace_events.h               |  8 +++---
 include/linux/trace_seq.h                  | 12 ++++++++-
 include/trace/stages/stage3_trace_output.h |  4 +--
 kernel/trace/trace.h                       |  1 +
 kernel/trace/trace_output.c                | 30 +++++++++++++++++++---
 kernel/trace/trace_seq.c                   | 29 ++++++++++++++++++++-
 7 files changed, 82 insertions(+), 11 deletions(-)

-- 
2.51.0

On Fri, Dec 26, 2025 at 11:07:23AM -0500, Aaron Tomlin wrote:
> Hi Steve,
> 
> This patch adds support for displaying bitmasks in human-readable list
> format (e.g., 0,2-5,7) in addition to the default hexadecimal bitmap
> representation. This is particularly useful when tracing CPU masks and
> other large bitmasks where individual bit positions are more meaningful
> than their hexadecimal encoding.
> 
> When the "bitmask-list" option is enabled, the printk "%*pbl" format
> specifier is used to render bitmasks as comma-separated ranges, making
> trace output easier to interpret for complex CPU configurations and
> large bitmask values.
> 
> This iteration incorporates the use of iter->tmp_seq to ensure the
> implementation is robust, instance-aware, and free from buffer contention
> or duplication issues.
> 
> Please let me know your thoughts.

Hi Steve,

I would like to ask if this iteration is suitable for inclusion, or should
any further refinements be made?


Kind regards,
-- 
Aaron Tomlin

On Sat, 10 Jan 2026 16:06:02 -0500
Aaron Tomlin <atomlin@atomlin.com> wrote:

> On Fri, Dec 26, 2025 at 11:07:23AM -0500, Aaron Tomlin wrote:
> > Hi Steve,
> > 
> > This patch adds support for displaying bitmasks in human-readable list
> > format (e.g., 0,2-5,7) in addition to the default hexadecimal bitmap
> > representation. This is particularly useful when tracing CPU masks and
> > other large bitmasks where individual bit positions are more meaningful
> > than their hexadecimal encoding.
> > 
> > When the "bitmask-list" option is enabled, the printk "%*pbl" format
> > specifier is used to render bitmasks as comma-separated ranges, making
> > trace output easier to interpret for complex CPU configurations and
> > large bitmask values.
> > 
> > This iteration incorporates the use of iter->tmp_seq to ensure the
> > implementation is robust, instance-aware, and free from buffer contention
> > or duplication issues.
> > 
> > Please let me know your thoughts.  
> 
> Hi Steve,
> 
> I would like to ask if this iteration is suitable for inclusion, or should
> any further refinements be made?
> 

You can always check the status of a patch from patchwork. This one is here:

  https://patchwork.kernel.org/project/linux-trace-kernel/patch/20251226160724.2246493-2-atomlin@atomlin.com/

The states are:

  New		- I haven't looked at it.
  Under Review	- I have it in a local queue (can still be rejected)
  Queued	- It's moved to linux-next
  Accepted	- It's in Linus's tree

Other states I will most likely have a response to.

This one is currently in the "Under Review" state. It also means I haven't
found anything wrong with it. It just hasn't gone through all my tests.

-- Steve


> 
> Kind regards,