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

[Benjamin Berg]

Hi,

On Wed, 2025-01-08 at 12:13 +0100, Geert Uytterhoeven wrote:
> 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?

Well, I expect there is the chance that the system version of the
header is included indirectly and that would lead to redefines.

> >   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...

I'll submit a patch. I am a bit ambivalent about supporting kernels as
old as 5.4. But, it is simple here, so might as well do it.

Benjamin