From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
clang-built-linux@googlegroups.com,
Nick Desaulniers <ndesaulniers@google.com>,
Nathan Chancellor <natechancellor@gmail.com>,
Eric Whitney <enwlinux@gmail.com>, Sean Fu <fxinrong@gmail.com>,
Jan Kara <jack@suse.cz>, Eric Biggers <ebiggers@google.com>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: use BUG() instead of BUG_ON(1)
Date: Mon, 25 Mar 2019 11:14:22 -0700 [thread overview]
Message-ID: <20190325181422.GH1173@magnolia> (raw)
In-Reply-To: <20190325130040.1437445-1-arnd@arndb.de>
On Mon, Mar 25, 2019 at 02:00:25PM +0100, Arnd Bergmann wrote:
> BUG_ON(1) leads to bogus warnings from clang when
> CONFIG_PROFILE_ANNOTATED_BRANCHES is set:
>
> fs/ext4/inode.c:544:4: error: variable 'retval' is used uninitialized whenever 'if' condition is false
> [-Werror,-Wsometimes-uninitialized]
> BUG_ON(1);
> ^~~~~~~~~
> include/asm-generic/bug.h:61:36: note: expanded from macro 'BUG_ON'
> ^~~~~~~~~~~~~~~~~~~
> include/linux/compiler.h:48:23: note: expanded from macro 'unlikely'
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> fs/ext4/inode.c:591:6: note: uninitialized use occurs here
> if (retval > 0 && map->m_flags & EXT4_MAP_MAPPED) {
> ^~~~~~
> fs/ext4/inode.c:544:4: note: remove the 'if' if its condition is always true
> BUG_ON(1);
> ^
> include/asm-generic/bug.h:61:32: note: expanded from macro 'BUG_ON'
> ^
> fs/ext4/inode.c:502:12: note: initialize the variable 'retval' to silence this warning
>
> Change it to BUG() so clang can see that this code path can never
> continue.
I grok that most of these look like "should never get here" assertions,
but shouldn't we be converting these BUG*() calls to "shut down fs,
bounce error back to userspace" instead of killing the whole kernel?
(He says knowing that ripping all of those out is its own project... :P)
--D
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> fs/ext4/extents_status.c | 4 ++--
> fs/ext4/inode.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
> index 2b439afafe13..023a3eb3afa3 100644
> --- a/fs/ext4/extents_status.c
> +++ b/fs/ext4/extents_status.c
> @@ -711,7 +711,7 @@ static void ext4_es_insert_extent_ind_check(struct inode *inode,
> * We don't need to check unwritten extent because
> * indirect-based file doesn't have it.
> */
> - BUG_ON(1);
> + BUG();
> }
> } else if (retval == 0) {
> if (ext4_es_is_written(es)) {
> @@ -780,7 +780,7 @@ static int __es_insert_extent(struct inode *inode, struct extent_status *newes)
> }
> p = &(*p)->rb_right;
> } else {
> - BUG_ON(1);
> + BUG();
> return -EINVAL;
> }
> }
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index b32a57bc5d5d..190f0478582a 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -541,7 +541,7 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode,
> map->m_len = retval;
> retval = 0;
> } else {
> - BUG_ON(1);
> + BUG();
> }
> #ifdef ES_AGGRESSIVE_TEST
> ext4_map_blocks_es_recheck(handle, inode, map,
> @@ -1876,7 +1876,7 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock,
> else if (ext4_es_is_unwritten(&es))
> map->m_flags |= EXT4_MAP_UNWRITTEN;
> else
> - BUG_ON(1);
> + BUG();
>
> #ifdef ES_AGGRESSIVE_TEST
> ext4_map_blocks_es_recheck(NULL, inode, map, &orig_map, 0);
> --
> 2.20.0
>
next prev parent reply other threads:[~2019-03-25 18:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 13:00 [PATCH] ext4: use BUG() instead of BUG_ON(1) Arnd Bergmann
2019-03-25 17:29 ` Nick Desaulniers
2019-03-25 17:30 ` Jan Kara
2019-03-25 18:14 ` Darrick J. Wong [this message]
2019-03-25 19:59 ` Andreas Dilger
2019-04-07 16:29 ` 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=20190325181422.GH1173@magnolia \
--to=darrick.wong@oracle.com \
--cc=adilger.kernel@dilger.ca \
--cc=arnd@arndb.de \
--cc=clang-built-linux@googlegroups.com \
--cc=ebiggers@google.com \
--cc=enwlinux@gmail.com \
--cc=fxinrong@gmail.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=tytso@mit.edu \
/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