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

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

[Salvatore Bonaccorso]

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

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

[Greg Kroah-Hartman]

On Sun, Aug 11, 2024 at 05:03:45PM +0200, Salvatore Bonaccorso wrote:
> 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/

They don't apply cleanly, so I'll just add a revert...

thanks,

greg k-h

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

[Salvatore Bonaccorso]

Hi Greg,

On Sun, Aug 11, 2024 at 05:40:58PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Aug 11, 2024 at 05:03:45PM +0200, Salvatore Bonaccorso wrote:
> > 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/
> 
> They don't apply cleanly, so I'll just add a revert...

FYI: Just realized that the breaking commit was as well queued for
older series 5.15.y, 5.10.y and 5.4.y, so that needs to be dropped
from those queues as well.

Regards,
Salvatore

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

[Greg Kroah-Hartman]

On Mon, Aug 12, 2024 at 07:49:34PM +0200, Salvatore Bonaccorso wrote:
> Hi Greg,
> 
> On Sun, Aug 11, 2024 at 05:40:58PM +0200, Greg Kroah-Hartman wrote:
> > On Sun, Aug 11, 2024 at 05:03:45PM +0200, Salvatore Bonaccorso wrote:
> > > 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/
> > 
> > They don't apply cleanly, so I'll just add a revert...
> 
> FYI: Just realized that the breaking commit was as well queued for
> older series 5.15.y, 5.10.y and 5.4.y, so that needs to be dropped
> from those queues as well.

Good catch, I'll go drop it now from them, thanks!

greg k-h