linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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).