public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
> 

  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