cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
* [Cluster-devel] [GFS2 PATCH] gfs2: Remove sb_start_write from gfs2_statfs_sync
       [not found] <355304031.29450600.1606249586453.JavaMail.zimbra@redhat.com>
@ 2020-11-24 20:26 ` Bob Peterson
  2020-11-25 17:07   ` Andreas Gruenbacher
  0 siblings, 1 reply; 3+ messages in thread
From: Bob Peterson @ 2020-11-24 20:26 UTC (permalink / raw)
  To: cluster-devel.redhat.com

Hi,

Before this patch, function gfs2_statfs_sync called sb_start_write. This is a
violation of the basic vfs rules that state that sb_start_write should always
be taken before s_umount. See this document:

https://www.kernel.org/doc/htmldocs/filesystems/API-sb-start-write.html

"Since freeze protection behaves as a lock, users have to preserve
ordering of freeze protection and other filesystem locks. Generally,
freeze protection should be the outermost lock. In particular, we have:

sb_start_write -> i_mutex (write path, truncate, directory ops, ...) ->
s_umount (freeze_super, thaw_super)"

deactivate_super
   down_write(&s->s_umount); <------------------------------------ s_umount
   deactivate_locked_super
      gfs2_kill_sb
         kill_block_super
            generic_shutdown_super
               gfs2_put_super
                  gfs2_make_fs_ro
                     gfs2_statfs_sync(sdp->sd_vfs, 0);
                        sb_start_write <--------------------- sb_start_write

As far as I can tell, gfs2_statfs_sync doesn't need to call sb_start_write
any more than any other write to the file system, which are policed by glocks.
None of the other functions in gfs2 lock sb_start_write so it only affects
how vfs calls gfs2.

This patch simply removes the call to sb_start_write.

Signed-off-by: Bob Peterson <rpeterso@redhat.com>
---
 fs/gfs2/super.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index b3d951ab8068..2f56acc41c04 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -353,7 +353,6 @@ int gfs2_statfs_sync(struct super_block *sb, int type)
 	struct buffer_head *m_bh, *l_bh;
 	int error;
 
-	sb_start_write(sb);
 	error = gfs2_glock_nq_init(m_ip->i_gl, LM_ST_EXCLUSIVE, GL_NOCACHE,
 				   &gh);
 	if (error)
@@ -392,7 +391,6 @@ int gfs2_statfs_sync(struct super_block *sb, int type)
 out_unlock:
 	gfs2_glock_dq_uninit(&gh);
 out:
-	sb_end_write(sb);
 	return error;
 }
 



^ permalink raw reply related	[flat|nested] 3+ messages in thread

* [Cluster-devel] [GFS2 PATCH] gfs2: Remove sb_start_write from gfs2_statfs_sync
  2020-11-24 20:26 ` Bob Peterson
@ 2020-11-25 17:07   ` Andreas Gruenbacher
  0 siblings, 0 replies; 3+ messages in thread
From: Andreas Gruenbacher @ 2020-11-25 17:07 UTC (permalink / raw)
  To: cluster-devel.redhat.com

Hi Bob,

On Tue, Nov 24, 2020 at 9:27 PM Bob Peterson <rpeterso@redhat.com> wrote:
> Before this patch, function gfs2_statfs_sync called sb_start_write. This is a
> violation of the basic vfs rules that state that sb_start_write should always
> be taken before s_umount. See this document:
>
> https://www.kernel.org/doc/htmldocs/filesystems/API-sb-start-write.html
>
> "Since freeze protection behaves as a lock, users have to preserve
> ordering of freeze protection and other filesystem locks. Generally,
> freeze protection should be the outermost lock. In particular, we have:
>
> sb_start_write -> i_mutex (write path, truncate, directory ops, ...) ->
> s_umount (freeze_super, thaw_super)"
>
> deactivate_super
>    down_write(&s->s_umount); <------------------------------------ s_umount
>    deactivate_locked_super
>       gfs2_kill_sb
>          kill_block_super
>             generic_shutdown_super
>                gfs2_put_super
>                   gfs2_make_fs_ro
>                      gfs2_statfs_sync(sdp->sd_vfs, 0);
>                         sb_start_write <--------------------- sb_start_write
>
> As far as I can tell, gfs2_statfs_sync doesn't need to call sb_start_write
> any more than any other write to the file system, which are policed by glocks.
> None of the other functions in gfs2 lock sb_start_write so it only affects
> how vfs calls gfs2.

you're quite right that the sb_start_write doesn't make sense in the
above code path. That was equally true when the call was added in
commit 2e60d7683c8d2 ("GFS2: update freeze code to use
freeze/thaw_super on all nodes"), so I'm wondering what the intention
may have been here. Are there any code paths not going through the vfs
that need protection from filesystem freezes?

I'll leave this patch out for now, at least until it's more obvious
what's going on exactly.

> This patch simply removes the call to sb_start_write.
>
> Signed-off-by: Bob Peterson <rpeterso@redhat.com>
> ---
>  fs/gfs2/super.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
> index b3d951ab8068..2f56acc41c04 100644
> --- a/fs/gfs2/super.c
> +++ b/fs/gfs2/super.c
> @@ -353,7 +353,6 @@ int gfs2_statfs_sync(struct super_block *sb, int type)
>         struct buffer_head *m_bh, *l_bh;
>         int error;
>
> -       sb_start_write(sb);
>         error = gfs2_glock_nq_init(m_ip->i_gl, LM_ST_EXCLUSIVE, GL_NOCACHE,
>                                    &gh);
>         if (error)
> @@ -392,7 +391,6 @@ int gfs2_statfs_sync(struct super_block *sb, int type)
>  out_unlock:
>         gfs2_glock_dq_uninit(&gh);
>  out:
> -       sb_end_write(sb);
>         return error;
>  }
>

Thanks,
Andreas



^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Cluster-devel] [GFS2 PATCH] gfs2: Remove sb_start_write from gfs2_statfs_sync
       [not found] <1532030071.31309682.1607003348976.JavaMail.zimbra@redhat.com>
@ 2020-12-03 13:49 ` Bob Peterson
  0 siblings, 0 replies; 3+ messages in thread
From: Bob Peterson @ 2020-12-03 13:49 UTC (permalink / raw)
  To: cluster-devel.redhat.com

Hi,

Before this patch, function gfs2_statfs_sync called sb_start_write and
sb_end_write. This is completely unnecessary because, aside from grabbing
glocks, gfs2_statfs_sync does all its updates to statfs with a transaction:
gfs2_trans_begin and _end. And transactions always do sb_start_intwrite in
gfs2_trans_begin and sb_end_intwrite in gfs2_trans_end.

This patch simply removes the call to sb_start_write.

Signed-off-by: Bob Peterson <rpeterso@redhat.com>
---
 fs/gfs2/super.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index b3d951ab8068..2f56acc41c04 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -353,7 +353,6 @@ int gfs2_statfs_sync(struct super_block *sb, int type)
 	struct buffer_head *m_bh, *l_bh;
 	int error;
 
-	sb_start_write(sb);
 	error = gfs2_glock_nq_init(m_ip->i_gl, LM_ST_EXCLUSIVE, GL_NOCACHE,
 				   &gh);
 	if (error)
@@ -392,7 +391,6 @@ int gfs2_statfs_sync(struct super_block *sb, int type)
 out_unlock:
 	gfs2_glock_dq_uninit(&gh);
 out:
-	sb_end_write(sb);
 	return error;
 }
 



^ permalink raw reply related	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-12-03 13:49 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1532030071.31309682.1607003348976.JavaMail.zimbra@redhat.com>
2020-12-03 13:49 ` [Cluster-devel] [GFS2 PATCH] gfs2: Remove sb_start_write from gfs2_statfs_sync Bob Peterson
     [not found] <355304031.29450600.1606249586453.JavaMail.zimbra@redhat.com>
2020-11-24 20:26 ` Bob Peterson
2020-11-25 17:07   ` Andreas Gruenbacher

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).