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$15bq$1@xxxxxxxxxxxxx/ > > > > 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@xxxxxxxxxx/ 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
