Fix directory hardlinks from deleted directories
authorDavid Woodhouse <David.Woodhouse@intel.com>
Mon, 1 Feb 2016 14:04:46 +0000 (14:04 +0000)
committerBen Hutchings <ben@decadent.org.uk>
Fri, 1 Apr 2016 00:54:35 +0000 (01:54 +0100)
commitbb96b5354a62154d0aca4b2015a5b3eee68a4ac5
treea49a9aa18f88bf8d64157f1ff82e014511f6182d
parent0a2688146b9afcfdc368b81cc0696a19c0cd6c6a
Fix directory hardlinks from deleted directories

commit be629c62a603e5935f8177fd8a19e014100a259e upstream.

When a directory is deleted, we don't take too much care about killing off
all the dirents that belong to it — on the basis that on remount, the scan
will conclude that the directory is dead anyway.

This doesn't work though, when the deleted directory contained a child
directory which was moved *out*. In the early stages of the fs build
we can then end up with an apparent hard link, with the child directory
appearing both in its true location, and as a child of the original
directory which are this stage of the mount process we don't *yet* know
is defunct.

To resolve this, take out the early special-casing of the "directories
shall not have hard links" rule in jffs2_build_inode_pass1(), and let the
normal nlink processing happen for directories as well as other inodes.

Then later in the build process we can set ic->pino_nlink to the parent
inode#, as is required for directories during normal operaton, instead
of the nlink. And complain only *then* about hard links which are still
in evidence even after killing off all the unreachable paths.

Reported-by: Liu Song <liu.song11@zte.com.cn>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
fs/jffs2/build.c
fs/jffs2/nodelist.h