From: Christoph Hellwig <hch@infradead.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Vinicius Tinti <viniciustinti@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Nathan Chancellor <natechancellor@gmail.com>,
Nick Desaulniers <ndesaulniers@google.com>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
clang-built-linux@googlegroups.com
Subject: Re: [PATCH v2] ext4: Enable code path when DX_DEBUG is set
Date: Tue, 2 Feb 2021 08:05:08 +0000 [thread overview]
Message-ID: <20210202080508.GA3550351@infradead.org> (raw)
In-Reply-To: <YBg20AuSC3/9w2zz@mit.edu>
On Mon, Feb 01, 2021 at 12:13:52PM -0500, Theodore Ts'o wrote:
> However, if there *is* a bug, having an early detection that the
> representation invariant of the data structure has been violated can
> be useful in root causing a bug. This would probably be clearer if
> the code was pulled out into a separate function with comments
> explaining that this is a rep invariant check.
>
> The main thing about DX_DEBUG right now is that it is **super**
> verbose. Unwary users who enable it.... will be sorry. If we want to
> make it to be a first-class feature enabled via CONFIG_EXT4_DEBUG, we
> should convert all of the dx_trace calls to use pr_debug so they are
> enabled only if dynamic debug enables those pr_debug() statements.
> And this should absolutely be a separate patch.
Yes. The problem with a non-Kconfig ifdef is that is is almost
guaranteed to bitrot very fast, so you might as well just remove the
code. The "if (0)", while ugly, at least ensures the code still
actually is seen and checked by the compiler.
next prev parent reply other threads:[~2021-02-02 8:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-29 18:58 [PATCH] ext4: Remove unreachable code Vinicius Tinti
2021-01-30 1:35 ` Nathan Chancellor
2021-01-30 6:42 ` Andreas Dilger
2021-02-01 0:31 ` [PATCH v2] ext4: Enable code path when DX_DEBUG is set Vinicius Tinti
2021-02-01 0:48 ` Nathan Chancellor
2021-02-01 12:49 ` Christoph Hellwig
2021-02-01 16:15 ` Vinicius Tinti
2021-02-01 17:13 ` Theodore Ts'o
2021-02-01 18:41 ` Vinicius Tinti
2021-02-01 20:45 ` Andreas Dilger
2021-02-01 21:09 ` Theodore Ts'o
2021-02-01 21:16 ` Nick Desaulniers
2021-02-01 21:38 ` Theodore Ts'o
2021-02-01 21:41 ` Nick Desaulniers
2021-02-01 22:05 ` Vinicius Tinti
2021-02-01 22:48 ` Theodore Ts'o
2021-02-01 23:09 ` Nick Desaulniers
2021-02-02 8:05 ` Christoph Hellwig [this message]
2021-02-02 16:28 ` [PATCH v3] " Vinicius Tinti
2021-02-03 5:39 ` Theodore Ts'o
2021-02-03 9:51 ` Vinicius Tinti
2021-02-01 16:58 ` [PATCH v2] " Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210202080508.GA3550351@infradead.org \
--to=hch@infradead.org \
--cc=adilger.kernel@dilger.ca \
--cc=clang-built-linux@googlegroups.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=tytso@mit.edu \
--cc=viniciustinti@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).