All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tiezhu Yang <yangtiezhu@loongson.cn>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
	Jonathan Corbet <corbet@lwn.net>
Cc: linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, Xuefeng Li <lixuefeng@loongson.cn>
Subject: [PATCH 2/3] fs: Introduce cmdline argument exceed_file_max_panic
Date: Sat,  6 Jun 2020 14:32:19 +0800	[thread overview]
Message-ID: <1591425140-20613-2-git-send-email-yangtiezhu@loongson.cn> (raw)
In-Reply-To: <1591425140-20613-1-git-send-email-yangtiezhu@loongson.cn>

It is important to ensure that files that are opened always get closed.
Failing to close files can result in file descriptor leaks. One common
answer to this problem is to just raise the limit of open file handles
and then restart the server every day or every few hours, this is not
a good idea for long-lived servers if there is no leaks.

If there exists file descriptor leaks, when file-max limit reached, we
can see that the system can not work well and at worst the user can do
nothing, it is even impossible to execute reboot command due to too many
open files in system. In order to reboot automatically to recover to the
normal status, introduce a new cmdline argument exceed_file_max_panic for
user to control whether to call panic in this case.

We can reproduce this problem used with the following simple test:

[yangtiezhu@linux ~]$ cat exceed_file_max_test.c
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main()
{
	int fd;

	while (1) {
		fd = open("/usr/include/stdio.h", 0444);
		if (fd == -1)
			fprintf(stderr, "%s\n", "open failed");
	}

	return 0;
}
[yangtiezhu@linux ~]$ cat exceed_file_max_test.sh
#!/bin/bash

gcc exceed_file_max_test.c -o exceed_file_max_test.bin -Wall

while true
do
	./exceed_file_max_test.bin >/dev/null 2>&1 &
done
[yangtiezhu@linux ~]$ sh exceed_file_max_test.sh &
[yangtiezhu@linux ~]$ reboot
bash: start pipeline: pgrp pipe: Too many open files in system
bash: /usr/sbin/reboot: Too many open files in system

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 fs/file_table.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/fs/file_table.c b/fs/file_table.c
index 26516d0..6943945 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -121,6 +121,17 @@ static struct file *__alloc_file(int flags, const struct cred *cred)
 	return f;
 }
 
+static bool exceed_file_max_panic;
+static int __init exceed_file_max_panic_setup(char *str)
+{
+	pr_info("Call panic when exceed file-max limit\n");
+	exceed_file_max_panic = true;
+
+	return 1;
+}
+
+__setup("exceed_file_max_panic", exceed_file_max_panic_setup);
+
 /* Find an unused file structure and return a pointer to it.
  * Returns an error pointer if some error happend e.g. we over file
  * structures limit, run out of memory or operation is not permitted.
@@ -159,6 +170,9 @@ struct file *alloc_empty_file(int flags, const struct cred *cred)
 	if (get_nr_files() > old_max) {
 		pr_info("VFS: file-max limit %lu reached\n", get_max_files());
 		old_max = get_nr_files();
+
+		if (exceed_file_max_panic)
+			panic("VFS: Too many open files in system\n");
 	}
 	return ERR_PTR(-ENFILE);
 }
-- 
2.1.0


  reply	other threads:[~2020-06-06  6:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-06  6:32 [PATCH 1/3] fs: Use get_max_files() instead of files_stat.max_files in alloc_empty_file() Tiezhu Yang
2020-06-06  6:32 ` Tiezhu Yang [this message]
2020-06-06 14:13   ` [PATCH 2/3] fs: Introduce cmdline argument exceed_file_max_panic Matthew Wilcox
2020-06-06 14:28   ` Al Viro
2020-06-06  6:32 ` [PATCH 3/3] docs: admin-guide: Explain cmdline argument exceed_file_max_panic in fs.rst Tiezhu Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1591425140-20613-2-git-send-email-yangtiezhu@loongson.cn \
    --to=yangtiezhu@loongson.cn \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lixuefeng@loongson.cn \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.