So, here’s more updates about my adventures within the realm of unionfs_lookup (I suggest you read part I first). After my first post about lookup code, I went back to coding, and I had the pleasure to try to figure out why I was hitting a BUG_ON() with my new code, but not with the old code.
I made a simple test case, in one terminal I’d run fsx (a POSIX compliance tester program) on unionfs:
mount -t unionfs -o dirs=/mnt/foo/b0:/mnt/foo/b1=ro none unionfs/ cd unionfs/ fsx -l 104060000 -q foo
And then mid-way through, I’d insert a branch as the new branch index 0:
mount -o remount,add=/mnt/foo/b0:/mnt/foo/b2=rw /mnt/unionfs
The remount command immediatelly caused the BUG_ON (that tests for dentry validity) in unionfs_setattr to trigger. It seemed rather odd that the lookup code replacement would do something that’d cause the unionfs dentry to be invalid. I pondered for a bit, and then I tried to insert a number of branches quickly with the old code. Eureka! The same BUG_ON() got triggered. Some lxr-ing later, it became apparent that we need to potentially revalidate inside the inode ops (like unionfs_setattr). Seems kinda obvious now, oh well. I’m also pondering about the posibility of changing the VFS to call d_revalidate, but I’m still not sure if that’s the Right Thing(tm) to do.
Until next time!