Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Dmitry Monakhov <dmonakhov@gmail.com>
To:     linux-ext4@vger.kernel.org
Cc:     tytso@mit.edu, Dmitry Monakhov <dmonakhov@gmail.com>
Subject: [PATCH 0/2] ext4: Workaround trace event flag decoding issues
Date:   Thu, 14 Nov 2019 07:03:28 +0000
Message-Id: <20191114070330.14115-1-dmonakhov@gmail.com>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk


Trace's macro __print_flags() produce raw event's decraration w/o knowing actual
flags value. For example trace_ext4_map_blocks_exit() has two __print_flags
tables, one for EXT4_GET_BLOCKS_XX, and second for EXT4_MAP_XXX

cat /sys/kernel/debug/tracing/events/ext4/ext4_ext_map_blocks_exit/format
..
print fmt: "dev %d,%d ino %lu flags %s lblk %u pblk %llu len %u mflags %s ret %d",
....
 __print_flags(REC->flags, "|", { 0x0001, "CREATE" }, { 0x0002, "UNWRIT" },...
 __print_flags(REC->mflags, "", { (1 << BH_New), "N" }, { (1 << BH_Mapped), "M" }..

First macro expanded w/o issued because EXT4_GET_BLOCKS_XXX flags are explicit
numbers, but second macro stil contains text fields because it depends on
implicit enum values. It is important to note that this is exact representation
of event's binary format. This means that  perf-script can not decode bintrace
file because BH_XXX is just a text token which is unknown to userspace.
As result perf fail to decode it and fallback to dump it as raw hex number.
For example:
  ext4:ext4_ext_map_blocks_exit: dev 253,0 ino 12 flags CREATE lblk 0 pblk 34304 len 1 mflags 0x60 ret 1

I tend to agree that this is likely to be trace API issue, but it looks like that
EXT4 is the only subsystem which is affected. Others already workaround this by
using explicit numbers. Let's do the same trick.
TOC:
   ext4: Use raw numbers for EXT4_MAP_XXX flags
   ext4: Fix extent_status trace events