Re: [PATCH] JFFS[23] slab corruption

["Artem B. Bityuckiy" <dedekind@yandex.ru>]

I'd like to do some analysis. David, could you please comment my notes:

1. Consider removing ic from mark_node_obsolete (NOR only).
When ic may have no nodes?

a). When the inode is deleted. In this case all it's nodes are marked 
obsolete (thankfully we may mark them obsolete physically). This happens 
when ic->nlink == 0 and last iput() is called.

b). I'm not sure, may be temporary it may have no valid nodes. I mean 
some transient state when, for example, there is one node A, and another 
node B is added, and B obsoletes A. Then possibly A will be first marked 
obsolete, then B will be added. Between these two operations, ic may 
have no nodes. I'm not sure, but it seems in the current implementation 
in such situations A will be always added first. So, mark_node_obsolete 
should not delete the ic in such temporary states.

But why do mark_node_obsolete code delete the correspondent ic if there 
is no nodes left? It should not delete ic because of b) . Moreover, 
conceptually it is not its work - the last iput handler should do that 
(do_clean_inode() may be).

Conclusions: a) remove that peace of code from the mark_node_obsolete. 
b) be sure ic will be deleted by somebody else.


2. Conceder jffs2_remove_node_refs_from_ino_list() function. It deletes 
ic if there are no nodes...

At first this is only valid for NAND. In case of NOR obsolete nodes are 
removed from the per-inode list as soon as they marked obsolete.

In case of nand our live is complicated because we can not mark nodes 
obsolete physically. And deletion/deleted direntries bring us 
misfortune. We must keep track of them in the per-inode list and only 
remove them when the last instance of the deleted direntry has been 
erased...

But before the erase code deletes ic, it should be sure there are no 
open files (iget count = 0) and ic->nlink = 0. But it seems it does not 
do so. ... May continue reasoning, but want to be sure I understand 
thing correctly. So, will wait for comments.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.