[PATCH 0/3] xfs: enums don't work with __print_symbolic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi folks,

When trying to read traces from fsx failurs, I kept coming across
fields in the traces that had no output what-so-ever. The common
theme was that they all were tables that were parsed by
__print_symbolic() and the value definitions were enums.

Unfortunately, __print_symbolic() does some crazy stuff involving
stringification of the table that is passed to it, which means
the enums are turned into strings and so their never get treated as
enums after pre-processing. The result is a format string that looks
like:

# cat /sys/kernel/debug/tracing/events/xfs/xfs_iomap_alloc/format
.....
print fmt: ..... __print_symbolic(REC->type, { XFS_IO_INVALID, "invalid" }, { XFS_IO_DELALLOC, "delalloc" }, { XFS_IO_UNWRITTEN, "unwritten" }, { XFS_IO_OVERWRITE, "overwrite" }, { XFS_IO_COW, "CoW" }, { XFS_IO_HOLE, "hole" }), ....
#

And, well, XFS_IO_OVERWRITE is a string, not an integer value of 3.
Hence __print_symbolic never prints out the correct value.

The way to fix this is to turn all the enums into defined macros,
that way the preprocessor still substitutes the value for the
stringified table as the it does string matches. The result is:

__print_symbolic(REC->type, { 0, "hole" }, { 1, "delalloc" }, { 2, "unwritten" }, { 3, "overwrite" }, { 4, "CoW" })

And the trace events now print the type correctly in the trace.

This series fixes the cases I noticed by removing the various enums
that end up in trace format tables.

Cheers,

Dave.




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux