From patchwork Wed Nov 21 22:59:55 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Chinner X-Patchwork-Id: 10693275 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 414B113BF for ; Wed, 21 Nov 2018 23:00:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 301FE2C3E4 for ; Wed, 21 Nov 2018 23:00:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 243182C47A; Wed, 21 Nov 2018 23:00:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CA3622C3E4 for ; Wed, 21 Nov 2018 23:00:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390422AbeKVJgd (ORCPT ); Thu, 22 Nov 2018 04:36:33 -0500 Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:7031 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390411AbeKVJgc (ORCPT ); Thu, 22 Nov 2018 04:36:32 -0500 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail06.adl2.internode.on.net with ESMTP; 22 Nov 2018 09:30:03 +1030 Received: from discord.disaster.area ([192.168.1.111]) by dastard with esmtp (Exim 4.80) (envelope-from ) id 1gPbTV-0003nh-E1 for linux-xfs@vger.kernel.org; Thu, 22 Nov 2018 10:00:01 +1100 Received: from dave by discord.disaster.area with local (Exim 4.91) (envelope-from ) id 1gPbTV-0008FG-Al for linux-xfs@vger.kernel.org; Thu, 22 Nov 2018 10:00:01 +1100 From: Dave Chinner To: linux-xfs@vger.kernel.org Subject: [PATCH 0/3] xfs: enums don't work with __print_symbolic Date: Thu, 22 Nov 2018 09:59:55 +1100 Message-Id: <20181121225958.30947-1-david@fromorbit.com> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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.