On Fri, 14 Aug 2026 18:57:09 +0200 Konstantin Khorenko <[email protected]> wrote:
> The test assumes fs.nr_open is close to the default 1048576, but some > systems set it much higher (e.g. 1073741816). This is systemd's doing: > since systemd v240 (2018), PID 1 bumps fs.nr_open and fs.file-max to > their largest possible values on boot, as file descriptors are already > accounted for by memcg [1]. > > In that case, dup2() to nr_open + 64 requires the kernel to allocate a > file descriptor table with ~1 billion entries, which fails with ENOMEM. 2018. Can you suggest why we (or I) haven't heard about this? > Cap the nr_open value used for the test's own arithmetic to a known > reasonable base value (1048576) and restore the true original value > once the test has completed. > > [1] > https://github.com/systemd/systemd/commit/a8b627aaed409a15260c25988970c795bf963812 > ("main: bump fs.nr_open + fs.max-file to their largest possible values") Well, we do want selftests to run well on the kernel with which they are shipped, so I'm thinking we should backport this into -stable kernels. We can probably skip the Fixes:, but a cc:stable should be added to capture this. Thoughts?
