From: Ben Myers <bpm@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Mark Tinguely <tinguely@sgi.com>,
xfs@oss.sgi.com
Subject: Re: xfs: stop the sync worker before xfs_unmountfs
Date: Thu, 13 Sep 2012 11:43:44 -0500 [thread overview]
Message-ID: <20120913164344.GV25175@sgi.com> (raw)
In-Reply-To: <20120912231406.GJ11511@dastard>
Hi Dave,
On Thu, Sep 13, 2012 at 09:14:06AM +1000, Dave Chinner wrote:
> On Wed, Sep 12, 2012 at 01:33:47PM -0500, Ben Myers wrote:
> > See what you think of this. Not heavily tested yet, and not pretty... but it
> > is fairly minimal.
> ....
> > Signed-off-by: Ben Myers <bpm@sgi.com>
> >
> > Index: xfs/fs/xfs/xfs_super.c
> > ===================================================================
> > --- xfs.orig/fs/xfs/xfs_super.c
> > +++ xfs/fs/xfs/xfs_super.c
> > @@ -919,6 +919,7 @@ xfs_fs_put_super(
> > struct xfs_mount *mp = XFS_M(sb);
> >
> > xfs_filestream_unmount(mp);
> > + cancel_delayed_work_sync(&mp->m_sync_work);
> > xfs_unmountfs(mp);
> > xfs_syncd_stop(mp);
> > xfs_freesb(mp);
>
> This is the only hunk in the patch needed to fix the problem.
>
> The rest of the patch does not change the order in which the sync
> worker is started and stopped - it just open codes it next to the
> xfs_syncd_start/stop calls. Essentially, all it does is obfuscate
> the real fix that is being made here and makes it harder to
> understand what the relationship between xfs_sync_worker() and
> xfs_syncd_start/stop is supposed to be.
>
> So a minimal patch, IMO, is just the above hunk....
Ah, you're right. I was working on the assumption that it is best not to
cancel the work twice. There really is no harm in cancel_delayed_work_sync
both in xfs_fs_put_super and in xfs_syncd_stop. However, we don't want them
spread around willy nilly. That can become obfuscatory too. I suggest we
should remove the cancel_delayed_work_sync(&mp->m_sync_work) in
xfs_log_unmount, leftover from commit 11159a05. It seems like that one hasn't
been effective.
Maybe we don't want to do that in this patch... I'll just add a comment and
repost.
Thanks,
Ben
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-09-13 16:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120829134624.316257238@sgi.com>
2012-08-29 13:46 ` [PATCH] xfs: flush workers before stopping log tinguely
2012-08-29 14:31 ` Mark Tinguely
2012-08-30 0:23 ` Dave Chinner
2012-08-30 17:25 ` Ben Myers
2012-08-30 22:35 ` Dave Chinner
2012-08-31 18:15 ` Mark Tinguely
2012-09-01 23:08 ` Christoph Hellwig
2012-09-12 18:33 ` xfs: stop the sync worker before xfs_unmountfs Ben Myers
2012-09-12 23:14 ` Dave Chinner
2012-09-13 16:43 ` Ben Myers [this message]
2012-09-13 21:18 ` [PATCH] " Ben Myers
2012-09-14 1:07 ` Dave Chinner
2012-09-18 13:28 ` Mark Tinguely
2012-09-13 8:17 ` Christoph Hellwig
2012-09-13 21:19 ` Ben Myers
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=20120913164344.GV25175@sgi.com \
--to=bpm@sgi.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=tinguely@sgi.com \
--cc=xfs@oss.sgi.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