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...
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
