Re: Patch for the close_range() musl build failure

...

Hi Huang Jing,

Thanks for investigating and fixing this! A few notes, inline, below.

They are all formal and trivial so I can fix up all of them on merge if you agree (but you can also choose to re-send as v2 with those fixed, let me know, in case).

I'm pointing those out especially for the future, should you happen to contribute again to this project or projects following a similar workflow.

Thanks!

...

...

From 25831e518c9227a31b75f2c1eb2e620fd4c5d049 Mon Sep 17 00:00:00 2001

We follow essentially the same contribution process as the Linux kernel, see also CONTRIBUTING.md and:

https://www.kernel.org/doc/html/next/process/submitting-patches.html

...so we don't send them patches as attachments, they're simply in the email body, just like git send-email sends them.

...

From: RadioNoiseE Date: Thu, 6 Aug 2026 19:58:45 +0800 Subject: [PATCH] isolation: Include linux_dep.h for close_range()

Now that close_open_files() has been moved, linux_dep.h can be safely

Stated like this, it looks like a more detailed description of the patch, compared to the title.

It's something you're adding to it instead. To avoid confusion about what the patch does (most importantly, what's in the title), I'd suggest to phrase it like:

...and now that close_open_files() ...

...

removed from util.c.

Here we need a couple of tags to provide some context (which might be important when looking at this later), that is:

Link: https://github.com/gentoo/gentoo/pull/46644 Fixes: 0a510066e916 ("isolation: Move close_open_files() to isolate_fds()")

and, while at it, it's a good practice to Cc: the author of the change that's being fixed up (I just did).

I second the minor procedural nits, but the patch looks good to me too, so,

Reviewed-by: David Gibson

Will send the fixed patch in the following mail.