DEntry is staill visible after unlink and rmdir in case of crashes

[iaoing]

Issue

In unlink and rmdir, NOVA will append a new DIR_LOG and reassign create_dentry if the creation and removal epoches differ. If the system crashes before invalidating (reassigning) the dentry, after recovery, the dentry will be considered a valid dentry and seen by users but the removed inode has been gone.

NOTE: This issue could be occurred in other circumstances.
After fixing the atomicity bug in rename (#135), this bug occurs.
This is because rename appends a new entry for detecting a dentry instead of updating it in-place, triggering the reassignment of the creation entry.

After fixing the issue #125 by disabling the in-place update of the log in unlink, this bug will occur without creating snapshots.
This is because the invalidation of the dentry will not be triggered if NOVA in-place updates the log to represent the removal.
After the fix, NOVA never in-place updates the log, so that, the invalidation is required, leading to this bug.

Reproduce

1. Modify the source code in nova_unlink to simulate a crash.
   

   linux-nova/fs/nova/namei.c

   Lines 459 to 460 in 976a4d1

   	nova_invalidate_link_change_entry(sb, old_linkc);
   	nova_invalidate_dentries(sb, &update_dir);

	nova_invalidate_link_change_entry(sb, old_linkc);
	goto out; // simulate a crash before reassigning the dentry
	nova_invalidate_dentries(sb, &update_dir);

2. The commands

insmod nova.ko metadata_csum=1 data_csum=1 data_parity=1
mount -t NOVA -o init,dbgmask=255 /dev/pmem0 /mnt/pmem0
# create a file
touch /mnt/pmem0/f1
# create and delete a snapshot to increase epochs
echo 1 > /proc/fs/NOVA/pmem0/create_snapshot
echo 0 > /proc/fs/NOVA/pmem0/delete_snapshot
# unlink the file
rm /mnt/pmem0/f1
# cat the image then umount
cat /dev/pmem0 > image
umount /mnt/pmem0
# remount
cat image > /dev/pmem0
mount -t NOVA -o dbgmask=255 /dev/pmem0 /mnt/pmem0
# ls can see the dentry, f1
ls /mnt/pmem0
# stat will arise an error, "stat: cannot stat '/mnt/pmem0/f1': No such file or directory"
stat /mnt/pmem0/f1

Testing the rmdir function has the similar reproduce process.

Reason

The reassignment of the dentry is non-synchronous
OR
The recovery process cannot distinguish whether the reassignment is unfinished.

Fix

There might be different ways to fix this bug. However, I have not tried any of them yet. Besides, the reassign flag is designed for snapshots, I do not whether this fix affects the design.

Option 1. Since the snapshots have been deleted, it should be safe to in-place update the dentry in unlink and rmdir.
Option 2. Journal the reassignment process.
Option 3. In recovery, when seeing a dentry is deleted, search backward to continue the unfinished reassign process.