utils: Handle close_range more gracefully

[evanphx]

This fixes 2 things:

1. The last argument needs to be at most a int32, so be sure to pass only that as the max (discovered under gvisor)
2. If close_range fails, don't error out, instead just close the fds the long way.

[rata]

Not sure I get this. If close range fails and we have detected closeRange is available, what does this fallback add?

The errors it can return don't seem like something using the regular close fallback will fix: https://man7.org/linux/man-pages/man2/close_range.2.html.

Am I missing something? Do you see where this new fallback can help?

[evanphx]

It's more defensive, given the existing defensive attempts to see if close_range is available at all. We probe if we can use it, and thusly if for some reason the probe was wrong, we've got the fallback functionality at hand so seems prudent to use it.

[kolyshkin]

I agree with @evanphx here -- if we can use a fallback, it makes more sense to use it rather than give up and fail right away. Yes, we might still fail later, but oh well, we tried.

[evanphx]

Cool! Should be all ready now.

[kolyshkin]

While the fallback makes sense, the call to CloseRange is guarded by haveCloseRangeCloexec, meaning if the former fails, the latter is not an adequate check.

Or is it failing only because gvisor doesn't like MaxUint? Maybe it makes sense to add const closeRangeMaxFD and use it in both CloseExecFrom and haveCloseRangeCloexec?

Also, the first and last arguments of close_range are of unsigned int type in both glibc and the kernel. From a cursory look at the kernel code I don't see how specifying MaxUint64 can break things in the kernel.

[kolyshkin]

Also, the first and last arguments of close_range are of unsigned int type in both glibc and the kernel. From a cursory look at the kernel code I don't see how specifying MaxUint64 can break things in the kernel.

My bad, I forgot that C int is 32-bit even on a 64-bit platform.

[rata]

@kolyshkin how are these PRs related to gvisor? I thought gvisor was used as an OCI runtime, as a runc replacement. But from your comment, it seems that is not what is happening here, is it? How is that runc and gvisor are run together in this scenario?

[evanphx]

This was running runc within a container managed by runsc, that’s why I’ve brought it up here.

…

On Wed, Jan 22, 2025 at 12:55 PM Rodrigo Campos ***@***.***> wrote: @kolyshkin <https://github.com/kolyshkin> how are these PRs related to gvisor? I thought gvisor was used as an OCI runtime, as a runc replacement. But from your comment, it seems that is not what is happening here, is it? How is that runc and gvisor are run together in this scenario? — Reply to this email directly, view it on GitHub <#4596 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAAB7PCJDVIJQ3EGW6DEL2MAATPAVCNFSM6AAAAABVPNYGF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYGI2DGNJWGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>