aboutsummaryrefslogtreecommitdiffstats
path: root/fs/file_table.c
diff options
context:
space:
mode:
authorMateusz Guzik <[email protected]>2025-03-20 10:26:37 +0000
committerChristian Brauner <[email protected]>2025-03-20 14:17:56 +0000
commit4dec4f91359c456a5eea26817ea151b42953432e (patch)
tree48bdebd75b06672be38b213be46cfabde08820d7 /fs/file_table.c
parentfs: call inode_sb_list_add() outside of inode hash lock (diff)
downloadkernel-4dec4f91359c456a5eea26817ea151b42953432e.tar.gz
kernel-4dec4f91359c456a5eea26817ea151b42953432e.zip
fs: sort out fd allocation vs dup2 race commentary, take 2
fd_install() has a questionable comment above it. While it correctly points out a possible race against dup2(), it states: > We need to detect this and fput() the struct file we are about to > overwrite in this case. > > It should never happen - if we allow dup2() do it, _really_ bad things > will follow. I have difficulty parsing the above. The first sentence would suggest fd_install() tries to detect and recover from the race (it does not), the next one claims the race needs to be dealt with (it is, by dup2()). Given that fd_install() does not suffer the burden, this patch removes the above and instead expands on the race in dup2() commentary. While here tidy up the docs around fd_install(). Signed-off-by: Mateusz Guzik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
Diffstat (limited to 'fs/file_table.c')
0 files changed, 0 insertions, 0 deletions