| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20200226161404.14136-5-longman@redhat.com>
Date: Wed, 26 Feb 2020 11:13:57 -0500
From: Waiman Long <longman@...hat.com>
To: Alexander Viro <viro@...iv.linux.org.uk>,
Jonathan Corbet <corbet@....net>,
Luis Chamberlain <mcgrof@...nel.org>,
Kees Cook <keescook@...omium.org>,
Iurii Zaikin <yzaikin@...gle.com>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-doc@...r.kernel.org,
Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
Eric Biggers <ebiggers@...gle.com>,
Dave Chinner <david@...morbit.com>,
Eric Sandeen <sandeen@...hat.com>,
Waiman Long <longman@...hat.com>
Subject: [PATCH 04/11] fs/dcache: Add sysctl parameter dentry-dir-max
The number of positive dentries in a system is limited by the actual
number of files in the system. The number of negative dentries, however,
has no such limit. As a result, it is possible that a system can have a
significant amount of memory tied up in negative dentries. For example,
running a negative dentry generator on a 4-socket 256GB x86-64 system,
the system can use up more than 150GB of memory in dentries and more
than 200GB in slabs and almost running out of free memory before memory
reclaim kicks in.
There are two major problems with having too many negative dentries:
1) When a filesystem with too many negative dentries is being unmounted,
the process of draining the dentries associated with the filesystem
can take some time. To users, the system may seem to hang for
a while. The long wait may also cause unexpected timeout error or
other warnings. This can happen when a long running container with
many negative dentries is being destroyed, for instance.
2) Tying up too much memory in unused negative dentries means there
are less memory available for other use. Even though the kernel is
able to reclaim unused dentries when running out of free memory,
it will still introduce additional latency to the application
reducing its performance.
This patch introduces a new sysctl parameter "dentry-dir-max" to
/proc/sys/fs. This syctl parameter represents a soft limit on the
total number of negative dentries allowable under any given directory.
Any non-negative integer is allowed. The default is 0 which means there
is no limit.
The actual negative dentry reclaim process to enforce the limit will
be done in a later patch.
Signed-off-by: Waiman Long <longman@...hat.com>
---
Documentation/admin-guide/sysctl/fs.rst | 18 ++++++++++++++++++
fs/dcache.c | 10 ++++++++++
kernel/sysctl.c | 10 ++++++++++
3 files changed, 38 insertions(+)
diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst
index 2a45119e3331..7274a7b34ee4 100644
--- a/Documentation/admin-guide/sysctl/fs.rst
+++ b/Documentation/admin-guide/sysctl/fs.rst
@@ -28,6 +28,7 @@ Currently, these files are in /proc/sys/fs:
- aio-max-nr
- aio-nr
+- dentry-dir-max
- dentry-state
- dquot-max
- dquot-nr
@@ -60,6 +61,23 @@ raising aio-max-nr does not result in the pre-allocation or re-sizing
of any kernel data structures.
+dentry-dir-max
+--------------
+
+This integer value specifies a soft limit on the maximum number
+of negative dentries that are allowed under any given directory.
+A negative dentry contains filename that is known to be nonexistent
+in the directory. No restriction is placed on the number of positive
+dentries as it is naturally limited by the number of files in the
+directory.
+
+The default value is 0 which means there is no limit. Any non-negative
+value is allowed. However, internal tracking is done on all dentry
+types. So the value given, if non-zero, should be larger than the
+number of files in a typical large directory in order to reduce the
+tracking overhead.
+
+
dentry-state
------------
diff --git a/fs/dcache.c b/fs/dcache.c
index 0ee5aa2c31cf..8f3ac31a582b 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -123,6 +123,16 @@ static DEFINE_PER_CPU(long, nr_dentry);
static DEFINE_PER_CPU(long, nr_dentry_unused);
static DEFINE_PER_CPU(long, nr_dentry_negative);
+/*
+ * dcache_dentry_dir_max_sysctl:
+ *
+ * This is sysctl parameter "dentry-dir-max" which specifies a limit on
+ * the maximum number of negative dentries that are allowed under any
+ * given directory.
+ */
+int dcache_dentry_dir_max_sysctl __read_mostly;
+EXPORT_SYMBOL_GPL(dcache_dentry_dir_max_sysctl);
+
#if defined(CONFIG_SYSCTL) && defined(CONFIG_PROC_FS)
/*
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index d396aaaf19a3..cd0a83ff1029 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -118,6 +118,7 @@ extern unsigned int sysctl_nr_open_min, sysctl_nr_open_max;
#ifndef CONFIG_MMU
extern int sysctl_nr_trim_pages;
#endif
+extern int dcache_dentry_dir_max_sysctl;
/* Constants used for minimum and maximum */
#ifdef CONFIG_LOCKUP_DETECTOR
@@ -127,6 +128,7 @@ static int sixty = 60;
static int __maybe_unused neg_one = -1;
static int __maybe_unused two = 2;
static int __maybe_unused four = 4;
+static int __maybe_unused zero;
static unsigned long zero_ul;
static unsigned long one_ul = 1;
static unsigned long long_max = LONG_MAX;
@@ -1949,6 +1951,14 @@ static struct ctl_table fs_table[] = {
.proc_handler = proc_dointvec_minmax,
.extra1 = SYSCTL_ONE,
},
+ {
+ .procname = "dentry-dir-max",
+ .data = &dcache_dentry_dir_max_sysctl,
+ .maxlen = sizeof(dcache_dentry_dir_max_sysctl),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ },
{ }
};
--
2.18.1
Powered by blists - more mailing lists