From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Austin Kim <austindh.kim@gmail.com>
Cc: adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: remove unreachable statement inside __es_insert_extent()
Date: Thu, 22 Aug 2019 11:14:44 -0400 [thread overview]
Message-ID: <20190822151444.GA7550@mit.edu> (raw)
In-Reply-To: <20190822063743.GA36528@LGEARND20B15>
On Thu, Aug 22, 2019 at 03:37:43PM +0900, Austin Kim wrote:
> __es_insert_extent() never returns -EINVAL after BUG is executed.
> So remove unreachable code.
> ---
> fs/ext4/extents_status.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
> index a959adc..7f97360 100644
> --- a/fs/ext4/extents_status.c
> +++ b/fs/ext4/extents_status.c
> @@ -781,7 +781,6 @@ static int __es_insert_extent(struct inode *inode, struct extent_status *newes)
> p = &(*p)->rb_right;
> } else {
> BUG();
> - return -EINVAL;
This would not be safe in the case of !CONFIG_BUG. (See init/Kconfig)
It's fair to argue that we shouldn't have CONFIG_BUG --- or
!CONFIG_BUG should still cause the kernel to stop without actually
printing the full BUG information, for those tiny kernel applications
which are really worried about kernel text space.
It also would be fair to argue that we should remove the unreachable
annotation for BUG(), or even, add a *reachable* annotation to catch
code where something something terribly might happen if the kernel is
built with !CONFIG_BUG and we trip against a bug.
But this is a much higher level issue than your sending individual
paches subsystems.
Regards,
- Ted
prev parent reply other threads:[~2019-08-22 15:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 6:37 [PATCH] ext4: remove unreachable statement inside __es_insert_extent() Austin Kim
2019-08-22 15:14 ` Theodore Y. Ts'o [this message]
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=20190822151444.GA7550@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=austindh.kim@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).