From: Tycho Andersen <tycho@tycho.pizza>
To: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Cc: brauner@kernel.org, stgraber@stgraber.org, cyphar@cyphar.com,
linux-kernel@vger.kernel.org,
Christian Brauner <christian.brauner@ubuntu.com>
Subject: Re: [PATCH v1 2/2] tests/pid_namespace: add pid_max tests
Date: Thu, 22 Feb 2024 09:54:08 -0700 [thread overview]
Message-ID: <Zdd8MAJJD3M11yeR@tycho.pizza> (raw)
In-Reply-To: <20240222160915.315255-3-aleksandr.mikhalitsyn@canonical.com>
On Thu, Feb 22, 2024 at 05:09:15PM +0100, Alexander Mikhalitsyn wrote:
> +static int pid_max_nested_limit_inner(void *data)
> +{
> + int fret = -1, nr_procs = 400;
> + int fd, ret;
> + pid_t pid;
> + pid_t pids[1000];
> +
> + ret = mount("", "/", NULL, MS_PRIVATE | MS_REC, 0);
> + if (ret) {
> + fprintf(stderr, "%m - Failed to make rootfs private mount\n");
> + return fret;
> + }
> +
> + umount2("/proc", MNT_DETACH);
> +
> + ret = mount("proc", "/proc", "proc", 0, NULL);
> + if (ret) {
> + fprintf(stderr, "%m - Failed to mount proc\n");
> + return fret;
> + }
> +
> + fd = open("/proc/sys/kernel/pid_max", O_RDWR | O_CLOEXEC | O_NOCTTY);
> + if (fd < 0) {
> + fprintf(stderr, "%m - Failed to open pid_max\n");
> + return fret;
> + }
> +
> + ret = write(fd, "500", sizeof("500") - 1);
> + close(fd);
> + if (ret < 0) {
> + fprintf(stderr, "%m - Failed to write pid_max\n");
> + return fret;
> + }
> +
> + for (nr_procs = 0; nr_procs < 500; nr_procs++) {
> + pid = fork();
> + if (pid < 0)
> + break;
> +
> + if (pid == 0)
> + exit(EXIT_SUCCESS);
> +
> + pids[nr_procs] = pid;
> + }
> +
> + if (nr_procs >= 400) {
> + fprintf(stderr, "Managed to create processes beyond the configured outer limit\n");
> + goto reap;
> + }
A small quibble, but I wonder about the semantics here. "You can write
whatever you want to this file, but we'll ignore it sometimes" seems
weird to me. What if someone (CRIU) wants to spawn a pid numbered 450
in this case? I suppose they read pid_max first, they'll be able to
tell it's impossible and can exit(1), but returning E2BIG from write()
might be more useful.
Tycho
next prev parent reply other threads:[~2024-02-22 16:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 16:09 [PATCH v1 0/2] pid_namespace: namespacify sysctl kernel.pid_max Alexander Mikhalitsyn
2024-02-22 16:09 ` [PATCH v1 1/2] pid: allow pid_max to be set per pid namespace Alexander Mikhalitsyn
2024-02-22 16:09 ` [PATCH v1 2/2] tests/pid_namespace: add pid_max tests Alexander Mikhalitsyn
2024-02-22 16:54 ` Tycho Andersen [this message]
2024-02-23 16:24 ` Christian Brauner
2024-02-24 14:59 ` Tycho Andersen
2024-02-26 8:57 ` Christian Brauner
2024-02-26 15:30 ` Tycho Andersen
2024-02-26 15:45 ` Christian Brauner
2024-02-29 15:14 ` Aleksandr Mikhalitsyn
2024-02-29 16:11 ` Aleksandr Mikhalitsyn
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=Zdd8MAJJD3M11yeR@tycho.pizza \
--to=tycho@tycho.pizza \
--cc=aleksandr.mikhalitsyn@canonical.com \
--cc=brauner@kernel.org \
--cc=christian.brauner@ubuntu.com \
--cc=cyphar@cyphar.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stgraber@stgraber.org \
/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.