Hi Greg,
On Sun, Aug 11, 2024 at 12:09:30PM +0200, Greg Kroah-Hartman wrote:
On Wed, Aug 07, 2024 at 10:35:11PM +0200, Salvatore Bonaccorso wrote:
Hi Greg,
On Wed, Aug 07, 2024 at 04:59:39PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.104 release. There are 86 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 09 Aug 2024 15:00:24 +0000. Anything received after that time might be too late.
6.1.103 had the regression of bpftool not building, due to a missing backport:
https://lore.kernel.org/stable/v8lqgl%2415bq%241@ciao.gmane.io/
The problem is that da5f8fd1f0d3 ("bpftool: Mount bpffs when pinmaps path not under the bpffs") was backported to 6.1.103 but there is no defintion of create_and_mount_bpffs_dir().
it was suggested to revert the commit completely.
Thanks for this, I'll fix it up after this release.
Thanks! Note today Quentin Monnet proposed another solution by cherry-picking two commits:
https://lore.kernel.org/stable/67bfcb8a-e00e-47b2-afe2-970a60e4a173@kernel.o...
Quoting:
You should be able to fix the build by first cherry-picking commit 2a36c26fe3b8 ("bpftool: Support bpffs mountpoint as pin path for prog loadall"), and then commit 478a535ae54a ("bpftool: Mount bpffs on provided dir instead of parent dir") as you figured. Both commits have a minor conflict on tools/bpf/bpftool/struct_ops.c, which should be addressed by discarding the relevant hunk (for both commit).
Alternatively, it's also fine to revert the breaking commit. It's a quality of life improvement without which users may have to manually mount the bpffs at the location they want to pin their maps when loading multiple BPF programs with "bpftool prog loadall", in the unlikely event they're not using /sys/kernel/bpf, prior to running the bpftool command. It's not in use during the kernel build process or for the BPF selftests, so not necessary on stable branches.
I hope this helps, Quentin
I cannot judge which is less risky, but I will for Debian in any case follow what will be picked (if needed to cherry-pick those in advance; I was meaning to release another update but can now as well wait for 6.1.105 with that bpftool fix).
Regards, Salvatore