[PATCH]jffs2:bugfix for should not appeared directory hard link

[David Woodhouse]

Thank you for the excellent analysis. However, I'm a little confused,
and I'm not sure we're focusing on the right thing.

Step five is to *unlink* the direction /mnt/old. Here's a
carefully-selected citation of your email...

On Fri, 2015-02-13 at 12:09 +0800, liu.song11 at zte.com.cn wrote:
> 
> 5. rmdir /mnt/old 
> 6. mkdir /mnt/old 
> 7. goto step 3 
> 
> In this loop, there only /mnt/old's ino number will changed. 
> 
> Before the problem happen, here we print the dirents' info(after step
> 3 and before step4). 
> We can see，/mnt/old/SW1's pino is 71, that means /mnt/old's ino
> number is 71. 
> The dirents all in same eraseblock(0x0e600000 - 0x0e61FFFF). 
> ------------------------------------------------------------- 
 ...
> ino = 71, name = old, version = 299, pino = 1, ofs = 0x0e6186bc 
> ------------------------------------------------------------- 

OK.

> After step5 and before step6, we print the dirents' info. 
...
> ino = 0, name = old, version = 298, pino = 1, ofs = 0x0e6185c4 
> ino = 71, name = old, version = 299, pino = 1, ofs = 0x0e6186bc 
> ---------------------------------------------------------------

That looks wrong. You said you unlinked /mnt/old. But a deletion dirent
appeared *before* the creation, with an *older* version number?

Was that an older deletion dirent from a previous round, and you just
didn't include it in your previous printout (also cited above)? Is the
*new* deletion dirent with version = 300 somewhere else on the flash?

This is the problem, I think.

I don't *care* if the old dirents for <ino#71>/SW1 and <ino#71>/SW2 are
marked as obsolete or not. Because the directory <ino#71> *itself* as
unlinked and should be dead.

If <ino#71> is somehow ending up linked as /mnt/foo again when it should
have been unlinked, *that* is the problem we need to be looking at. The
zombie *children* of <ino#71> are just a symptom of its reincarnation.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20150213/4ca64407/attachment.bin>