[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZrjS0V-tCQ1tGkRu@eldamar.lan>
Date: Sun, 11 Aug 2024 17:03:45 +0200
From: Salvatore Bonaccorso <carnil@...ian.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: stable@...r.kernel.org, patches@...ts.linux.dev,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, linux@...ck-us.net, shuah@...nel.org,
patches@...nelci.org, lkft-triage@...ts.linaro.org, pavel@...x.de,
jonathanh@...dia.com, f.fainelli@...il.com,
sudipm.mukherjee@...il.com, srw@...dewatkins.net, rwarsow@....de,
conor@...nel.org, allen.lkml@...il.com, broonie@...nel.org,
Akemi Yagi <toracat@...epo.org>,
Hardik Garg <hargar@...ux.microsoft.com>,
Quentin Monnet <qmo@...nel.org>, bpf@...r.kernel.org
Subject: Re: [PATCH 6.1 00/86] 6.1.104-rc1 review
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
Powered by blists - more mailing lists