diff options
| author | Mateusz Guzik <[email protected]> | 2025-03-20 10:26:37 +0000 |
|---|---|---|
| committer | Christian Brauner <[email protected]> | 2025-03-20 14:17:56 +0000 |
| commit | 4dec4f91359c456a5eea26817ea151b42953432e (patch) | |
| tree | 48bdebd75b06672be38b213be46cfabde08820d7 /fs/file_table.c | |
| parent | fs: call inode_sb_list_add() outside of inode hash lock (diff) | |
| download | kernel-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
