On Sun, May 06, 2018 at 10:32:47PM +0100, Al Viro wrote: > On Sun, May 06, 2018 at 09:46:23PM +0100, Al Viro wrote: > > > I'm fixing that pile of crap (along with the NFS exports > > one and, hopefully, rename mess as well). HOWEVER, I am not going > > to take over the damn thing - David has violated the 11th > > commandment (Thou Shalt Never Volunteer), so he gets to joy of > > learning that codebase and taking care of it from now on. > > Same scenario on link(2) ends up with > * ST_LINKFILE created, inserted into the link chain and left around, > without being present in any hash chain > * target becoming positive hashed dentry, as if link(2) has succeeded, > so dcache lookups will be finding it (for a while) > * unlink(2) on source will have very interesting effects, what with > the attempts to move ST_FILE entry into the directory presumed to > contain ST_LINKFILE one, removing ST_LINKFILE from it at the same time.
Oh, lovely... Looks like that thing wants the hash chains sorted by block number. affs_insert_hash() doesn't give a toss - it always adds to the very end of chain. Maintaining that requirement (and I can understand the rationale - they don't want too many back-and-forth seeks on directory lookups) is going to be great fun on rename(), especially for the case when the target of rename happens to be a primary name for a file with additional hardlinks. I think I see how to deal with that sanely, but... ouch. Incidentally, we'd better verify that hash chains are not looped - as it is, there's no checks whatsoever, and it *will* happily loop if you feed it an image with such braindamage. I really hope that no fan of desktop experience has set the things up for e.g. USB sticks with that on them being recognized and automounted on insertion...
