close_range is not available on older systems, preventing the building of a UML kernel

[Geert Uytterhoeven]

Hi Benjamin,

On Wed, Jan 8, 2025 at 11:58 AM Benjamin Berg <benjamin at sipsolutions.net> wrote:
> On Wed, 2025-01-08 at 02:24 -0600, Glenn Washburn wrote:
> > I'm wanting to build a UML kernel on Debian bullseye, which is at
> > kernel version 5.10, which does not support close_range(). It appears
> > as though close_range() support is required on the host since commit
> > 32e8eaf263d ("um: use execveat to create userspace MMs"). Was there a
> > conscious decision to break support for kernels less than 5.11, when
> > close_range() was added. What is the policy on support of the host
> > kernel? Since 5.4 is still supported as a longterm release. I think it
> > would be nice to at least support 5.4. Is there any interest in
> > removing this restriction?
> >
> > Also, this system is at glibc 2.31, which does not have execveat()
> > support, which is required by that same commit above. Since execveat()
> > has been supported since 3.19, this kernel should support it. Perhaps
> > the issue can be resolved by defining a syscall wrapper in the UM
> > headers if support is not found in glibc.
>
> Yeah, we need the CLOSE_RANGE_CLOEXEC flag, which was added in 5.11.
>
> On the one hand, there is no real alternative. This is a relatively hot
> path (fork/exec), so I wouldn't want to replace the call with a loop.
>
> On the other, this is "only" an extra safety measure. It is acceptable
> for this to fail (the result is not even checked currently). As such,
> the biggest issue seems to be that your libc does not yet have the
> symbol.
>
> Said differently, we could just replace the call with:
>
> #ifndef CLOSE_RANGE_CLOEXEC
> #define CLOSE_RANGE_CLOEXEC    (1U << 2)
> #endif

Would including include/uapi/linux/close_range.h help?

>   syscall(__NR_close_range, 0, ~0U, CLOSE_RANGE_CLOEXEC);
>
> I am not sure whether we would want to do this in the upstream code.

tools/testing/selftests/bpf/prog_tests/d_path.c does that, too.
But that's not real upstream kernel code...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds