Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 10 Aug 2023 14:48:45 +0300
From:   Dan Carpenter <dan.carpenter@linaro.org>
To:     Zhang Yi <yi.zhang@huawei.com>
Cc:     linux-ext4@vger.kernel.org
Subject: Re: [bug report] ext4: convert symlink external data block mapping
 to bdev
Message-ID: <0ff22f40-3eee-44ed-970d-8ee6af7979e4@kadam.mountain>
References: <797feb23-f8c8-4ce7-b25c-b4f591be1387@moroto.mountain>
 <7f69ac7e-bfad-ec37-f48b-0633583838d5@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7f69ac7e-bfad-ec37-f48b-0633583838d5@huawei.com>
Precedence: bulk

On Thu, Aug 10, 2023 at 07:25:02PM +0800, Zhang Yi wrote:
> On 2023/8/10 18:31, Dan Carpenter wrote:
> > Hello Zhang Yi,
> > 
> > The patch 6493792d3299: "ext4: convert symlink external data block
> > mapping to bdev" from Apr 24, 2022 (linux-next), leads to the
> > following Smatch static checker warning:
> > 
> > 	fs/ext4/namei.c:3353 ext4_init_symlink_block()
> > 	error: potential NULL/IS_ERR bug 'bh'
> > 
> > fs/ext4/namei.c
> >     3337 static int ext4_init_symlink_block(handle_t *handle, struct inode *inode,
> >     3338                                    struct fscrypt_str *disk_link)
> >     3339 {
> >     3340         struct buffer_head *bh;
> >     3341         char *kaddr;
> >     3342         int err = 0;
> >     3343 
> >     3344         bh = ext4_bread(handle, inode, 0, EXT4_GET_BLOCKS_CREATE);
> >     3345         if (IS_ERR(bh))
> >     3346                 return PTR_ERR(bh);
> > 
> >>From reading the code, it looks like ext4_bread() can return both error
> > pointers and NULL.  (Second return statement).
> 
> Hello, Dan,
> 
> After checking the code, we have passed in EXT4_GET_BLOCKS_CREATE to
> ext4_bread(), the return value must be an error code or a valid
> buffer_head, it's impossible to return NULL. So I think the warning
> is a false positive.
> 

Yep.  You're right.  Thanks for taking a look at this.

Eventually, I will get around to tracking bits set across function
boundaries and that should silence this warning.

regards,
dan carpenter