Patchwork jffs2: Re-enable write-buffering after filesystem sync

login
register
mail settings
Submitter Jeff Harris
Date Aug. 1, 2014, 4:06 p.m.
Message ID <1406909172-7219-1-git-send-email-jharris@westell.com>
Download mbox | patch
Permalink /patch/375799/
State New
Headers show

Comments

Jeff Harris - Aug. 1, 2014, 4:06 p.m.
A JFFS2 filesystem sync cancels the write buffering dirty work and performs
the flush manually.  However, the flag which indicates that the work is active
is not reset.  Thus, if a sync happens while the work is pending, the flag
will never be reset resulting in future work never being started.  The flag is
now reset under the appropriate lock along with the timer cancellation.

Tested on 3.13.6.

Signed-off-by: Jeff Harris <jharris@westell.com>
---
 fs/jffs2/super.c |    3 +++
 1 file changed, 3 insertions(+)
Al Viro - Aug. 1, 2014, 4:56 p.m.
On Fri, Aug 01, 2014 at 12:06:12PM -0400, Jeff Harris wrote:

> +	spin_lock(&c->wbuf_dwork_lock);
>  	cancel_delayed_work_sync(&c->wbuf_dwork);

Umm...  Usually ..._sync in function name is a sign of potential sleeper,
and calling those under a spinlock is a bad idea.

And looking at the definition of cancel_delayed_work_sync() turns up the
following call chain: cancel_delayed_work_sync() -> __cancel_work_timer() ->
flush_work() -> wait_for_completion(), which definitely isn't something
you should ever do under a spinlock.

While we are at it, you follow that with
> +	c->wbuf_queued = 0;
> +	spin_lock(&c->wbuf_dwork_lock);
which would be broken even if cancel_delayed_work_sync() hadn't blocked.
That's easily fixed, of course, (s/lock/unlock/).  cancel_delayed_work_sync()
under a spinlock is more serious...
Jeff Harris - Aug. 1, 2014, 5:15 p.m.
On Fri, Aug 1, 2014 at 12:56 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Fri, Aug 01, 2014 at 12:06:12PM -0400, Jeff Harris wrote:
>
> > +     spin_lock(&c->wbuf_dwork_lock);
> >       cancel_delayed_work_sync(&c->wbuf_dwork);
>
> Umm...  Usually ..._sync in function name is a sign of potential sleeper,
> and calling those under a spinlock is a bad idea.
>
> And looking at the definition of cancel_delayed_work_sync() turns up the
> following call chain: cancel_delayed_work_sync() -> __cancel_work_timer() ->
> flush_work() -> wait_for_completion(), which definitely isn't something
> you should ever do under a spinlock.

The jffs2_dirty_trigger function calls queue_delayed_work under the spinlock.
I suppose the flag could be reset after the cancel so the dirty
trigger would see
the false value.

>
>
> While we are at it, you follow that with
> > +     c->wbuf_queued = 0;
> > +     spin_lock(&c->wbuf_dwork_lock);
> which would be broken even if cancel_delayed_work_sync() hadn't blocked.
> That's easily fixed, of course, (s/lock/unlock/).  cancel_delayed_work_sync()
> under a spinlock is more serious...

Whoops, sorry about that.

Jeff

Patch

diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 0918f0e..263136b 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -101,7 +101,10 @@  static int jffs2_sync_fs(struct super_block *sb, int wait)
 	struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
 
 #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
+	spin_lock(&c->wbuf_dwork_lock);
 	cancel_delayed_work_sync(&c->wbuf_dwork);
+	c->wbuf_queued = 0;
+	spin_lock(&c->wbuf_dwork_lock);
 #endif
 
 	mutex_lock(&c->alloc_sem);