From: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
To: linux-mtd@lists.infradead.org
Subject: spin_lock() needed ?
Date: Thu, 11 Nov 2004 21:44:20 +0300 [thread overview]
Message-ID: <4193B304.1010009@yandex.ru> (raw)
Hello,
In JFFS2 I have mentioned the following:
When new node is successfully written to the flash, its node_ref is
insert to the correspondent inode's node_ref list. Tis is done as following:
jffs2_add_physical_node_ref(c, raw);
raw->next_in_ino = f->inocache->nodes;
f->inocache->nodes = raw;
For example, see functions jffs2_write_dirent() and jffs2_write_dnode()
in the write.c file.
I am not sure, but it seems there is a race here. The f->inocache->nodes
may be obsolete node which is in the block pending for erase. So, this
node may be removed when the correspondent block is erased.
I mean the following.
Suppose we have inode with two nodes. The first node is obsolete and is
physically located to the block (say block number A), which is currently
in the c->erase_pending_list. So, suppose:
jffs2_add_physical_node_ref(c, raw);
raw->next_in_ino = f->inocache->nodes; /* We save the address of the
first obsolete node */
/* Suppose we are preempted here and the another process calls the
jffs2_erase_pending_blocks() function, which erases the block A. Before
erasing, it removes all the node_ref structures corresponding to nodes
in this block A (see the implementation of jffs2_erase_pending_blocks(),
i.e., the call to jffs2_free_all_node_refs()). Thus, the first node will
be removed from list */
f->inocache->nodes = raw;
/* Now the first node_ref corresponds to new (3rd) node, but
f->inocache->nodes->next_in_ino points to wrong place */
So, I think we should hold the c->erase_completion_lock here. I mean:
jffs2_add_physical_node_ref(c, raw);
spin_lock(&c->erase_completion_lock); /* <--------- this */
raw->next_in_ino = f->inocache->nodes;
f->inocache->nodes = raw;
spin_unlock(&c->erase_completion_lock); /* <--------- and this */
Can anybody comment this please?
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
next reply other threads:[~2004-11-11 18:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-11 18:44 Artem B. Bityuckiy [this message]
2004-11-12 12:34 ` spin_lock() needed ? David Woodhouse
2004-11-12 13:04 ` Artem 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=4193B304.1010009@yandex.ru \
--to=abityuckiy@yandex.ru \
--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