Re: [PATCH 6.1 00/86] 6.1.104-rc1 review

[Salvatore Bonaccorso <carnil@debian.org>]

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@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.org/

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