summaryrefslogtreecommitdiff
path: root/lib/Makefile
diff options
context:
space:
mode:
authorDavid Woodhouse <David.Woodhouse@intel.com>2016-02-01 17:04:46 +0300
committerDavid Woodhouse <David.Woodhouse@intel.com>2016-02-25 14:11:28 +0300
commitbe629c62a603e5935f8177fd8a19e014100a259e (patch)
treef94560a8b9a91a2ada6253a55133977f8553b31c /lib/Makefile
parent49e91e7079febe59a20ca885a87dd1c54240d0f1 (diff)
downloadlinux-be629c62a603e5935f8177fd8a19e014100a259e.tar.xz
Fix directory hardlinks from deleted directories
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> Cc: stable@vger.kernel.org
Diffstat (limited to 'lib/Makefile')
0 files changed, 0 insertions, 0 deletions