* [PATCH 0/1] fs: cap max_files at LONG_MAX
@ 2018-10-17 23:11 Christian Brauner
2018-10-17 23:11 ` [PATCH 1/1] " Christian Brauner
0 siblings, 1 reply; 2+ messages in thread
From: Christian Brauner @ 2018-10-17 23:11 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel; +Cc: viro, keescook, Christian Brauner
Hey,
This is a follow-up to [1] and [2] that caps the file-max sysctl at
LONG_MAX and rejects any larger values with EINVAL because of the way
percup counters work. This intends to align the kernel side of files_max
handling as well by capping the maximum number of files at LONG_MAX
until such time as we have the need and the precision for percpu
unsigned long counters.
Note, that in a quick discussion with Tejun investigating percpu unsigned
long counters it became obvious that technically, both LONG_MAX and
ULONG_MAX should be unreachable. Given that an fd is usually larger than 2
bytes one would likely run out of address space before even reaching the
LONG_MAX limit.
Al, I suggested this patch in [3] but I didn't see you reply so I'm not
sure whether you would be in favor of this or not.
Thanks!
Christian
[1]: https://lkml.org/lkml/2018/10/17/74
[2]: https://lkml.org/lkml/2018/10/17/184
[3]: https://lkml.org/lkml/2018/10/17/555
Christian Brauner (1):
fs: cap max_files at LONG_MAX
fs/file_table.c | 8 ++++++++
1 file changed, 8 insertions(+)
--
2.19.1
^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH 1/1] fs: cap max_files at LONG_MAX
2018-10-17 23:11 [PATCH 0/1] fs: cap max_files at LONG_MAX Christian Brauner
@ 2018-10-17 23:11 ` Christian Brauner
0 siblings, 0 replies; 2+ messages in thread
From: Christian Brauner @ 2018-10-17 23:11 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel; +Cc: viro, keescook, Christian Brauner
The percpu counters can only deal with long ints but max_files is declared
as an unsigned long. We have already started to reject anything exceeding
LONG_INT in the file-max sysctl as well [1].
Should we ever have the need and precision for unsigned long percpu
counters we can simply switch to that api for the sysctls and then lift the
LONG_MAX cap from files_maxfiles_init() as well.
Note, that in a quick discussion with Tejun investigating percpu unsigned
long counters it became obvious that technically, both LONG_MAX and
ULONG_MAX should be unreachable. Given that an fd is usually larger than 2
bytes one would likely run out of address space before even reaching the
LONG_MAX limit.
[1]: https://lkml.org/lkml/2018/10/17/74
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
---
fs/file_table.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/file_table.c b/fs/file_table.c
index e49af4caf15d..2e3cddce20d6 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -10,6 +10,7 @@
#include <linux/file.h>
#include <linux/fdtable.h>
#include <linux/init.h>
+#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/security.h>
@@ -386,4 +387,11 @@ void __init files_maxfiles_init(void)
n = ((totalram_pages - memreserve) * (PAGE_SIZE / 1024)) / 10;
files_stat.max_files = max_t(unsigned long, n, NR_FILE);
+
+ /*
+ * The percpu counters only handle long ints so cap maximum number of
+ * files at LONG_MAX.
+ */
+ if (files_stat.max_files > LONG_MAX)
+ files_stat.max_files = LONG_MAX;
}
--
2.19.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-10-18 7:10 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-17 23:11 [PATCH 0/1] fs: cap max_files at LONG_MAX Christian Brauner
2018-10-17 23:11 ` [PATCH 1/1] " Christian Brauner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).