On Tue, Feb 15, 2022 at 01:37:40PM +0000, Al Viro wrote: > On Tue, Feb 15, 2022 at 10:56:29AM +0100, Miklos Szeredi wrote: > > > Doing "lock_rename() + lookup last components" would fix this race. > > No go - thanks to the possibility of AT_SYMLINK_FOLLOW there. > Think of it - we'd need to > * lock parents (both at the same time) > * look up the last component of source > * if it turns a symlink - unlock parents and repeat the entire > thing for its body, except when asked not to. > * when we are done with the source, look the last component of > target up > > ... and then there is sodding -ESTALE handling, with all the elegance > that brings in. > > > If this was only done on retry, then that would prevent possible > > performance regressions, at the cost of extra complexity. > > Extra compared to the above, that is. How delightful... Actually, it's even viler than that: lock_rename() relies upon the directories being locked sitting on the same fs. Now, surely link(2) would fail if source and target are on the different filesystem, wouldn't it? Alas, with AT_SYMLINK_FOLLOW it's quite possible to have the source resolving to a symlink that does lead to the same fs as the target, while the symlink itself is on a different fs. So it's not even straight lock_rename() - it has to be a special version that would handle cross-fs invocations (somehow - e.g. ordering them on superblock or mount in-core address in such case; ordering between dentries could be arbitrary for cross-fs cases). Worse, you need to deal with the corner cases. "/" or anything ending on "." or ".." can be rejected (no links to directories) and thankfully we do not allow AT_EMPTY for linkat(2), but... procfs symlinks are in the game, since AT_SYMLINK_FOLLOW is there. And _that_ is a real bitch - what "parent" would you lock for (followed) /proc/self/fd/0? It can change right under you; one solution would be to grab ->vfs_rename_mutex first, same parent or not, then do what lock_rename() does, relying upon ->d_parent having been stabilized by ->vfs_rename_mutex. But that would have to be conditional upon running into that case - you don't want to serialize the shit out of (same-directory) link(2) on given filesystem. Which makes the entire thing even harder to follow and reason about. And to make it even more fun, you'll need to either duplicate pick_link() guts, or try and make it usable in this situation. Might or might not be easy - I hadn't tried to go into that. "Fucking ugly" is inadequate for the likely results of that approach. It's guaranteed to be a source of headache for pretty much ever after. Does POSIX actually make any promises in that area? That would affect how high a cost we ought to pay for that - I agree that it would be nicer to have atomicity from userland point of view, but there's a difference between hard bug and QoI issue. Again, what really makes it painful is AT_SYMLINK_FOLLOW support in linkat(2). For plain link(2) it would be easier to deal with.
