All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Ranganath V N <vnranganath.20@gmail.com>
Cc: lkp@intel.com, adilger.kernel@dilger.ca,
	david.hunter.linux@gmail.com, khalid@kernel.org,
	linux-ext4@vger.kernel.org,
	linux-kernel-mentees@lists.linuxfoundation.org,
	linux-kernel@vger.kernel.org, oe-kbuild-all@lists.linux.dev,
	skhan@linuxfoundation.org
Subject: Re: [PATCH v2] fs: ext4: fix uninitialized symbols
Date: Sun, 12 Oct 2025 15:07:31 -0400	[thread overview]
Message-ID: <20251012190731.GF354523@mit.edu> (raw)
In-Reply-To: <20251011063830.47485-1-vnranganath.20@gmail.com>

On Sat, Oct 11, 2025 at 12:08:29PM +0530, Ranganath V N wrote:
> Fix the issue detected by the smatch tool.
> 
> fs/ext4/inode.c:3583 ext4_map_blocks_atomic_write_slow() error: uninitialized symbol 'next_pblk'.

This one is valid, and I agree with your proposed changed.  (Although
the worst that will happen is that in case of an ENOSPC error comined
with a corrpted file system the warning message may print an
uninitialized value.  So not a big eal, but we might as well fix it.)

> fs/ext4/namei.c:1776 ext4_lookup() error: uninitialized symbol 'de'.

This is a false positive for smatch.  There isn't actualy a prolem
here, because all of these funtions are calling ext4_find_entry() or
ext4_lookup_entry(), and the callers will not try to dereference the
pointer passed into *res_dir ('de') if the function has either
returned NULL or an ERR_PTR(), and that's in fact correct.

I don't especially mind the fix (but I do wish smatch could be
smarter).  Out of curiosity, if we move the *res_dir = NULL from
__ext4_find_entry() and move it so it's unconditionally set in
ext4_find_entry() and ext4_lookup_entry(), is that sufficient to make
smatch stop complaining?

					- Ted

  reply	other threads:[~2025-10-12 19:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-08 17:16 [PATCH] fs: ext4: fix uninitialized symbols Ranganath V N
2025-10-10 18:31 ` kernel test robot
2025-10-10 18:41 ` kernel test robot
2025-10-11  6:38   ` [PATCH v2] " Ranganath V N
2025-10-12 19:07     ` Theodore Ts'o [this message]
2025-11-06 15:45     ` Theodore Ts'o
2025-10-11  7:48 ` [PATCH] " kernel test robot

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=20251012190731.GF354523@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=david.hunter.linux@gmail.com \
    --cc=khalid@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=skhan@linuxfoundation.org \
    --cc=vnranganath.20@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.