From: Konstantin Khorenko <khorenko@virtuozzo.com>
Subject: [Devel] [PATCH vz10 v2 0/1] selftests/core: fix unshare_test with large fs.nr_open
Date: Fri, 14 Aug 2026 18:18:51 +0200 [thread overview]
Message-ID: <20260814161852.278262-1-khorenko@virtuozzo.com> (raw)
In-Reply-To: <20260518113556.516760-1-eva.kurchatova@virtuozzo.com>
unshare_test assumes fs.nr_open is close to the default 1048576, but
systemd bumps it to its largest possible value on boot (e.g.
1073741816) since v240, which makes the test's dup2() past nr_open
try to allocate a ~1 billion entry fd table and fail with ENOMEM.
Changes from v1:
- v1 capped nr_open in place and reused the same buffer (buf/n) both
for the capped test value and for the original fs.nr_open readout,
so the "restore fs.nr_open" write done by the child before calling
unshare() ended up writing the capped value back instead of the
real original one. Since fs.nr_open is a global, non-namespaced
sysctl, this permanently lowered it on any system where it was
originally set above 1 MiB, as a side effect of running the test.
- v2 keeps buf/n untouched as the real original value and caps only
the local nr_open variable used for the test's own arithmetic. The
child still restores the capped baseline before calling unshare()
(that's still needed to trigger EMFILE), but we now additionally
restore the real original fs.nr_open value in the parent once the
test has completed, so the test no longer leaves the sysctl
modified after a run.
Eva Kurchatova (1):
selftests/core: fix unshare_test with large fs.nr_open
tools/testing/selftests/core/unshare_test.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
--
2.43.0
next parent reply other threads:[~2026-08-14 16:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260518113556.516760-1-eva.kurchatova@virtuozzo.com>
2026-08-14 16:18 ` Konstantin Khorenko [this message]
2026-08-14 16:18 ` [Devel] [PATCH vz10 v2 1/1] " Konstantin Khorenko
2026-08-14 16:24 ` [Devel] [PATCH RHEL10 COMMIT] " Konstantin Khorenko
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=20260814161852.278262-1-khorenko@virtuozzo.com \
--to=khorenko@virtuozzo.com \
/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.