Skip to content

Commit a48bdf8

Browse files
mjguzikbrauner
authored andcommitted
fs: delay sysctl_nr_open check in expand_files()
Suppose a thread sharing the table started a resize, while sysctl_nr_open got lowered to a value which prohibits it. This is still going to go through with and without the patch, which is fine. Further suppose another thread shows up to do a matching expansion while resize_in_progress == true. It is going to error out since it performs the sysctl_nr_open check *before* finding out if there is an expansion in progress. But the aformentioned thread is going to succeded, so the error is spurious (and it would not happen if the thread showed up a little bit later). Checking the sysctl *after* we know there are no pending updates sorts it out. While here annotate the thing as unlikely. Signed-off-by: Mateusz Guzik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
1 parent 40384c8 commit a48bdf8

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

fs/file.c

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -278,17 +278,17 @@ static int expand_files(struct files_struct *files, unsigned int nr)
278278
if (nr < fdt->max_fds)
279279
return 0;
280280

281-
/* Can we expand? */
282-
if (nr >= sysctl_nr_open)
283-
return -EMFILE;
284-
285281
if (unlikely(files->resize_in_progress)) {
286282
spin_unlock(&files->file_lock);
287283
wait_event(files->resize_wait, !files->resize_in_progress);
288284
spin_lock(&files->file_lock);
289285
goto repeat;
290286
}
291287

288+
/* Can we expand? */
289+
if (unlikely(nr >= sysctl_nr_open))
290+
return -EMFILE;
291+
292292
/* All good, so we try */
293293
files->resize_in_progress = true;
294294
error = expand_fdtable(files, nr);

0 commit comments

Comments
 (0)