From: "Artem B. Bityuckiy" <dedekind@yandex.ru>
To: Estelle HAMMACHE <estelle.hammache@st.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 & NAND failure
Date: Mon, 04 Apr 2005 16:58:16 +0400 [thread overview]
Message-ID: <425139E8.5000508@yandex.ru> (raw)
In-Reply-To: <41C02F29.92D2B5A@st.com>
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
Estelle HAMMACHE wrote:
> Hi everyone,
>
> it seems there is a problem with jffs2_wbuf_recover and
> the wbuf_sem...
>
> jffs2_flash_writev
> ** down_write(&c->wbuf_sem); !!!
> ** __jffs2_flush_wbuf
> **** jffs2_wbuf_recover
> ****** jffs2_block_refile
> ******** nextblock = NULL;
> ****** jffs2_reserve_space_gc
> ******** jffs2_do_reserve_space
> ********** jffs2_erase_pending_blocks
> ************ jffs2_mark_erased_block
> ************** jffs2_flash_read
> **************** down_read(&c->wbuf_sem); !!!
>
> I believe that when checking a newly erased block, the
> wbuf should not be used anyway, so this is probably easy to
> correct. Is it ok to create a jffs2_flash_read_nobuf function
> and call it only from jffs2_mark_erased_block ?
>
Hello Estelle,
I've found that JFFS2 has wbuf problems on SMP again. The reason are the
changes which were made to fix the deadlock you've spotted.
The wbuf_sem rwsem doesn't help if it is locked after you've read flash
because by the time you copy data from wbuf it might have been chaneged.
I.e:
/* A part of our data is in wbuf at this point */
mtd->read_ecc(...)
/* At this point another CPU fills wbuf and flushes it, so in contains
the wrong data */
down_read(&c->wbuf_sem)
memcpy(buf, c->wbuf, len)
up_read(&c->wbuf_sem)
I'd prefer not to use jffs2_flash_read() in jffs2_mark_erased_block()
but to directly read flash since it wbuf anyway must not correspond to a
newly erased block.
Please, look at the attached patch.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
[-- Attachment #2: wbuf_sem-1.diff --]
[-- Type: text/plain, Size: 1817 bytes --]
diff -auNrp --exclude=CVS mtd/fs/jffs2/erase.c mtd-fixed/fs/jffs2/erase.c
--- mtd/fs/jffs2/erase.c 2005-04-04 16:37:02.099649680 +0400
+++ mtd-fixed/fs/jffs2/erase.c 2005-04-04 16:33:18.665344419 +0400
@@ -333,7 +333,11 @@ static void jffs2_mark_erased_block(stru
bad_offset = ofs;
- ret = jffs2_flash_read(c, ofs, readlen, &retlen, ebuf);
+ if (!jffs2_is_writebuffered(c) || !jffs2_cleanmarker_oob(c))
+ ret = c->mtd->read(c->mtd, ofs, readlen, &retlen, ebuf);
+ else
+ ret = c->mtd->read_ecc(c->mtd, ofs, readlen, &retlen, ebuf, NULL, c->oobinfo);
+
if (ret) {
printk(KERN_WARNING "Read of newly-erased block at 0x%08x failed: %d. Putting on bad_list\n", ofs, ret);
goto bad;
diff -auNrp --exclude=CVS mtd/fs/jffs2/wbuf.c mtd-fixed/fs/jffs2/wbuf.c
--- mtd/fs/jffs2/wbuf.c 2005-04-04 16:37:09.133148264 +0400
+++ mtd-fixed/fs/jffs2/wbuf.c 2005-04-04 16:33:18.667343992 +0400
@@ -873,6 +873,7 @@ int jffs2_flash_read(struct jffs2_sb_inf
return c->mtd->read(c->mtd, ofs, len, retlen, buf);
/* Read flash */
+ down_read(&c->wbuf_sem);
if (jffs2_cleanmarker_oob(c))
ret = c->mtd->read_ecc(c->mtd, ofs, len, retlen, buf, NULL, c->oobinfo);
else
@@ -896,16 +897,11 @@ int jffs2_flash_read(struct jffs2_sb_inf
/* if no writebuffer available or write buffer empty, return */
if (!c->wbuf_pagesize || !c->wbuf_len)
- return ret;;
+ goto exit;
/* if we read in a different block, return */
if (SECTOR_ADDR(ofs) != SECTOR_ADDR(c->wbuf_ofs))
- return ret;
-
- /* Lock only if we have reason to believe wbuf contains relevant data,
- so that checking an erased block during wbuf recovery space allocation
- does not deadlock. */
- down_read(&c->wbuf_sem);
+ goto exit;
if (ofs >= c->wbuf_ofs) {
owbf = (ofs - c->wbuf_ofs); /* offset in write buffer */
next prev parent reply other threads:[~2005-04-04 12:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-17 17:15 JFFS2 & NAND failure Estelle HAMMACHE
2004-11-18 16:27 ` David Woodhouse
2004-11-18 17:54 ` Estelle HAMMACHE
2004-11-19 13:17 ` David Woodhouse
2004-11-19 16:22 ` Estelle HAMMACHE
2004-11-20 18:57 ` David Woodhouse
2004-11-20 19:19 ` David Woodhouse
2004-11-20 22:13 ` David Woodhouse
2004-12-09 14:57 ` David Woodhouse
2004-12-09 17:06 ` Estelle HAMMACHE
2004-12-15 12:33 ` Estelle HAMMACHE
2005-02-02 16:21 ` Estelle HAMMACHE
2005-04-04 12:58 ` Artem B. Bityuckiy [this message]
2005-04-04 13:58 ` Estelle HAMMACHE
2005-04-04 14:47 ` Artem B. Bityuckiy
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=425139E8.5000508@yandex.ru \
--to=dedekind@yandex.ru \
--cc=estelle.hammache@st.com \
--cc=linux-mtd@lists.infradead.org \
/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