Unverified Commit ec052fae authored by Mateusz Guzik's avatar Mateusz Guzik Committed by Christian Brauner
Browse files

fs: sort out a stale comment about races between fd alloc and dup2 



It claims the issue is only relevant for shared descriptor tables which
is of no concern for POSIX (but then is POSIX of concern to anyone
today?), which I presume predates standarized threading.

The comment also mentions the following systems:
- OpenBSD installing a larval file -- they moved away from it, file is
  installed late and EBUSY is returned on conflict
- FreeBSD returning EBADF -- reworked to install the file early like
  OpenBSD used to do
- NetBSD "deadlocks in amusing ways" -- their solution looks
  Solaris-inspired (not a compliment) and I would not be particularly
  surprised if it indeed deadlocked, in amusing ways or otherwise

I don't believe mentioning any of these adds anything and the statement
about the issue not being POSIX-relevant is outdated.

dup2 description in POSIX still does not mention the problem.

Just shorten the comment and be done with it.

Signed-off-by: default avatarMateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20241205154743.1586584-1-mjguzik@gmail.com


Signed-off-by: default avatarChristian Brauner <brauner@kernel.org>
parent 175c6a21

fs/file.c

+3 −11
Original line number Diff line number Diff line
@@ -1230,17 +1230,9 @@ __releases(&files->file_lock) 


	/*

	 * We need to detect attempts to do dup2() over allocated but still

	 * not finished descriptor.  NB: OpenBSD avoids that at the price of

	 * extra work in their equivalent of fget() - they insert struct

	 * file immediately after grabbing descriptor, mark it larval if

	 * more work (e.g. actual opening) is needed and make sure that

	 * fget() treats larval files as absent.  Potentially interesting,

	 * but while extra work in fget() is trivial, locking implications

	 * and amount of surgery on open()-related paths in VFS are not.

	 * FreeBSD fails with -EBADF in the same situation, NetBSD "solution"

	 * deadlocks in rather amusing ways, AFAICS.  All of that is out of

	 * scope of POSIX or SUS, since neither considers shared descriptor

	 * tables and this condition does not arise without those.

	 * not finished descriptor.

	 *

	 * POSIX is silent on the issue, we return -EBUSY.

	 */

	fdt = files_fdtable(files);

	fd = array_index_nospec(fd, fdt->max_fds);