All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
To: "ludovic.desroches" <ludovic.desroches@atmel.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	linux-mtd@lists.infradead.org,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: JFFS2 issue with v3.5.x and later on Atmel chips at least
Date: Thu, 23 Aug 2012 15:37:39 +0300	[thread overview]
Message-ID: <1345725459.2848.238.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <5035F266.2040909@atmel.com>

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

On Thu, 2012-08-23 at 11:05 +0200, ludovic.desroches wrote:
> 
> Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com> 

Thanks, pushed to l2-mtd.git tree a bit modified patch. Will ping dwmw2
about merging it to Linus.

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date: Thu, 23 Aug 2012 10:10:07 +0300
Subject: [PATCH] JFFS2: fix unmount regression

This patch fixes regression introduced by
"8bdc81c jffs2: get rid of jffs2_sync_super". We submit a delayed work in order
to make sure the write-buffer is synchronized at some point. But we do not
flush it when we unmount, which causes an oops when we unmount the file-system
and then the delayed work is executed.

This patch fixes the issue by adding a "cancel_delayed_work_sync()" infocation
in the '->sync_fs()' handler. This will make sure the delayed work is canceled
on sync, unmount and re-mount. And because VFS always callse 'sync_fs()' before
unmounting or remounting, this fixes the issue.

Reported-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Cc: stable@vger.kernel.org [3.5+]
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
---
 fs/jffs2/super.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 61ea413..1224d6b 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -100,6 +100,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
+	cancel_delayed_work_sync(&c->wbuf_dwork);
+#endif
+
 	mutex_lock(&c->alloc_sem);
 	jffs2_flush_wbuf_pad(c);
 	mutex_unlock(&c->alloc_sem);
-- 
1.7.10.4


-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
To: "ludovic.desroches" <ludovic.desroches@atmel.com>
Cc: linux-mtd@lists.infradead.org,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: JFFS2 issue with v3.5.x and later on Atmel chips at least
Date: Thu, 23 Aug 2012 15:37:39 +0300	[thread overview]
Message-ID: <1345725459.2848.238.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <5035F266.2040909@atmel.com>

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

On Thu, 2012-08-23 at 11:05 +0200, ludovic.desroches wrote:
> 
> Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com> 

Thanks, pushed to l2-mtd.git tree a bit modified patch. Will ping dwmw2
about merging it to Linus.

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date: Thu, 23 Aug 2012 10:10:07 +0300
Subject: [PATCH] JFFS2: fix unmount regression

This patch fixes regression introduced by
"8bdc81c jffs2: get rid of jffs2_sync_super". We submit a delayed work in order
to make sure the write-buffer is synchronized at some point. But we do not
flush it when we unmount, which causes an oops when we unmount the file-system
and then the delayed work is executed.

This patch fixes the issue by adding a "cancel_delayed_work_sync()" infocation
in the '->sync_fs()' handler. This will make sure the delayed work is canceled
on sync, unmount and re-mount. And because VFS always callse 'sync_fs()' before
unmounting or remounting, this fixes the issue.

Reported-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Cc: stable@vger.kernel.org [3.5+]
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
---
 fs/jffs2/super.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 61ea413..1224d6b 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -100,6 +100,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
+	cancel_delayed_work_sync(&c->wbuf_dwork);
+#endif
+
 	mutex_lock(&c->alloc_sem);
 	jffs2_flush_wbuf_pad(c);
 	mutex_unlock(&c->alloc_sem);
-- 
1.7.10.4


-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: artem.bityutskiy@linux.intel.com (Artem Bityutskiy)
To: linux-arm-kernel@lists.infradead.org
Subject: JFFS2 issue with v3.5.x and later on Atmel chips at least
Date: Thu, 23 Aug 2012 15:37:39 +0300	[thread overview]
Message-ID: <1345725459.2848.238.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <5035F266.2040909@atmel.com>

On Thu, 2012-08-23 at 11:05 +0200, ludovic.desroches wrote:
> 
> Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com> 

Thanks, pushed to l2-mtd.git tree a bit modified patch. Will ping dwmw2
about merging it to Linus.

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date: Thu, 23 Aug 2012 10:10:07 +0300
Subject: [PATCH] JFFS2: fix unmount regression

This patch fixes regression introduced by
"8bdc81c jffs2: get rid of jffs2_sync_super". We submit a delayed work in order
to make sure the write-buffer is synchronized at some point. But we do not
flush it when we unmount, which causes an oops when we unmount the file-system
and then the delayed work is executed.

This patch fixes the issue by adding a "cancel_delayed_work_sync()" infocation
in the '->sync_fs()' handler. This will make sure the delayed work is canceled
on sync, unmount and re-mount. And because VFS always callse 'sync_fs()' before
unmounting or remounting, this fixes the issue.

Reported-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Cc: stable at vger.kernel.org [3.5+]
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
---
 fs/jffs2/super.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 61ea413..1224d6b 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -100,6 +100,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
+	cancel_delayed_work_sync(&c->wbuf_dwork);
+#endif
+
 	mutex_lock(&c->alloc_sem);
 	jffs2_flush_wbuf_pad(c);
 	mutex_unlock(&c->alloc_sem);
-- 
1.7.10.4


-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120823/c05bd241/attachment.sig>

  reply	other threads:[~2012-08-23 12:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22 10:28 Kernel oops since v3.5.x on Atmel chips ludovic.desroches
2012-08-22 15:00 ` JFFS2 issue with v3.5.x and later on Atmel chips at least (was: Kernel oops since v3.5.x on Atmel chips) ludovic.desroches
2012-08-22 15:00   ` ludovic.desroches
2012-08-23  6:35   ` Artem Bityutskiy
2012-08-23  6:35     ` Artem Bityutskiy
2012-08-23  6:35     ` Artem Bityutskiy
2012-08-23  7:41   ` Artem Bityutskiy
2012-08-23  7:41     ` Artem Bityutskiy
2012-08-23  7:41     ` Artem Bityutskiy
2012-08-23  9:05     ` JFFS2 issue with v3.5.x and later on Atmel chips at least ludovic.desroches
2012-08-23  9:05       ` ludovic.desroches
2012-08-23 12:37       ` Artem Bityutskiy [this message]
2012-08-23 12:37         ` Artem Bityutskiy
2012-08-23 12:37         ` Artem Bityutskiy

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=1345725459.2848.238.camel@sauron.fi.intel.com \
    --to=artem.bityutskiy@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ludovic.desroches@atmel.com \
    --cc=nicolas.ferre@atmel.com \
    --cc=plagnioj@jcrosoft.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.