Skip to content

Commit 9ae7e5a

Browse files
mjguzikbrauner
authored andcommitted
fs: predict not reaching the limit in alloc_empty_file()
Eliminates a jump over a call to capable() in the common case. By default the limit is not even set, in which case the check can't even fail to begin with. It remains unset at least on Debian and Ubuntu. For this cases this can probably become a static branch instead. In the meantime tidy it up. I note the check separate from the bump makes the entire thing racy. Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://lore.kernel.org/r/20250319124923.1838719-1-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
1 parent 5a607aa commit 9ae7e5a

1 file changed

Lines changed: 2 additions & 1 deletion

File tree

fs/file_table.c

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -216,7 +216,8 @@ struct file *alloc_empty_file(int flags, const struct cred *cred)
216216
/*
217217
* Privileged users can go above max_files
218218
*/
219-
if (get_nr_files() >= files_stat.max_files && !capable(CAP_SYS_ADMIN)) {
219+
if (unlikely(get_nr_files() >= files_stat.max_files) &&
220+
!capable(CAP_SYS_ADMIN)) {
220221
/*
221222
* percpu_counters are inaccurate. Do an expensive check before
222223
* we go and fail.

0 commit comments

Comments
 (0)