On Thu, 20 Jul 2023 10:50:42 +1000 Stephen Rothwell wrote:
> Hi all,
>
> On Sat, 8 Jul 2023 00:17:15 +0000 "Von Dentz, Luiz" <luiz.von.dentz@xxxxxxxxx> wrote:
> >
> > There was a patch sent to net-next that was supposed to fix this:
> >
> > [PATCH v1 net-next 2/2] net: scm: introduce and use scm_recv_unix helper
> >
> > I am waiting for it to be merged.
> >
> >
> > ________________________________
> > From: Stephen Rothwell
> > Sent: Thursday, July 6, 2023 4:41 PM
> > To: Marcel Holtmann; Johan Hedberg
> > Cc: Von Dentz, Luiz; Linux Kernel Mailing List; Linux Next Mailing List
> > Subject: Re: linux-next: build failure after merge of the bluetooth tree
> >
> > Hi all,
> >
> > On Fri, 16 Jun 2023 08:32:37 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Tue, 13 Jun 2023 13:02:58 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> > > >
> > > After merging the bluetooth tree, today's linux-next build (arm
> > > > multi_v7_defconfig) failed like this:
> > > >
> > > > ERROR: modpost: "pidfd_prepare" [net/bluetooth/bluetooth.ko] undefined!
> > > >
> > > > Caused by commit
> > > >
> > > > 817efd3cad74 ("Bluetooth: hci_sock: Forward credentials to monitor")
> > > >
> > > > I have reverted that commit for today.
> > >
> > > I am still reverting that commit.
> >
> > Ditto
>
> This is getting a bit ridiculous ... a build failure reported over a
> month ago with a fix
> (https://lore.kernel.org/netdev/20230626215951.563715-1-aleksandr.mikhalitsyn@xxxxxxxxxxxxx)
> posted 3 weeks ago, has not yet been fixed :-(
>
> What is stopping that fix (with the appropriate followup) being added
> to the bluetooth tree? Or just the fix being added to the net-next tree?
>
> Yes, I know that the time period includes the merge window, but it has
> been more that a week since then.
Something weird. We did merge it, there was a sort-of-v2-called-v1:
https://lore.kernel.org/all/20230627174314.67688-1-kuniyu@xxxxxxxxxx/
Merged as https://git.kernel.org/netdev/net-next/c/a9c49cc2f5b5
Dunno how it's supposed to fix this particular issue, tho, on a closer
look, as it still calls:
scm_recv_unix() -> scm_pidfd_recv() -> pidfd_prepare()
:S
