linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@dilger.ca>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Theodore Ts'o <tytso@mit.edu>,
	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>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ext4: use BUG() instead of BUG_ON(1)
Date: Mon, 25 Mar 2019 13:59:58 -0600	[thread overview]
Message-ID: <9F56F958-2DEF-4350-8BBC-9A40598D0365@dilger.ca> (raw)
In-Reply-To: <20190325181422.GH1173@magnolia>

[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]

On Mar 25, 2019, at 12:14 PM, Darrick J. Wong <darrick.wong@oracle.com> wrote:
> 
> 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)

We definitely shouldn't be adding "BUG()" or "BUG_ON()" to active code, but
rather call ext4_error() and let the admin to set "errors=panic" if they
want this action, or leave "errors=remount-ro" (which is the default these
days) and just return an error to userspace.

Looking at the nearby code, it is using pr_warn("ES insert assertion failed..."
instead of using an actual assertion for the failure cases.

I guess a saving grace is that this code is only enabled if ES_AGGRESSIVE_TEST
is defined, which it is not by default, so probably it is only when some
developer is testing this code.  So using BUG() is probably OK in this case.

Cheers, Andreas

> 
>> 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


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

  reply	other threads:[~2019-03-25 20:00 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
2019-03-25 19:59   ` Andreas Dilger [this message]
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=9F56F958-2DEF-4350-8BBC-9A40598D0365@dilger.ca \
    --to=adilger@dilger.ca \
    --cc=arnd@arndb.de \
    --cc=clang-built-linux@googlegroups.com \
    --cc=darrick.wong@oracle.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;
as well as URLs for NNTP newsgroup(s).