All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wangshaobo (bobo)" <bobo.shaobowang@huawei.com>
To: unlisted-recipients:; (no To-header on input)
Cc: <liwei391@huawei.com>, <rpeterso@redhat.com>,
	<agruenba@redhat.com>, <cluster-devel@redhat.com>,
	<syzkaller-bugs@googlegroups.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] gfs2: Fix missing cleanup quota in gfs2_put_super()
Date: Sat, 3 Dec 2022 15:28:00 +0800	[thread overview]
Message-ID: <5c66dbe3-5701-ba42-7933-73a31c2dc891@huawei.com> (raw)
In-Reply-To: <20221201115032.3540859-1-bobo.shaobowang@huawei.com>



在 2022/12/1 19:50, Wang ShaoBo 写道:
> syzbot has reported an interesting issue:
> 
> INFO: task syz-executor888:3126 blocked for more than 143 seconds.
>        Not tainted 6.1.0-rc6-syzkaller-32662-g6d464646530f #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:syz-executor888 state:D stack:0     pid:3126  ppid:3124   flags:0x00000000
> Call trace:
>   __switch_to+0x180/0x298 arch/arm64/kernel/process.c:553
>   context_switch kernel/sched/core.c:5209 [inline]
>   __schedule+0x408/0x594 kernel/sched/core.c:6521
>   schedule+0x64/0xa4 kernel/sched/core.c:6597
>   schedule_timeout+0x108/0x1b4 kernel/time/timer.c:1935
>   gfs2_gl_hash_clear+0xd4/0x1b0 fs/gfs2/glock.c:2263
>   gfs2_put_super+0x318/0x390 fs/gfs2/super.c:620
>   generic_shutdown_super+0x94/0x198 fs/super.c:492
>   kill_block_super+0x30/0x78 fs/super.c:1428
>   gfs2_kill_sb+0x68/0x78
>   deactivate_locked_super+0x70/0xe8 fs/super.c:332
>   deactivate_super+0xd0/0xd4 fs/super.c:363
>   cleanup_mnt+0x184/0x1c0 fs/namespace.c:1186
>   __cleanup_mnt+0x20/0x30 fs/namespace.c:1193
>   task_work_run+0x100/0x148 kernel/task_work.c:179
>   resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
>   do_notify_resume+0x174/0x1f0 arch/arm64/kernel/signal.c:1127
>   prepare_exit_to_user_mode arch/arm64/kernel/entry-common.c:137 [inline]
>   exit_to_user_mode arch/arm64/kernel/entry-common.c:142 [inline]
>   el0_svc+0x9c/0x150 arch/arm64/kernel/entry-common.c:638
>   el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
>   el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:584
> 
> Showing all locks held in the system:
> 1 lock held by rcu_tasks_kthre/11:
>   #0: ffff80000d4a4768 (rcu_tasks.tasks_gp_mutex){+.+.}-{3:3}, at: rcu_tasks_one_gp+0x3c/0x450 kernel/rcu/tasks.h:507
> 1 lock held by rcu_tasks_trace/12:
>   #0: ffff80000d4a4db8 (rcu_tasks_trace.tasks_gp_mutex){+.+.}-{3:3}, at: rcu_tasks_one_gp+0x3c/0x450 kernel/rcu/tasks.h:507
> 1 lock held by khungtaskd/27:
>   #0: ffff80000d4a4640 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x4/0x48 include/linux/rcupdate.h:303
> 2 locks held by getty/2759:
>   #0: ffff0000c7d7e098 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x28/0x58 drivers/tty/tty_ldisc.c:244
>   #1: ffff80000f6be2f0 (&ldata->atomic_read_lock){+.+.}-{3:3}, at: n_tty_read+0x19c/0x89c drivers/tty/n_tty.c:2177
> 1 lock held by syz-executor888/3126:
>   #0: ffff0000cae680e0 (&type->s_umount_key#41){+.+.}-{3:3}, at: deactivate_super+0xc8/0xd4 fs/super.c:362
> 
> =============================================
> 
> One task blocked after executing gfs2_gl_hash_clear(), it looks
> like go to sleep for waiting the condition (&sdp->sd_glock_disposal == 0),
> this field sd_glock_disposal is used to count the getting times
> that calling gfs2_glock_get() success, In most cases, when we operate
> the mount interface, we will finally call this function:
> 
>                                do_mount()
>                                path_mount()
>                                vfs_get_tree()
>                                gfs2_get_tree()
>                                get_tree_bdev()
>                                gfs2_fill_super()
>                       ________ init_inodes()_____________
>                      V                                   V
>         gfs2_lookup_simple()                         gfs2_rindex_update()
>         gfs2_lookupi()                               gfs2_ri_update()
>         gfs2_dir_search()                         -> read_rindex_entry() //*gfs2_rgrpd->rd_gl
>      -> gfs2_inode_lookup() //*gfs2_inode->i_gl  |__ gfs2_glock_get()
>     |__gfs2_glock_get()
> 
> Correspondingly, release this glock's reference and decrease
> sdp->sd_glock_disposal through this path when umount:
> 
>                                cleanup_mnt()
>                                deactivate_super()
>                                deactivate_locked_super()
>                                gfs2_kill_sb()
>                                kill_block_super()
>                                generic_shutdown_super()
>            _gfs2_rgrpd->rd_gl__gfs2_put_super()__gfs2_inode->i_gl__
>           V                                                        V
> 	gfs2_clear_rgrpd()                           gfs2_put_super()
> 	gfs2_glock_put()                             iput()
>          gfs2_glock_free()                            evict()
>                                                       gfs2_evict_inode()
>                                                       gfs2_glock_put_eventually()
>                                                       gfs2_glock_put()
>                                                       gfs2_glock_free()
> 
> But if calling reconfigure_super() from sysfs between mount and umount,
> this path will also take the glock lock and increase sdp->sd_glock_disposal
> as it also call gfs2_glock_get():
> 
>     reconfigure_super()
>      gfs2_reconfigure()
>        gfs2_make_fs_rw() //remount filesystem read-write
>         gfs2_quota_init()
>       -> qd_alloc()      //*gfs2_quota_data->qd_gl
>      |___ gfs2_glock_get()
> 
> This relies on gfs2_quota_cleanup() that is eventually called by
> gfs2_make_fs_ro() to clean up but unfortunately the file system
> has not been remounted at this time, the condition (!sb_rdonly(sb))
> is false and gfs2_make_fs_ro() can not be called, ultimately makes
> sdp->sd_glock_disposal never be 0.
> 
> This add calling gfs2_quota_cleanup() when this filesystem remains
> readOnly, in this case we don't need sync quota or other operation
> otherwise the filesystem was really remounted.
> 
> But this modification will trigger this warning:
> 
>     WARNING: CPU: 7 PID: 2595 at include/linux/backing-dev.h:246 __folio_mark_dirty+0x559/0x7b0
I paste wrong, the warning is:
gfs2: fsid=mounts.0: warning: assertion "!qd->qd_change" failed at 
function = gfs2_quota_cleanup, file = fs/gfs2/quota.c, line = 1474

qd->qd_change has been changed in gfs2_quota_init(), but it looks
we don't need to do anything before remounting the file system as 
read-write.
> 
> We can filter this warning with adding a parameter as it doesn't
> really make sense here.
> 
> Fixes: 9e6e0a128bca ("GFS2: Merge mount.c and ops_super.c into super.c")
> Reported-by: syzbot+ed7d0f71a89e28557a77@syzkaller.appspotmail.com
> Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
> ---
>   fs/gfs2/super.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
> index b018957a1bb2..9a3c6da8db55 100644
> --- a/fs/gfs2/super.c
> +++ b/fs/gfs2/super.c
> @@ -586,7 +586,10 @@ static void gfs2_put_super(struct super_block *sb)
>   
>   	if (!sb_rdonly(sb)) {
>   		gfs2_make_fs_ro(sdp);
> +	} else {
> +		gfs2_quota_cleanup(sdp);
>   	}
> +
>   	WARN_ON(gfs2_withdrawing(sdp));
>   
>   	/*  At this point, we're through modifying the disk  */
> 

WARNING: multiple messages have this Message-ID (diff)
From: Wangshaobo (bobo) <bobo.shaobowang@huawei.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [RFC PATCH] gfs2: Fix missing cleanup quota in gfs2_put_super()
Date: Sat, 3 Dec 2022 15:28:00 +0800	[thread overview]
Message-ID: <5c66dbe3-5701-ba42-7933-73a31c2dc891@huawei.com> (raw)
In-Reply-To: <20221201115032.3540859-1-bobo.shaobowang@huawei.com>



? 2022/12/1 19:50, Wang ShaoBo ??:
> syzbot has reported an interesting issue:
> 
> INFO: task syz-executor888:3126 blocked for more than 143 seconds.
>        Not tainted 6.1.0-rc6-syzkaller-32662-g6d464646530f #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:syz-executor888 state:D stack:0     pid:3126  ppid:3124   flags:0x00000000
> Call trace:
>   __switch_to+0x180/0x298 arch/arm64/kernel/process.c:553
>   context_switch kernel/sched/core.c:5209 [inline]
>   __schedule+0x408/0x594 kernel/sched/core.c:6521
>   schedule+0x64/0xa4 kernel/sched/core.c:6597
>   schedule_timeout+0x108/0x1b4 kernel/time/timer.c:1935
>   gfs2_gl_hash_clear+0xd4/0x1b0 fs/gfs2/glock.c:2263
>   gfs2_put_super+0x318/0x390 fs/gfs2/super.c:620
>   generic_shutdown_super+0x94/0x198 fs/super.c:492
>   kill_block_super+0x30/0x78 fs/super.c:1428
>   gfs2_kill_sb+0x68/0x78
>   deactivate_locked_super+0x70/0xe8 fs/super.c:332
>   deactivate_super+0xd0/0xd4 fs/super.c:363
>   cleanup_mnt+0x184/0x1c0 fs/namespace.c:1186
>   __cleanup_mnt+0x20/0x30 fs/namespace.c:1193
>   task_work_run+0x100/0x148 kernel/task_work.c:179
>   resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
>   do_notify_resume+0x174/0x1f0 arch/arm64/kernel/signal.c:1127
>   prepare_exit_to_user_mode arch/arm64/kernel/entry-common.c:137 [inline]
>   exit_to_user_mode arch/arm64/kernel/entry-common.c:142 [inline]
>   el0_svc+0x9c/0x150 arch/arm64/kernel/entry-common.c:638
>   el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
>   el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:584
> 
> Showing all locks held in the system:
> 1 lock held by rcu_tasks_kthre/11:
>   #0: ffff80000d4a4768 (rcu_tasks.tasks_gp_mutex){+.+.}-{3:3}, at: rcu_tasks_one_gp+0x3c/0x450 kernel/rcu/tasks.h:507
> 1 lock held by rcu_tasks_trace/12:
>   #0: ffff80000d4a4db8 (rcu_tasks_trace.tasks_gp_mutex){+.+.}-{3:3}, at: rcu_tasks_one_gp+0x3c/0x450 kernel/rcu/tasks.h:507
> 1 lock held by khungtaskd/27:
>   #0: ffff80000d4a4640 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x4/0x48 include/linux/rcupdate.h:303
> 2 locks held by getty/2759:
>   #0: ffff0000c7d7e098 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x28/0x58 drivers/tty/tty_ldisc.c:244
>   #1: ffff80000f6be2f0 (&ldata->atomic_read_lock){+.+.}-{3:3}, at: n_tty_read+0x19c/0x89c drivers/tty/n_tty.c:2177
> 1 lock held by syz-executor888/3126:
>   #0: ffff0000cae680e0 (&type->s_umount_key#41){+.+.}-{3:3}, at: deactivate_super+0xc8/0xd4 fs/super.c:362
> 
> =============================================
> 
> One task blocked after executing gfs2_gl_hash_clear(), it looks
> like go to sleep for waiting the condition (&sdp->sd_glock_disposal == 0),
> this field sd_glock_disposal is used to count the getting times
> that calling gfs2_glock_get() success, In most cases, when we operate
> the mount interface, we will finally call this function:
> 
>                                do_mount()
>                                path_mount()
>                                vfs_get_tree()
>                                gfs2_get_tree()
>                                get_tree_bdev()
>                                gfs2_fill_super()
>                       ________ init_inodes()_____________
>                      V                                   V
>         gfs2_lookup_simple()                         gfs2_rindex_update()
>         gfs2_lookupi()                               gfs2_ri_update()
>         gfs2_dir_search()                         -> read_rindex_entry() //*gfs2_rgrpd->rd_gl
>      -> gfs2_inode_lookup() //*gfs2_inode->i_gl  |__ gfs2_glock_get()
>     |__gfs2_glock_get()
> 
> Correspondingly, release this glock's reference and decrease
> sdp->sd_glock_disposal through this path when umount:
> 
>                                cleanup_mnt()
>                                deactivate_super()
>                                deactivate_locked_super()
>                                gfs2_kill_sb()
>                                kill_block_super()
>                                generic_shutdown_super()
>            _gfs2_rgrpd->rd_gl__gfs2_put_super()__gfs2_inode->i_gl__
>           V                                                        V
> 	gfs2_clear_rgrpd()                           gfs2_put_super()
> 	gfs2_glock_put()                             iput()
>          gfs2_glock_free()                            evict()
>                                                       gfs2_evict_inode()
>                                                       gfs2_glock_put_eventually()
>                                                       gfs2_glock_put()
>                                                       gfs2_glock_free()
> 
> But if calling reconfigure_super() from sysfs between mount and umount,
> this path will also take the glock lock and increase sdp->sd_glock_disposal
> as it also call gfs2_glock_get():
> 
>     reconfigure_super()
>      gfs2_reconfigure()
>        gfs2_make_fs_rw() //remount filesystem read-write
>         gfs2_quota_init()
>       -> qd_alloc()      //*gfs2_quota_data->qd_gl
>      |___ gfs2_glock_get()
> 
> This relies on gfs2_quota_cleanup() that is eventually called by
> gfs2_make_fs_ro() to clean up but unfortunately the file system
> has not been remounted at this time, the condition (!sb_rdonly(sb))
> is false and gfs2_make_fs_ro() can not be called, ultimately makes
> sdp->sd_glock_disposal never be 0.
> 
> This add calling gfs2_quota_cleanup() when this filesystem remains
> readOnly, in this case we don't need sync quota or other operation
> otherwise the filesystem was really remounted.
> 
> But this modification will trigger this warning:
> 
>     WARNING: CPU: 7 PID: 2595 at include/linux/backing-dev.h:246 __folio_mark_dirty+0x559/0x7b0
I paste wrong, the warning is:
gfs2: fsid=mounts.0: warning: assertion "!qd->qd_change" failed at 
function = gfs2_quota_cleanup, file = fs/gfs2/quota.c, line = 1474

qd->qd_change has been changed in gfs2_quota_init(), but it looks
we don't need to do anything before remounting the file system as 
read-write.
> 
> We can filter this warning with adding a parameter as it doesn't
> really make sense here.
> 
> Fixes: 9e6e0a128bca ("GFS2: Merge mount.c and ops_super.c into super.c")
> Reported-by: syzbot+ed7d0f71a89e28557a77 at syzkaller.appspotmail.com
> Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
> ---
>   fs/gfs2/super.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
> index b018957a1bb2..9a3c6da8db55 100644
> --- a/fs/gfs2/super.c
> +++ b/fs/gfs2/super.c
> @@ -586,7 +586,10 @@ static void gfs2_put_super(struct super_block *sb)
>   
>   	if (!sb_rdonly(sb)) {
>   		gfs2_make_fs_ro(sdp);
> +	} else {
> +		gfs2_quota_cleanup(sdp);
>   	}
> +
>   	WARN_ON(gfs2_withdrawing(sdp));
>   
>   	/*  At this point, we're through modifying the disk  */
> 


  reply	other threads:[~2022-12-03  7:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01 11:50 [RFC PATCH] gfs2: Fix missing cleanup quota in gfs2_put_super() Wang ShaoBo
2022-12-01 11:50 ` [Cluster-devel] " Wang ShaoBo
2022-12-03  7:28 ` Wangshaobo (bobo) [this message]
2022-12-03  7:28   ` Wangshaobo
2022-12-03 13:15   ` Andreas Gruenbacher
2022-12-03 13:15     ` [Cluster-devel] " Andreas Gruenbacher
2022-12-05  1:36     ` Wangshaobo (bobo)
2022-12-05  1:36       ` [Cluster-devel] " Wangshaobo

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=5c66dbe3-5701-ba42-7933-73a31c2dc891@huawei.com \
    --to=bobo.shaobowang@huawei.com \
    --cc=agruenba@redhat.com \
    --cc=cluster-devel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liwei391@huawei.com \
    --cc=rpeterso@redhat.com \
    --cc=syzkaller-bugs@googlegroups.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.