All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Matthias Goergens" <matthias.goergens@gmail.com>
Cc: tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [PATCH v3] ext4: drop extra ea_inode ref in cached-block reuse path
Date: Wed, 16 Sep 2026 07:24:19 +0000	[thread overview]
Message-ID: <20260916072420.316321F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260916071046.2182813-1-matthias.goergens@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] ext4: double decrement of EA inode refcount in cache hit path
- [Low] ext4: build failure due to undefined ext4_put_ea_inode()
--

commit 918f13e87ab50346ca215dbe65d8940b03723d64
Author: Matthias Goergens <matthias.goergens@gmail.com>

    ext4: drop extra ea_inode ref in cached-block reuse path

    ext4_xattr_block_set() takes a reference on the ea_inode via
    ext4_xattr_inode_lookup_create() before it builds the new xattr block.
    The new-block path drops that reference once
    ext4_xattr_inode_inc_ref_all() has counted every entry in the block.
    When a separately built block is discarded in favour of an identical
    cached block, the cached block already counts its entries and the
    lookup reference is left unbalanced.

> diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
> index 6127e94ea4f5d..0da96678051e4 100644
> --- a/fs/ext4/xattr.c
> +++ b/fs/ext4/xattr.c
> @@ -2032,6 +2032,24 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
>  			mb_cache_entry_touch(ea_block_cache, ce);
>  			mb_cache_entry_put(ea_block_cache, ce);
>  			ce = NULL;
> +			if (ea_inode && !(bs->bh && s->base == bs->bh->b_data)) {
> +				/*
> +				 * The cached block already owns its EA inode
> +				 * references.  For an in-place update the lookup
> +				 * reference belongs to the old block and is
> +				 * dropped when that block is released.
> +				 */
> +				error = ext4_xattr_inode_dec_ref(handle,
> +								 ea_inode);

[Severity: Critical]
Does this code leave ea_inode set after successfully decrementing the
reference count?

If ea_inode isn't cleared here (and its in-memory reference via iput
isn't dropped), won't execution eventually fall through to the cleanup
label below where ext4_xattr_inode_dec_ref is unconditionally called a
second time for the non-NULL pointer?

> +				if (error) {
> +					EXT4_ERROR_INODE(inode,
> +							 "dec ref error=%d",
> +							 error);
> +					ext4_put_ea_inode(ea_inode);

[Severity: Low]
Does this break the build? ext4_put_ea_inode appears to be undefined.
Should this be iput?

> +					ea_inode = NULL;
> +					goto cleanup;
> +				}
> +			}

[ ... ]

>  	error = 0;
>  
>  cleanup:
>  	if (ea_inode) {
>  		int error2;
>  
>  		error2 = ext4_xattr_inode_dec_ref(handle, ea_inode);
>  		if (error2)
>  			ext4_warning_inode(ea_inode, "dec ref error=%d",
>  					   error2);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916071046.2182813-1-matthias.goergens@gmail.com?part=1

  reply	other threads:[~2026-09-16  7:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16  7:10 [PATCH v3] ext4: drop extra ea_inode ref in cached-block reuse path Matthias Goergens
2026-09-16  7:24 ` sashiko-bot [this message]
2026-09-23 10:18   ` Matthias Goergens
2026-09-24 16:56 ` Jan Kara

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=20260916072420.316321F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=matthias.goergens@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --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 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.