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

[David Woodhouse]

On Fri, 2014-10-24 at 17:26 +0800, liu.song11 at zte.com.cn wrote:
> 
> When jffs2 with summary, during the mounting period, in 
> jffs2_build_remove_unlinked_inode will handle unlinke inode, but this
> will cause unlinked directory's deletion  dirent erased before
> it's obsoleted dirent.So if the directory has renamed, then could
> cause a hard link when we remount jffs2.

> We can stable reproduce the hard link only by following process.
> 1. we mount jffs2 in /mnt
> 2. create directories /mnt/SW1/, /mnt/SW2/
> 3. create directory /mnt/old/
> 4. rename /mnt/SW1/ to /mnt/old/SW1/, /mnt/SW2/ to /mnt/old/SW2/
> 5. do some data write. don't touch these directories.
> 6. rename /mnt/old/SW1/ to /mnt/SW1/, /mnt/old/SW2/ to /mnt/SW2/
> 7. delete /mnt/old/
> 
> do above process 3 - 7 several times, then reboot, during the mounting
> process, we could found
> /mnt/SW1/ and /mnt/old/SW1/ become hard link,/mnt/SW2/
> and /mnt/old/SW2/ become hard link. So we
> do some job to fix this bug.We have tested this patch and the hard
> link error will never occur.

Hi, apologies for the delay in looking at this.

I'm trying to understand the root cause of the problem. It looks like
the real problem here is that the /mnt/old/ directory seems to exist,
when it shouldn't?

It shouldn't *matter* that we erased the deletion dirents from /mnt/old/
leaving potentially *valid* dirents pointing to the "SW1" and "SW2"
inodes, should it? Because the /mnt/ directory *itself* shouldn't exist.

As far as I can tell, your patch seems to focus on the dirents pointing
to the SW1 and SW2 directories. But I think that's the wrong approach.

On mounting the file system again after /mnt/old was supposed to have
been deleted, *why* is it still appearing? Can you capture debug
messages over a serial console with CONFIG_JFFS2_FS_DEBUG=2? 

I'd like to see the part in step #7 where it actually writes the
deletion dirent for /mnt/foo, followed by the full log of the remount
where it erroneously decides that /mnt/foo still exists.

Thanks.

-- 
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/20150212/a1239c97/attachment.bin>