From: Brian Foster <bfoster@redhat.com>
To: Baokun Li <libaokun1@huawei.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 <libaokun@huaweicloud.com>
Subject: Re: [PATCH] ext4: goto right label 'out_mmap_sem' in ext4_setattr()
Date: Thu, 13 Feb 2025 08:41:15 -0500 [thread overview]
Message-ID: <Z632e360SySsBRSk@bfoster> (raw)
In-Reply-To: <5e39cc34-99e8-451e-8f61-4f0187a8db6a@huawei.com>
On Thu, Feb 13, 2025 at 09:20:21PM +0800, Baokun Li wrote:
> Hi,
>
> On 2025/2/13 20:51, Brian Foster wrote:
> > 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. :)
> Thanks for your review!
> >
> > > 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
> Indeed, this is confusing.
>
> The reason is that we don't want to call ext4_std_error() when
> ext4_break_layouts() fails. So we first store the error in 'rc', and then
> pass the error to 'error' at the end. (See b9c1c26739ec
> ("ext4: gracefully handle ext4_break_layouts() failure during truncate"))
>
> However, because 'error' is not assigned, the goto out_mmap_sem label will
> execute some code that shouldn't be executed. Therefore, in the error
> handling of ext4_break_layouts(), we unlock and then goto err_out label.
>
> While under normal error conditions, 'error' is assigned, and it should
> enter the out_mmap_sem label. Therefore, in the error handling of
> ext4_inode_attach_jinode(), we directly goto out_mmap_sem label.
>
> The handling of 'rc' in this function is indeed very subtle.
>
Ah, indeed.. I glossed over the use of rc in there on my quick read.
Thanks for the clarification!
Brian
>
> Cheers,
> Baokun
> > > handle = ext4_journal_start(inode, EXT4_HT_INODE, 3);
> > > --
> > > 2.39.2
> > >
> > >
>
next prev parent reply other threads:[~2025-02-13 13:38 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
2025-02-13 13:20 ` Baokun Li
2025-02-13 13:41 ` Brian Foster [this message]
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=Z632e360SySsBRSk@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 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.