From: Brian Foster <bfoster@redhat.com>
To: libaokun@huaweicloud.com
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu,
adilger.kernel@dilger.ca, jack@suse.cz,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
yangerkun@huawei.com, Baokun Li <libaokun1@huawei.com>
Subject: Re: [PATCH] ext4: goto right label 'out_mmap_sem' in ext4_setattr()
Date: Thu, 13 Feb 2025 07:51:25 -0500 [thread overview]
Message-ID: <Z63qzaDONxM9fRVl@bfoster> (raw)
In-Reply-To: <20250213112247.3168709-1-libaokun@huaweicloud.com>
On Thu, Feb 13, 2025 at 07:22:47PM +0800, libaokun@huaweicloud.com wrote:
> From: Baokun Li <libaokun1@huawei.com>
>
> Otherwise, if ext4_inode_attach_jinode() fails, a hung task will
> happen because filemap_invalidate_unlock() isn't called to unlock
> mapping->invalidate_lock. Like this:
>
> EXT4-fs error (device sda) in ext4_setattr:5557: Out of memory
> INFO: task fsstress:374 blocked for more than 122 seconds.
> Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:fsstress state:D stack:0 pid:374 tgid:374 ppid:373
> task_flags:0x440140 flags:0x00000000
> Call Trace:
> <TASK>
> __schedule+0x2c9/0x7f0
> schedule+0x27/0xa0
> schedule_preempt_disabled+0x15/0x30
> rwsem_down_read_slowpath+0x278/0x4c0
> down_read+0x59/0xb0
> page_cache_ra_unbounded+0x65/0x1b0
> filemap_get_pages+0x124/0x3e0
> filemap_read+0x114/0x3d0
> vfs_read+0x297/0x360
> ksys_read+0x6c/0xe0
> do_syscall_64+0x4b/0x110
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Fixes: c7fc0366c656 ("ext4: partial zero eof block on unaligned inode size extension")
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> ---
First off, thank you for catching this. :)
> fs/ext4/inode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 3cc8da6357aa..04ffd802dbde 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -5452,7 +5452,7 @@ int ext4_setattr(struct mnt_idmap *idmap, struct dentry *dentry,
> oldsize & (inode->i_sb->s_blocksize - 1)) {
> error = ext4_inode_attach_jinode(inode);
> if (error)
> - goto err_out;
> + goto out_mmap_sem;
> }
This looks reasonable to me, but I notice that the immediate previous
error check looks like this:
...
rc = ext4_break_layouts(inode);
if (rc) {
filemap_invalidate_unlock(inode->i_mapping);
goto err_out;
}
...
... and then the following after the broken logic uses out_mmap_sem.
Could we be a little more consistent here one way or the other? The
change looks functionally correct to me either way:
Reviewed-by: Brian Foster <bfoster@redhat.com>
Brian
>
> handle = ext4_journal_start(inode, EXT4_HT_INODE, 3);
> --
> 2.39.2
>
>
next prev parent reply other threads:[~2025-02-13 12:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 11:22 [PATCH] ext4: goto right label 'out_mmap_sem' in ext4_setattr() libaokun
2025-02-13 12:51 ` Brian Foster [this message]
2025-02-13 13:20 ` Baokun Li
2025-02-13 13:41 ` Brian Foster
2025-02-13 14:29 ` Jan Kara
2025-03-18 3:41 ` 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=Z63qzaDONxM9fRVl@bfoster \
--to=bfoster@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=libaokun1@huawei.com \
--cc=libaokun@huaweicloud.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox