[-- Attachment #1: Type: text/plain, Size: 534 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc pseries_defconfig) failed like this: drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'write_swqe2_data': drivers/net/ethernet/ibm/ehea/ehea_main.c:1692: error: implicit declaration of function 'frag_size' Presumably caused by commit 9e903e085262 ("net: add skb frag size accessors"). I guess it should have been "skb_frag_size()". -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
Le mercredi 26 octobre 2011 à 00:55 +1100, Stephen Rothwell a écrit : > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > pseries_defconfig) failed like this: > > drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'write_swqe2_data': > drivers/net/ethernet/ibm/ehea/ehea_main.c:1692: error: implicit declaration of function 'frag_size' > > Presumably caused by commit 9e903e085262 ("net: add skb frag size > accessors"). I guess it should have been "skb_frag_size()". My bad, sorry [PATCH] ehea: fix skb_frag_size typo commit 9e903e085262 (net: add skb frag size accessors) introduced a typo in ehea driver. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> --- drivers/net/ethernet/ibm/ehea/ehea_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c index 0d4d4f6..37b70f7 100644 --- a/drivers/net/ethernet/ibm/ehea/ehea_main.c +++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c @@ -1689,7 +1689,7 @@ static inline void write_swqe2_data(struct sk_buff *skb, struct net_device *dev, sgentry = &sg_list[i - sg1entry_contains_frag_data]; sgentry->l_key = lkey; - sgentry->len = frag_size(frag); + sgentry->len = skb_frag_size(frag); sgentry->vaddr = ehea_map_vaddr(skb_frag_address(frag)); swqe->descriptors++; }
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 23 Apr 2012 12:14:51 +1000
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> net/ax25/af_ax25.c: In function 'ax25_exit':
> net/ax25/af_ax25.c:2015:2: error: implicit declaration of function 'ax25_unregister_sysctl' [-Werror=implicit-function-declaration]
>
> Caused by a mismerge between commit 3adadc08cc1e ("net ax25: Reorder
> ax25_exit to remove races") from the net tree and commit 0ca7a4c87d27
> ("net ax25: Simplify and cleanup the ax25 sysctl handling") from the
> net-next tree.
>
> I have applied the following merge fix patch:
Looks correct, and I'll resolve this the next time I pull
net into net-next.
Thanks!
[-- Attachment #1: Type: text/plain, Size: 583 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: ERROR: "clk_get_rate" [drivers/net/can/c_can/c_can_pci.ko] undefined! ERROR: "clk_get" [drivers/net/can/c_can/c_can_pci.ko] undefined! ERROR: "clk_put" [drivers/net/can/c_can/c_can_pci.ko] undefined! Caused by commit 5b92da0443c2 ("c_can_pci: generic module for C_CAN/D_CAN on PCI"). Maybe a missing Kconfig dependency/select? I have used the net-next tree from next-20120619 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 20 Jun 2012 13:33:48 +1000 > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > ERROR: "clk_get_rate" [drivers/net/can/c_can/c_can_pci.ko] undefined! > ERROR: "clk_get" [drivers/net/can/c_can/c_can_pci.ko] undefined! > ERROR: "clk_put" [drivers/net/can/c_can/c_can_pci.ko] undefined! > > Caused by commit 5b92da0443c2 ("c_can_pci: generic module for C_CAN/D_CAN > on PCI"). Maybe a missing Kconfig dependency/select? > > I have used the net-next tree from next-20120619 for today. Known problem: http://marc.info/?l=linux-netdev&m=134014347620836&w=2
Hi, > -----Original Message----- > From: Stephen Rothwell [mailto:sfr@canb.auug.org.au] > Sent: Wednesday, June 20, 2012 9:04 AM > To: David Miller; netdev@vger.kernel.org > Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Federico > Vaga; Giancarlo ASNAGHI; Wolfgang Grandegger; Bhupesh SHARMA; Marc > Kleine-Budde > Subject: linux-next: build failure after merge of the net-next tree > > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > ERROR: "clk_get_rate" [drivers/net/can/c_can/c_can_pci.ko] undefined! > ERROR: "clk_get" [drivers/net/can/c_can/c_can_pci.ko] undefined! > ERROR: "clk_put" [drivers/net/can/c_can/c_can_pci.ko] undefined! > > Caused by commit 5b92da0443c2 ("c_can_pci: generic module for > C_CAN/D_CAN on PCI"). Maybe a missing Kconfig dependency/select? > > I have used the net-next tree from next-20120619 for today. > -- clk_get/clk_put* variants are usually used by ARM platforms. Protecting their calls under macro 'CONFIG_HAVE_CLK' should solve the problem. See [1] for how it is done in c_can_platform.c Could you possibly add these checks and send a patch for the same? It should be fairly simple. [1] http://lxr.linux.no/linux+v3.4.3/drivers/net/can/c_can/c_can_platform.c#L68 Regards, Bhupesh
From: Bhupesh SHARMA <bhupesh.sharma@st.com>
Date: Wed, 20 Jun 2012 12:27:11 +0800
> clk_get/clk_put* variants are usually used by ARM platforms.
> Protecting their calls under macro 'CONFIG_HAVE_CLK' should solve the problem.
No, we don't pepper foo.c files with crappy ifdefs.
Hi David,
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, June 20, 2012 10:07 AM
> To: Bhupesh SHARMA
> Cc: sfr@canb.auug.org.au; netdev@vger.kernel.org; linux-
> next@vger.kernel.org; linux-kernel@vger.kernel.org;
> federico.vaga@gmail.com; Giancarlo ASNAGHI; wg@grandegger.com;
> mkl@pengutronix.de
> Subject: Re: linux-next: build failure after merge of the net-next tree
>
> From: Bhupesh SHARMA <bhupesh.sharma@st.com>
> Date: Wed, 20 Jun 2012 12:27:11 +0800
>
> > clk_get/clk_put* variants are usually used by ARM platforms.
> > Protecting their calls under macro 'CONFIG_HAVE_CLK' should solve the
> problem.
>
> No, we don't pepper foo.c files with crappy ifdefs.
So, whether adding a check in Kconfig for HAVE_CLK be a proper solution ?
But that will limit the compilation of this driver for only platforms which are ARM based.
One may need to support this driver on x86 like platforms also..
Regards,
Bhupesh
From: Bhupesh SHARMA <bhupesh.sharma@st.com>
Date: Wed, 20 Jun 2012 12:45:46 +0800
> So, whether adding a check in Kconfig for HAVE_CLK be a proper
> solution ? But that will limit the compilation of this driver for
> only platforms which are ARM based.
>
> One may need to support this driver on x86 like platforms also..
Then x86 will need to provide clock operations, or there needs to
be dummy ones for such platforms.
This isn't rocket science.
On 20/06/12 05:27, Bhupesh SHARMA wrote: >> -----Original Message----- >> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au] >> Sent: Wednesday, June 20, 2012 9:04 AM >> To: David Miller; netdev@vger.kernel.org >> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Federico >> Vaga; Giancarlo ASNAGHI; Wolfgang Grandegger; Bhupesh SHARMA; Marc >> Kleine-Budde >> Subject: linux-next: build failure after merge of the net-next tree >> >> Hi all, >> >> After merging the net-next tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >> ERROR: "clk_get_rate" [drivers/net/can/c_can/c_can_pci.ko] undefined! >> ERROR: "clk_get" [drivers/net/can/c_can/c_can_pci.ko] undefined! >> ERROR: "clk_put" [drivers/net/can/c_can/c_can_pci.ko] undefined! >> >> Caused by commit 5b92da0443c2 ("c_can_pci: generic module for >> C_CAN/D_CAN on PCI"). Maybe a missing Kconfig dependency/select? >> >> I have used the net-next tree from next-20120619 for today. >> -- > > clk_get/clk_put* variants are usually used by ARM platforms. > Protecting their calls under macro 'CONFIG_HAVE_CLK' should solve the problem. > > See [1] for how it is done in c_can_platform.c > > Could you possibly add these checks and send a patch for the same? > It should be fairly simple. Hi Bhupesh, Please see following patchset from me, that got applied in linux-next https://lkml.org/lkml/2012/4/24/154 Please check if this patchset is present in your build repo. I believe it should be there. If it is, then you shouldn't get these errors. -- viresh -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
From: viresh kumar <viresh.kumar2@arm.com>
Date: Wed, 20 Jun 2012 09:08:34 +0100
> Please see following patchset from me, that got applied in linux-next
>
> https://lkml.org/lkml/2012/4/24/154
>
> Please check if this patchset is present in your build repo. I believe it should be
> there. If it is, then you shouldn't get these errors.
Well, then Stephen shouldn't get those errors either.
But obviously he did.
But all of this talk about changes existing only in linux-next is
entirely moot. Because The damn thing MUST build independently inside
of net-next which doesn't have those clock layer changes.
Someone send me a clean fix for net-next now.
[-- Attachment #1: Type: text/plain, Size: 1542 bytes --] On 06/20/2012 06:45 AM, Bhupesh SHARMA wrote: > Hi David, > >> -----Original Message----- >> From: David Miller [mailto:davem@davemloft.net] >> Sent: Wednesday, June 20, 2012 10:07 AM >> To: Bhupesh SHARMA >> Cc: sfr@canb.auug.org.au; netdev@vger.kernel.org; linux- >> next@vger.kernel.org; linux-kernel@vger.kernel.org; >> federico.vaga@gmail.com; Giancarlo ASNAGHI; wg@grandegger.com; >> mkl@pengutronix.de >> Subject: Re: linux-next: build failure after merge of the net-next tree >> >> From: Bhupesh SHARMA <bhupesh.sharma@st.com> >> Date: Wed, 20 Jun 2012 12:27:11 +0800 >> >>> clk_get/clk_put* variants are usually used by ARM platforms. >>> Protecting their calls under macro 'CONFIG_HAVE_CLK' should solve the >> problem. >> >> No, we don't pepper foo.c files with crappy ifdefs. > > So, whether adding a check in Kconfig for HAVE_CLK be a proper solution ? > But that will limit the compilation of this driver for only platforms which are ARM based. > > One may need to support this driver on x86 like platforms also.. I think the driver is currently used/tested only on ARM only, so what about adding a HAVE_CLK dependency, until Viresh Kumar's patches are available in net-next. Later we can remove it. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 262 bytes --]
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 20 Jun 2012 10:31:26 +0200
> I think the driver is currently used/tested only on ARM only, so what
> about adding a HAVE_CLK dependency, until Viresh Kumar's patches are
> available in net-next. Later we can remove it.
Sounds good.
On 20/06/12 09:20, David Miller wrote:
> From: viresh kumar <viresh.kumar2@arm.com>
> Date: Wed, 20 Jun 2012 09:08:34 +0100
>
>> > Please see following patchset from me, that got applied in linux-next
>> >
>> > https://lkml.org/lkml/2012/4/24/154
>> >
>> > Please check if this patchset is present in your build repo. I believe it should be
>> > there. If it is, then you shouldn't get these errors.
> Well, then Stephen shouldn't get those errors either.
>
> But obviously he did.
Surprised. I am not able to get why this happen. Because we don't have HAVE_CLK defined
for x86_64, then the inline routines like following should come into play:
static inline unsigned long clk_get_rate(struct clk *clk)
{
return 0;
}
Is there any tricky part for such routines with drivers compiled as modules?
--
Viresh
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> I think the driver is currently used/tested only on ARM only, so what
> about adding a HAVE_CLK dependency, until Viresh Kumar's patches are
> available in net-next. Later we can remove it.
This driver is tested only on an x86 with AMBA peripherals on PCI. We
are developing the clk side for this new platform.
--
Federico Vaga
From: Federico Vaga <federico.vaga@gmail.com>
Date: Wed, 20 Jun 2012 11:03:08 +0200
>> I think the driver is currently used/tested only on ARM only, so what
>> about adding a HAVE_CLK dependency, until Viresh Kumar's patches are
>> available in net-next. Later we can remove it.
>
> This driver is tested only on an x86 with AMBA peripherals on PCI. We
> are developing the clk side for this new platform.
Then the driver should NEVER have been submitted without the
required infrastructure in place first.
If what you say is true, I'm extremely pissed off about this now.
This submission was a complete cluster fuck, and it means the person
who submitted this to me didn't test the damn build even.
From: Federico Vaga <federico.vaga@gmail.com>
Date: Wed, 20 Jun 2012 11:59:26 +0200
>> Then the driver should NEVER have been submitted without the
>> required infrastructure in place first.
>
> This particular driver don't use the clk framework at the moment. I put
> that lines about clk to try to be generic as possibile, but I see that I
> made a mistake: I'm sorry.
Why would you try to be generic by using an interface currently
only available on certain platforms?
That is how you make drivers non-portable, and not generic.
> Then the driver should NEVER have been submitted without the
> required infrastructure in place first.
This particular driver don't use the clk framework at the moment. I put
that lines about clk to try to be generic as possibile, but I see that I
made a mistake: I'm sorry. An alternative solution to HAVE_CLK
dependency can be: remove the clk_* lines because actualy nobody use
them. In the future, if our c_can migrate to clk and our clk framework
is accepted in the kernel, we can re-add the clk_* lines.
--
Federico Vaga
> Why would you try to be generic by using an interface currently > only available on certain platforms? I know, I was wrong. > That is how you make drivers non-portable, and not generic. Now is fixed in my mind; I learn the lesson. -- Federico Vaga
[-- Attachment #1: Type: text/plain, Size: 1139 bytes --] Hi all, On Wed, 20 Jun 2012 01:20:37 -0700 (PDT) David Miller <davem@davemloft.net> wrote: > > From: viresh kumar <viresh.kumar2@arm.com> > Date: Wed, 20 Jun 2012 09:08:34 +0100 > > > Please see following patchset from me, that got applied in linux-next > > > > https://lkml.org/lkml/2012/4/24/154 > > > > Please check if this patchset is present in your build repo. I believe it should be > > there. If it is, then you shouldn't get these errors. > > Well, then Stephen shouldn't get those errors either. > > But obviously he did. > > But all of this talk about changes existing only in linux-next is > entirely moot. Because The damn thing MUST build independently inside > of net-next which doesn't have those clock layer changes. > > Someone send me a clean fix for net-next now. I get those errors because those patches are in the akpm tree which is merged after everything else ... One possibility is to put those changes in another (stable) tree and merge that into the net-next tree (and any other tree that needs it). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --] On 06/20/2012 12:26 PM, Stephen Rothwell wrote: > Hi all, > > On Wed, 20 Jun 2012 01:20:37 -0700 (PDT) David Miller <davem@davemloft.net> wrote: >> >> From: viresh kumar <viresh.kumar2@arm.com> >> Date: Wed, 20 Jun 2012 09:08:34 +0100 >> >>> Please see following patchset from me, that got applied in linux-next >>> >>> https://lkml.org/lkml/2012/4/24/154 >>> >>> Please check if this patchset is present in your build repo. I believe it should be >>> there. If it is, then you shouldn't get these errors. >> >> Well, then Stephen shouldn't get those errors either. >> >> But obviously he did. >> >> But all of this talk about changes existing only in linux-next is >> entirely moot. Because The damn thing MUST build independently inside >> of net-next which doesn't have those clock layer changes. >> >> Someone send me a clean fix for net-next now. > > I get those errors because those patches are in the akpm tree which is > merged after everything else ... > > One possibility is to put those changes in another (stable) tree and > merge that into the net-next tree (and any other tree that needs it). We're about to remove the offending clk_*() functions from the driver, as they are untested anyway. The hardware the driver was developed for uses a hardcoded clock rate in the driver anyway, as it cannot be retrieved from clock tree. As soon as there is hardware available that will work with the clock tree, we can add those functions back. Sorry for the noise, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 262 bytes --]
On Tue, Jun 19, 2012 at 09:47:59PM -0700, David Miller wrote: > From: Bhupesh SHARMA <bhupesh.sharma@st.com> > > So, whether adding a check in Kconfig for HAVE_CLK be a proper > > solution ? But that will limit the compilation of this driver for > > only platforms which are ARM based. > > One may need to support this driver on x86 like platforms also.. > Then x86 will need to provide clock operations, or there needs to > be dummy ones for such platforms. Not directly germane but I've been sending patches for this to the x86 guys for a little while though they're doing a /dev/null impression. > This isn't rocket science. The other option is that the clock API stubs itself out when not enabled which is going into mainline (not sure quite where it is at the minute). These sort of per-arch APIs should be a legacy thing, hopefully we'll manage to squash them at some point and we should certainly work to avoid introducing new ones.
[-- Attachment #1: Type: text/plain, Size: 1400 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/usb/qmi_wwan.c:381:13: error: 'qmi_wwan_unbind_shared' undeclared here (not in a function) Caused by a bad automatic merge between commit 6fecd35d4cd7 ("net: qmi_wwan: add ZTE MF60") from the net tree and commit 230718bda1be ("net: qmi_wwan: bind to both control and data interface") from the net-next tree. I added the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 10 Jul 2012 13:06:01 +1000 Subject: [PATCH] net: fix for qmi_wwan_unbind_shared changes Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/usb/qmi_wwan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 06cfcc7..85c983d 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -378,7 +378,7 @@ static const struct driver_info qmi_wwan_force_int2 = { .description = "Qualcomm WWAN/QMI device", .flags = FLAG_WWAN, .bind = qmi_wwan_bind_shared, - .unbind = qmi_wwan_unbind_shared, + .unbind = qmi_wwan_unbind, .manage_power = qmi_wwan_manage_power, .data = BIT(2), /* interface whitelist bitmap */ }; -- 1.7.10.280.gaa39 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/net/usb/qmi_wwan.c:381:13: error: 'qmi_wwan_unbind_shared' undeclared here (not in a function)
>
> Caused by a bad automatic merge between commit 6fecd35d4cd7 ("net:
> qmi_wwan: add ZTE MF60") from the net tree and commit 230718bda1be ("net:
> qmi_wwan: bind to both control and data interface") from the net-next
> tree.
>
> I added the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 10 Jul 2012 13:06:01 +1000
> Subject: [PATCH] net: fix for qmi_wwan_unbind_shared changes
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/net/usb/qmi_wwan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 06cfcc7..85c983d 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -378,7 +378,7 @@ static const struct driver_info qmi_wwan_force_int2 = {
> .description = "Qualcomm WWAN/QMI device",
> .flags = FLAG_WWAN,
> .bind = qmi_wwan_bind_shared,
> - .unbind = qmi_wwan_unbind_shared,
> + .unbind = qmi_wwan_unbind,
> .manage_power = qmi_wwan_manage_power,
> .data = BIT(2), /* interface whitelist bitmap */
> };
Looks good. Thanks.
Bjørn
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 10 Jul 2012 13:08:48 +1000
> I added the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 10 Jul 2012 13:06:01 +1000
> Subject: [PATCH] net: fix for qmi_wwan_unbind_shared changes
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks Stephen, I'll incorporate this when I merge net into net-next.
Thanks again!
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc pmac32_defconfig) failed like this: ERROR: "phy_disconnect" [drivers/net/usb/asix.ko] undefined! ERROR: "phy_stop" [drivers/net/usb/asix.ko] undefined! ERROR: "phy_ethtool_gset" [drivers/net/usb/asix.ko] undefined! ERROR: "mdiobus_unregister" [drivers/net/usb/asix.ko] undefined! ERROR: "phy_start_aneg" [drivers/net/usb/asix.ko] undefined! ERROR: "phy_print_status" [drivers/net/usb/asix.ko] undefined! ERROR: "phy_start" [drivers/net/usb/asix.ko] undefined! ERROR: "mdiobus_free" [drivers/net/usb/asix.ko] undefined! ERROR: "mdiobus_register" [drivers/net/usb/asix.ko] undefined! ERROR: "genphy_resume" [drivers/net/usb/asix.ko] undefined! ERROR: "phy_connect" [drivers/net/usb/asix.ko] undefined! ERROR: "phy_mii_ioctl" [drivers/net/usb/asix.ko] undefined! ERROR: "phy_ethtool_sset" [drivers/net/usb/asix.ko] undefined! ERROR: "mdiobus_alloc_size" [drivers/net/usb/asix.ko] undefined! Caused by commit 16626b0cc3d5 ("asix: Add a new driver for the AX88172A") and reverting that commit fixes the build. Thanks to Mikey for reporting this porblem. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 420 bytes --] On Fri, 20 Jul 2012 12:01:18 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (powerpc > pmac32_defconfig) failed like this: This was actually yesterday's linux-next - I guess it is fixed by commit 215029375c83 ("asix: AX88172A driver depends on phylib") in today's tree. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[Sent again due to problems with email client] Hi, On 07/20/2012 04:01 AM, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > pmac32_defconfig) failed like this: > > ERROR: "phy_disconnect" [drivers/net/usb/asix.ko] undefined! > ERROR: "phy_stop" [drivers/net/usb/asix.ko] undefined! > ERROR: "phy_ethtool_gset" [drivers/net/usb/asix.ko] undefined! > ERROR: "mdiobus_unregister" [drivers/net/usb/asix.ko] undefined! > ERROR: "phy_start_aneg" [drivers/net/usb/asix.ko] undefined! > ERROR: "phy_print_status" [drivers/net/usb/asix.ko] undefined! > ERROR: "phy_start" [drivers/net/usb/asix.ko] undefined! > ERROR: "mdiobus_free" [drivers/net/usb/asix.ko] undefined! > ERROR: "mdiobus_register" [drivers/net/usb/asix.ko] undefined! > ERROR: "genphy_resume" [drivers/net/usb/asix.ko] undefined! > ERROR: "phy_connect" [drivers/net/usb/asix.ko] undefined! > ERROR: "phy_mii_ioctl" [drivers/net/usb/asix.ko] undefined! > ERROR: "phy_ethtool_sset" [drivers/net/usb/asix.ko] undefined! > ERROR: "mdiobus_alloc_size" [drivers/net/usb/asix.ko] undefined! > > Caused by commit 16626b0cc3d5 ("asix: Add a new driver for the AX88172A") > and reverting that commit fixes the build. Sorry about that. I missed the dependency of the new driver on phylib. A fix for this problem is already in net-next, see commit 215029375c83. Thanks, Christian > > Thanks to Mikey for reporting this porblem.
[-- Attachment #1: Type: text/plain, Size: 528 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/net/ethernet/emulex/benet/be_main.c: In function 'be_find_vfs': drivers/net/ethernet/emulex/benet/be_main.c:1090:28: error: 'struct pci_dev' has no member named 'physfn' Caused by commit 51af6d7c1f31 ("be2net: fix vfs enumeration"). physfn is only defined if CONFIG_PCI_ATS is set. I have reverted that commit for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 28 Sep 2012 11:43:35 +1000
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/net/ethernet/emulex/benet/be_main.c: In function 'be_find_vfs':
> drivers/net/ethernet/emulex/benet/be_main.c:1090:28: error: 'struct pci_dev' has no member named 'physfn'
>
> Caused by commit 51af6d7c1f31 ("be2net: fix vfs enumeration"). physfn is
> only defined if CONFIG_PCI_ATS is set.
>
> I have reverted that commit for today.
I'm reverting it too, thanks for reporting Stephen.
On 09/28/2012 04:19 AM, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 28 Sep 2012 11:43:35 +1000
>
>> Hi all,
>>
>> After merging the net-next tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> drivers/net/ethernet/emulex/benet/be_main.c: In function 'be_find_vfs':
>> drivers/net/ethernet/emulex/benet/be_main.c:1090:28: error: 'struct pci_dev' has no member named 'physfn'
>>
>> Caused by commit 51af6d7c1f31 ("be2net: fix vfs enumeration"). physfn is
>> only defined if CONFIG_PCI_ATS is set.
>>
>> I have reverted that commit for today.
>
> I'm reverting it too, thanks for reporting Stephen.
>
Sorry for that, it will be better to use pci_physfn to access this
member. I'll repost the patch.
Ivan
[-- Attachment #1: Type: text/plain, Size: 2021 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c:1721:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'qlcnic_probe' drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c:1912:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'qlcnic_remove' Caused by commits 7e2cf4feba05 ("qlcnic: change driver hardware interface mechanism") and 13159183ec7a ("qlcnic: 83xx base driver") from the net-next tree interacting with commit 54b956b90360 ("Remove __dev* markings from init.h") from the drover-core.current tree. I have added the following merge fix patch for today which could be added directly to the scsi tree (please). From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 11 Jan 2013 13:15:05 +1100 Subject: [PATCH] qlcnic: remove new __dev* annotations CONFIG_HOTPLUG is always true now and the __dev* macros have been removed. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c index d331313..fb7ac8e 100644 --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c @@ -1717,7 +1717,7 @@ int qlcnic_alloc_tx_rings(struct qlcnic_adapter *adapter, return 0; } -static int __devinit +static int qlcnic_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { struct net_device *netdev = NULL; @@ -1909,7 +1909,7 @@ err_out_disable_pdev: return err; } -static void __devexit qlcnic_remove(struct pci_dev *pdev) +static void qlcnic_remove(struct pci_dev *pdev) { struct qlcnic_adapter *adapter; struct net_device *netdev; -- 1.7.10.280.gaa39 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 746 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/ipv6/xfrm6_policy.c: In function 'xfrm6_dst_destroy': net/ipv6/xfrm6_policy.c:238:6: error: 'struct rt6_info' has no member named 'n' net/ipv6/xfrm6_policy.c:239:28: error: 'struct rt6_info' has no member named 'n' Caused by commit 887c95cc1da5 ("ipv6: Complete neighbour entry removal from dst_entry") interacting with commit 18cf0d0784b4 ("xfrm: release neighbor upon dst destruction") from the net tree. I assume that the problem fixed by the net tree commit is fixed some other way in the net-next tree, so I reverted the net tree commit. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 19 Feb 2013 12:17:22 +1100
> I assume that the problem fixed by the net tree commit is fixed some
> other way in the net-next tree, so I reverted the net tree commit.
The net tree commit should be simply reverted, yes.
[-- Attachment #1: Type: text/plain, Size: 6924 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/batman-adv/network-coding.c: In function 'batadv_nc_skb_store_sniffed_unicast': net/batman-adv/network-coding.c:1487:2: warning: passing argument 1 of 'batadv_is_my_mac' from incompatible pointer type [enabled by default] net/batman-adv/main.h:168:5: note: expected 'struct batadv_priv *' but argument is of type 'unsigned char *' net/batman-adv/network-coding.c:1487:2: error: too few arguments to function 'batadv_is_my_mac' net/batman-adv/main.h:168:5: note: declared here net/batman-adv/network-coding.c: In function 'batadv_nc_skb_decode_packet': net/batman-adv/network-coding.c:1540:2: warning: passing argument 1 of 'batadv_is_my_mac' from incompatible pointer type [enabled by default] net/batman-adv/main.h:168:5: note: expected 'struct batadv_priv *' but argument is of type 'uint8_t *' net/batman-adv/network-coding.c:1540:2: error: too few arguments to function 'batadv_is_my_mac' net/batman-adv/main.h:168:5: note: declared here net/batman-adv/network-coding.c: In function 'batadv_nc_find_decoding_packet': net/batman-adv/network-coding.c:1611:2: warning: passing argument 1 of 'batadv_is_my_mac' from incompatible pointer type [enabled by default] net/batman-adv/main.h:168:5: note: expected 'struct batadv_priv *' but argument is of type 'uint8_t *' net/batman-adv/network-coding.c:1611:2: error: too few arguments to function 'batadv_is_my_mac' net/batman-adv/main.h:168:5: note: declared here net/batman-adv/network-coding.c: In function 'batadv_nc_recv_coded_packet': net/batman-adv/network-coding.c:1678:2: warning: passing argument 1 of 'batadv_is_my_mac' from incompatible pointer type [enabled by default] net/batman-adv/main.h:168:5: note: expected 'struct batadv_priv *' but argument is of type 'unsigned char *' net/batman-adv/network-coding.c:1678:2: error: too few arguments to function 'batadv_is_my_mac' net/batman-adv/main.h:168:5: note: declared here net/batman-adv/network-coding.c:1679:6: warning: passing argument 1 of 'batadv_is_my_mac' from incompatible pointer type [enabled by default] net/batman-adv/main.h:168:5: note: expected 'struct batadv_priv *' but argument is of type 'uint8_t *' net/batman-adv/network-coding.c:1679:6: error: too few arguments to function 'batadv_is_my_mac' net/batman-adv/main.h:168:5: note: declared here net/batman-adv/network-coding.c:1683:2: warning: passing argument 1 of 'batadv_is_my_mac' from incompatible pointer type [enabled by default] net/batman-adv/main.h:168:5: note: expected 'struct batadv_priv *' but argument is of type 'uint8_t *' net/batman-adv/network-coding.c:1683:2: error: too few arguments to function 'batadv_is_my_mac' net/batman-adv/main.h:168:5: note: declared here Caused by commits 612d2b4fe0a1 ("batman-adv: network coding - save overheard and tx packets for decoding") and 2df5278b0267 ("batman-adv: network coding - receive coded packets and decode them") from the net-next tree interacting with commit fe8a93b95145 ("batman-adv: make is_my_mac() check for the current mesh only") from the net tree. I added the following merge fix patch and can carry it as necessary: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 19 Apr 2013 13:13:25 +1000 Subject: [PATCH] batman-adv: merge fix for batadv_is_my_mac() API change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/batman-adv/network-coding.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/net/batman-adv/network-coding.c b/net/batman-adv/network-coding.c index 6b9a544..382db5e 100644 --- a/net/batman-adv/network-coding.c +++ b/net/batman-adv/network-coding.c @@ -1484,7 +1484,7 @@ void batadv_nc_skb_store_sniffed_unicast(struct batadv_priv *bat_priv, { struct ethhdr *ethhdr = (struct ethhdr *)skb_mac_header(skb); - if (batadv_is_my_mac(ethhdr->h_dest)) + if (batadv_is_my_mac(bat_priv, ethhdr->h_dest)) return; /* Set data pointer to MAC header to mimic packets from our tx path */ @@ -1496,6 +1496,7 @@ void batadv_nc_skb_store_sniffed_unicast(struct batadv_priv *bat_priv, /** * batadv_nc_skb_decode_packet - decode given skb using the decode data stored * in nc_packet + * @bat_priv: the bat priv with all the soft interface information * @skb: unicast skb to decode * @nc_packet: decode data needed to decode the skb * @@ -1503,7 +1504,7 @@ void batadv_nc_skb_store_sniffed_unicast(struct batadv_priv *bat_priv, * in case of an error. */ static struct batadv_unicast_packet * -batadv_nc_skb_decode_packet(struct sk_buff *skb, +batadv_nc_skb_decode_packet(struct batadv_priv *bat_priv, struct sk_buff *skb, struct batadv_nc_packet *nc_packet) { const int h_size = sizeof(struct batadv_unicast_packet); @@ -1537,7 +1538,7 @@ batadv_nc_skb_decode_packet(struct sk_buff *skb, /* Select the correct unicast header information based on the location * of our mac address in the coded_packet header */ - if (batadv_is_my_mac(coded_packet_tmp.second_dest)) { + if (batadv_is_my_mac(bat_priv, coded_packet_tmp.second_dest)) { /* If we are the second destination the packet was overheard, * so the Ethernet address must be copied to h_dest and * pkt_type changed from PACKET_OTHERHOST to PACKET_HOST @@ -1608,7 +1609,7 @@ batadv_nc_find_decoding_packet(struct batadv_priv *bat_priv, /* Select the correct packet id based on the location of our mac-addr */ dest = ethhdr->h_source; - if (!batadv_is_my_mac(coded->second_dest)) { + if (!batadv_is_my_mac(bat_priv, coded->second_dest)) { source = coded->second_source; packet_id = coded->second_crc; } else { @@ -1675,12 +1676,12 @@ static int batadv_nc_recv_coded_packet(struct sk_buff *skb, ethhdr = (struct ethhdr *)skb_mac_header(skb); /* Verify frame is destined for us */ - if (!batadv_is_my_mac(ethhdr->h_dest) && - !batadv_is_my_mac(coded_packet->second_dest)) + if (!batadv_is_my_mac(bat_priv, ethhdr->h_dest) && + !batadv_is_my_mac(bat_priv, coded_packet->second_dest)) return NET_RX_DROP; /* Update stat counter */ - if (batadv_is_my_mac(coded_packet->second_dest)) + if (batadv_is_my_mac(bat_priv, coded_packet->second_dest)) batadv_inc_counter(bat_priv, BATADV_CNT_NC_SNIFFED); nc_packet = batadv_nc_find_decoding_packet(bat_priv, ethhdr, @@ -1698,7 +1699,7 @@ static int batadv_nc_recv_coded_packet(struct sk_buff *skb, goto free_nc_packet; /* Decode the packet */ - unicast_packet = batadv_nc_skb_decode_packet(skb, nc_packet); + unicast_packet = batadv_nc_skb_decode_packet(bat_priv, skb, nc_packet); if (!unicast_packet) { batadv_inc_counter(bat_priv, BATADV_CNT_NC_DECODE_FAILED); goto free_nc_packet; -- 1.8.1 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1014 bytes --] Hi Stephen, On Fri, Apr 19, 2013 at 01:21:27PM +1000, Stephen Rothwell wrote: > > Caused by commits 612d2b4fe0a1 ("batman-adv: network coding - save > overheard and tx packets for decoding") and 2df5278b0267 ("batman-adv: > network coding - receive coded packets and decode them") from the > net-next tree interacting with commit fe8a93b95145 ("batman-adv: make > is_my_mac() check for the current mesh only") from the net tree. > > I added the following merge fix patch and can carry it as necessary: thank you very much for taking care of this. However, as I wrote to David in the pull request which generated this noise (http://patchwork.ozlabs.org/patch/237363/), I am now going to send a second pull request which fixes this problem properly and adds the related kernel doc. Your patch looks good, but I'd prefer to send my already prepared pull request. Is it ok with you? Cheers, -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto "Che" Guevara [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 542 bytes --] Hi Antonio, On Fri, 19 Apr 2013 09:34:09 +0200 Antonio Quartulli <ordex@autistici.org> wrote: > > Your patch looks good, but I'd prefer to send my already prepared pull request. > > Is it ok with you? Its entirely up to Dave how/if he fixes this up. He could just leave it to Linus, though he would usually pull the net tree into the net-next tree after Linus merges the net tree - in which case, this should be fixed in that merge. i.e. ask Dave :-) -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 912 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'ehea_proc_rwqes': drivers/net/ethernet/ibm/ehea/ehea_main.c:728:5: error: too few arguments to function '__vlan_hwaccel_put_tag' include/linux/if_vlan.h:237:31: note: declared here Caused by commit 86a9bad3ab6b ("net: vlan: add protocol argument to packet tagging functions"). Grep is your friend. :-( drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'ehea_setup_single_port': drivers/net/ethernet/ibm/ehea/ehea_main.c:3027:9: error: expected expression before '|' token Caused by commit f646968f8f7c ("net: vlan: rename NETIF_F_HW_VLAN_* feature flags to NETIF_F_HW_VLAN_CTAG_*"). I have used the net-net tree from next-20130419 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 19 Apr 2013 13:21:27 +1000
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
I also made sure this got fixed in the merge commit.
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/net/ethernet/emulex/benet/be_main.c: In function 'be_insert_vlan_in_pkt': drivers/net/ethernet/emulex/benet/be_main.c:786:3: error: too few arguments to function '__vlan_put_tag' include/linux/if_vlan.h:220:31: note: declared here drivers/net/ethernet/emulex/benet/be_main.c:796:3: error: too few arguments to function '__vlan_put_tag' include/linux/if_vlan.h:220:31: note: declared here Caused by comt interaction of commit 86a9bad3ab6b ("net: vlan: add protocol argument to packet tagging functions") from the net-next tree and commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") from the net tree. I applied the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 26 Apr 2013 13:45:23 +1000 Subject: [PATCH] be2net: merge fix for __vlan_put_tag() API change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/emulex/benet/be_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c index 768a7d1..d6ab777 100644 --- a/drivers/net/ethernet/emulex/benet/be_main.c +++ b/drivers/net/ethernet/emulex/benet/be_main.c @@ -783,7 +783,7 @@ static struct sk_buff *be_insert_vlan_in_pkt(struct be_adapter *adapter, } if (vlan_tag) { - skb = __vlan_put_tag(skb, vlan_tag); + skb = __vlan_put_tag(skb, htons(ETH_P_8021Q), vlan_tag); if (unlikely(!skb)) return skb; @@ -793,7 +793,7 @@ static struct sk_buff *be_insert_vlan_in_pkt(struct be_adapter *adapter, /* Insert the outer VLAN, if any */ if (adapter->qnq_vid) { vlan_tag = adapter->qnq_vid; - skb = __vlan_put_tag(skb, vlan_tag); + skb = __vlan_put_tag(skb, htons(ETH_P_8021Q), vlan_tag); if (unlikely(!skb)) return skb; if (skip_hw_vlan) -- 1.8.1 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 26 Apr 2013 13:48:14 +1000
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/net/ethernet/emulex/benet/be_main.c: In function 'be_insert_vlan_in_pkt':
> drivers/net/ethernet/emulex/benet/be_main.c:786:3: error: too few arguments to function '__vlan_put_tag'
> include/linux/if_vlan.h:220:31: note: declared here
> drivers/net/ethernet/emulex/benet/be_main.c:796:3: error: too few arguments to function '__vlan_put_tag'
> include/linux/if_vlan.h:220:31: note: declared here
>
> Caused by comt interaction of commit 86a9bad3ab6b ("net: vlan: add
> protocol argument to packet tagging functions") from the net-next tree
> and commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific
> ipv6 packet") from the net tree.
>
> I applied the following merge fix patch:
I fixed this in the merge commit when I merged net into net-next, thanks!
[-- Attachment #1: Type: text/plain, Size: 571 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/9p/trans_rdma.c:724:15: error: 'rdma_cancelled' undeclared here (not in a function) .cancelled = rdma_cancelled, ^ Caused by commit 59ea52dc461e ("net: trans_rdma: remove unused function") interacting with commit d538a4ba906a ("net/9p: link rdma_cancelled in with trans_module") from the v9fs tree. I just reverted that net-next tree commit for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
From: Eric Van Hensbergen <ericvh@gmail.com>
Date: Mon, 29 Jul 2013 21:30:20 -0500
> I didn't realize that had trickled in already, I can go ahead and revert
> the commit in my tree. Neither is perfect, hopefully the folks working on
> it will get something a bit better before the next merge window.
Please revert, thanks.
[-- Attachment #1: Type: text/plain, Size: 797 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from include/linux/hashtable.h:12:0, from include/linux/elevator.h:5, from include/linux/blkdev.h:222, from init/do_mounts.h:2, from init/do_mounts_rd.c:21: include/linux/hash.h:18:22: fatal error: asm/hash.h: No such file or directory #include <asm/hash.h> ^ And many more ... Caused by commit 71ae8aac3e19 ("lib: introduce arch optimized hash library"). Presumably this would break any architecture other than x86 :-( I have used the net-next tree from next-20131217 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 18 Dec 2013 12:56:43 +1100
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/hashtable.h:12:0,
> from include/linux/elevator.h:5,
> from include/linux/blkdev.h:222,
> from init/do_mounts.h:2,
> from init/do_mounts_rd.c:21:
> include/linux/hash.h:18:22: fatal error: asm/hash.h: No such file or directory
> #include <asm/hash.h>
> ^
>
> And many more ...
>
> Caused by commit 71ae8aac3e19 ("lib: introduce arch optimized hash
> library"). Presumably this would break any architecture other than
> x86 :-(
The author believed that putting a header file in asm-generic/
makes it get used automatically by architectures which lack
that header file.
At the very least we have to add a generic-y entry for it to
arch/${ARCH}/include/asm/Kbuild
I'll try to fix this up, thanks for the report.
From: David Miller <davem@davemloft.net> Date: Tue, 17 Dec 2013 21:21:45 -0500 (EST) > I'll try to fix this up, thanks for the report. Here's what I committed, thanks again Stephen: ==================== [PATCH] lib: Add missing arch generic-y entries for asm-generic/hash.h Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- arch/alpha/include/asm/Kbuild | 1 + arch/arc/include/asm/Kbuild | 1 + arch/arm/include/asm/Kbuild | 1 + arch/arm64/include/asm/Kbuild | 1 + arch/avr32/include/asm/Kbuild | 1 + arch/blackfin/include/asm/Kbuild | 1 + arch/c6x/include/asm/Kbuild | 1 + arch/cris/include/asm/Kbuild | 1 + arch/frv/include/asm/Kbuild | 1 + arch/hexagon/include/asm/Kbuild | 1 + arch/ia64/include/asm/Kbuild | 3 ++- arch/m32r/include/asm/Kbuild | 1 + arch/m68k/include/asm/Kbuild | 1 + arch/metag/include/asm/Kbuild | 1 + arch/microblaze/include/asm/Kbuild | 1 + arch/mips/include/asm/Kbuild | 1 + arch/mn10300/include/asm/Kbuild | 1 + arch/openrisc/include/asm/Kbuild | 1 + arch/parisc/include/asm/Kbuild | 1 + arch/powerpc/include/asm/Kbuild | 3 ++- arch/s390/include/asm/Kbuild | 1 + arch/score/include/asm/Kbuild | 2 ++ arch/sh/include/asm/Kbuild | 1 + arch/sparc/include/asm/Kbuild | 1 + arch/tile/include/asm/Kbuild | 1 + arch/um/include/asm/Kbuild | 1 + arch/unicore32/include/asm/Kbuild | 1 + arch/xtensa/include/asm/Kbuild | 1 + 28 files changed, 31 insertions(+), 2 deletions(-) diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild index f01fb50..a73a8e2 100644 --- a/arch/alpha/include/asm/Kbuild +++ b/arch/alpha/include/asm/Kbuild @@ -4,3 +4,4 @@ generic-y += clkdev.h generic-y += exec.h generic-y += trace_clock.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild index 5943f7f..93e6ca9 100644 --- a/arch/arc/include/asm/Kbuild +++ b/arch/arc/include/asm/Kbuild @@ -47,3 +47,4 @@ generic-y += user.h generic-y += vga.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild index c38b58c..3278afe 100644 --- a/arch/arm/include/asm/Kbuild +++ b/arch/arm/include/asm/Kbuild @@ -34,3 +34,4 @@ generic-y += timex.h generic-y += trace_clock.h generic-y += unaligned.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild index 519f89f..626d4a9 100644 --- a/arch/arm64/include/asm/Kbuild +++ b/arch/arm64/include/asm/Kbuild @@ -51,3 +51,4 @@ generic-y += user.h generic-y += vga.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild index 658001b..cfb9fe1 100644 --- a/arch/avr32/include/asm/Kbuild +++ b/arch/avr32/include/asm/Kbuild @@ -18,3 +18,4 @@ generic-y += sections.h generic-y += topology.h generic-y += trace_clock.h generic-y += xor.h +generic-y += hash.h diff --git a/arch/blackfin/include/asm/Kbuild b/arch/blackfin/include/asm/Kbuild index f2b4347..359d36f 100644 --- a/arch/blackfin/include/asm/Kbuild +++ b/arch/blackfin/include/asm/Kbuild @@ -45,3 +45,4 @@ generic-y += unaligned.h generic-y += user.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild index fc0b3c3..d73bb85 100644 --- a/arch/c6x/include/asm/Kbuild +++ b/arch/c6x/include/asm/Kbuild @@ -57,3 +57,4 @@ generic-y += user.h generic-y += vga.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild index b06caf6..c5963b3 100644 --- a/arch/cris/include/asm/Kbuild +++ b/arch/cris/include/asm/Kbuild @@ -12,3 +12,4 @@ generic-y += trace_clock.h generic-y += vga.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/frv/include/asm/Kbuild b/arch/frv/include/asm/Kbuild index 74742dc..bc42f14 100644 --- a/arch/frv/include/asm/Kbuild +++ b/arch/frv/include/asm/Kbuild @@ -3,3 +3,4 @@ generic-y += clkdev.h generic-y += exec.h generic-y += trace_clock.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/hexagon/include/asm/Kbuild b/arch/hexagon/include/asm/Kbuild index 67c3450..469d223 100644 --- a/arch/hexagon/include/asm/Kbuild +++ b/arch/hexagon/include/asm/Kbuild @@ -54,3 +54,4 @@ generic-y += ucontext.h generic-y += unaligned.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/ia64/include/asm/Kbuild b/arch/ia64/include/asm/Kbuild index f93ee08..283a831 100644 --- a/arch/ia64/include/asm/Kbuild +++ b/arch/ia64/include/asm/Kbuild @@ -4,4 +4,5 @@ generic-y += exec.h generic-y += kvm_para.h generic-y += trace_clock.h generic-y += preempt.h -generic-y += vtime.h \ No newline at end of file +generic-y += vtime.h +generic-y += hash.h diff --git a/arch/m32r/include/asm/Kbuild b/arch/m32r/include/asm/Kbuild index 2b58c5f..932435a 100644 --- a/arch/m32r/include/asm/Kbuild +++ b/arch/m32r/include/asm/Kbuild @@ -4,3 +4,4 @@ generic-y += exec.h generic-y += module.h generic-y += trace_clock.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild index a5d27f2..7cc8c36 100644 --- a/arch/m68k/include/asm/Kbuild +++ b/arch/m68k/include/asm/Kbuild @@ -32,3 +32,4 @@ generic-y += types.h generic-y += word-at-a-time.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/metag/include/asm/Kbuild b/arch/metag/include/asm/Kbuild index 84d0c1d..b716d80 100644 --- a/arch/metag/include/asm/Kbuild +++ b/arch/metag/include/asm/Kbuild @@ -53,3 +53,4 @@ generic-y += user.h generic-y += vga.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/microblaze/include/asm/Kbuild b/arch/microblaze/include/asm/Kbuild index ce0bbf8..43eec33 100644 --- a/arch/microblaze/include/asm/Kbuild +++ b/arch/microblaze/include/asm/Kbuild @@ -4,3 +4,4 @@ generic-y += exec.h generic-y += trace_clock.h generic-y += syscalls.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/mips/include/asm/Kbuild b/arch/mips/include/asm/Kbuild index 1acbb8b..2d7f650 100644 --- a/arch/mips/include/asm/Kbuild +++ b/arch/mips/include/asm/Kbuild @@ -14,3 +14,4 @@ generic-y += trace_clock.h generic-y += preempt.h generic-y += ucontext.h generic-y += xor.h +generic-y += hash.h diff --git a/arch/mn10300/include/asm/Kbuild b/arch/mn10300/include/asm/Kbuild index 74742dc..bc42f14 100644 --- a/arch/mn10300/include/asm/Kbuild +++ b/arch/mn10300/include/asm/Kbuild @@ -3,3 +3,4 @@ generic-y += clkdev.h generic-y += exec.h generic-y += trace_clock.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/openrisc/include/asm/Kbuild b/arch/openrisc/include/asm/Kbuild index da1951a..2e40f1c 100644 --- a/arch/openrisc/include/asm/Kbuild +++ b/arch/openrisc/include/asm/Kbuild @@ -69,3 +69,4 @@ generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/parisc/include/asm/Kbuild b/arch/parisc/include/asm/Kbuild index a603b9e..75edd5f 100644 --- a/arch/parisc/include/asm/Kbuild +++ b/arch/parisc/include/asm/Kbuild @@ -5,3 +5,4 @@ generic-y += word-at-a-time.h auxvec.h user.h cputime.h emergency-restart.h \ poll.h xor.h clkdev.h exec.h generic-y += trace_clock.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild index d8f9d2f..6c0a955 100644 --- a/arch/powerpc/include/asm/Kbuild +++ b/arch/powerpc/include/asm/Kbuild @@ -3,4 +3,5 @@ generic-y += clkdev.h generic-y += rwsem.h generic-y += trace_clock.h generic-y += preempt.h -generic-y += vtime.h \ No newline at end of file +generic-y += vtime.h +generic-y += hash.h diff --git a/arch/s390/include/asm/Kbuild b/arch/s390/include/asm/Kbuild index 7a5288f..8386a4a 100644 --- a/arch/s390/include/asm/Kbuild +++ b/arch/s390/include/asm/Kbuild @@ -3,3 +3,4 @@ generic-y += clkdev.h generic-y += trace_clock.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/score/include/asm/Kbuild b/arch/score/include/asm/Kbuild index f3414ad..099e7ba 100644 --- a/arch/score/include/asm/Kbuild +++ b/arch/score/include/asm/Kbuild @@ -5,3 +5,5 @@ generic-y += clkdev.h generic-y += trace_clock.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h + diff --git a/arch/sh/include/asm/Kbuild b/arch/sh/include/asm/Kbuild index 231efbb..0cd7198 100644 --- a/arch/sh/include/asm/Kbuild +++ b/arch/sh/include/asm/Kbuild @@ -35,3 +35,4 @@ generic-y += trace_clock.h generic-y += ucontext.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/sparc/include/asm/Kbuild b/arch/sparc/include/asm/Kbuild index bf39066..4b60a0c 100644 --- a/arch/sparc/include/asm/Kbuild +++ b/arch/sparc/include/asm/Kbuild @@ -17,3 +17,4 @@ generic-y += trace_clock.h generic-y += types.h generic-y += word-at-a-time.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/tile/include/asm/Kbuild b/arch/tile/include/asm/Kbuild index 22f3bd1..3793c75 100644 --- a/arch/tile/include/asm/Kbuild +++ b/arch/tile/include/asm/Kbuild @@ -39,3 +39,4 @@ generic-y += trace_clock.h generic-y += types.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild index fdde187..75de4ab 100644 --- a/arch/um/include/asm/Kbuild +++ b/arch/um/include/asm/Kbuild @@ -4,3 +4,4 @@ generic-y += ftrace.h pci.h io.h param.h delay.h mutex.h current.h exec.h generic-y += switch_to.h clkdev.h generic-y += trace_clock.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/unicore32/include/asm/Kbuild b/arch/unicore32/include/asm/Kbuild index 00045cb..3ef4f9d 100644 --- a/arch/unicore32/include/asm/Kbuild +++ b/arch/unicore32/include/asm/Kbuild @@ -61,3 +61,4 @@ generic-y += user.h generic-y += vga.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h diff --git a/arch/xtensa/include/asm/Kbuild b/arch/xtensa/include/asm/Kbuild index 228d6ae..d7efa15 100644 --- a/arch/xtensa/include/asm/Kbuild +++ b/arch/xtensa/include/asm/Kbuild @@ -29,3 +29,4 @@ generic-y += topology.h generic-y += trace_clock.h generic-y += xor.h generic-y += preempt.h +generic-y += hash.h -- 1.7.11.7
On Wed, Dec 18, 2013 at 3:30 AM, David Miller <davem@davemloft.net> wrote:
> diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild
> index f01fb50..a73a8e2 100644
> --- a/arch/alpha/include/asm/Kbuild
> +++ b/arch/alpha/include/asm/Kbuild
> @@ -4,3 +4,4 @@ generic-y += clkdev.h
> generic-y += exec.h
> generic-y += trace_clock.h
> generic-y += preempt.h
> +generic-y += hash.h
Please keep them sorted.
Yes, Peter violated that too, when adding preempt.h.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Dec 18, 2013 at 09:33:47AM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 18, 2013 at 3:30 AM, David Miller <davem@davemloft.net> wrote:
> > diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild
> > index f01fb50..a73a8e2 100644
> > --- a/arch/alpha/include/asm/Kbuild
> > +++ b/arch/alpha/include/asm/Kbuild
> > @@ -4,3 +4,4 @@ generic-y += clkdev.h
> > generic-y += exec.h
> > generic-y += trace_clock.h
> > generic-y += preempt.h
> > +generic-y += hash.h
>
> Please keep them sorted.
>
> Yes, Peter violated that too, when adding preempt.h.
So what I did was something like:
for i in arch/*/include/asm/Kbuild
do
echo "generic-y += preempt.h" >> $i
done
Whoever is going to hand edit all gazillion archs for changes like that?
And sort(1) is annoying in that it doesn't do in-place sort; you'll end
up with empty files if you try the naive thing.
Worse most of those Kbuild files include other random garbage, which
makes automated sorting harder still.
So unless there's a sane and easy way to keep it sorted; I'm going to
ignore that rule.
On Wed, Dec 18, 2013 at 11:15 AM, Peter Zijlstra <peterz@infradead.org> wrote: > On Wed, Dec 18, 2013 at 09:33:47AM +0100, Geert Uytterhoeven wrote: >> On Wed, Dec 18, 2013 at 3:30 AM, David Miller <davem@davemloft.net> wrote: >> > diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild >> > index f01fb50..a73a8e2 100644 >> > --- a/arch/alpha/include/asm/Kbuild >> > +++ b/arch/alpha/include/asm/Kbuild >> > @@ -4,3 +4,4 @@ generic-y += clkdev.h >> > generic-y += exec.h >> > generic-y += trace_clock.h >> > generic-y += preempt.h >> > +generic-y += hash.h >> >> Please keep them sorted. >> >> Yes, Peter violated that too, when adding preempt.h. > > So what I did was something like: > > for i in arch/*/include/asm/Kbuild > do > echo "generic-y += preempt.h" >> $i > done > > Whoever is going to hand edit all gazillion archs for changes like that? So we need a script for that (adding Joe), that adds the "generic-y += ..." line to all architectures that don't have it yet, and don't provide their own version. > And sort(1) is annoying in that it doesn't do in-place sort; you'll end > up with empty files if you try the naive thing. > > Worse most of those Kbuild files include other random garbage, which > makes automated sorting harder still. > > So unless there's a sane and easy way to keep it sorted; I'm going to > ignore that rule. Not keeping them sorted causes merge conflicts and duplicate/missing entries. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
> > And sort(1) is annoying in that it doesn't do in-place sort; you'll end
> > up with empty files if you try the naive thing.
> >
> > Worse most of those Kbuild files include other random garbage, which
> > makes automated sorting harder still.
> >
> > So unless there's a sane and easy way to keep it sorted; I'm going to
> > ignore that rule.
>
> Not keeping them sorted causes merge conflicts and duplicate/missing
> entries.
Edit in vi put cursor on the first line to be sorted and type !}sort
(assuming there is a nice blank line at the end).
David
On Wed, Dec 18, 2013 at 11:07:34AM -0000, David Laight wrote: > > > And sort(1) is annoying in that it doesn't do in-place sort; you'll end > > > up with empty files if you try the naive thing. > > > > > > Worse most of those Kbuild files include other random garbage, which > > > makes automated sorting harder still. > > > > > > So unless there's a sane and easy way to keep it sorted; I'm going to > > > ignore that rule. > > > > Not keeping them sorted causes merge conflicts and duplicate/missing > > entries. Surely sorting doesn't cure missing entries. Also sorting can at most reduce merge conflicts, not take them out entirely. > Edit in vi put cursor on the first line to be sorted and type !}sort > (assuming there is a nice blank line at the end). That's a manual operation, and therefore disqualified.
On Wed, Dec 18, 2013 at 12:33:24PM +0100, Peter Zijlstra wrote:
> On Wed, Dec 18, 2013 at 11:07:34AM -0000, David Laight wrote:
> > > > And sort(1) is annoying in that it doesn't do in-place sort; you'll end
> > > > up with empty files if you try the naive thing.
> > > >
> > > > Worse most of those Kbuild files include other random garbage, which
> > > > makes automated sorting harder still.
> > > >
> > > > So unless there's a sane and easy way to keep it sorted; I'm going to
> > > > ignore that rule.
> > >
> > > Not keeping them sorted causes merge conflicts and duplicate/missing
> > > entries.
>
> Surely sorting doesn't cure missing entries. Also sorting can at most
> reduce merge conflicts, not take them out entirely.
In fact, manually editing these files carries a far greater risk of
causing missing entries than sorting could possibly cure.
Also, missing entires isn't much of a problem to begin with, compilers
are rather good at finding the problem.
On 12/18/2013 03:30 AM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 17 Dec 2013 21:21:45 -0500 (EST)
>
>> I'll try to fix this up, thanks for the report.
>
> Here's what I committed, thanks again Stephen:
>
> ====================
> [PATCH] lib: Add missing arch generic-y entries for asm-generic/hash.h
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Sorry for the inconvenient. Thanks for fixing it up.
Francesco
From: Peter Zijlstra <peterz@infradead.org>
Date: Wed, 18 Dec 2013 11:15:23 +0100
> So unless there's a sane and easy way to keep it sorted; I'm going to
> ignore that rule.
Me too, it's unreasonable and of dubious value.
[-- Attachment #1: Type: text/plain, Size: 1581 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: lib/hash.c:16:43: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__read_mostly' static struct fast_hash_ops arch_hash_ops __read_mostly = { ^ lib/hash.c: In function 'arch_fast_hash': lib/hash.c:23:9: error: 'arch_hash_ops' undeclared (first use in this function) return arch_hash_ops.hash(data, len, seed); ^ lib/hash.c:23:9: note: each undeclared identifier is reported only once for each function it appears in lib/hash.c: In function 'arch_fast_hash2': lib/hash.c:29:9: error: 'arch_hash_ops' undeclared (first use in this function) return arch_hash_ops.hash2(data, len, seed); ^ lib/hash.c: In function 'hashlib_init': lib/hash.c:35:24: error: 'arch_hash_ops' undeclared (first use in this function) setup_arch_fast_hash(&arch_hash_ops); ^ lib/hash.c: In function 'arch_fast_hash': lib/hash.c:24:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ lib/hash.c: In function 'arch_fast_hash2': lib/hash.c:30:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ Caused by commit 71ae8aac3e19 ("lib: introduce arch optimized hash library"). Read Rule 1 in Documentation/SubmitChecklist :-( Hint: __read_mostly is defined in linux/cache.h ... I have used the net-next tree from next-20131217 again today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 19 Dec 2013 11:57:10 +1100 > Caused by commit 71ae8aac3e19 ("lib: introduce arch optimized hash > library"). Read Rule 1 in Documentation/SubmitChecklist :-( Hint: > __read_mostly is defined in linux/cache.h ... > > I have used the net-next tree from next-20131217 again today. Sorry for this breaking in two different ways two days in a row :-/ I hope with the following commit everything is good now: ==================== >From 237217546d44fe06c16b8895eecaef22f18ba5ee Mon Sep 17 00:00:00 2001 From: Francesco Fusco <ffusco@redhat.com> Date: Wed, 18 Dec 2013 16:05:48 +0100 Subject: [PATCH] lib: hash: follow-up fixups for arch hash This patch adds the include file to pull in __read_mostly on some architectures e.g. ppc and also fixes up signatures in generic asm. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Francesco Fusco <ffusco@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> --- include/asm-generic/hash.h | 4 ++-- lib/hash.c | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/include/asm-generic/hash.h b/include/asm-generic/hash.h index 05cb342..b631284 100644 --- a/include/asm-generic/hash.h +++ b/include/asm-generic/hash.h @@ -1,8 +1,8 @@ #ifndef __ASM_GENERIC_HASH_H #define __ASM_GENERIC_HASH_H -struct arch_hash_ops; -static inline void setup_arch_fast_hash(struct arch_hash_ops *ops) +struct fast_hash_ops; +static inline void setup_arch_fast_hash(struct fast_hash_ops *ops) { } diff --git a/lib/hash.c b/lib/hash.c index b89f06a..fea973f 100644 --- a/lib/hash.c +++ b/lib/hash.c @@ -12,6 +12,7 @@ #include <linux/jhash.h> #include <linux/hash.h> +#include <linux/cache.h> static struct fast_hash_ops arch_hash_ops __read_mostly = { .hash = jhash, -- 1.7.11.7
[-- Attachment #1: Type: text/plain, Size: 600 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from net/core/dev.c:134:0: include/linux/if_macvlan.h: In function 'macvlan_count_rx': include/linux/if_macvlan.h:68:3: error: invalid use of undefined type 'struct vlan_pcpu_stats' pcpu_stats = this_cpu_ptr(vlan->pcpu_stats); ^ And lots more. Caused by commit cdf3e274cf1b ("macvlan: unify macvlan_pcpu_stats and vlan_pcpu_stats"); I have reverted that commit for today. --- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Mon, Jan 06, 2014 at 03:54:13PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from net/core/dev.c:134:0: > include/linux/if_macvlan.h: In function 'macvlan_count_rx': > include/linux/if_macvlan.h:68:3: error: invalid use of undefined type 'struct vlan_pcpu_stats' > pcpu_stats = this_cpu_ptr(vlan->pcpu_stats); > ^ > > And lots more. > > Caused by commit cdf3e274cf1b ("macvlan: unify macvlan_pcpu_stats and > vlan_pcpu_stats"); > > I have reverted that commit for today. This is fixed by: https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=1e85c9b66d86a776e78c332d5d32ae370ab84d3f Greetings, Hannes
[-- Attachment #1: Type: text/plain, Size: 653 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig, gcc 4.6.3) failed like this: drivers/built-in.o: In function `cdc_ncm_get_coalesce': ak8975.c:(.text+0x1ac994): undefined reference to `__aeabi_uldivmod' (The file name above seems to be rubbish, the above function is in drivers/net/usb/cdc_ncm.c) Probably caused by commit 6c4e548ff366 ("net: cdc_ncm: use ethtool to tune coalescing settings"). I assume that there are some 64 bit divides in that function. I have used the net-next tree from next-20140516 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 436 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) failed like this: ERROR: "of_mdiobus_link_phydev" [drivers/net/phy/libphy.ko] undefined! Caused by commit 86f6cf41272d ("net: of_mdio: add of_mdiobus_link_phydev()") from te net-next tree. CONFIG_PHYLIB=m for this build. I have reverted that commit for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/core/filter.c: In function 'convert_bpf_extensions': net/core/filter.c:696:17: error: 'A_REG' undeclared (first use in this function) insn->a_reg = A_REG; ^ Caused by my bad merge resolution :-( I applied this in the hope that it is correct (at least it builds): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 6 Jun 2014 14:00:07 +1000 Subject: [PATCH] net: filter: merge fix up Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/core/filter.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/net/core/filter.c b/net/core/filter.c index 7b46e4553c17..74dd87596257 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -691,10 +691,7 @@ static bool convert_bpf_extensions(struct sock_filter *fp, *insn = BPF_ALU32_IMM(BPF_AND, BPF_REG_A, PKT_TYPE_MAX); #ifdef __BIG_ENDIAN_BITFIELD insn++; - - insn->code = BPF_ALU | BPF_RSH | BPF_K; - insn->a_reg = A_REG; - insn->imm = 5; + *insn = BPF_ALU32_IMM(BPF_RSH, BPF_REG_A, 5); #endif break; -- 2.0.0 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 836 bytes --]
On Thu, Jun 5, 2014 at 9:06 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/core/filter.c: In function 'convert_bpf_extensions': > net/core/filter.c:696:17: error: 'A_REG' undeclared (first use in this function) > insn->a_reg = A_REG; > ^ > > Caused by my bad merge resolution :-( > > I applied this in the hope that it is correct (at least it builds): Thank you. It is correct. I think Dave was about to push the same fix to net-next. You're too fast :) > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri, 6 Jun 2014 14:00:07 +1000 > Subject: [PATCH] net: filter: merge fix up > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > net/core/filter.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/net/core/filter.c b/net/core/filter.c > index 7b46e4553c17..74dd87596257 100644 > --- a/net/core/filter.c > +++ b/net/core/filter.c > @@ -691,10 +691,7 @@ static bool convert_bpf_extensions(struct sock_filter *fp, > *insn = BPF_ALU32_IMM(BPF_AND, BPF_REG_A, PKT_TYPE_MAX); > #ifdef __BIG_ENDIAN_BITFIELD > insn++; > - > - insn->code = BPF_ALU | BPF_RSH | BPF_K; > - insn->a_reg = A_REG; > - insn->imm = 5; > + *insn = BPF_ALU32_IMM(BPF_RSH, BPF_REG_A, 5); > #endif > break; > > -- > 2.0.0 > > -- > Cheers, > Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #1: Type: text/plain, Size: 502 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/ethernet/amd/xgbe/xgbe-dev.c:119:25: fatal error: asm/cputype.h: No such file or directory #include <asm/cputype.h> ^ Caused by commit c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver"). I reverted commit 54a4ca8e3730 ("Merge branch 'amd-xgbe'") for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 836 bytes --]
On 06/06/2014 01:45 AM, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc allyesconfig) > failed like this: > > > drivers/net/ethernet/amd/xgbe/xgbe-dev.c:119:25: fatal error: asm/cputype.h: No such file or directory > #include <asm/cputype.h> > ^ I accidentally left this in from driver debugging and it is not necessary. Patch to follow. Tom > > Caused by commit c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver"). > > I reverted commit 54a4ca8e3730 ("Merge branch 'amd-xgbe'") for today. >
[-- Attachment #1: Type: text/plain, Size: 2989 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/bridge/br_multicast.c: In function 'br_multicast_has_querier_adjacent': net/bridge/br_multicast.c:2248:25: error: 'struct net_bridge' has no member named 'ip6_other_query' if (!timer_pending(&br->ip6_other_query.timer) || ^ In file included from include/linux/idr.h:18:0, from include/linux/kernfs.h:14, from include/linux/sysfs.h:15, from include/linux/kobject.h:21, from include/linux/device.h:17, from include/linux/dma-mapping.h:5, from arch/powerpc/include/asm/machdep.h:14, from arch/powerpc/include/asm/archrandom.h:6, from include/linux/random.h:81, from include/linux/net.h:22, from include/linux/skbuff.h:27, from include/linux/if_ether.h:23, from net/bridge/br_multicast.c:15: net/bridge/br_multicast.c:2249:25: error: 'struct net_bridge' has no member named 'ip6_querier' rcu_dereference(br->ip6_querier.port) == port) ^ net/bridge/br_multicast.c:2249:25: error: 'struct net_bridge' has no member named 'ip6_querier' rcu_dereference(br->ip6_querier.port) == port) ^ In file included from include/linux/err.h:4:0, from net/bridge/br_multicast.c:13: net/bridge/br_multicast.c:2249:25: error: 'struct net_bridge' has no member named 'ip6_querier' rcu_dereference(br->ip6_querier.port) == port) ^ net/bridge/br_multicast.c:2249:25: error: 'struct net_bridge' has no member named 'ip6_querier' rcu_dereference(br->ip6_querier.port) == port) ^ In file included from include/linux/idr.h:18:0, from include/linux/kernfs.h:14, from include/linux/sysfs.h:15, from include/linux/kobject.h:21, from include/linux/device.h:17, from include/linux/dma-mapping.h:5, from arch/powerpc/include/asm/machdep.h:14, from arch/powerpc/include/asm/archrandom.h:6, from include/linux/random.h:81, from include/linux/net.h:22, from include/linux/skbuff.h:27, from include/linux/if_ether.h:23, from net/bridge/br_multicast.c:15: net/bridge/br_multicast.c:2249:25: error: 'struct net_bridge' has no member named 'ip6_querier' rcu_dereference(br->ip6_querier.port) == port) ^ Caused by commit 2cd4143192e8 ("bridge: memorize and export selected IGMP/MLD querier port"). This build has CONFIG_IPV6 not set. I have reverted that commit for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from include/net/inet_connection_sock.h:23:0, from include/linux/tcp.h:24, from include/net/tcp.h:24, from net/ipv4/tcp_input.c:72: net/ipv4/tcp_input.c: In function 'pr_drop_req': include/net/inet_sock.h:77:41: error: 'struct sock_common' has no member named 'skc_v6_daddr' #define ir_v6_rmt_addr req.__req_common.skc_v6_daddr ^ include/net/sock.h:2273:57: note: in expansion of macro 'ir_v6_rmt_addr' do { if (net_msg_warn && net_ratelimit()) printk(fmt,##args); } while(0) ^ net/ipv4/tcp_input.c:5889:3: note: in expansion of macro 'LIMIT_NETDEBUG' LIMIT_NETDEBUG(KERN_DEBUG pr_fmt("drop open request from %pI6/%u\n"), ^ Caused by commit 1fb6f159fd21 ("tcp: add tcp_conn_request"). This build has CONFIG_IPV6 unset. I have used the net-next tree from next-20140627 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 30 Jun 2014 12:47:50 +1000
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/net/inet_connection_sock.h:23:0,
> from include/linux/tcp.h:24,
> from include/net/tcp.h:24,
> from net/ipv4/tcp_input.c:72:
> net/ipv4/tcp_input.c: In function 'pr_drop_req':
> include/net/inet_sock.h:77:41: error: 'struct sock_common' has no member named 'skc_v6_daddr'
> #define ir_v6_rmt_addr req.__req_common.skc_v6_daddr
> ^
> include/net/sock.h:2273:57: note: in expansion of macro 'ir_v6_rmt_addr'
> do { if (net_msg_warn && net_ratelimit()) printk(fmt,##args); } while(0)
> ^
> net/ipv4/tcp_input.c:5889:3: note: in expansion of macro 'LIMIT_NETDEBUG'
> LIMIT_NETDEBUG(KERN_DEBUG pr_fmt("drop open request from %pI6/%u\n"),
> ^
>
> Caused by commit 1fb6f159fd21 ("tcp: add tcp_conn_request"). This
> build has CONFIG_IPV6 unset.
I've just pushed a fix for this, sorry about that.
[-- Attachment #1: Type: text/plain, Size: 1583 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from include/linux/tcp.h:23:0, from include/linux/ipv6.h:63, from include/net/ipv6.h:16, from include/linux/sunrpc/clnt.h:27, from include/linux/nfs_fs.h:30, from init/do_mounts.c:32: include/net/ipv6.h: In function 'ip6_set_txhash': include/net/sock.h:327:33: error: 'struct sock_common' has no member named 'skc_v6_daddr' #define sk_v6_daddr __sk_common.skc_v6_daddr ^ include/net/ipv6.h:695:49: note: in expansion of macro 'sk_v6_daddr' keys.dst = (__force __be32)ipv6_addr_hash(&sk->sk_v6_daddr); ^ In file included from include/linux/sunrpc/clnt.h:27:0, from include/linux/nfs_fs.h:30, from init/do_mounts.c:32: include/net/ipv6.h: In function 'ip6_make_flowlabel': include/net/ipv6.h:705:37: error: 'struct net' has no member named 'ipv6' if (!flowlabel && (autolabel || net->ipv6.sysctl.auto_flowlabels)) { ^ And lots more ... Caused by commits b73c3d0e4f0e ("net: Save TX flow hash in sock and set in skbuf on xmit") and cb1ce2ef387b ("ipv6: Implement automatic flow label generation on transmit"). This build has CONFIG_IPV6 unset. I have used the net-next tree from next-20140708 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 9 Jul 2014 13:26:19 +1000
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
This got fixed 5 minutes ago.
[-- Attachment #1: Type: text/plain, Size: 468 bytes --] Hi David, On Tue, 08 Jul 2014 20:47:51 -0700 (PDT) David Miller <davem@davemloft.net> wrote: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Wed, 9 Jul 2014 13:26:19 +1000 > > > After merging the net-next tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > This got fixed 5 minutes ago. Thanks, I guess that will be picked up tomorrow. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 595 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: ERROR: ".ipv6_dev_get_saddr" [drivers/scsi/cxgbi/libcxgbi.ko] undefined! ERROR: ".ip6_route_output" [drivers/scsi/cxgbi/libcxgbi.ko] undefined! Caused by commit fc8d0590d914 ("libcxgbi: Add ipv6 api to driver"). Presumably some missing Kconfig dependency (this build does not have CONFIG_IPV6 enabled) or it needs some #ifdef guarding. I have used the net-next tree from next-20140717 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
This is totally my bad. Already posted the fix some time ago.
[-- Attachment #1: Type: text/plain, Size: 2143 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/bridge/br_nf_core.c:77:1: error: expected identifier or '(' before '{' token { ^ net/bridge/br_nf_core.c:88:12: error: redefinition of 'br_nf_core_init' int __init br_nf_core_init(void) ^ In file included from net/bridge/br_nf_core.c:23:0: net/bridge/br_private.h:762:19: note: previous definition of 'br_nf_core_init' was here static inline int br_nf_core_init(void) { return 0; } ^ net/bridge/br_nf_core.c:93:6: error: redefinition of 'br_nf_core_fini' void br_nf_core_fini(void) ^ In file included from net/bridge/br_nf_core.c:23:0: net/bridge/br_private.h:763:20: note: previous definition of 'br_nf_core_fini' was here static inline void br_nf_core_fini(void) {} ^ Caused by commit 34666d467cbf ("netfilter: bridge: move br_netfilter out of the core"). This build has CONFIG_BRIDGE_NETFILTER not set ... I have applied the following patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 30 Sep 2014 13:09:09 +1000 Subject: [PATCH] netfilter: bridge: don't build br_nf_core unless necessary Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/bridge/Makefile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/net/bridge/Makefile b/net/bridge/Makefile index 5e3eac5dc8b9..eb653a225397 100644 --- a/net/bridge/Makefile +++ b/net/bridge/Makefile @@ -6,12 +6,11 @@ obj-$(CONFIG_BRIDGE) += bridge.o bridge-y := br.o br_device.o br_fdb.o br_forward.o br_if.o br_input.o \ br_ioctl.o br_stp.o br_stp_bpdu.o \ - br_stp_if.o br_stp_timer.o br_netlink.o \ - br_nf_core.o + br_stp_if.o br_stp_timer.o br_netlink.o bridge-$(CONFIG_SYSFS) += br_sysfs_if.o br_sysfs_br.o -obj-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o +obj-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o br_nf_core.o bridge-$(CONFIG_BRIDGE_IGMP_SNOOPING) += br_multicast.o br_mdb.o -- 2.1.1 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2689 bytes --] Hi all, On Tue, 30 Sep 2014 13:13:54 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/bridge/br_nf_core.c:77:1: error: expected identifier or '(' before '{' token > { > ^ > net/bridge/br_nf_core.c:88:12: error: redefinition of 'br_nf_core_init' > int __init br_nf_core_init(void) > ^ > In file included from net/bridge/br_nf_core.c:23:0: > net/bridge/br_private.h:762:19: note: previous definition of 'br_nf_core_init' was here > static inline int br_nf_core_init(void) { return 0; } > ^ > net/bridge/br_nf_core.c:93:6: error: redefinition of 'br_nf_core_fini' > void br_nf_core_fini(void) > ^ > In file included from net/bridge/br_nf_core.c:23:0: > net/bridge/br_private.h:763:20: note: previous definition of 'br_nf_core_fini' was here > static inline void br_nf_core_fini(void) {} > ^ > > Caused by commit 34666d467cbf ("netfilter: bridge: move br_netfilter > out of the core"). This build has CONFIG_BRIDGE_NETFILTER not set ... > > I have applied the following patch for today: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 30 Sep 2014 13:09:09 +1000 > Subject: [PATCH] netfilter: bridge: don't build br_nf_core unless necessary > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > net/bridge/Makefile | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/net/bridge/Makefile b/net/bridge/Makefile > index 5e3eac5dc8b9..eb653a225397 100644 > --- a/net/bridge/Makefile > +++ b/net/bridge/Makefile > @@ -6,12 +6,11 @@ obj-$(CONFIG_BRIDGE) += bridge.o > > bridge-y := br.o br_device.o br_fdb.o br_forward.o br_if.o br_input.o \ > br_ioctl.o br_stp.o br_stp_bpdu.o \ > - br_stp_if.o br_stp_timer.o br_netlink.o \ > - br_nf_core.o > + br_stp_if.o br_stp_timer.o br_netlink.o > > bridge-$(CONFIG_SYSFS) += br_sysfs_if.o br_sysfs_br.o > > -obj-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o > +obj-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o br_nf_core.o > > bridge-$(CONFIG_BRIDGE_IGMP_SNOOPING) += br_multicast.o br_mdb.o > > -- > 2.1.1 After whish I get this from an x86_64 allmodconfig build: ERROR: "br_nf_core_fini" [net/bridge/bridge.ko] undefined! ERROR: "br_netfilter_rtable_init" [net/bridge/bridge.ko] undefined! ERROR: "br_nf_core_init" [net/bridge/bridge.ko] undefined! So I gave up :-( I have used the net-next tree from next-20140926 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2084 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done': drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev_kfree_skb_irq((struct sk_buff *)cur_p->app4); ^ drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c: In function 'fm10k_set_ringparam': drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c:477:2: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration] temp_ring = vmalloc(i * sizeof(struct fm10k_ring)); ^ drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c:477:12: warning: assignment makes pointer from integer without a cast temp_ring = vmalloc(i * sizeof(struct fm10k_ring)); ^ drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c:546:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] vfree(temp_ring); ^ Caused by commit 82dd0f7ee9a3 ("fm10k: Add ethtool support"). See Rule 1 in Documentation/SubmitChecklist. I have added the following fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 1 Oct 2014 17:00:49 +1000 Subject: [PATCH] fm10k: using vmalloc requires including linux/vmalloc.h Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c index a9bbe60347d8..2d04464e6aa3 100644 --- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c +++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c @@ -18,6 +18,8 @@ * Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 */ +#include <linux/vmalloc.h> + #include "fm10k.h" struct fm10k_stats { -- 2.1.1 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2234 bytes --] On Wed, 2014-10-01 at 17:04 +1000, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done': > drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > dev_kfree_skb_irq((struct sk_buff *)cur_p->app4); > ^ > drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c: In function 'fm10k_set_ringparam': > drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c:477:2: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration] > temp_ring = vmalloc(i * sizeof(struct fm10k_ring)); > ^ > drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c:477:12: warning: assignment makes pointer from integer without a cast > temp_ring = vmalloc(i * sizeof(struct fm10k_ring)); > ^ > drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c:546:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] > vfree(temp_ring); > ^ > > Caused by commit 82dd0f7ee9a3 ("fm10k: Add ethtool support"). See Rule > 1 in Documentation/SubmitChecklist. > > I have added the following fix patch for today: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Wed, 1 Oct 2014 17:00:49 +1000 > Subject: [PATCH] fm10k: using vmalloc requires including linux/vmalloc.h > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> > --- > drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c > index a9bbe60347d8..2d04464e6aa3 100644 > --- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c > +++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c > @@ -18,6 +18,8 @@ > * Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 > */ > > +#include <linux/vmalloc.h> > + > #include "fm10k.h" > > struct fm10k_stats { > -- > 2.1.1 > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 1 Oct 2014 17:04:03 +1000
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 1 Oct 2014 17:00:49 +1000
> Subject: [PATCH] fm10k: using vmalloc requires including linux/vmalloc.h
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks Stephen.
[-- Attachment #1: Type: text/plain, Size: 2933 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/printk.h:6:0, from include/linux/kernel.h:13, from net/openvswitch/flow.h:23, from net/openvswitch/flow_netlink.c:21: net/openvswitch/flow_netlink.c: In function 'ovs_key_from_nlattrs': include/linux/kern_levels.h:4:18: error: called object is not a function or function pointer #define KERN_SOH "\001" /* ASCII Start Of Header */ ^ include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH' #define KERN_INFO KERN_SOH "6" /* informational */ ^ include/linux/printk.h:247:9: note: in expansion of macro 'KERN_INFO' printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__) ^ net/openvswitch/datapath.h:205:3: note: in expansion of macro 'pr_info' pr_info("netlink: " fmt "\n", ##__VA_ARGS__); \ ^ net/openvswitch/flow_netlink.c:777:4: note: in expansion of macro 'OVS_NLERR' OVS_NLERR("IPv6 flow label %x is out of range (max=%x).\n", ^ net/openvswitch/datapath.h:205:27: error: expected ')' before string constant pr_info("netlink: " fmt "\n", ##__VA_ARGS__); \ ^ net/openvswitch/flow_netlink.c:19:41: note: in definition of macro 'pr_fmt' #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt ^ net/openvswitch/datapath.h:205:3: note: in expansion of macro 'pr_info' pr_info("netlink: " fmt "\n", ##__VA_ARGS__); \ ^ net/openvswitch/flow_netlink.c:777:4: note: in expansion of macro 'OVS_NLERR' OVS_NLERR("IPv6 flow label %x is out of range (max=%x).\n", ^ Caused by commit 05da5898a96c ("openvswitch: Add support for OVS_FLOW_ATTR_PROBE") interacting with commit fecaef85f718 ("openvswitch: Validate IPv6 flow key and mask values") from the net tree. I applied the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 17 Nov 2014 13:31:33 +1100 Subject: [PATCH] openvswitch: fix up for OVS_NLERR API change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/openvswitch/flow_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c index 259b2f1ebd0d..45bdcf596414 100644 --- a/net/openvswitch/flow_netlink.c +++ b/net/openvswitch/flow_netlink.c @@ -774,7 +774,7 @@ static int ovs_key_from_nlattrs(struct sw_flow_match *match, u64 attrs, } if (ipv6_key->ipv6_label & htonl(0xFFF00000)) { - OVS_NLERR("IPv6 flow label %x is out of range (max=%x).\n", + OVS_NLERR(log, "IPv6 flow label %x is out of range (max=%x).\n", ntohl(ipv6_key->ipv6_label), (1 << 20) - 1); return -EINVAL; } -- 2.1.3 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 17 Nov 2014 13:34:04 +1100
> I applied the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 17 Nov 2014 13:31:33 +1100
> Subject: [PATCH] openvswitch: fix up for OVS_NLERR API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks Stephen, I integrated this into the merge commit when
I merge net into net-next just now.
Thanks again.
[-- Attachment #1: Type: text/plain, Size: 4399 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/ethernet/chelsio/cxgb4vf/built-in.o:(.opd+0x630): multiple definition of `t4_bar2_sge_qregs' drivers/net/ethernet/chelsio/cxgb4/built-in.o:(.opd+0x14d0): first defined here drivers/net/ethernet/chelsio/cxgb4vf/built-in.o: In function `.t4_bar2_sge_qregs': (.text+0x9220): multiple definition of `.t4_bar2_sge_qregs' drivers/net/ethernet/chelsio/cxgb4/built-in.o:(.text+0x24e24): first defined here Caused by commit e85c9a7abfa4 ("cxgb4/cxgb4vf: Add code to calculate T5 BAR2 Offsets for SGE Queue Registers") which added both versions. :-( I have applied this fir patch for today (including the subject typo :-)): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 10 Dec 2014 19:48:02 +1100 Subject: [PATCH] cxgb4/cxgb4vf: global named must be unique Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 2 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 ++-- drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 +- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h index 2c37e1bf253a..a18d33fdb271 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h @@ -1007,7 +1007,7 @@ int t4_prep_fw(struct adapter *adap, struct fw_info *fw_info, int t4_prep_adapter(struct adapter *adapter); enum t4_bar2_qtype { T4_BAR2_QTYPE_EGRESS, T4_BAR2_QTYPE_INGRESS }; -int t4_bar2_sge_qregs(struct adapter *adapter, +int cxgb4_t4_bar2_sge_qregs(struct adapter *adapter, unsigned int qid, enum t4_bar2_qtype qtype, u64 *pbar2_qoffset, diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c index c8c5b3d36d4e..1645f59648f0 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c @@ -3815,7 +3815,7 @@ int cxgb4_bar2_sge_qregs(struct net_device *dev, u64 *pbar2_qoffset, unsigned int *pbar2_qid) { - return t4_bar2_sge_qregs(netdev2adap(dev), + return cxgb4_t4_bar2_sge_qregs(netdev2adap(dev), qid, (qtype == CXGB4_BAR2_QTYPE_EGRESS ? T4_BAR2_QTYPE_EGRESS @@ -4011,7 +4011,7 @@ static void process_db_drop(struct work_struct *work) unsigned int bar2_qid; int ret; - ret = t4_bar2_sge_qregs(adap, qid, T4_BAR2_QTYPE_EGRESS, + ret = cxgb4_t4_bar2_sge_qregs(adap, qid, T4_BAR2_QTYPE_EGRESS, &bar2_qoffset, &bar2_qid); if (ret) dev_err(adap->pdev_dev, "doorbell drop recovery: " diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c index f12debd98dac..ebf935a1e352 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c @@ -2270,7 +2270,7 @@ static void __iomem *bar2_address(struct adapter *adapter, u64 bar2_qoffset; int ret; - ret = t4_bar2_sge_qregs(adapter, qid, qtype, + ret = cxgb4_t4_bar2_sge_qregs(adapter, qid, qtype, &bar2_qoffset, pbar2_qid); if (ret) return NULL; diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c index 67345c73e570..28d04153f999 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c +++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c @@ -4031,7 +4031,7 @@ int t4_prep_adapter(struct adapter *adapter) } /** - * t4_bar2_sge_qregs - return BAR2 SGE Queue register information + * cxgb4_t4_bar2_sge_qregs - return BAR2 SGE Queue register information * @adapter: the adapter * @qid: the Queue ID * @qtype: the Ingress or Egress type for @qid @@ -4055,7 +4055,7 @@ int t4_prep_adapter(struct adapter *adapter) * Write Combining Doorbell Buffer. If the BAR2 Queue ID is not 0, * then these "Inferred Queue ID" register may not be used. */ -int t4_bar2_sge_qregs(struct adapter *adapter, +int cxgb4_t4_bar2_sge_qregs(struct adapter *adapter, unsigned int qid, enum t4_bar2_qtype qtype, u64 *pbar2_qoffset, -- 2.1.3 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
On Wed, Dec 10, 2014 at 19:54:05 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/net/ethernet/chelsio/cxgb4vf/built-in.o:(.opd+0x630): multiple definition of `t4_bar2_sge_qregs'
> drivers/net/ethernet/chelsio/cxgb4/built-in.o:(.opd+0x14d0): first defined here
> drivers/net/ethernet/chelsio/cxgb4vf/built-in.o: In function `.t4_bar2_sge_qregs':
> (.text+0x9220): multiple definition of `.t4_bar2_sge_qregs'
> drivers/net/ethernet/chelsio/cxgb4/built-in.o:(.text+0x24e24): first defined here
>
> Caused by commit e85c9a7abfa4 ("cxgb4/cxgb4vf: Add code to calculate T5
> BAR2 Offsets for SGE Queue Registers") which added both versions. :-(
>
> I have applied this fir patch for today (including the subject
> typo :-)):
>
My bad. Thanks for the fix.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Dec 2014 19:54:05 +1100
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 10 Dec 2014 19:48:02 +1100
> Subject: [PATCH] cxgb4/cxgb4vf: global named must be unique
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks.
[-- Attachment #1: Type: text/plain, Size: 2463 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/net/ethernet/mellanox/mlx4/en_clock.c: In function 'mlx4_en_init_timestamp': drivers/net/ethernet/mellanox/mlx4/en_clock.c:249:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration] mdev->cycles.mask = CLOCKSOURCE_MASK(48); ^ drivers/net/ethernet/mellanox/mlx4/en_clock.c:257:3: error: implicit declaration of function 'clocksource_khz2mult' [-Werror=implicit-function-declaration] clocksource_khz2mult(1000 * dev->caps.hca_core_clock, mdev->cycles.shift); ^ drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c: In function 'ixgbe_ptp_start_cyclecounter': drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c:796:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration] adapter->cc.mask = CLOCKSOURCE_MASK(64); ^ Presumably caused by commit 74d23cc704d1 ("time: move the timecounter/cyclecounter code into its own file"). I added the following commit for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Sat, 3 Jan 2015 09:07:21 +1100 Subject: [PATCH] ixgbe_ptp, mlx4: Include clocksource.h to get CLOCKSOURCE_MASK Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 1 + drivers/net/ethernet/mellanox/mlx4/en_clock.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c index 47c29eaaa140..73548280cbae 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c @@ -25,6 +25,7 @@ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 *******************************************************************************/ +#include <linux/clocksource.h> #include "ixgbe.h" #include <linux/ptp_classify.h> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_clock.c b/drivers/net/ethernet/mellanox/mlx4/en_clock.c index e9cce4f72b24..7c6ef4b48f8e 100644 --- a/drivers/net/ethernet/mellanox/mlx4/en_clock.c +++ b/drivers/net/ethernet/mellanox/mlx4/en_clock.c @@ -31,6 +31,7 @@ * */ +#include <linux/clocksource.h> #include <linux/mlx4/device.h> #include "mlx4_en.h" -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
On Fri, Jan 2, 2015 at 11:11 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > drivers/net/ethernet/mellanox/mlx4/en_clock.c: In function 'mlx4_en_init_timestamp': > drivers/net/ethernet/mellanox/mlx4/en_clock.c:249:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration] > mdev->cycles.mask = CLOCKSOURCE_MASK(48); > ^ > drivers/net/ethernet/mellanox/mlx4/en_clock.c:257:3: error: implicit declaration of function 'clocksource_khz2mult' [-Werror=implicit-function-declaration] > clocksource_khz2mult(1000 * dev->caps.hca_core_clock, mdev->cycles.shift); > ^ > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c: In function 'ixgbe_ptp_start_cyclecounter': > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c:796:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration] > adapter->cc.mask = CLOCKSOURCE_MASK(64); > ^ > > Presumably caused by commit 74d23cc704d1 ("time: move the > timecounter/cyclecounter code into its own file"). > Happy new 2015 Stephen... [ The last days I revived my linux-next build-script inspired by willing to test block-loop-mq v3 patchset against next-20141231 ] Just FYI... Richard posted a new patch-series "[PATCH net-next 0/7] Fixing the "Time Counter fixes and improvements" on linux-nextdev fixing this. - Sedat - [1] https://lkml.org/lkml/2015/1/1/27 > I added the following commit for today: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Sat, 3 Jan 2015 09:07:21 +1100 > Subject: [PATCH] ixgbe_ptp, mlx4: Include clocksource.h to get CLOCKSOURCE_MASK > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 1 + > drivers/net/ethernet/mellanox/mlx4/en_clock.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c > index 47c29eaaa140..73548280cbae 100644 > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c > @@ -25,6 +25,7 @@ > Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 > > *******************************************************************************/ > +#include <linux/clocksource.h> > #include "ixgbe.h" > #include <linux/ptp_classify.h> > > diff --git a/drivers/net/ethernet/mellanox/mlx4/en_clock.c b/drivers/net/ethernet/mellanox/mlx4/en_clock.c > index e9cce4f72b24..7c6ef4b48f8e 100644 > --- a/drivers/net/ethernet/mellanox/mlx4/en_clock.c > +++ b/drivers/net/ethernet/mellanox/mlx4/en_clock.c > @@ -31,6 +31,7 @@ > * > */ > > +#include <linux/clocksource.h> > #include <linux/mlx4/device.h> > > #include "mlx4_en.h" > -- > 2.1.4 > > -- > Cheers, > Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #1: Type: text/plain, Size: 1649 bytes --] Hi Sedat, On Fri, 2 Jan 2015 23:21:05 +0100 Sedat Dilek <sedat.dilek@gmail.com> wrote: > > On Fri, Jan 2, 2015 at 11:11 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > After merging the net-next tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > > > drivers/net/ethernet/mellanox/mlx4/en_clock.c: In function 'mlx4_en_init_timestamp': > > drivers/net/ethernet/mellanox/mlx4/en_clock.c:249:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration] > > mdev->cycles.mask = CLOCKSOURCE_MASK(48); > > ^ > > drivers/net/ethernet/mellanox/mlx4/en_clock.c:257:3: error: implicit declaration of function 'clocksource_khz2mult' [-Werror=implicit-function-declaration] > > clocksource_khz2mult(1000 * dev->caps.hca_core_clock, mdev->cycles.shift); > > ^ > > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c: In function 'ixgbe_ptp_start_cyclecounter': > > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c:796:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration] > > adapter->cc.mask = CLOCKSOURCE_MASK(64); > > ^ > > > > Presumably caused by commit 74d23cc704d1 ("time: move the > > timecounter/cyclecounter code into its own file"). > > Just FYI... > > Richard posted a new patch-series "[PATCH net-next 0/7] Fixing the > "Time Counter fixes and improvements" on linux-nextdev fixing this. > > - Sedat - > > [1] https://lkml.org/lkml/2015/1/1/27 Thanks, so hopefully I won't need my patch for very long. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2299 bytes --] Hi all, On Sat, 3 Jan 2015 09:11:01 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > drivers/net/ethernet/mellanox/mlx4/en_clock.c: In function 'mlx4_en_init_timestamp': > drivers/net/ethernet/mellanox/mlx4/en_clock.c:249:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration] > mdev->cycles.mask = CLOCKSOURCE_MASK(48); > ^ > drivers/net/ethernet/mellanox/mlx4/en_clock.c:257:3: error: implicit declaration of function 'clocksource_khz2mult' [-Werror=implicit-function-declaration] > clocksource_khz2mult(1000 * dev->caps.hca_core_clock, mdev->cycles.shift); > ^ > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c: In function 'ixgbe_ptp_start_cyclecounter': > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c:796:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration] > adapter->cc.mask = CLOCKSOURCE_MASK(64); > ^ > My powerpc allyesconfig build also produced this: drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function 'bnx2x_init_cyclecounter': drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:14613:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration] bp->cyclecounter.mask = CLOCKSOURCE_MASK(64); ^ So I added this patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Sat, 3 Jan 2015 12:15:37 +1100 Subject: [PATCH] bnx2x: Include clocksource.h to get CLOCKSOURCE_MASK Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c index 2c951326a85d..119c190721da 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c @@ -57,6 +57,7 @@ #include <linux/semaphore.h> #include <linux/stringify.h> #include <linux/vmalloc.h> +#include <linux/clocksource.h> #include "bnx2x.h" #include "bnx2x_init.h" -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sat, 3 Jan 2015 09:11:01 +1100
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/net/ethernet/mellanox/mlx4/en_clock.c: In function 'mlx4_en_init_timestamp':
> drivers/net/ethernet/mellanox/mlx4/en_clock.c:249:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration]
> mdev->cycles.mask = CLOCKSOURCE_MASK(48);
Stephen please let me know if this failure is persisting.
[-- Attachment #1: Type: text/plain, Size: 792 bytes --] Hi David, On Sat, 03 Jan 2015 14:45:30 -0500 (EST) David Miller <davem@davemloft.net> wrote: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Sat, 3 Jan 2015 09:11:01 +1100 > > > After merging the net-next tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > > > drivers/net/ethernet/mellanox/mlx4/en_clock.c: In function 'mlx4_en_init_timestamp': > > drivers/net/ethernet/mellanox/mlx4/en_clock.c:249:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration] > > mdev->cycles.mask = CLOCKSOURCE_MASK(48); > > Stephen please let me know if this failure is persisting. All the ones I reported are fixed, thanks. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 770 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: Documentation/networking/timestamping/txtimestamp.c: In function '__recv_errmsg_cmsg': Documentation/networking/timestamping/txtimestamp.c:205:33: error: dereferencing pointer to incomplete type Documentation/networking/timestamping/txtimestamp.c:206:23: error: dereferencing pointer to incomplete type Caused by commit cd91cc5bdddf ("doc: fix the compile error of txtimestamp.c"). On (at least) Debian stable, the system's definition of struct in6_pktinfo depends on __USE_GNU being defined (at least, I think that is the problem). I have reverted that commit for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 12 Jan 2015 14:05:15 +1100
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> Documentation/networking/timestamping/txtimestamp.c: In function '__recv_errmsg_cmsg':
> Documentation/networking/timestamping/txtimestamp.c:205:33: error: dereferencing pointer to incomplete type
> Documentation/networking/timestamping/txtimestamp.c:206:23: error: dereferencing pointer to incomplete type
>
> Caused by commit cd91cc5bdddf ("doc: fix the compile error of
> txtimestamp.c"). On (at least) Debian stable, the system's definition
> of struct in6_pktinfo depends on __USE_GNU being defined (at least, I
> think that is the problem).
>
> I have reverted that commit for today.
It's fixed as of 5 minutes ago in the net-next tree, sorry for this.
[-- Attachment #1: Type: text/plain, Size: 261 bytes --] Hi David, On Sun, 11 Jan 2015 22:08:29 -0500 (EST) David Miller <davem@davemloft.net> wrote: > > It's fixed as of 5 minutes ago in the net-next tree, sorry for this. OK, thanks. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 836 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from net/bridge/br.c:22:0: include/net/switchdev.h:73:1: error: expected identifier or '(' before '{' token { ^ include/net/switchdev.h:71:19: warning: 'call_netdev_switch_notifiers' declared 'static' but never defined [-Wunused-function] static inline int call_netdev_switch_notifiers(unsigned long val, struct net_device *dev, ^ Caused by commit 03bf0c281234 ("switchdev: introduce switchdev notifier"). I have used the net-next tree from next-20150116 for today. I also had to use the bluetooth tree from next-20150116 as it was fast forwarded to be the same as the net-next tree today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
Hi Stephen,
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from net/bridge/br.c:22:0:
> include/net/switchdev.h:73:1: error: expected identifier or '(' before '{' token
> {
> ^
> include/net/switchdev.h:71:19: warning: 'call_netdev_switch_notifiers' declared 'static' but never defined [-Wunused-function]
> static inline int call_netdev_switch_notifiers(unsigned long val, struct net_device *dev,
> ^
>
> Caused by commit 03bf0c281234 ("switchdev: introduce switchdev notifier").
>
> I have used the net-next tree from next-20150116 for today. I also had
> to use the bluetooth tree from next-20150116 as it was fast forwarded
> to be the same as the net-next tree today.
it seems Dave forgot to push out his net-next tree, but in theory it should contain a fix for it.
Regards
Marcel
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --] Hi Marcel, On Sun, 18 Jan 2015 19:13:17 -0800 Marcel Holtmann <marcel@holtmann.org> wrote: > > > After merging the net-next tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > > > In file included from net/bridge/br.c:22:0: > > include/net/switchdev.h:73:1: error: expected identifier or '(' before '{' token > > { > > ^ > > include/net/switchdev.h:71:19: warning: 'call_netdev_switch_notifiers' declared 'static' but never defined [-Wunused-function] > > static inline int call_netdev_switch_notifiers(unsigned long val, struct net_device *dev, > > ^ > > > > Caused by commit 03bf0c281234 ("switchdev: introduce switchdev notifier"). > > > > I have used the net-next tree from next-20150116 for today. I also had > > to use the bluetooth tree from next-20150116 as it was fast forwarded > > to be the same as the net-next tree today. > > it seems Dave forgot to push out his net-next tree, but in theory it should contain a fix for it. Or he did so after I fetched his tree this morning. Either way, I assume it will be fixed tomorrow. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1277 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: lib/rhashtable.c: In function 'rhashtable_walk_next': lib/rhashtable.c:1002:3: error: implicit declaration of function 'ERR_PTR' [-Werror=implicit-function-declaration] return ERR_PTR(-EAGAIN); ^ lib/rhashtable.c:1002:3: warning: return makes pointer from integer without a cast Caused by commit f2dba9c6ff0d ("rhashtable: Introduce rhashtable_walk_*"). See Rule 1 in Documentation/SubmitChecklist. I have added the following fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 9 Feb 2015 14:04:03 +1100 Subject: [PATCH] rhashtable: using ERR_PTR requires linux/err.h Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- lib/rhashtable.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/rhashtable.c b/lib/rhashtable.c index e96fc00208bc..9cc4c4a90d00 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -23,6 +23,7 @@ #include <linux/jhash.h> #include <linux/random.h> #include <linux/rhashtable.h> +#include <linux/err.h> #define HASH_DEFAULT_SIZE 64UL #define HASH_MIN_SIZE 4UL -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 9 Feb 2015 14:07:45 +1100
> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> index e96fc00208bc..9cc4c4a90d00 100644
> --- a/lib/rhashtable.c
> +++ b/lib/rhashtable.c
> @@ -23,6 +23,7 @@
> #include <linux/jhash.h>
> #include <linux/random.h>
> #include <linux/rhashtable.h>
> +#include <linux/err.h>
>
> #define HASH_DEFAULT_SIZE 64UL
> #define HASH_MIN_SIZE 4UL
Applied, thanks Stephen.
[-- Attachment #1: Type: text/plain, Size: 718 bytes --] Hi all, After merging the net-next tree, today's linux-next build (i386 allmodconfig and a few others) failed like this: drivers/net/ethernet/intel/i40e/i40e_txrx.c: In function 'i40e_setup_rx_descriptors': drivers/net/ethernet/intel/i40e/i40e_txrx.c:1101:3: error: incompatible type for argument 1 of '__seqcount_init' include/linux/seqlock.h:53:20: note: expected 'struct seqcount_t *' but argument is of type 'seqcount_t' Caused by commit 638702bd59a3 ("i40e/i40evf: Add call to u64_stats_init to init"). Discovered after the release, so no fix done. The indentation of the lines added by that patch is also a bit strange. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1435 bytes --] On Tue, 2015-02-10 at 22:02 +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (i386 > allmodconfig and a few others) failed like this: > > drivers/net/ethernet/intel/i40e/i40e_txrx.c: In function > 'i40e_setup_rx_descriptors': > drivers/net/ethernet/intel/i40e/i40e_txrx.c:1101:3: error: > incompatible type for argument 1 of '__seqcount_init' > include/linux/seqlock.h:53:20: note: expected 'struct seqcount_t *' > but argument is of type 'seqcount_t' > > Caused by commit 638702bd59a3 ("i40e/i40evf: Add call to > u64_stats_init > to init"). > > Discovered after the release, so no fix done. > > The indentation of the lines added by that patch is also a bit > strange. Yeah, this was fixed with the follow on patch: commit c07a213db1437a8fd40c328e6a2c426723caec65 Author: Carolyn Wyborny <carolyn.wyborny@intel.com> Date: Tue Feb 10 07:33:15 2015 +0000 i40e: Fix for stats init function call in Rx setup This patch fixes indentation issue and error found in argument reported by static analysis. Without this patch, sparse and other static analysis errors will be found. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Reported-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) failed like this: net/mpls/af_mpls.c: In function 'resize_platform_label_table': net/mpls/af_mpls.c:767:4: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration] labels = vzalloc(size); ^ Caused by commit 7720c01f3f59 ("mpls: Add a sysctl to control the size of the mpls label table"). I have added this commit for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 5 Mar 2015 13:37:05 +1100 Subject: [PATCH] mpls: using vzalloc requires including vmalloc.h Fixes this build error: net/mpls/af_mpls.c: In function 'resize_platform_label_table': net/mpls/af_mpls.c:767:4: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration] labels = vzalloc(size); ^ Fixes: 7720c01f3f59 ("mpls: Add a sysctl to control the size of the mpls label table") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/mpls/af_mpls.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c index 23e51d13b0ff..20cf48a8593d 100644 --- a/net/mpls/af_mpls.c +++ b/net/mpls/af_mpls.c @@ -7,6 +7,7 @@ #include <linux/if_arp.h> #include <linux/ipv6.h> #include <linux/mpls.h> +#include <linux/vmalloc.h> #include <net/ip.h> #include <net/dst.h> #include <net/sock.h> -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 5 Mar 2015 13:42:47 +1100
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 5 Mar 2015 13:37:05 +1100
> Subject: [PATCH] mpls: using vzalloc requires including vmalloc.h
>
> Fixes this build error:
>
> net/mpls/af_mpls.c: In function 'resize_platform_label_table':
> net/mpls/af_mpls.c:767:4: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
> labels = vzalloc(size);
> ^
>
> Fixes: 7720c01f3f59 ("mpls: Add a sysctl to control the size of the mpls label table")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks Stephen.
[-- Attachment #1: Type: text/plain, Size: 925 bytes --] Hi Dave, On Thu, 05 Mar 2015 00:01:58 -0500 (EST) David Miller <davem@davemloft.net> wrote: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Thu, 5 Mar 2015 13:42:47 +1100 > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > Date: Thu, 5 Mar 2015 13:37:05 +1100 > > Subject: [PATCH] mpls: using vzalloc requires including vmalloc.h > > > > Fixes this build error: > > > > net/mpls/af_mpls.c: In function 'resize_platform_label_table': > > net/mpls/af_mpls.c:767:4: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration] > > labels = vzalloc(size); > > ^ > > > > Fixes: 7720c01f3f59 ("mpls: Add a sysctl to control the size of the mpls label table") > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > Applied, thanks Stephen. I don't see it in net-next? -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 6 Mar 2015 10:26:14 +1100
> On Thu, 05 Mar 2015 00:01:58 -0500 (EST) David Miller <davem@davemloft.net> wrote:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Thu, 5 Mar 2015 13:42:47 +1100
>>
>> > From: Stephen Rothwell <sfr@canb.auug.org.au>
>> > Date: Thu, 5 Mar 2015 13:37:05 +1100
>> > Subject: [PATCH] mpls: using vzalloc requires including vmalloc.h
>> >
>> > Fixes this build error:
>> >
>> > net/mpls/af_mpls.c: In function 'resize_platform_label_table':
>> > net/mpls/af_mpls.c:767:4: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
>> > labels = vzalloc(size);
>> > ^
>> >
>> > Fixes: 7720c01f3f59 ("mpls: Add a sysctl to control the size of the mpls label table")
>> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>
>> Applied, thanks Stephen.
>
> I don't see it in net-next?
The perils of working on multiple workstations :-)
Pushed out now, sorry about that.
[-- Attachment #1: Type: text/plain, Size: 325 bytes --] Hi Dave, On Thu, 05 Mar 2015 21:01:47 -0500 (EST) David Miller <davem@davemloft.net> wrote: > > The perils of working on multiple workstations :-) > > Pushed out now, sorry about that. No worries. I know what its like as we get older ;-) -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: crypto/algif_skcipher.c: In function 'skcipher_async_cb': crypto/algif_skcipher.c:109:2: error: implicit declaration of function 'aio_complete' [-Werror=implicit-function-declaration] aio_complete(iocb, err, err); ^ Caused by commit a596999b7ddf ("crypto: algif - change algif_skcipher to be asynchronous") interacting with commit 04b2fa9f8f36 ("fs: split generic and aio kiocb") from the vfs tree. I applied the following merge fix patch (which gets it building, but I am not sure if more is needed). From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 24 Mar 2015 13:40:45 +1100 Subject: [PATCH] crypto: algif - cope with aio_complete() going away Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- crypto/algif_skcipher.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c index 8276f21ea7be..506eb5f62b03 100644 --- a/crypto/algif_skcipher.c +++ b/crypto/algif_skcipher.c @@ -106,7 +106,7 @@ static void skcipher_async_cb(struct crypto_async_request *req, int err) atomic_dec(&ctx->inflight); skcipher_free_async_sgls(sreq); kfree(req); - aio_complete(iocb, err, err); + iocb->ki_complete(iocb, err, err); } static inline int skcipher_sndbuf(struct sock *sk) -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 24 Mar 2015 13:45:08 +1100
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> crypto/algif_skcipher.c: In function 'skcipher_async_cb':
> crypto/algif_skcipher.c:109:2: error: implicit declaration of function 'aio_complete' [-Werror=implicit-function-declaration]
> aio_complete(iocb, err, err);
> ^
>
> Caused by commit a596999b7ddf ("crypto: algif - change algif_skcipher
> to be asynchronous") interacting with commit 04b2fa9f8f36 ("fs: split
> generic and aio kiocb") from the vfs tree.
>
> I applied the following merge fix patch (which gets it building, but I
> am not sure if more is needed).
Ok, more conflicts wiht Al's vfs work.
This is starting to pile on, heavily...
On Mon, Mar 23, 2015 at 11:00:03PM -0400, David Miller wrote:
> Ok, more conflicts wiht Al's vfs work.
>
> This is starting to pile on, heavily...
These are my changes. But I think it would be much better if any aio-related
changes like this one we be one on top of my changes in Al's iocb branch,
there have been various changes, and it would be better to review and
commit the changes on top of it instead of carrying the changes as fixups.
Nevermind the actual test coverage..
From: Christoph Hellwig <hch@lst.de>
Date: Tue, 24 Mar 2015 11:43:46 +0100
> On Mon, Mar 23, 2015 at 11:00:03PM -0400, David Miller wrote:
>> Ok, more conflicts wiht Al's vfs work.
>>
>> This is starting to pile on, heavily...
>
> These are my changes. But I think it would be much better if any aio-related
> changes like this one we be one on top of my changes in Al's iocb branch,
> there have been various changes, and it would be better to review and
> commit the changes on top of it instead of carrying the changes as fixups.
>
> Nevermind the actual test coverage..
That's no longer possible as my tree never rebases and the commits are pushed
out already.
Another solution to this set of conflicts, is therefore necessary.
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/usb/cdc_ncm.c: In function 'cdc_ncm_fill_tx_frame': drivers/net/usb/cdc_ncm.c:1187:2: error: too few arguments to function 'usbnet_set_skb_tx_stats' usbnet_set_skb_tx_stats(skb_out, n); ^ In file included from drivers/net/usb/cdc_ncm.c:51:0: include/linux/usb/usbnet.h:238:1: note: declared here usbnet_set_skb_tx_stats(struct sk_buff *skb, ^ Caused by a bad merge between commits 1e9e39f4a298 ("usbnet: Fix tx_packets stat for FLAG_MULTI_FRAME drivers") and 7a1e890e2168 ("usbnet: Fix tx_bytes statistic running backward in cdc_ncm") form the net tree and commit 6588af614e7b ("usbnet: Fix tx_packets stat for FLAG_MULTI_FRAME drivers") from the net-next tree. (Presumably, 6588af614e7b was cherry-picked as a bug fix. So, Dave, something to watch for if you merge net into net-next.) I applied the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 30 Mar 2015 14:59:49 +1100 Subject: [PATCH] usbnet: fix bad merge in cdc_ncm.c Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/usb/cdc_ncm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index ee6fed0af6f5..c3e4da9e79ca 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -1184,8 +1184,6 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) usbnet_set_skb_tx_stats(skb_out, n, ctx->tx_curr_frame_payload - skb_out->len); - usbnet_set_skb_tx_stats(skb_out, n); - return skb_out; exit_no_skb: -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 30 Mar 2015 15:05:34 +1100
> Caused by a bad merge between commits 1e9e39f4a298 ("usbnet: Fix
> tx_packets stat for FLAG_MULTI_FRAME drivers") and 7a1e890e2168
> ("usbnet: Fix tx_bytes statistic running backward in cdc_ncm") form the
> net tree and commit 6588af614e7b ("usbnet: Fix tx_packets stat for
> FLAG_MULTI_FRAME drivers") from the net-next tree. (Presumably,
> 6588af614e7b was cherry-picked as a bug fix. So, Dave, something to
> watch for if you merge net into net-next.)
Thanks a lot for bringing this to my attention Stephen.
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/ethernet/mellanox/mlx5/core/main.c: In function 'mlx5_irq_set_affinity_hint': drivers/net/ethernet/mellanox/mlx5/core/main.c:474:2: error: implicit declaration of function 'cpumask_set_cpu_local_first' [-Werror=implicit-function-declaration] err = cpumask_set_cpu_local_first(i, numa_node, priv->irq_info[i].mask); ^ Caused by commit db058a186f98 ("net/mlx5_core: Set irq affinity hints") interacting with commit f36963c9d3f6 ("cpumask_set_cpu_local_first => cpumask_local_spread, lament") from Linus' tree. I have applied the following merge fix patch (Dave, you could do this by back merging commit f36963c9d3f6 from Linus' tree - which is based on v4.1-rc2 if that worries you). Please yell if this is not correct (it does build). From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 1 Jun 2015 13:36:49 +1000 Subject: [PATCH] net/mlx5_core: merge fix for cpumask_set_cpu_local_first API change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/mellanox/mlx5/core/main.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c index 1c37f587426d..2510fed3494d 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c @@ -471,11 +471,8 @@ static int mlx5_irq_set_affinity_hint(struct mlx5_core_dev *mdev, int i) return -ENOMEM; } - err = cpumask_set_cpu_local_first(i, numa_node, priv->irq_info[i].mask); - if (err) { - mlx5_core_warn(mdev, "cpumask_set_cpu_local_first failed"); - goto err_clear_mask; - } + cpumask_set_cpu(cpumask_local_spread(i, numa_node), + priv->irq_info[i].mask); err = irq_set_affinity_hint(irq, priv->irq_info[i].mask); if (err) { -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 1 Jun 2015 13:44:13 +1000
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/net/ethernet/mellanox/mlx5/core/main.c: In function 'mlx5_irq_set_affinity_hint':
> drivers/net/ethernet/mellanox/mlx5/core/main.c:474:2: error: implicit declaration of function 'cpumask_set_cpu_local_first' [-Werror=implicit-function-declaration]
> err = cpumask_set_cpu_local_first(i, numa_node, priv->irq_info[i].mask);
> ^
>
> Caused by commit db058a186f98 ("net/mlx5_core: Set irq affinity hints")
> interacting with commit f36963c9d3f6 ("cpumask_set_cpu_local_first =>
> cpumask_local_spread, lament") from Linus' tree.
>
> I have applied the following merge fix patch (Dave, you could do this
> by back merging commit f36963c9d3f6 from Linus' tree - which is based
> on v4.1-rc2 if that worries you). Please yell if this is not correct
> (it does build).
Thanks Stephen, I'll take care of this next time I merge.
[-- Attachment #1: Type: text/plain, Size: 2020 bytes --] Hi all, After merging the net-next tree, today's linux-next build (KCONFIG_NAME) failed like this: drivers/net/ethernet/apm/xgene/xgene_enet_main.c: In function 'xgene_get_port_id_acpi': drivers/net/ethernet/apm/xgene/xgene_enet_main.c:880:2: error: implicit declaration of function 'acpi_evaluate_integer' [-Werror=implicit-function-declaration] status = acpi_evaluate_integer(ACPI_HANDLE(dev), "_SUN", NULL, &temp); ^ drivers/net/ethernet/apm/xgene/xgene_enet_main.c: At top level: drivers/net/ethernet/apm/xgene/xgene_enet_main.c:874:12: warning: 'xgene_get_port_id_acpi' defined but not used [-Wunused-function] static int xgene_get_port_id_acpi(struct device *dev, ^ Caused by commit 0738c54d6324 ("drivers: net: xgene: Fix the ACPI support for RGMII/SGMII0/XFI interface of APM X-Gene SoC ethernet controller"). I have applied this patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 24 Jun 2015 17:29:51 +1000 Subject: [PATCH] drivers: net: xgene: fix for ACPI support without ACPI Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c index b334f279ce8d..95153b234c71 100644 --- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c @@ -871,6 +871,7 @@ static const struct net_device_ops xgene_ndev_ops = { .ndo_set_mac_address = xgene_enet_set_mac_address, }; +#ifdef CONFIG_ACPI static int xgene_get_port_id_acpi(struct device *dev, struct xgene_enet_pdata *pdata) { @@ -886,6 +887,7 @@ static int xgene_get_port_id_acpi(struct device *dev, return 0; } +#endif static int xgene_get_port_id_dt(struct device *dev, struct xgene_enet_pdata *pdata) { -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 24 Jun 2015 17:37:10 +1000
> I have applied this patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 24 Jun 2015 17:29:51 +1000
> Subject: [PATCH] drivers: net: xgene: fix for ACPI support without ACPI
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks Stephen.
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: net/ipv4/ip_tunnel_core.c:301:1: warning: data definition has no type or storage class module_init(ip_tunnel_core_init); ^ net/ipv4/ip_tunnel_core.c:301:1: error: type defaults to 'int' in declaration of 'module_init' [-Werror=implicit-int] net/ipv4/ip_tunnel_core.c:301:1: warning: parameter names (without types) in function declaration net/ipv4/ip_tunnel_core.c:307:1: warning: data definition has no type or storage class module_exit(ip_tunnel_core_exit); ^ net/ipv4/ip_tunnel_core.c:307:1: error: type defaults to 'int' in declaration of 'module_exit' [-Werror=implicit-int] net/ipv4/ip_tunnel_core.c:307:1: warning: parameter names (without types) in function declaration net/ipv4/ip_tunnel_core.c:295:19: warning: 'ip_tunnel_core_init' defined but not used [-Wunused-function] static int __init ip_tunnel_core_init(void) ^ Caused by commit 3093fbe7ff4b ("route: Per route IP tunnel metadata via lightweight tunnel") Forgot to include module.h ... I have used the net-next tree from next-20150722 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/built-in.o: In function `.vnic_wq_devcmd2_alloc': (.text+0x49fe40): multiple definition of `.vnic_wq_devcmd2_alloc' drivers/scsi/built-in.o:(.text+0xb4318): first defined here drivers/net/built-in.o:(.opd+0x2af00): multiple definition of `vnic_wq_devcmd2_alloc' drivers/scsi/built-in.o:(.opd+0xad70): first defined here drivers/net/built-in.o: In function `.vnic_wq_init_start': (.text+0x49f9c0): multiple definition of `.vnic_wq_init_start' drivers/scsi/built-in.o:(.text+0xb3b58): first defined here drivers/net/built-in.o:(.opd+0x2ae88): multiple definition of `vnic_wq_init_start' drivers/scsi/built-in.o:(.opd+0xace0): first defined here Caused by commit 373fb0873d43 ("enic: add devcmd2") I have reverted that commit for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 18 Aug 2015 18:39:17 +1000 > drivers/net/built-in.o: In function `.vnic_wq_devcmd2_alloc': > (.text+0x49fe40): multiple definition of `.vnic_wq_devcmd2_alloc' > drivers/scsi/built-in.o:(.text+0xb4318): first defined here > drivers/net/built-in.o:(.opd+0x2af00): multiple definition of `vnic_wq_devcmd2_alloc' > drivers/scsi/built-in.o:(.opd+0xad70): first defined here > drivers/net/built-in.o: In function `.vnic_wq_init_start': > (.text+0x49f9c0): multiple definition of `.vnic_wq_init_start' > drivers/scsi/built-in.o:(.text+0xb3b58): first defined here > drivers/net/built-in.o:(.opd+0x2ae88): multiple definition of `vnic_wq_init_start' > drivers/scsi/built-in.o:(.opd+0xace0): first defined here I've committed the following to fix this: ==================== [PATCH] enic: Fix namespace pollution causing build errors. drivers/net/built-in.o: In function `.vnic_wq_devcmd2_alloc': (.text+0x49fe40): multiple definition of `.vnic_wq_devcmd2_alloc' drivers/scsi/built-in.o:(.text+0xb4318): first defined here drivers/net/built-in.o:(.opd+0x2af00): multiple definition of `vnic_wq_devcmd2_alloc' drivers/scsi/built-in.o:(.opd+0xad70): first defined here drivers/net/built-in.o: In function `.vnic_wq_init_start': (.text+0x49f9c0): multiple definition of `.vnic_wq_init_start' drivers/scsi/built-in.o:(.text+0xb3b58): first defined here drivers/net/built-in.o:(.opd+0x2ae88): multiple definition of `vnic_wq_init_start' drivers/scsi/built-in.o:(.opd+0xace0): first defined here Rename these to 'enic_*' to avoid the conflict with the functiosn of the same name in the snic scsi driver. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- drivers/net/ethernet/cisco/enic/vnic_dev.c | 4 ++-- drivers/net/ethernet/cisco/enic/vnic_wq.c | 6 +++--- drivers/net/ethernet/cisco/enic/vnic_wq.h | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/cisco/enic/vnic_dev.c b/drivers/net/ethernet/cisco/enic/vnic_dev.c index 9f6c641..19a49a6 100644 --- a/drivers/net/ethernet/cisco/enic/vnic_dev.c +++ b/drivers/net/ethernet/cisco/enic/vnic_dev.c @@ -388,7 +388,7 @@ static int vnic_dev_init_devcmd2(struct vnic_dev *vdev) vdev->devcmd2->color = 1; vdev->devcmd2->result_size = DEVCMD2_RING_SIZE; - err = vnic_wq_devcmd2_alloc(vdev, &vdev->devcmd2->wq, DEVCMD2_RING_SIZE, + err = enic_wq_devcmd2_alloc(vdev, &vdev->devcmd2->wq, DEVCMD2_RING_SIZE, DEVCMD2_DESC_SIZE); if (err) goto err_free_devcmd2; @@ -400,7 +400,7 @@ static int vnic_dev_init_devcmd2(struct vnic_dev *vdev) return -ENODEV; } - vnic_wq_init_start(&vdev->devcmd2->wq, 0, fetch_index, fetch_index, 0, + enic_wq_init_start(&vdev->devcmd2->wq, 0, fetch_index, fetch_index, 0, 0); vnic_wq_enable(&vdev->devcmd2->wq); diff --git a/drivers/net/ethernet/cisco/enic/vnic_wq.c b/drivers/net/ethernet/cisco/enic/vnic_wq.c index 627f3b1..05ad16a 100644 --- a/drivers/net/ethernet/cisco/enic/vnic_wq.c +++ b/drivers/net/ethernet/cisco/enic/vnic_wq.c @@ -114,7 +114,7 @@ int vnic_wq_alloc(struct vnic_dev *vdev, struct vnic_wq *wq, unsigned int index, return 0; } -int vnic_wq_devcmd2_alloc(struct vnic_dev *vdev, struct vnic_wq *wq, +int enic_wq_devcmd2_alloc(struct vnic_dev *vdev, struct vnic_wq *wq, unsigned int desc_count, unsigned int desc_size) { int err; @@ -131,7 +131,7 @@ int vnic_wq_devcmd2_alloc(struct vnic_dev *vdev, struct vnic_wq *wq, return err; } -void vnic_wq_init_start(struct vnic_wq *wq, unsigned int cq_index, +void enic_wq_init_start(struct vnic_wq *wq, unsigned int cq_index, unsigned int fetch_index, unsigned int posted_index, unsigned int error_interrupt_enable, unsigned int error_interrupt_offset) @@ -158,7 +158,7 @@ void vnic_wq_init(struct vnic_wq *wq, unsigned int cq_index, unsigned int error_interrupt_enable, unsigned int error_interrupt_offset) { - vnic_wq_init_start(wq, cq_index, 0, 0, + enic_wq_init_start(wq, cq_index, 0, 0, error_interrupt_enable, error_interrupt_offset); } diff --git a/drivers/net/ethernet/cisco/enic/vnic_wq.h b/drivers/net/ethernet/cisco/enic/vnic_wq.h index c9b25d3..8944af9 100644 --- a/drivers/net/ethernet/cisco/enic/vnic_wq.h +++ b/drivers/net/ethernet/cisco/enic/vnic_wq.h @@ -185,9 +185,9 @@ void vnic_wq_enable(struct vnic_wq *wq); int vnic_wq_disable(struct vnic_wq *wq); void vnic_wq_clean(struct vnic_wq *wq, void (*buf_clean)(struct vnic_wq *wq, struct vnic_wq_buf *buf)); -int vnic_wq_devcmd2_alloc(struct vnic_dev *vdev, struct vnic_wq *wq, +int enic_wq_devcmd2_alloc(struct vnic_dev *vdev, struct vnic_wq *wq, unsigned int desc_count, unsigned int desc_size); -void vnic_wq_init_start(struct vnic_wq *wq, unsigned int cq_index, +void enic_wq_init_start(struct vnic_wq *wq, unsigned int cq_index, unsigned int fetch_index, unsigned int posted_index, unsigned int error_interrupt_enable, unsigned int error_interrupt_offset); -- 2.1.0
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: net/ipv4/fib_semantics.c: In function 'fib_encap_match': net/ipv4/fib_semantics.c:553:3: error: implicit declaration of function 'lwtstate_free' [-Werror=implicit-function-declaration] lwtstate_free(lwtstate); ^ Caused by commit df383e6240ef ("lwtunnel: fix memory leak") CONFIG_LWTUNNEL is not set for this build. I reverted that commit for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 20 Aug 2015 12:57:34 +1000 > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > net/ipv4/fib_semantics.c: In function 'fib_encap_match': > net/ipv4/fib_semantics.c:553:3: error: implicit declaration of function 'lwtstate_free' [-Werror=implicit-function-declaration] > lwtstate_free(lwtstate); > ^ > > Caused by commit > > df383e6240ef ("lwtunnel: fix memory leak") > > CONFIG_LWTUNNEL is not set for this build. > > I reverted that commit for today. Ought to already be fixed by: ==================== From 824e7383e92815cb591793c74cc836aa5165f7f8 Mon Sep 17 00:00:00 2001 From: Ying Xue <ying.xue@windriver.com> Date: Wed, 19 Aug 2015 15:46:17 +0800 Subject: [PATCH 1/2] lwtunnel: Fix the sparse warnings in fib_encap_match MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When CONFIG_LWTUNNEL config is not enabled, the lwtstate_free() is not declared in lwtunnel.h at all. However, even in this case, the function is still referenced in fib_semantics.c so that there appears the following sparse warnings: net/ipv4/fib_semantics.c:553:17: error: undefined identifier 'lwtstate_free' CC net/ipv4/fib_semantics.o net/ipv4/fib_semantics.c: In function ‘fib_encap_match’: net/ipv4/fib_semantics.c:553:3: error: implicit declaration of function ‘lwtstate_free’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[1]: *** [net/ipv4/fib_semantics.o] Error 1 make: *** [net/ipv4/fib_semantics.o] Error 2 To eliminate the error, we define an empty function for lwtstate_free() in lwtunnel.h when CONFIG_LWTUNNEL is disabled. Fixes: df383e6240ef ("lwtunnel: fix memory leak") Cc: Jiri Benc <jbenc@redhat.com> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Ying Xue <ying.xue@windriver.com> Acked-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> --- include/net/lwtunnel.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/net/lwtunnel.h b/include/net/lwtunnel.h index 34fd8f7..cfee539 100644 --- a/include/net/lwtunnel.h +++ b/include/net/lwtunnel.h @@ -93,6 +93,10 @@ int lwtunnel_input6(struct sk_buff *skb); #else +static inline void lwtstate_free(struct lwtunnel_state *lws) +{ +} + static inline struct lwtunnel_state * lwtstate_get(struct lwtunnel_state *lws) { -- 2.1.0
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: In function 'dst_hold', inlined from '__ipv6_dev_ac_dec' at /home/sfr/next/next/net/ipv6/anycast.c:328:2: /home/sfr/next/next/include/linux/compiler.h:447:38: error: call to '__compiletime_assert_243' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct dst_entry, __refcnt) & 63 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ /home/sfr/next/next/include/linux/compiler.h:430:4: note: in definition of macro '__compiletime_assert' prefix ## suffix(); \ ^ /home/sfr/next/next/include/linux/compiler.h:447:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ /home/sfr/next/next/include/linux/bug.h:50:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^ /home/sfr/next/next/include/linux/bug.h:74:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) ^ /home/sfr/next/next/include/net/dst.h:243:2: note: in expansion of macro 'BUILD_BUG_ON' BUILD_BUG_ON(offsetof(struct dst_entry, __refcnt) & 63); ^ And many more :-( Caused by commit 61adedf3e3f1 ("route: move lwtunnel state to dst_entry") I have used the net-next tree from next-20150821 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 24 Aug 2015 13:21:11 +1000 > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: Fixed by: ==================== [PATCH] route: fix breakage after moving lwtunnel state __recnt and related fields need to be in its own cacheline for performance reasons. Commit 61adedf3e3f1 ("route: move lwtunnel state to dst_entry") broke that on 32bit archs, causing BUILD_BUG_ON in dst_hold to be triggered. This patch fixes the breakage by moving the lwtunnel state to the end of dst_entry on 32bit archs. Unfortunately, this makes it share the cacheline with __refcnt and may affect performance, thus further patches may be needed. Reported-by: kbuild test robot <fengguang.wu@intel.com> Fixes: 61adedf3e3f1 ("route: move lwtunnel state to dst_entry") Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> --- include/net/dst.h | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/include/net/dst.h b/include/net/dst.h index 0a9a723..ef8f1d4 100644 --- a/include/net/dst.h +++ b/include/net/dst.h @@ -44,7 +44,6 @@ struct dst_entry { #else void *__pad1; #endif - struct lwtunnel_state *lwtstate; int (*input)(struct sk_buff *); int (*output)(struct sock *sk, struct sk_buff *skb); @@ -85,11 +84,12 @@ struct dst_entry { __u32 __pad2; #endif +#ifdef CONFIG_64BIT + struct lwtunnel_state *lwtstate; /* * Align __refcnt to a 64 bytes alignment * (L1_CACHE_SIZE would be too much) */ -#ifdef CONFIG_64BIT long __pad_to_align_refcnt[1]; #endif /* @@ -99,6 +99,9 @@ struct dst_entry { atomic_t __refcnt; /* client references */ int __use; unsigned long lastuse; +#ifndef CONFIG_64BIT + struct lwtunnel_state *lwtstate; +#endif union { struct dst_entry *next; struct rtable __rcu *rt_next; -- 2.1.0
Hi Dave,
On Sun, 23 Aug 2015 20:33:25 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 24 Aug 2015 13:21:11 +1000
>
> > After merging the net-next tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
>
> Fixed by:
>
> ====================
> [PATCH] route: fix breakage after moving lwtunnel state
Thanks, I will get that tomorrow. I must try to remember to check to
see if you have added fixes to your tree when I get these errors (not
that it happens all that often).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
Hi all, After merging the net-next tree, today's linux-next build (i386 defconfig) failed like this: net/built-in.o: In function `fib_rebalance': fib_semantics.c:(.text+0x9d6d4): undefined reference to `__divdi3' Caused by commit 0e884c78ee19 ("ipv4: L3 hash-based multipath") I have reverted that commit (and the following commit since it may depend on the former) for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/net/phy/micrel.c: In function 'ksz9031_config_init': drivers/net/phy/micrel.c:492:22: error: 'struct phy_device' has no member named 'dev' dev_walker = &phydev->dev; ^ Caused by commit e5a03bfd873c ("phy: Add an mdio_device structure") interacting with commit b4c19f71252e ("phy: micrel: Fix finding PHY properties in MAC node for KSZ9031.") from the net tree. I applied the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 11 Jan 2016 13:25:09 +1100 Subject: [PATCH] phy: micrel: fix up for "phy: Add an mdio_device structure" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/phy/micrel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c index 41b598548f2e..03833dbfca67 100644 --- a/drivers/net/phy/micrel.c +++ b/drivers/net/phy/micrel.c @@ -489,7 +489,7 @@ static int ksz9031_config_init(struct phy_device *phydev) * properties in the MAC node. Walk up the tree of devices to * find a device with an OF node. */ - dev_walker = &phydev->dev; + dev_walker = &phydev->mdio.dev; do { of_node = dev_walker->of_node; dev_walker = dev_walker->parent; -- 2.6.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 11 Jan 2016 13:46:15 +1100
> I applied the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 11 Jan 2016 13:25:09 +1100
> Subject: [PATCH] phy: micrel: fix up for "phy: Add an mdio_device structure"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks Stephen, it's correct and I'll make sure I do this when
I merge net into net-next.
Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from drivers/net/ethernet/broadcom/bnx2x/bnx2x.h:56:0, from drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:30: drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c: In function 'bnx2x_dcbx_get_ap_feature': drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:224:11: error: 'DCBX_APP_SF_DEFAULT' undeclared (first use in this function) DCBX_APP_SF_DEFAULT) && ^ drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.h:120:45: note: in definition of macro 'GET_FLAGS' #define GET_FLAGS(flags, bits) ((flags) & (bits)) ^ drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:224:11: note: each undeclared identifier is reported only once for each function it appears in DCBX_APP_SF_DEFAULT) && ^ drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.h:120:45: note: in definition of macro 'GET_FLAGS' #define GET_FLAGS(flags, bits) ((flags) & (bits)) ^ Caused by commit e5d3a51cefbb ("This adds support for default application priority.") This build is big endian. I have used the net-next tree from next-20160217 for today. -- Cheers, Stephen Rothwell
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 18 Feb 2016 12:28:55 +1100
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from drivers/net/ethernet/broadcom/bnx2x/bnx2x.h:56:0,
> from drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:30:
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c: In function 'bnx2x_dcbx_get_ap_feature':
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:224:11: error: 'DCBX_APP_SF_DEFAULT' undeclared (first use in this function)
> DCBX_APP_SF_DEFAULT) &&
> ^
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.h:120:45: note: in definition of macro 'GET_FLAGS'
> #define GET_FLAGS(flags, bits) ((flags) & (bits))
> ^
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:224:11: note: each undeclared identifier is reported only once for each function it appears in
> DCBX_APP_SF_DEFAULT) &&
> ^
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.h:120:45: note: in definition of macro 'GET_FLAGS'
> #define GET_FLAGS(flags, bits) ((flags) & (bits))
> ^
>
> Caused by commit
>
> e5d3a51cefbb ("This adds support for default application priority.")
>
> This build is big endian.
Yuval and Ariel, you _MUST_ fix this.
This build failure has been in the tree for 24 hours and I haven't heard anything
from you two yet.
If this persists for another day I'm reverting all of your changes.
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from drivers/net/ethernet/broadcom/bnx2x/bnx2x.h:56:0,
> > from drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:30:
> > drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c: In function
> 'bnx2x_dcbx_get_ap_feature':
> > drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:224:11: error:
> 'DCBX_APP_SF_DEFAULT' undeclared (first use in this function)
> > DCBX_APP_SF_DEFAULT) &&
> > ^
> > Caused by commit
> >
> > e5d3a51cefbb ("This adds support for default application priority.")
> >
> > This build is big endian.
>
> Yuval and Ariel, you _MUST_ fix this.
>
> This build failure has been in the tree for 24 hours and I haven't heard anything
> from you two yet.
Hi Dave,
Perhaps I wasn't clear enough in the title I've provided for the fixing patch,
but I've sent it yesterday and it's marked as 'under review' for net-next.
The patch is "bnx2x: Add missing HSI for big-endian machines".
Sorry about all the noise.
Hi all, [A report from Mark's buildbot] After merging the net-next tree, today's linux-next build (arm allmodconfig) failed like thisi (this has actually been failing for a few days, now): ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] undefined! Caused by commit 49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type") arm only allows udelay()s up to 2 milliseconds. This commit adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c. -- Cheers, Stephen Rothwell
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 13 Apr 2016 17:50:28 +1000
> After merging the net-next tree, today's linux-next build (arm
> allmodconfig) failed like thisi (this has actually been failing for a
> few days, now):
>
> ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] undefined!
>
> Caused by commit
>
> 49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type")
>
> arm only allows udelay()s up to 2 milliseconds. This commit
> adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in
> drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c.
Jeff, please have your folks look into this. Probably just a simple
conversion to mdelay().
Thanks!
On Wednesday 13 April 2016 11:15:13 David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 13 Apr 2016 17:50:28 +1000
>
> > After merging the net-next tree, today's linux-next build (arm
> > allmodconfig) failed like thisi (this has actually been failing for a
> > few days, now):
> >
> > ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] undefined!
> >
> > Caused by commit
> >
> > 49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type")
> >
> > arm only allows udelay()s up to 2 milliseconds. This commit
> > adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in
> > drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c.
>
> Jeff, please have your folks look into this. Probably just a simple
> conversion to mdelay().
>
I sent a patch, pretty sure we can use msleep() here rather than
a wasteful mdelay().
Arnd
[-- Attachment #1: Type: text/plain, Size: 816 bytes --] On Wed, Apr 13, 2016 at 11:15:13AM -0400, David Miller wrote: > From: Stephen Rothwell <sfr@canb.auug.org.au> > > After merging the net-next tree, today's linux-next build (arm > > allmodconfig) failed like thisi (this has actually been failing for a > > few days, now): > > ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] undefined! > > Caused by commit > > 49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type") > > arm only allows udelay()s up to 2 milliseconds. This commit > > adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in > > drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c. > Jeff, please have your folks look into this. Probably just a simple > conversion to mdelay(). This is still present, it's been breaking ARM allmodconfig builds for about two weeks now. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1062 bytes --] On Fri, 2016-04-22 at 10:20 +0100, Mark Brown wrote: > On Wed, Apr 13, 2016 at 11:15:13AM -0400, David Miller wrote: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > > > After merging the net-next tree, today's linux-next build (arm > > > allmodconfig) failed like thisi (this has actually been failing > for a > > > few days, now): > > > > ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] > undefined! > > > > Caused by commit > > > > 49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type") > > > > arm only allows udelay()s up to 2 milliseconds. This commit > > > adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in > > > drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c. > > > Jeff, please have your folks look into this. Probably just a > simple > > conversion to mdelay(). > > This is still present, it's been breaking ARM allmodconfig builds for > about two weeks now. Interesting that no one spoke up until just a week ago. I have a fix and I ready to push it to David Miller. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 783 bytes --] On Fri, Apr 22, 2016 at 04:20:43PM -0700, Jeff Kirsher wrote: > On Fri, 2016-04-22 at 10:20 +0100, Mark Brown wrote: > > > Jeff, please have your folks look into this. Probably just a > > simple > > > conversion to mdelay(). > > This is still present, it's been breaking ARM allmodconfig builds for > > about two weeks now. > Interesting that no one spoke up until just a week ago. I have a fix > and I ready to push it to David Miller. Like Stephen said it had been there for a couple of days already at the time it was reported; I happened to be busy at the time it came up so wasn't looking at the build reports myself. If you've got a fix please get it submitted ASAP, having common test configurations broken for any length of time does get disruptive. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --]
Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .callback = qcom_smd_qrtr_callback, ^ net/qrtr/smd.c:106:14: note: (near initialization for 'qcom_smd_qrtr_driver.callback') Caused by commit bdabad3e363d ("net: Add Qualcomm IPC router") interacting with commit b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference") from the arm-soc tree. I added the following merge fix patch (and it turned out I needed the new stubs). From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 10 May 2016 11:14:06 +1000 Subject: [PATCH] soc: qcom: smd: fix for Qualcomm IPC router and callback API change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- include/linux/soc/qcom/smd.h | 9 +++++++++ net/qrtr/smd.c | 9 ++++++--- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/include/linux/soc/qcom/smd.h b/include/linux/soc/qcom/smd.h index 086e36d76be9..fbebbfc82ed3 100644 --- a/include/linux/soc/qcom/smd.h +++ b/include/linux/soc/qcom/smd.h @@ -70,6 +70,15 @@ static inline void qcom_smd_driver_unregister(struct qcom_smd_driver *drv) WARN_ON(1); } +static inline void *qcom_smd_get_drvdata(struct qcom_smd_channel *channel) +{ + return NULL; +} + +static inline void qcom_smd_set_drvdata(struct qcom_smd_channel *channel, void *data) +{ +} + static inline int qcom_smd_send(struct qcom_smd_channel *channel, const void *data, int len) { diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c index 84ebce73aa23..0d11132b3370 100644 --- a/net/qrtr/smd.c +++ b/net/qrtr/smd.c @@ -21,13 +21,14 @@ struct qrtr_smd_dev { struct qrtr_endpoint ep; struct qcom_smd_channel *channel; + struct device *dev; }; /* from smd to qrtr */ -static int qcom_smd_qrtr_callback(struct qcom_smd_device *sdev, +static int qcom_smd_qrtr_callback(struct qcom_smd_channel *channel, const void *data, size_t len) { - struct qrtr_smd_dev *qdev = dev_get_drvdata(&sdev->dev); + struct qrtr_smd_dev *qdev = qcom_smd_get_drvdata(channel); int rc; if (!qdev) @@ -35,7 +36,7 @@ static int qcom_smd_qrtr_callback(struct qcom_smd_device *sdev, rc = qrtr_endpoint_post(&qdev->ep, data, len); if (rc == -EINVAL) { - dev_err(&sdev->dev, "invalid ipcrouter packet\n"); + dev_err(qdev->dev, "invalid ipcrouter packet\n"); /* return 0 to let smd drop the packet */ rc = 0; } @@ -73,12 +74,14 @@ static int qcom_smd_qrtr_probe(struct qcom_smd_device *sdev) return -ENOMEM; qdev->channel = sdev->channel; + qdev->dev = &sdev->dev; qdev->ep.xmit = qcom_smd_qrtr_send; rc = qrtr_endpoint_register(&qdev->ep, QRTR_EP_NID_AUTO); if (rc) return rc; + qcom_smd_set_drvdata(sdev->channel, qdev); dev_set_drvdata(&sdev->dev, qdev); dev_dbg(&sdev->dev, "Qualcomm SMD QRTR driver probed\n"); -- 2.7.0 -- Cheers, Stephen Rothwell
Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/net/ethernet/mellanox/mlx5/core/en_main.c:37:0: drivers/net/ethernet/mellanox/mlx5/core/en.h:525:29: error: field 'fts' has incomplete type struct mlx5e_flow_tables fts; ^ drivers/net/ethernet/mellanox/mlx5/core/en.h:526:29: error: field 'eth_addr' has incomplete type struct mlx5e_eth_addr_db eth_addr; ^ drivers/net/ethernet/mellanox/mlx5/core/en.h:527:29: error: field 'vlan' has incomplete type struct mlx5e_vlan_db vlan; ^ In file included from drivers/net/ethernet/mellanox/mlx5/core/en_fs.c:38:0: drivers/net/ethernet/mellanox/mlx5/core/en.h:525:29: error: field 'fts' has incomplete type struct mlx5e_flow_tables fts; ^ drivers/net/ethernet/mellanox/mlx5/core/en.h:526:29: error: field 'eth_addr' has incomplete type struct mlx5e_eth_addr_db eth_addr; ^ drivers/net/ethernet/mellanox/mlx5/core/en.h:527:29: error: field 'vlan' has incomplete type struct mlx5e_vlan_db vlan; ^ In file included from drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c:33:0: drivers/net/ethernet/mellanox/mlx5/core/en.h:525:29: error: field 'fts' has incomplete type struct mlx5e_flow_tables fts; ^ drivers/net/ethernet/mellanox/mlx5/core/en.h:526:29: error: field 'eth_addr' has incomplete type struct mlx5e_eth_addr_db eth_addr; ^ drivers/net/ethernet/mellanox/mlx5/core/en.h:527:29: error: field 'vlan' has incomplete type struct mlx5e_vlan_db vlan; ^ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:2619:0: error: unterminated #ifdef #ifdef CONFIG_MLX5_CORE_EN_VXLAN ^ Caused by commit e800072c18f0 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") which seems to have reversed some of the merge fixes in commit cba653210056 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") But I am not reaaly sure what has happened here :-( I tried to use the net-next tree from next-20160509 but that now has conflicts agains other changes, so I applied the following fix patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 10 May 2016 11:20:23 +1000 Subject: [PATCH] net-next: fix bad merge Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/mellanox/mlx5/core/en.h | 3 --- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 1 + 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h index 7aea32e085b3..19b1b021af2d 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h @@ -522,9 +522,6 @@ struct mlx5e_priv { struct mlx5e_direct_tir direct_tir[MLX5E_MAX_NUM_CHANNELS]; struct mlx5e_flow_steering fs; - struct mlx5e_flow_tables fts; - struct mlx5e_eth_addr_db eth_addr; - struct mlx5e_vlan_db vlan; #ifdef CONFIG_MLX5_CORE_EN_VXLAN struct mlx5e_vxlan_db vxlan; #endif diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c index b60a1bc6f457..98be1ce3afd8 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c @@ -2620,6 +2620,7 @@ static const struct net_device_ops mlx5e_netdev_ops_sriov = { .ndo_add_vxlan_port = mlx5e_add_vxlan_port, .ndo_del_vxlan_port = mlx5e_del_vxlan_port, .ndo_features_check = mlx5e_features_check, +#endif #ifdef CONFIG_RFS_ACCEL .ndo_rx_flow_steer = mlx5e_rx_flow_steer, #endif -- 2.7.0 -- Cheers, Stephen Rothwell
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 10 May 2016 11:29:14 +1000
> Caused by commit
>
> e800072c18f0 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
>
> which seems to have reversed some of the merge fixes in commit
>
> cba653210056 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
>
> But I am not reaaly sure what has happened here :-(
>
> I tried to use the net-next tree from next-20160509 but that now has
> conflicts agains other changes, so I applied the following fix patch
> for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 10 May 2016 11:20:23 +1000
> Subject: [PATCH] net-next: fix bad merge
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks Stephen, I'll try to sort this out.
On 9 May 2016 at 20:29, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .callback = qcom_smd_qrtr_callback,
> ^
> net/qrtr/smd.c:106:14: note: (near initialization for 'qcom_smd_qrtr_driver.callback')
>
> Caused by commit
>
> bdabad3e363d ("net: Add Qualcomm IPC router")
>
> interacting with commit
>
> b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")
>
> from the arm-soc tree.
>
> I added the following merge fix patch (and it turned out I needed the
> new stubs).
Thanks for fixing this up. I'll work with Bjorn to get this resolved.
I'll have something up for tomorrow's next pull.
Regards,
Andy Gross
On Mon 09 May 18:29 PDT 2016, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .callback = qcom_smd_qrtr_callback,
> ^
> net/qrtr/smd.c:106:14: note: (near initialization for 'qcom_smd_qrtr_driver.callback')
>
> Caused by commit
>
> bdabad3e363d ("net: Add Qualcomm IPC router")
>
> interacting with commit
>
> b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")
>
> from the arm-soc tree.
>
> I added the following merge fix patch (and it turned out I needed the
> new stubs).
>
Sorry for not spotting this issue earlier, I missed Andy's second pull
request towards arm-soc and thought the SMD changes missed this cycle.
Your patch looks good, but I'm not sure how we should approach the merge
window; Andy can't pick the patch because he doesn't have the qrtr code
and David doesn't have the SMD patches coming through Andy.
FWIW, Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
I assume we could have the QRTR go through Andy and arm-soc, with
David's approval and this fix squashed in. But we're running rather late
in this cycle, perhaps we should just back the QRTR patches out and I
can respin and resend them after the merge window (for v4.8 instead)?
Suggestions are welcome.
Regards,
Bjorn
On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:
> On Mon 09 May 18:29 PDT 2016, Stephen Rothwell wrote:
>
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> > .callback = qcom_smd_qrtr_callback,
> > ^
> > net/qrtr/smd.c:106:14: note: (near initialization for 'qcom_smd_qrtr_driver.callback')
> >
> > Caused by commit
> >
> > bdabad3e363d ("net: Add Qualcomm IPC router")
> >
> > interacting with commit
> >
> > b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")
> >
> > from the arm-soc tree.
> >
> > I added the following merge fix patch (and it turned out I needed the
> > new stubs).
> >
>
> Sorry for not spotting this issue earlier, I missed Andy's second pull
> request towards arm-soc and thought the SMD changes missed this cycle.
>
>
> Your patch looks good, but I'm not sure how we should approach the merge
> window; Andy can't pick the patch because he doesn't have the qrtr code
> and David doesn't have the SMD patches coming through Andy.
>
> FWIW, Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>
>
> I assume we could have the QRTR go through Andy and arm-soc, with
> David's approval and this fix squashed in. But we're running rather late
> in this cycle, perhaps we should just back the QRTR patches out and I
> can respin and resend them after the merge window (for v4.8 instead)?
I'd suggest you do a merge of next-next with the qcom/soc-2 branch that
we have in arm-soc and resolve the conflict in the merge, then send
a pull request with the merge to davem.
Alternatively, in case Linus merges net-next before we get that fix
in, I could send Stephen's fix to Linus along with the pull requests.
Arnd
Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/smc/af_smc.c: In function 'smc_splice_read': net/smc/af_smc.c:1258:39: error: passing argument 1 of 'smc->clcsock->ops->splice_read' from incompatible pointer type [-Werror=incompatible-pointer-types] rc = smc->clcsock->ops->splice_read(smc->clcsock, ppos, ^ net/smc/af_smc.c:1258:39: note: expected 'struct file *' but argument is of type 'struct socket *' net/smc/af_smc.c: At top level: net/smc/af_smc.c:1288:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .splice_read = smc_splice_read, ^ net/smc/af_smc.c:1288:17: note: (near initialization for 'smc_sock_ops.splice_read') Caused by commit ac7138746e14 ("smc: establish new socket family") interacting with commit 15a8f657c71d ("switch socket ->splice_read() to struct file *") from the vfs tree. I applied the following merge fix patch which could well be incorrect ... From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 10 Jan 2017 10:52:38 +1100 Subject: [PATCH] smc: merge fix for "switch socket ->splice_read() to struct file *" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/smc/af_smc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c index 5d4208ad029e..4875e65f0c4a 100644 --- a/net/smc/af_smc.c +++ b/net/smc/af_smc.c @@ -1242,10 +1242,11 @@ static ssize_t smc_sendpage(struct socket *sock, struct page *page, return rc; } -static ssize_t smc_splice_read(struct socket *sock, loff_t *ppos, +static ssize_t smc_splice_read(struct file *file, loff_t *ppos, struct pipe_inode_info *pipe, size_t len, unsigned int flags) { + struct socket *sock = file->private_data; struct sock *sk = sock->sk; struct smc_sock *smc; int rc = -ENOTCONN; @@ -1255,7 +1256,7 @@ static ssize_t smc_splice_read(struct socket *sock, loff_t *ppos, if ((sk->sk_state != SMC_ACTIVE) && (sk->sk_state != SMC_CLOSED)) goto out; if (smc->use_fallback) { - rc = smc->clcsock->ops->splice_read(smc->clcsock, ppos, + rc = smc->clcsock->ops->splice_read(file, ppos, pipe, len, flags); } else { rc = -EOPNOTSUPP; -- 2.10.2 -- Cheers, Stephen Rothwell
ACK - smc_splice_read() is just a place holder at the moment. Its implementation for AF_SMC will follow.
Regards, Ursula Braun
On 01/10/2017 12:59 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> net/smc/af_smc.c: In function 'smc_splice_read':
> net/smc/af_smc.c:1258:39: error: passing argument 1 of 'smc->clcsock->ops->splice_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
> rc = smc->clcsock->ops->splice_read(smc->clcsock, ppos,
> ^
> net/smc/af_smc.c:1258:39: note: expected 'struct file *' but argument is of type 'struct socket *'
> net/smc/af_smc.c: At top level:
> net/smc/af_smc.c:1288:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .splice_read = smc_splice_read,
> ^
> net/smc/af_smc.c:1288:17: note: (near initialization for 'smc_sock_ops.splice_read')
>
> Caused by commit
>
> ac7138746e14 ("smc: establish new socket family")
>
> interacting with commit
>
> 15a8f657c71d ("switch socket ->splice_read() to struct file *")
>
> from the vfs tree.
>
> I applied the following merge fix patch which could well be incorrect ...
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 10 Jan 2017 10:52:38 +1100
> Subject: [PATCH] smc: merge fix for "switch socket ->splice_read() to struct file *"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> net/smc/af_smc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 5d4208ad029e..4875e65f0c4a 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -1242,10 +1242,11 @@ static ssize_t smc_sendpage(struct socket *sock, struct page *page,
> return rc;
> }
>
> -static ssize_t smc_splice_read(struct socket *sock, loff_t *ppos,
> +static ssize_t smc_splice_read(struct file *file, loff_t *ppos,
> struct pipe_inode_info *pipe, size_t len,
> unsigned int flags)
> {
> + struct socket *sock = file->private_data;
> struct sock *sk = sock->sk;
> struct smc_sock *smc;
> int rc = -ENOTCONN;
> @@ -1255,7 +1256,7 @@ static ssize_t smc_splice_read(struct socket *sock, loff_t *ppos,
> if ((sk->sk_state != SMC_ACTIVE) && (sk->sk_state != SMC_CLOSED))
> goto out;
> if (smc->use_fallback) {
> - rc = smc->clcsock->ops->splice_read(smc->clcsock, ppos,
> + rc = smc->clcsock->ops->splice_read(file, ppos,
> pipe, len, flags);
> } else {
> rc = -EOPNOTSUPP;
>
Hi all,
On Tue, 10 Jan 2017 10:59:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> net/smc/af_smc.c: In function 'smc_splice_read':
> net/smc/af_smc.c:1258:39: error: passing argument 1 of 'smc->clcsock->ops->splice_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
> rc = smc->clcsock->ops->splice_read(smc->clcsock, ppos,
> ^
> net/smc/af_smc.c:1258:39: note: expected 'struct file *' but argument is of type 'struct socket *'
> net/smc/af_smc.c: At top level:
> net/smc/af_smc.c:1288:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .splice_read = smc_splice_read,
> ^
> net/smc/af_smc.c:1288:17: note: (near initialization for 'smc_sock_ops.splice_read')
>
> Caused by commit
>
> ac7138746e14 ("smc: establish new socket family")
>
> interacting with commit
>
> 15a8f657c71d ("switch socket ->splice_read() to struct file *")
>
> from the vfs tree.
>
> I applied the following merge fix patch which could well be incorrect ...
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 10 Jan 2017 10:52:38 +1100
> Subject: [PATCH] smc: merge fix for "switch socket ->splice_read() to struct file *"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> net/smc/af_smc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 5d4208ad029e..4875e65f0c4a 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -1242,10 +1242,11 @@ static ssize_t smc_sendpage(struct socket *sock, struct page *page,
> return rc;
> }
>
> -static ssize_t smc_splice_read(struct socket *sock, loff_t *ppos,
> +static ssize_t smc_splice_read(struct file *file, loff_t *ppos,
> struct pipe_inode_info *pipe, size_t len,
> unsigned int flags)
> {
> + struct socket *sock = file->private_data;
> struct sock *sk = sock->sk;
> struct smc_sock *smc;
> int rc = -ENOTCONN;
> @@ -1255,7 +1256,7 @@ static ssize_t smc_splice_read(struct socket *sock, loff_t *ppos,
> if ((sk->sk_state != SMC_ACTIVE) && (sk->sk_state != SMC_CLOSED))
> goto out;
> if (smc->use_fallback) {
> - rc = smc->clcsock->ops->splice_read(smc->clcsock, ppos,
> + rc = smc->clcsock->ops->splice_read(file, ppos,
> pipe, len, flags);
> } else {
> rc = -EOPNOTSUPP;
> --
> 2.10.2
This fix up is now needed when the vfs tree is merged with Linus' tree.
--
Cheers,
Stephen Rothwell
Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/socket.c: In function 'put_ts_pktinfo': net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function) put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO, ^ Caused by commit aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets") This probably broke every architecture that has its own arch/<arch>/include/uapi/asm/socket.h that does not include include/uapi/asm-generic/socket.h :-( I have used the net-next tree from next-20170519 for today. -- Cheers, Stephen Rothwell
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 22 May 2017 11:16:05 +1000 > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/socket.c: In function 'put_ts_pktinfo': > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function) > put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO, > ^ > Caused by commit > > aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets") > > This probably broke every architecture that has its own > arch/<arch>/include/uapi/asm/socket.h that does not include > include/uapi/asm-generic/socket.h :-( > > I have used the net-next tree from next-20170519 for today. I've just pushed the following, thanks for the report: ==================== net: Define SCM_TIMESTAMPING_PKTINFO on all architectures. A definition was only provided for asm-generic/socket.h using platforms, define it for the others as well Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- arch/alpha/include/uapi/asm/socket.h | 2 ++ arch/frv/include/uapi/asm/socket.h | 2 ++ arch/ia64/include/uapi/asm/socket.h | 2 ++ arch/m32r/include/uapi/asm/socket.h | 2 ++ arch/mips/include/uapi/asm/socket.h | 2 ++ arch/mn10300/include/uapi/asm/socket.h | 2 ++ arch/parisc/include/uapi/asm/socket.h | 2 ++ arch/powerpc/include/uapi/asm/socket.h | 2 ++ arch/s390/include/uapi/asm/socket.h | 2 ++ arch/sparc/include/uapi/asm/socket.h | 2 ++ arch/xtensa/include/uapi/asm/socket.h | 2 ++ 11 files changed, 22 insertions(+) diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h index 148d7a3..0926de6 100644 --- a/arch/alpha/include/uapi/asm/socket.h +++ b/arch/alpha/include/uapi/asm/socket.h @@ -105,4 +105,6 @@ #define SO_COOKIE 57 +#define SCM_TIMESTAMPING_PKTINFO 58 + #endif /* _UAPI_ASM_SOCKET_H */ diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h index 1ccf456..e491ff0 100644 --- a/arch/frv/include/uapi/asm/socket.h +++ b/arch/frv/include/uapi/asm/socket.h @@ -98,5 +98,7 @@ #define SO_COOKIE 57 +#define SCM_TIMESTAMPING_PKTINFO 58 + #endif /* _ASM_SOCKET_H */ diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h index 2c3f4b4..8693724 100644 --- a/arch/ia64/include/uapi/asm/socket.h +++ b/arch/ia64/include/uapi/asm/socket.h @@ -107,4 +107,6 @@ #define SO_COOKIE 57 +#define SCM_TIMESTAMPING_PKTINFO 58 + #endif /* _ASM_IA64_SOCKET_H */ diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h index ae6548d..5d97890 100644 --- a/arch/m32r/include/uapi/asm/socket.h +++ b/arch/m32r/include/uapi/asm/socket.h @@ -98,4 +98,6 @@ #define SO_COOKIE 57 +#define SCM_TIMESTAMPING_PKTINFO 58 + #endif /* _ASM_M32R_SOCKET_H */ diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h index 3418ec9..365ff51 100644 --- a/arch/mips/include/uapi/asm/socket.h +++ b/arch/mips/include/uapi/asm/socket.h @@ -116,4 +116,6 @@ #define SO_COOKIE 57 +#define SCM_TIMESTAMPING_PKTINFO 58 + #endif /* _UAPI_ASM_SOCKET_H */ diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h index 4526e92..d013c0d 100644 --- a/arch/mn10300/include/uapi/asm/socket.h +++ b/arch/mn10300/include/uapi/asm/socket.h @@ -98,4 +98,6 @@ #define SO_COOKIE 57 +#define SCM_TIMESTAMPING_PKTINFO 58 + #endif /* _ASM_SOCKET_H */ diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h index 5147018..784b871 100644 --- a/arch/parisc/include/uapi/asm/socket.h +++ b/arch/parisc/include/uapi/asm/socket.h @@ -97,4 +97,6 @@ #define SO_COOKIE 0x4032 +#define SCM_TIMESTAMPING_PKTINFO 58 + #endif /* _UAPI_ASM_SOCKET_H */ diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h index 58e2ec0..bc4ca72 100644 --- a/arch/powerpc/include/uapi/asm/socket.h +++ b/arch/powerpc/include/uapi/asm/socket.h @@ -105,4 +105,6 @@ #define SO_COOKIE 57 +#define SCM_TIMESTAMPING_PKTINFO 58 + #endif /* _ASM_POWERPC_SOCKET_H */ diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h index e8e5ecf..fb9769d 100644 --- a/arch/s390/include/uapi/asm/socket.h +++ b/arch/s390/include/uapi/asm/socket.h @@ -104,4 +104,6 @@ #define SO_COOKIE 57 +#define SCM_TIMESTAMPING_PKTINFO 58 + #endif /* _ASM_SOCKET_H */ diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h index 3f4ad19..5d67330 100644 --- a/arch/sparc/include/uapi/asm/socket.h +++ b/arch/sparc/include/uapi/asm/socket.h @@ -94,6 +94,8 @@ #define SO_COOKIE 0x003b +#define SCM_TIMESTAMPING_PKTINFO 0x003c + /* Security levels - as per NRL IPv6 - don't actually do anything */ #define SO_SECURITY_AUTHENTICATION 0x5001 #define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002 diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h index 1eb6d2f..982c253 100644 --- a/arch/xtensa/include/uapi/asm/socket.h +++ b/arch/xtensa/include/uapi/asm/socket.h @@ -109,4 +109,6 @@ #define SO_COOKIE 57 +#define SCM_TIMESTAMPING_PKTINFO 58 + #endif /* _XTENSA_SOCKET_H */ -- 2.7.4
On Sun, May 21, 2017 at 9:16 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/socket.c: In function 'put_ts_pktinfo': > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function) > put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO, > ^ > > Caused by commit > > aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets") > > This probably broke every architecture that has its own > arch/<arch>/include/uapi/asm/socket.h that does not include > include/uapi/asm-generic/socket.h :-( Indeed. I added the architecture specific versions in patch http://patchwork.ozlabs.org/patch/765238/ That fixes the powerpc build for me. The new option is now defined in every file that also defines the last added such option SCM_TIMESTAMPING_OPT_STATS. Apologies for missing this earlier.
Hi Dave, On Sun, 21 May 2017 23:14:10 -0400 (EDT) David Miller <davem@davemloft.net> wrote: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 22 May 2017 11:16:05 +1000 > > > After merging the net-next tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > > > net/socket.c: In function 'put_ts_pktinfo': > > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function) > > put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO, > > ^ > > Caused by commit > > > > aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets") > > > > This probably broke every architecture that has its own > > arch/<arch>/include/uapi/asm/socket.h that does not include > > include/uapi/asm-generic/socket.h :-( > > > > I have used the net-next tree from next-20170519 for today. > > I've just pushed the following, thanks for the report: Looks good except: > diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h > index 5147018..784b871 100644 > --- a/arch/parisc/include/uapi/asm/socket.h > +++ b/arch/parisc/include/uapi/asm/socket.h > @@ -97,4 +97,6 @@ > > #define SO_COOKIE 0x4032 > > +#define SCM_TIMESTAMPING_PKTINFO 58 Does this need to be 0x4033 (or something)? -- Cheers, Stephen Rothwell
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 May 2017 13:43:00 +1000
> Hi Dave,
>
> On Sun, 21 May 2017 23:14:10 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Mon, 22 May 2017 11:16:05 +1000
>>
>> > After merging the net-next tree, today's linux-next build (powerpc
>> > ppc64_defconfig) failed like this:
>> >
>> > net/socket.c: In function 'put_ts_pktinfo':
>> > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
>> > put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
>> > ^
>> > Caused by commit
>> >
>> > aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
>> >
>> > This probably broke every architecture that has its own
>> > arch/<arch>/include/uapi/asm/socket.h that does not include
>> > include/uapi/asm-generic/socket.h :-(
>> >
>> > I have used the net-next tree from next-20170519 for today.
>>
>> I've just pushed the following, thanks for the report:
>
> Looks good except:
>
>> diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
>> index 5147018..784b871 100644
>> --- a/arch/parisc/include/uapi/asm/socket.h
>> +++ b/arch/parisc/include/uapi/asm/socket.h
>> @@ -97,4 +97,6 @@
>>
>> #define SO_COOKIE 0x4032
>>
>> +#define SCM_TIMESTAMPING_PKTINFO 58
>
> Does this need to be 0x4033 (or something)?
Good catch, I'll fix this up!
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: net/core/filter.o: In function `xdp_do_flush_map': filter.c:(.text+0x3770): undefined reference to `__dev_map_flush' net/core/filter.o: In function `__bpf_tx_xdp': filter.c:(.text+0x56dc): undefined reference to `__dev_map_insert_ctx' net/core/filter.o: In function `xdp_do_redirect_map': filter.c:(.text+0x5e24): undefined reference to `__dev_map_lookup_elem' Caused by commit 11393cc9b9be ("xdp: Add batching support to redirect map") This build has CONFIG_BPF=y # CONFIG_BPF_SYSCALL is not set I have used the net-next tree from next-20170717 for today. -- Cheers, Stephen Rothwell
On 07/17/2017 06:09 PM, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > net/core/filter.o: In function `xdp_do_flush_map': > filter.c:(.text+0x3770): undefined reference to `__dev_map_flush' > net/core/filter.o: In function `__bpf_tx_xdp': > filter.c:(.text+0x56dc): undefined reference to `__dev_map_insert_ctx' > net/core/filter.o: In function `xdp_do_redirect_map': > filter.c:(.text+0x5e24): undefined reference to `__dev_map_lookup_elem' > > Caused by commit > > 11393cc9b9be ("xdp: Add batching support to redirect map") > > This build has > > CONFIG_BPF=y > # CONFIG_BPF_SYSCALL is not set > > I have used the net-next tree from next-20170717 for today. > I missed testing without CONFIG_BPF_SYSCALL. Patch is posted to netdev and on patchworks at, https://patchwork.ozlabs.org/patch/789862/ Thanks, John
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: arch/arm/boot/dts/rk3228-evb.dtb: ERROR (phandle_references): Reference to non-existent node or label "phy0" Caused by commit db40f15b53e4 ("ARM: dts: rk3228-evb: Enable the integrated PHY for gmac") Its possible that the error is caused by an interaction with another commit, but I could not find anything obvious. I have reverted that commit for today. -- Cheers, Stephen Rothwell
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: net/ipv4/fib_frontend.c: In function 'fib_validate_source': net/ipv4/fib_frontend.c:411:16: error: 'struct netns_ipv4' has no member named 'fib_has_custom_local_routes' if (net->ipv4.fib_has_custom_local_routes) ^ net/ipv4/fib_frontend.c: In function 'inet_rtm_newroute': net/ipv4/fib_frontend.c:773:12: error: 'struct netns_ipv4' has no member named 'fib_has_custom_local_routes' net->ipv4.fib_has_custom_local_routes = true; ^ Caused by commit 6e617de84e87 ("net: avoid a full fib lookup when rp_filter is disabled.") This build has CONFIG_IP_MULTIPLE_TABLES unset. I have reverted that commit for today. -- Cheers, Stephen Rothwell
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 22 Sep 2017 11:03:55 +1000 > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > net/ipv4/fib_frontend.c: In function 'fib_validate_source': > net/ipv4/fib_frontend.c:411:16: error: 'struct netns_ipv4' has no member named 'fib_has_custom_local_routes' > if (net->ipv4.fib_has_custom_local_routes) > ^ > net/ipv4/fib_frontend.c: In function 'inet_rtm_newroute': > net/ipv4/fib_frontend.c:773:12: error: 'struct netns_ipv4' has no member named 'fib_has_custom_local_routes' > net->ipv4.fib_has_custom_local_routes = true; > ^ > > Caused by commit > > 6e617de84e87 ("net: avoid a full fib lookup when rp_filter is disabled.") Paolo, it seems this struct member should be placed outside of IP_MULTIPLE_TABLES protection, since users can insert custom local routes even without that set. So I'm installing the following fix for this: ==================== [PATCH] ipv4: Move fib_has_custom_local_routes outside of IP_MULTIPLE_TABLES. > net/ipv4/fib_frontend.c: In function 'fib_validate_source': > net/ipv4/fib_frontend.c:411:16: error: 'struct netns_ipv4' has no member named 'fib_has_custom_local_routes' > if (net->ipv4.fib_has_custom_local_routes) > ^ > net/ipv4/fib_frontend.c: In function 'inet_rtm_newroute': > net/ipv4/fib_frontend.c:773:12: error: 'struct netns_ipv4' has no member named 'fib_has_custom_local_routes' > net->ipv4.fib_has_custom_local_routes = true; > ^ Fixes: 6e617de84e87 ("net: avoid a full fib lookup when rp_filter is disabled.") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- include/net/netns/ipv4.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h index 20720721da4b..8387f099115e 100644 --- a/include/net/netns/ipv4.h +++ b/include/net/netns/ipv4.h @@ -49,10 +49,10 @@ struct netns_ipv4 { #ifdef CONFIG_IP_MULTIPLE_TABLES struct fib_rules_ops *rules_ops; bool fib_has_custom_rules; - bool fib_has_custom_local_routes; struct fib_table __rcu *fib_main; struct fib_table __rcu *fib_default; #endif + bool fib_has_custom_local_routes; #ifdef CONFIG_IP_ROUTE_CLASSID int fib_num_tclassid_users; #endif -- 2.13.5
On Thu, 2017-09-21 at 18:37 -0700, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 22 Sep 2017 11:03:55 +1000
>
> > After merging the net-next tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > net/ipv4/fib_frontend.c: In function 'fib_validate_source':
> > net/ipv4/fib_frontend.c:411:16: error: 'struct netns_ipv4' has no member named 'fib_has_custom_local_routes'
> > if (net->ipv4.fib_has_custom_local_routes)
> > ^
> > net/ipv4/fib_frontend.c: In function 'inet_rtm_newroute':
> > net/ipv4/fib_frontend.c:773:12: error: 'struct netns_ipv4' has no member named 'fib_has_custom_local_routes'
> > net->ipv4.fib_has_custom_local_routes = true;
> > ^
> >
> > Caused by commit
> >
> > 6e617de84e87 ("net: avoid a full fib lookup when rp_filter is disabled.")
>
> Paolo, it seems this struct member should be placed outside of
> IP_MULTIPLE_TABLES protection, since users can insert custom
> local routes even without that set.
>
> So I'm installing the following fix for this:
>
> ====================
> [PATCH] ipv4: Move fib_has_custom_local_routes outside of IP_MULTIPLE_TABLES.
>
> > net/ipv4/fib_frontend.c: In function 'fib_validate_source':
> > net/ipv4/fib_frontend.c:411:16: error: 'struct netns_ipv4' has no member named 'fib_has_custom_local_routes'
> > if (net->ipv4.fib_has_custom_local_routes)
> > ^
> > net/ipv4/fib_frontend.c: In function 'inet_rtm_newroute':
> > net/ipv4/fib_frontend.c:773:12: error: 'struct netns_ipv4' has no member named 'fib_has_custom_local_routes'
> > net->ipv4.fib_has_custom_local_routes = true;
> > ^
>
> Fixes: 6e617de84e87 ("net: avoid a full fib lookup when rp_filter is disabled.")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> include/net/netns/ipv4.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
> index 20720721da4b..8387f099115e 100644
> --- a/include/net/netns/ipv4.h
> +++ b/include/net/netns/ipv4.h
> @@ -49,10 +49,10 @@ struct netns_ipv4 {
> #ifdef CONFIG_IP_MULTIPLE_TABLES
> struct fib_rules_ops *rules_ops;
> bool fib_has_custom_rules;
> - bool fib_has_custom_local_routes;
> struct fib_table __rcu *fib_main;
> struct fib_table __rcu *fib_default;
> #endif
> + bool fib_has_custom_local_routes;
> #ifdef CONFIG_IP_ROUTE_CLASSID
> int fib_num_tclassid_users;
> #endif
> --
> 2.13.5
My fault, I should have fuzzed the configuration before posting.
Fix looks good, thanks David!
Paolo
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: net/dsa/slave.c: In function 'dsa_slave_create': net/dsa/slave.c:1191:18: error: 'struct dsa_slave_priv' has no member named 'phy' phy_disconnect(p->phy); ^ Caused by commit 0115dcd1787d ("net: dsa: use slave device phydev") Interacting with commit e804441cfe0b ("net: dsa: Fix network device registration order") from the net tree. I applied the following merge fix patch (which I am not sure about): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 29 Sep 2017 11:28:45 +1000 Subject: [PATCH] net: dsa: merge fix patch for removal of phy Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/dsa/slave.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/dsa/slave.c b/net/dsa/slave.c index 8869954485db..9191c929c6c8 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -1188,7 +1188,7 @@ int dsa_slave_create(struct dsa_port *port, const char *name) return 0; out_phy: - phy_disconnect(p->phy); + phy_disconnect(slave_dev->phydev); if (of_phy_is_fixed_link(p->dp->dn)) of_phy_deregister_fixed_link(p->dp->dn); out_free: -- 2.14.1 -- Cheers, Stephen Rothwell
Le 09/28/17 à 18:36, Stephen Rothwell a écrit : > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > net/dsa/slave.c: In function 'dsa_slave_create': > net/dsa/slave.c:1191:18: error: 'struct dsa_slave_priv' has no member named 'phy' > phy_disconnect(p->phy); > ^ > > Caused by commit > > 0115dcd1787d ("net: dsa: use slave device phydev") > > Interacting with commit > > e804441cfe0b ("net: dsa: Fix network device registration order") > > from the net tree. > > I applied the following merge fix patch (which I am not sure about): Your resolution looks fine to me, thanks Stephen! > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri, 29 Sep 2017 11:28:45 +1000 > Subject: [PATCH] net: dsa: merge fix patch for removal of phy > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > net/dsa/slave.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/dsa/slave.c b/net/dsa/slave.c > index 8869954485db..9191c929c6c8 100644 > --- a/net/dsa/slave.c > +++ b/net/dsa/slave.c > @@ -1188,7 +1188,7 @@ int dsa_slave_create(struct dsa_port *port, const char *name) > return 0; > > out_phy: > - phy_disconnect(p->phy); > + phy_disconnect(slave_dev->phydev); > if (of_phy_is_fixed_link(p->dp->dn)) > of_phy_deregister_fixed_link(p->dp->dn); > out_free: > -- Florian
Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/netdevsim/bpf.c: In function 'nsim_bpf_setup_tc_block_cb': drivers/net/netdevsim/bpf.c:127:7: error: 'TC_CLSBPF_REPLACE' undeclared (first use in this function) case TC_CLSBPF_REPLACE: ^ drivers/net/netdevsim/bpf.c:129:7: error: 'TC_CLSBPF_ADD' undeclared (first use in this function) case TC_CLSBPF_ADD: ^ drivers/net/netdevsim/bpf.c:131:7: error: 'TC_CLSBPF_DESTROY' undeclared (first use in this function) case TC_CLSBPF_DESTROY: ^ Caused by commit 31d3ad832948 ("netdevsim: add bpf offload support") interacting with commit 102740bd9436 ("cls_bpf: fix offload assumptions after callback conversion") from the net tree. I applied the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 21 Dec 2017 10:18:46 +1100 Subject: [PATCH] netdevsim: fix up for "cls_bpf: fix offload assumptions after callback conversion" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/netdevsim/bpf.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/net/netdevsim/bpf.c b/drivers/net/netdevsim/bpf.c index 7da814686ad9..afaf980bbbe7 100644 --- a/drivers/net/netdevsim/bpf.c +++ b/drivers/net/netdevsim/bpf.c @@ -123,16 +123,10 @@ int nsim_bpf_setup_tc_block_cb(enum tc_setup_type type, if (prog && !prog->aux->offload && !ns->bpf_tc_non_bound_accept) return -EOPNOTSUPP; - switch (cls_bpf->command) { - case TC_CLSBPF_REPLACE: - return nsim_bpf_offload(ns, prog, true); - case TC_CLSBPF_ADD: - return nsim_bpf_offload(ns, prog, false); - case TC_CLSBPF_DESTROY: - return nsim_bpf_offload(ns, NULL, true); - default: + if (cls_bpf->command != TC_CLSBPF_OFFLOAD) return -EOPNOTSUPP; - } + + return nsim_bpf_offload(ns, prog, cls_bpf->oldprog); } int nsim_bpf_disable_tc(struct netdevsim *ns) -- 2.15.0 -- Cheers, Stephen Rothwell
On Thu, 21 Dec 2017 10:43:04 +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/net/netdevsim/bpf.c: In function 'nsim_bpf_setup_tc_block_cb': > drivers/net/netdevsim/bpf.c:127:7: error: 'TC_CLSBPF_REPLACE' undeclared (first use in this function) > case TC_CLSBPF_REPLACE: > ^ > drivers/net/netdevsim/bpf.c:129:7: error: 'TC_CLSBPF_ADD' undeclared (first use in this function) > case TC_CLSBPF_ADD: > ^ > drivers/net/netdevsim/bpf.c:131:7: error: 'TC_CLSBPF_DESTROY' undeclared (first use in this function) > case TC_CLSBPF_DESTROY: > ^ > > Caused by commit > > 31d3ad832948 ("netdevsim: add bpf offload support") > > interacting with commit > > 102740bd9436 ("cls_bpf: fix offload assumptions after callback conversion") > > from the net tree. > > I applied the following merge fix patch: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Thu, 21 Dec 2017 10:18:46 +1100 > Subject: [PATCH] netdevsim: fix up for "cls_bpf: fix offload assumptions after > callback conversion" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Hi Stephen, sorry about those merges today. The proper fix is queued up in patchwork for when net-next is merged in to net: http://patchwork.ozlabs.org/patch/851063/ I will CC you on patches which may cause/fix merge trouble in the future, often the information about how to resolve the conflict is not part of the commit message. Sorry I didn't think about CCing you earlier!
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: net/ipv6/route.c: In function 'inet6_rtm_getroute': net/ipv6/route.c:4324:25: error: 'struct dst_entry' has no member named 'from' if (fibmatch && rt->dst.from) { ^ In file included from include/linux/uio.h:12:0, from include/linux/socket.h:8, from net/ipv6/route.c:34: net/ipv6/route.c:4325:46: error: 'struct dst_entry' has no member named 'from' struct rt6_info *ort = container_of(rt->dst.from, ^ include/linux/kernel.h:929:26: note: in definition of macro 'container_of' void *__mptr = (void *)(ptr); \ ^ In file included from include/linux/kernel.h:10:0, from include/linux/uio.h:12, from include/linux/socket.h:8, from net/ipv6/route.c:34: net/ipv6/route.c:4325:46: error: 'struct dst_entry' has no member named 'from' struct rt6_info *ort = container_of(rt->dst.from, ^ include/linux/compiler.h:301:19: note: in definition of macro '__compiletime_assert' bool __cond = !(condition); \ ^ include/linux/compiler.h:324:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ include/linux/build_bug.h:47:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^ include/linux/kernel.h:930:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^ include/linux/kernel.h:930:20: note: in expansion of macro '__same_type' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^ net/ipv6/route.c:4325:26: note: in expansion of macro 'container_of' struct rt6_info *ort = container_of(rt->dst.from, ^ net/ipv6/route.c:4325:46: error: 'struct dst_entry' has no member named 'from' struct rt6_info *ort = container_of(rt->dst.from, ^ include/linux/compiler.h:301:19: note: in definition of macro '__compiletime_assert' bool __cond = !(condition); \ ^ include/linux/compiler.h:324:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ include/linux/build_bug.h:47:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^ include/linux/kernel.h:930:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^ include/linux/kernel.h:931:6: note: in expansion of macro '__same_type' !__same_type(*(ptr), void), \ ^ net/ipv6/route.c:4325:26: note: in expansion of macro 'container_of' struct rt6_info *ort = container_of(rt->dst.from, ^ Caused by commit 3a2232e92e87 ("ipv6: Move dst->from into struct rt6_info") interacting with commit 58acfd714e6b ("ipv6: Honor specified parameters in fibmatch lookup" from the net tree. I have added the following merge fix patch for today (I am guessing a bit here): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 22 Dec 2017 11:25:13 +1100 Subject: [PATCH] ipv6: fix up for "ipv6: Move dst->from into struct rt6_info" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/ipv6/route.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 4efaac956f0c..2490280b3394 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -4321,9 +4321,8 @@ static int inet6_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh, goto errout; } - if (fibmatch && rt->dst.from) { - struct rt6_info *ort = container_of(rt->dst.from, - struct rt6_info, dst); + if (fibmatch && rt->from) { + struct rt6_info *ort = rt->from; dst_hold(&ort->dst); ip6_rt_put(rt); -- 2.15.0 -- Cheers, Stephen Rothwell
Hi Stephen, On Fri, Dec 22, 2017 at 11:45:19AM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: [...] > I have added the following merge fix patch for today (I am guessing > a bit here): > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri, 22 Dec 2017 11:25:13 +1100 > Subject: [PATCH] ipv6: fix up for "ipv6: Move dst->from into struct rt6_info" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > net/ipv6/route.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/net/ipv6/route.c b/net/ipv6/route.c > index 4efaac956f0c..2490280b3394 100644 > --- a/net/ipv6/route.c > +++ b/net/ipv6/route.c > @@ -4321,9 +4321,8 @@ static int inet6_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh, > goto errout; > } > > - if (fibmatch && rt->dst.from) { > - struct rt6_info *ort = container_of(rt->dst.from, > - struct rt6_info, dst); > + if (fibmatch && rt->from) { > + struct rt6_info *ort = rt->from; Your merge fix is correct. Thanks! > > dst_hold(&ort->dst); > ip6_rt_put(rt);
Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) failed like this: net/socket.o: In function `tun_xdp_to_ptr': (.text+0x3180): multiple definition of `tun_xdp_to_ptr' fs/compat_ioctl.o:compat_ioctl.c:(.text+0x0): first defined here net/socket.o: In function `tun_ptr_to_xdp': (.text+0x31a0): multiple definition of `tun_ptr_to_xdp' fs/compat_ioctl.o:compat_ioctl.c:(.text+0x20): first defined here Caused by commit fc72d1d54dd9 ("tuntap: XDP transmission") I applied the following fix for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 10 Jan 2018 15:01:41 +1100 Subject: [PATCH] tuntap: fix for "tuntap: XDP transmission" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- include/linux/if_tun.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h index 08e66827ad8e..c5b0a75a7812 100644 --- a/include/linux/if_tun.h +++ b/include/linux/if_tun.h @@ -42,11 +42,11 @@ static inline bool tun_is_xdp_buff(void *ptr) { return false; } -void *tun_xdp_to_ptr(void *ptr) +static inline void *tun_xdp_to_ptr(void *ptr) { return NULL; } -void *tun_ptr_to_xdp(void *ptr) +static inline void *tun_ptr_to_xdp(void *ptr) { return NULL; } -- 2.15.1 -- Cheers, Stephen Rothwell
On 2018年01月10日 12:06, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (sparc64
> defconfig) failed like this:
>
> net/socket.o: In function `tun_xdp_to_ptr':
> (.text+0x3180): multiple definition of `tun_xdp_to_ptr'
> fs/compat_ioctl.o:compat_ioctl.c:(.text+0x0): first defined here
> net/socket.o: In function `tun_ptr_to_xdp':
> (.text+0x31a0): multiple definition of `tun_ptr_to_xdp'
> fs/compat_ioctl.o:compat_ioctl.c:(.text+0x20): first defined here
>
> Caused by commit
>
> fc72d1d54dd9 ("tuntap: XDP transmission")
>
> I applied the following fix for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 10 Jan 2018 15:01:41 +1100
> Subject: [PATCH] tuntap: fix for "tuntap: XDP transmission"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> include/linux/if_tun.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
> index 08e66827ad8e..c5b0a75a7812 100644
> --- a/include/linux/if_tun.h
> +++ b/include/linux/if_tun.h
> @@ -42,11 +42,11 @@ static inline bool tun_is_xdp_buff(void *ptr)
> {
> return false;
> }
> -void *tun_xdp_to_ptr(void *ptr)
> +static inline void *tun_xdp_to_ptr(void *ptr)
> {
> return NULL;
> }
> -void *tun_ptr_to_xdp(void *ptr)
> +static inline void *tun_ptr_to_xdp(void *ptr)
> {
> return NULL;
> }
Acked-by: Jason Wang <jasowang@redhat.com>
David, we need this for net-next, need I repost it?
Thanks
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Jan 2018 15:06:14 +1100
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 10 Jan 2018 15:01:41 +1100
> Subject: [PATCH] tuntap: fix for "tuntap: XDP transmission"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks Stephen.
Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: kernel/bpf/verifier.o: In function `bpf_check': verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args' Caused by commit 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter") interacting with commit 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config") from the bpf and net trees. I have just reverted commit 290af86629b2 for today. A better solution would be nice (lie fixing this in a merge between the net-next and net trees). -- Cheers, Stephen Rothwell
On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> kernel/bpf/verifier.o: In function `bpf_check':
> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
>
> Caused by commit
>
> 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
>
> interacting with commit
>
> 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
>
> from the bpf and net trees.
>
> I have just reverted commit 290af86629b2 for today. A better solution
> would be nice (lie fixing this in a merge between the net-next and net
> trees).
that's due to 'endif' from 290af86629b2 needs to be moved above
bpf_patch_call_args() definition.
There is another fixup needed for net-next.
I'll send a follow up patch when net gets merged into net-next.
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Wed, 10 Jan 2018 17:58:54 -0800
> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the net-next tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> kernel/bpf/verifier.o: In function `bpf_check':
>> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
>>
>> Caused by commit
>>
>> 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
>>
>> interacting with commit
>>
>> 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
>>
>> from the bpf and net trees.
>>
>> I have just reverted commit 290af86629b2 for today. A better solution
>> would be nice (lie fixing this in a merge between the net-next and net
>> trees).
>
> that's due to 'endif' from 290af86629b2 needs to be moved above
> bpf_patch_call_args() definition.
That doesn't fix it, because then you'd need to expose
interpreters_args as well and obviously that can't be right.
Instead, we should never call bpf_patch_call_args() when JIT always on
is enabled. So if we fail to JIT the subprogs we should fail
immediately.
This is the net --> net-next merge resolution I am about to use to fix
this:
...
+static int fixup_call_args(struct bpf_verifier_env *env)
+{
+ struct bpf_prog *prog = env->prog;
+ struct bpf_insn *insn = prog->insnsi;
- int i, depth;
++ int i, depth, err;
+
- if (env->prog->jit_requested)
- if (jit_subprogs(env) == 0)
++ err = 0;
++ if (env->prog->jit_requested) {
++ err = jit_subprogs(env);
++ if (err == 0)
+ return 0;
-
++ }
++#ifndef CONFIG_BPF_JIT_ALWAYS_ON
+ for (i = 0; i < prog->len; i++, insn++) {
+ if (insn->code != (BPF_JMP | BPF_CALL) ||
+ insn->src_reg != BPF_PSEUDO_CALL)
+ continue;
+ depth = get_callee_stack_depth(env, insn, i);
+ if (depth < 0)
+ return depth;
+ bpf_patch_call_args(insn, depth);
+ }
- return 0;
++ err = 0;
++#endif
++ return err;
+}
+
/* fixup insn->imm field of bpf_call instructions
* and inline eligible helpers as explicit sequence of BPF instructions
*
On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote: > From: Alexei Starovoitov <alexei.starovoitov@gmail.com> > Date: Wed, 10 Jan 2018 17:58:54 -0800 > > > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: > >> Hi all, > >> > >> After merging the net-next tree, today's linux-next build (x86_64 > >> allmodconfig) failed like this: > >> > >> kernel/bpf/verifier.o: In function `bpf_check': > >> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args' > >> > >> Caused by commit > >> > >> 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter") > >> > >> interacting with commit > >> > >> 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config") > >> > >> from the bpf and net trees. > >> > >> I have just reverted commit 290af86629b2 for today. A better solution > >> would be nice (lie fixing this in a merge between the net-next and net > >> trees). > > > > that's due to 'endif' from 290af86629b2 needs to be moved above > > bpf_patch_call_args() definition. > > That doesn't fix it, because then you'd need to expose > interpreters_args as well and obviously that can't be right. > > Instead, we should never call bpf_patch_call_args() when JIT always on > is enabled. So if we fail to JIT the subprogs we should fail > immediately. right, as I was trying to say one extra hunk would be needed for net-next. I was reading this patch: diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index a2b211262c25..ca80559c4ec3 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env *env) depth = get_callee_stack_depth(env, insn, i); if (depth < 0) return depth; +#ifdef CONFIG_BPF_JIT_ALWAYS_ON + return -ENOTSUPP; +#else bpf_patch_call_args(insn, depth); +#endif } return 0; but below should be fine too. Will test it asap. > This is the net --> net-next merge resolution I am about to use to fix > this: > > ... > +static int fixup_call_args(struct bpf_verifier_env *env) > +{ > + struct bpf_prog *prog = env->prog; > + struct bpf_insn *insn = prog->insnsi; > - int i, depth; > ++ int i, depth, err; > + > - if (env->prog->jit_requested) > - if (jit_subprogs(env) == 0) > ++ err = 0; > ++ if (env->prog->jit_requested) { > ++ err = jit_subprogs(env); > ++ if (err == 0) > + return 0; > - > ++ } > ++#ifndef CONFIG_BPF_JIT_ALWAYS_ON > + for (i = 0; i < prog->len; i++, insn++) { > + if (insn->code != (BPF_JMP | BPF_CALL) || > + insn->src_reg != BPF_PSEUDO_CALL) > + continue; > + depth = get_callee_stack_depth(env, insn, i); > + if (depth < 0) > + return depth; > + bpf_patch_call_args(insn, depth); > + } > - return 0; > ++ err = 0; > ++#endif > ++ return err; > +} > + > /* fixup insn->imm field of bpf_call instructions > * and inline eligible helpers as explicit sequence of BPF instructions > *
On 01/12/2018 05:21 AM, Alexei Starovoitov wrote: > On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote: >> From: Alexei Starovoitov <alexei.starovoitov@gmail.com> >> Date: Wed, 10 Jan 2018 17:58:54 -0800 >> >>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: >>>> Hi all, >>>> >>>> After merging the net-next tree, today's linux-next build (x86_64 >>>> allmodconfig) failed like this: >>>> >>>> kernel/bpf/verifier.o: In function `bpf_check': >>>> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args' >>>> >>>> Caused by commit >>>> >>>> 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter") >>>> >>>> interacting with commit >>>> >>>> 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config") >>>> >>>> from the bpf and net trees. >>>> >>>> I have just reverted commit 290af86629b2 for today. A better solution >>>> would be nice (lie fixing this in a merge between the net-next and net >>>> trees). >>> >>> that's due to 'endif' from 290af86629b2 needs to be moved above >>> bpf_patch_call_args() definition. >> >> That doesn't fix it, because then you'd need to expose >> interpreters_args as well and obviously that can't be right. >> >> Instead, we should never call bpf_patch_call_args() when JIT always on >> is enabled. So if we fail to JIT the subprogs we should fail >> immediately. > > right, as I was trying to say one extra hunk would be needed for net-next. > I was reading this patch: > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index a2b211262c25..ca80559c4ec3 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env *env) > depth = get_callee_stack_depth(env, insn, i); > if (depth < 0) > return depth; > +#ifdef CONFIG_BPF_JIT_ALWAYS_ON > + return -ENOTSUPP; > +#else > bpf_patch_call_args(insn, depth); > +#endif > } > return 0; > > but below should be fine too. > Will test it asap. > >> This is the net --> net-next merge resolution I am about to use to fix >> this: >> >> ... >> +static int fixup_call_args(struct bpf_verifier_env *env) >> +{ >> + struct bpf_prog *prog = env->prog; >> + struct bpf_insn *insn = prog->insnsi; >> - int i, depth; >> ++ int i, depth, err; >> + >> - if (env->prog->jit_requested) >> - if (jit_subprogs(env) == 0) >> ++ err = 0; Looks fine to me. The only thing I was wondering was whether we should set err = -ENOTSUPP here above, but actually that is unnecessary. Say, if for some reason we would missed to set prog->jit_requested bit under CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have calls in the prog. But that also means for bpf_prog_load() that right after bpf_check() returned, we would go into bpf_prog_select_runtime() since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile() from there wouldn't do anything either since prog->jit_requested was not set in the first place, therefore we return with -ENOTSUPP from there. So the resolution looks fine to me, we can leave it as is. >> ++ if (env->prog->jit_requested) { >> ++ err = jit_subprogs(env); >> ++ if (err == 0) >> + return 0; >> - >> ++ } >> ++#ifndef CONFIG_BPF_JIT_ALWAYS_ON >> + for (i = 0; i < prog->len; i++, insn++) { >> + if (insn->code != (BPF_JMP | BPF_CALL) || >> + insn->src_reg != BPF_PSEUDO_CALL) >> + continue; >> + depth = get_callee_stack_depth(env, insn, i); >> + if (depth < 0) >> + return depth; >> + bpf_patch_call_args(insn, depth); >> + } >> - return 0; >> ++ err = 0; >> ++#endif >> ++ return err; >> +} >> + >> /* fixup insn->imm field of bpf_call instructions >> * and inline eligible helpers as explicit sequence of BPF instructions >> *
On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote:
> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
> > On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
> >> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> >> Date: Wed, 10 Jan 2018 17:58:54 -0800
> >>
> >>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
> >>>> Hi all,
> >>>>
> >>>> After merging the net-next tree, today's linux-next build (x86_64
> >>>> allmodconfig) failed like this:
> >>>>
> >>>> kernel/bpf/verifier.o: In function `bpf_check':
> >>>> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
> >>>>
> >>>> Caused by commit
> >>>>
> >>>> 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
> >>>>
> >>>> interacting with commit
> >>>>
> >>>> 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
> >>>>
> >>>> from the bpf and net trees.
> >>>>
> >>>> I have just reverted commit 290af86629b2 for today. A better solution
> >>>> would be nice (lie fixing this in a merge between the net-next and net
> >>>> trees).
> >>>
> >>> that's due to 'endif' from 290af86629b2 needs to be moved above
> >>> bpf_patch_call_args() definition.
> >>
> >> That doesn't fix it, because then you'd need to expose
> >> interpreters_args as well and obviously that can't be right.
> >>
> >> Instead, we should never call bpf_patch_call_args() when JIT always on
> >> is enabled. So if we fail to JIT the subprogs we should fail
> >> immediately.
> >
> > right, as I was trying to say one extra hunk would be needed for net-next.
> > I was reading this patch:
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index a2b211262c25..ca80559c4ec3 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env *env)
> > depth = get_callee_stack_depth(env, insn, i);
> > if (depth < 0)
> > return depth;
> > +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
> > + return -ENOTSUPP;
> > +#else
> > bpf_patch_call_args(insn, depth);
> > +#endif
> > }
> > return 0;
> >
> > but below should be fine too.
> > Will test it asap.
> >
> >> This is the net --> net-next merge resolution I am about to use to fix
> >> this:
> >>
> >> ...
> >> +static int fixup_call_args(struct bpf_verifier_env *env)
> >> +{
> >> + struct bpf_prog *prog = env->prog;
> >> + struct bpf_insn *insn = prog->insnsi;
> >> - int i, depth;
> >> ++ int i, depth, err;
> >> +
> >> - if (env->prog->jit_requested)
> >> - if (jit_subprogs(env) == 0)
> >> ++ err = 0;
>
> Looks fine to me. The only thing I was wondering was whether we should
> set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
> if for some reason we would missed to set prog->jit_requested bit under
> CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
> calls in the prog. But that also means for bpf_prog_load() that right
> after bpf_check() returned, we would go into bpf_prog_select_runtime()
> since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
> from there wouldn't do anything either since prog->jit_requested was
> not set in the first place, therefore we return with -ENOTSUPP from
> there. So the resolution looks fine to me, we can leave it as is.
jit_subprogs() can fail, so err = -ENOTSUPP is necessary.
On 01/12/2018 04:56 PM, Alexei Starovoitov wrote:
> On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote:
>> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
>>> On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
>>>> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>>>> Date: Wed, 10 Jan 2018 17:58:54 -0800
>>>>
>>>>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> After merging the net-next tree, today's linux-next build (x86_64
>>>>>> allmodconfig) failed like this:
>>>>>>
>>>>>> kernel/bpf/verifier.o: In function `bpf_check':
>>>>>> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
>>>>>>
>>>>>> Caused by commit
>>>>>>
>>>>>> 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
>>>>>>
>>>>>> interacting with commit
>>>>>>
>>>>>> 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
>>>>>>
>>>>>> from the bpf and net trees.
>>>>>>
>>>>>> I have just reverted commit 290af86629b2 for today. A better solution
>>>>>> would be nice (lie fixing this in a merge between the net-next and net
>>>>>> trees).
>>>>>
>>>>> that's due to 'endif' from 290af86629b2 needs to be moved above
>>>>> bpf_patch_call_args() definition.
>>>>
>>>> That doesn't fix it, because then you'd need to expose
>>>> interpreters_args as well and obviously that can't be right.
>>>>
>>>> Instead, we should never call bpf_patch_call_args() when JIT always on
>>>> is enabled. So if we fail to JIT the subprogs we should fail
>>>> immediately.
>>>
>>> right, as I was trying to say one extra hunk would be needed for net-next.
>>> I was reading this patch:
>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>> index a2b211262c25..ca80559c4ec3 100644
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>>> @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env *env)
>>> depth = get_callee_stack_depth(env, insn, i);
>>> if (depth < 0)
>>> return depth;
>>> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
>>> + return -ENOTSUPP;
>>> +#else
>>> bpf_patch_call_args(insn, depth);
>>> +#endif
>>> }
>>> return 0;
>>>
>>> but below should be fine too.
>>> Will test it asap.
>>>
>>>> This is the net --> net-next merge resolution I am about to use to fix
>>>> this:
>>>>
>>>> ...
>>>> +static int fixup_call_args(struct bpf_verifier_env *env)
>>>> +{
>>>> + struct bpf_prog *prog = env->prog;
>>>> + struct bpf_insn *insn = prog->insnsi;
>>>> - int i, depth;
>>>> ++ int i, depth, err;
>>>> +
>>>> - if (env->prog->jit_requested)
>>>> - if (jit_subprogs(env) == 0)
>>>> ++ err = 0;
>>
>> Looks fine to me. The only thing I was wondering was whether we should
>> set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
>> if for some reason we would missed to set prog->jit_requested bit under
>> CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
>> calls in the prog. But that also means for bpf_prog_load() that right
>> after bpf_check() returned, we would go into bpf_prog_select_runtime()
>> since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
>> from there wouldn't do anything either since prog->jit_requested was
>> not set in the first place, therefore we return with -ENOTSUPP from
>> there. So the resolution looks fine to me, we can leave it as is.
>
> jit_subprogs() can fail, so err = -ENOTSUPP is necessary.
But if jit_subprogs() fails, then the err is propagated at the end of
the function (the 'return err' I mean).
On Fri, Jan 12, 2018 at 05:21:54PM +0100, Daniel Borkmann wrote:
> On 01/12/2018 04:56 PM, Alexei Starovoitov wrote:
> > On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote:
> >> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
> >>> On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
> >>>> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> >>>> Date: Wed, 10 Jan 2018 17:58:54 -0800
> >>>>
> >>>>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> After merging the net-next tree, today's linux-next build (x86_64
> >>>>>> allmodconfig) failed like this:
> >>>>>>
> >>>>>> kernel/bpf/verifier.o: In function `bpf_check':
> >>>>>> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
> >>>>>>
> >>>>>> Caused by commit
> >>>>>>
> >>>>>> 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
> >>>>>>
> >>>>>> interacting with commit
> >>>>>>
> >>>>>> 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
> >>>>>>
> >>>>>> from the bpf and net trees.
> >>>>>>
> >>>>>> I have just reverted commit 290af86629b2 for today. A better solution
> >>>>>> would be nice (lie fixing this in a merge between the net-next and net
> >>>>>> trees).
> >>>>>
> >>>>> that's due to 'endif' from 290af86629b2 needs to be moved above
> >>>>> bpf_patch_call_args() definition.
> >>>>
> >>>> That doesn't fix it, because then you'd need to expose
> >>>> interpreters_args as well and obviously that can't be right.
> >>>>
> >>>> Instead, we should never call bpf_patch_call_args() when JIT always on
> >>>> is enabled. So if we fail to JIT the subprogs we should fail
> >>>> immediately.
> >>>
> >>> right, as I was trying to say one extra hunk would be needed for net-next.
> >>> I was reading this patch:
> >>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> >>> index a2b211262c25..ca80559c4ec3 100644
> >>> --- a/kernel/bpf/verifier.c
> >>> +++ b/kernel/bpf/verifier.c
> >>> @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env *env)
> >>> depth = get_callee_stack_depth(env, insn, i);
> >>> if (depth < 0)
> >>> return depth;
> >>> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
> >>> + return -ENOTSUPP;
> >>> +#else
> >>> bpf_patch_call_args(insn, depth);
> >>> +#endif
> >>> }
> >>> return 0;
> >>>
> >>> but below should be fine too.
> >>> Will test it asap.
> >>>
> >>>> This is the net --> net-next merge resolution I am about to use to fix
> >>>> this:
> >>>>
> >>>> ...
> >>>> +static int fixup_call_args(struct bpf_verifier_env *env)
> >>>> +{
> >>>> + struct bpf_prog *prog = env->prog;
> >>>> + struct bpf_insn *insn = prog->insnsi;
> >>>> - int i, depth;
> >>>> ++ int i, depth, err;
> >>>> +
> >>>> - if (env->prog->jit_requested)
> >>>> - if (jit_subprogs(env) == 0)
> >>>> ++ err = 0;
> >>
> >> Looks fine to me. The only thing I was wondering was whether we should
> >> set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
> >> if for some reason we would missed to set prog->jit_requested bit under
> >> CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
> >> calls in the prog. But that also means for bpf_prog_load() that right
> >> after bpf_check() returned, we would go into bpf_prog_select_runtime()
> >> since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
> >> from there wouldn't do anything either since prog->jit_requested was
> >> not set in the first place, therefore we return with -ENOTSUPP from
> >> there. So the resolution looks fine to me, we can leave it as is.
> >
> > jit_subprogs() can fail, so err = -ENOTSUPP is necessary.
>
> But if jit_subprogs() fails, then the err is propagated at the end of
> the function (the 'return err' I mean).
right.
Also, since we do:
fp->jit_requested = ebpf_jit_enabled();
and
static inline bool ebpf_jit_enabled(void)
{
return bpf_jit_enable && bpf_jit_is_ebpf();
}
and JIT_ALWAYS_ON depends on CONFIG_HAVE_EBPF_JIT
we should be good.
Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from /home/sfr/next/next/include/linux/init_task.h:17:0, from /home/sfr/next/next/init/init_task.c:2: /home/sfr/next/next/include/net/net_namespace.h: In function 'check_net': /home/sfr/next/next/include/net/net_namespace.h:228:21: error: passing argument 1 of 'atomic_read' from incompatible pointer type [-Werror=incompatible-pointer-types] return atomic_read(&net->count) != 0; ^ In file included from /home/sfr/next/next/include/linux/atomic.h:5:0, from /home/sfr/next/next/include/linux/rcupdate.h:38, from /home/sfr/next/next/include/linux/init_task.h:5, from /home/sfr/next/next/init/init_task.c:2: /home/sfr/next/next/arch/powerpc/include/asm/atomic.h:34:23: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'const refcount_t * {aka const struct refcount_struct *}' static __inline__ int atomic_read(const atomic_t *v) ^~~~~~~~~~~ and several others similar. Caused by commit 273c28bc57ca ("net: Convert atomic_t net::count to refcount_t") interacting with commit 4ee806d51176 ("net: tcp: close sock if net namespace is exiting") from the net tree. I have applied the following merge fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 29 Jan 2018 12:34:37 +1100 Subject: [PATCH] net: fixup for "net: tcp: close sock if net namespace is exiting" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- include/net/net_namespace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h index 235105afa5e1..f306b2aa15a4 100644 --- a/include/net/net_namespace.h +++ b/include/net/net_namespace.h @@ -225,7 +225,7 @@ int net_eq(const struct net *net1, const struct net *net2) static inline int check_net(const struct net *net) { - return atomic_read(&net->count) != 0; + return refcount_read(&net->count) != 0; } void net_drop_ns(void *); -- 2.15.1 -- Cheers, Stephen Rothwell
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Jan 2018 12:50:28 +1100
> I have applied the following merge fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 29 Jan 2018 12:34:37 +1100
> Subject: [PATCH] net: fixup for "net: tcp: close sock if net namespace is exiting"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> include/net/net_namespace.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index 235105afa5e1..f306b2aa15a4 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -225,7 +225,7 @@ int net_eq(const struct net *net1, const struct net *net2)
>
> static inline int check_net(const struct net *net)
> {
> - return atomic_read(&net->count) != 0;
> + return refcount_read(&net->count) != 0;
> }
>
> void net_drop_ns(void *);
Yep, this is perfect.
[-- Attachment #1: Type: text/plain, Size: 2321 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/core/devlink.c: In function 'devlink_resource_validate_size': net/core/devlink.c:2349:34: error: invalid type argument of '->' (have 'struct devlink_resource_size_params') if (size > resource->size_params->size_max) { ^~ net/core/devlink.c:2354:34: error: invalid type argument of '->' (have 'struct devlink_resource_size_params') if (size < resource->size_params->size_min) { ^~ net/core/devlink.c:2359:43: error: invalid type argument of '->' (have 'struct devlink_resource_size_params') div64_u64_rem(size, resource->size_params->size_granularity, &reminder); ^~ Caused by commit cc944ead839a ("devlink: Move size validation to core") interacting with commit 77d270967c5f ("mlxsw: spectrum: Fix handling of resource_size_param") from the net tree. I have applied the following merge fix patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 1 Mar 2018 10:24:31 +1100 Subject: [PATCH] devlink: merge fix up for resource_size_param changes Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/core/devlink.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/core/devlink.c b/net/core/devlink.c index e7cb957d9efb..1b5bf0d1cee9 100644 --- a/net/core/devlink.c +++ b/net/core/devlink.c @@ -2346,17 +2346,17 @@ devlink_resource_validate_size(struct devlink_resource *resource, u64 size, u64 reminder; int err = 0; - if (size > resource->size_params->size_max) { + if (size > resource->size_params.size_max) { NL_SET_ERR_MSG_MOD(extack, "Size larger than maximum"); err = -EINVAL; } - if (size < resource->size_params->size_min) { + if (size < resource->size_params.size_min) { NL_SET_ERR_MSG_MOD(extack, "Size smaller than minimum"); err = -EINVAL; } - div64_u64_rem(size, resource->size_params->size_granularity, &reminder); + div64_u64_rem(size, resource->size_params.size_granularity, &reminder); if (reminder) { NL_SET_ERR_MSG_MOD(extack, "Wrong granularity"); err = -EINVAL; -- 2.16.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 592 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: x86_64-linux-ld: unknown architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with i386:x86-64 output Caused by commit d2ba09c17a06 ("net: add skeleton of bpfilter kernel module") In my builds, the host is PowerPC 64 LE ... I have reverted that commit along with 61a552eb487f ("bpfilter: fix build dependency") 13405468f49d ("bpfilter: don't pass O_CREAT when opening console for debug") for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2149 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/xdp/xsk.c: In function 'xsk_poll': net/xdp/xsk.c:207:22: error: implicit declaration of function 'datagram_poll'; did you mean 'datagram_poll_mask'? [-Werror=implicit-function-declaration] unsigned int mask = datagram_poll(file, sock, wait); ^~~~~~~~~~~~~ datagram_poll_mask Caused by commit c497176cb2e4 ("xsk: add Rx receive functions and poll support") interacting with commit db5051ead64a ("net: convert datagram_poll users tp ->poll_mask") from the vfs tree. [Christoph, I noticed that the comment above datagram_poll in net/core/datagram.c needs the function name updated] I have added the following merge fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 29 May 2018 13:34:25 +1000 Subject: [PATCH] xsk: update for "net: convert datagram_poll users tp->poll_mask" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/xdp/xsk.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c index cce0e4f8a536..4ee140afbc61 100644 --- a/net/xdp/xsk.c +++ b/net/xdp/xsk.c @@ -201,10 +201,9 @@ static int xsk_sendmsg(struct socket *sock, struct msghdr *m, size_t total_len) return xsk_generic_xmit(sk, m, total_len); } -static unsigned int xsk_poll(struct file *file, struct socket *sock, - struct poll_table_struct *wait) +static __poll_t xsk_poll_mask(struct socket *sock, __poll_t events) { - unsigned int mask = datagram_poll(file, sock, wait); + __poll_t mask = datagram_poll_mask(sock, events); struct sock *sk = sock->sk; struct xdp_sock *xs = xdp_sk(sk); @@ -580,7 +579,7 @@ static const struct proto_ops xsk_proto_ops = { .socketpair = sock_no_socketpair, .accept = sock_no_accept, .getname = sock_no_getname, - .poll = xsk_poll, + .poll_mask = xsk_poll_mask, .ioctl = sock_no_ioctl, .listen = sock_no_listen, .shutdown = sock_no_shutdown, -- 2.17.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
> [Christoph, I noticed that the comment above datagram_poll in > net/core/datagram.c needs the function name updated] I'll send a fix for that. > > I have added the following merge fix patch for today: This looks correct, thanks!
[-- Attachment #1: Type: text/plain, Size: 781 bytes --] Hi all, On Tue, 29 May 2018 13:25:48 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > x86_64-linux-ld: unknown architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with i386:x86-64 output > > Caused by commit > > d2ba09c17a06 ("net: add skeleton of bpfilter kernel module") > > In my builds, the host is PowerPC 64 LE ... > > I have reverted that commit along with > > 61a552eb487f ("bpfilter: fix build dependency") > 13405468f49d ("bpfilter: don't pass O_CREAT when opening console for debug") > > for today. I am still getting this failure (well, at least yesterday I did). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1995 bytes --] Hi all, On Thu, 31 May 2018 07:38:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Tue, 29 May 2018 13:25:48 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > After merging the net-next tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > x86_64-linux-ld: unknown architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with i386:x86-64 output > > > > Caused by commit > > > > d2ba09c17a06 ("net: add skeleton of bpfilter kernel module") > > > > In my builds, the host is PowerPC 64 LE ... > > > > I have reverted that commit along with > > > > 61a552eb487f ("bpfilter: fix build dependency") > > 13405468f49d ("bpfilter: don't pass O_CREAT when opening console for debug") > > > > for today. > > I am still getting this failure (well, at least yesterday I did). Still happened today. My guess is that bpfilter_umh needs to be built with the kernel compiler (not the host compiler - since ir is meant to run on the some machine as the kernel, right?) but will require the kernel architecture libc etc I replaced the reverts above with the following: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 1 Jun 2018 13:33:28 +1000 Subject: [PATCH] net: bpfilter: mark as BROKEN for now This does not build in a cross compile environment Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/bpfilter/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/net/bpfilter/Kconfig b/net/bpfilter/Kconfig index a948b072c28f..ea4be72fdf6e 100644 --- a/net/bpfilter/Kconfig +++ b/net/bpfilter/Kconfig @@ -2,6 +2,7 @@ menuconfig BPFILTER bool "BPF based packet filtering framework (BPFILTER)" default n depends on NET && BPF && INET + depends on BROKEN help This builds experimental bpfilter framework that is aiming to provide netfilter compatible functionality via BPF -- 2.17.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, Jun 01, 2018 at 01:59:43PM +1000, Stephen Rothwell wrote: > Hi all, > > On Thu, 31 May 2018 07:38:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Tue, 29 May 2018 13:25:48 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > After merging the net-next tree, today's linux-next build (x86_64 > > > allmodconfig) failed like this: > > > > > > x86_64-linux-ld: unknown architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with i386:x86-64 output > > > > > > Caused by commit > > > > > > d2ba09c17a06 ("net: add skeleton of bpfilter kernel module") > > > > > > In my builds, the host is PowerPC 64 LE ... > > > > > > I have reverted that commit along with > > > > > > 61a552eb487f ("bpfilter: fix build dependency") > > > 13405468f49d ("bpfilter: don't pass O_CREAT when opening console for debug") > > > > > > for today. > > > > I am still getting this failure (well, at least yesterday I did). > > Still happened today. My guess is that bpfilter_umh needs to be built > with the kernel compiler (not the host compiler - since ir is meant to > run on the some machine as the kernel, right?) but will require the > kernel architecture libc etc > > > I replaced the reverts above with the following: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri, 1 Jun 2018 13:33:28 +1000 > Subject: [PATCH] net: bpfilter: mark as BROKEN for now > > This does not build in a cross compile environment > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > net/bpfilter/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/bpfilter/Kconfig b/net/bpfilter/Kconfig > index a948b072c28f..ea4be72fdf6e 100644 > --- a/net/bpfilter/Kconfig > +++ b/net/bpfilter/Kconfig > @@ -2,6 +2,7 @@ menuconfig BPFILTER > bool "BPF based packet filtering framework (BPFILTER)" > default n > depends on NET && BPF && INET > + depends on BROKEN yeah. that's another option. Sorry for delay. networking folks are traveling to netconf. The issue is being discussed here: https://patchwork.ozlabs.org/patch/921597/ Currently we're thinking how to add a check that hostcc's arch is equal to cross-cc target arch and ideally equal to arch of the host where it will be run.
[-- Attachment #1: Type: text/plain, Size: 2108 bytes --] Hi all, On Fri, 1 Jun 2018 04:52:45 -0400 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > On Fri, Jun 01, 2018 at 01:59:43PM +1000, Stephen Rothwell wrote: > > > > On Thu, 31 May 2018 07:38:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > On Tue, 29 May 2018 13:25:48 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > > > After merging the net-next tree, today's linux-next build (x86_64 > > > > allmodconfig) failed like this: > > > > > > > > x86_64-linux-ld: unknown architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with i386:x86-64 output > > > > > > > > Caused by commit > > > > > > > > d2ba09c17a06 ("net: add skeleton of bpfilter kernel module") > > > > > > > > In my builds, the host is PowerPC 64 LE ... > > > > > > > > I have reverted that commit along with > > > > > > > > 61a552eb487f ("bpfilter: fix build dependency") > > > > 13405468f49d ("bpfilter: don't pass O_CREAT when opening console for debug") > > > > > > > > for today. > > > > > > I am still getting this failure (well, at least yesterday I did). > > > > Still happened today. My guess is that bpfilter_umh needs to be built > > with the kernel compiler (not the host compiler - since ir is meant to > > run on the some machine as the kernel, right?) but will require the > > kernel architecture libc etc > > Sorry for delay. networking folks are traveling to netconf. > The issue is being discussed here: > https://patchwork.ozlabs.org/patch/921597/ > > Currently we're thinking how to add a check that hostcc's arch > is equal to cross-cc target arch and ideally equal to arch > of the host where it will be run. Looks like this is fixed in today's tree by not building bpfilter when CC cannot link against user libraries. Unfortunately this means that it will never be built by my infrastructure (since all my compilers are minimal cross compilers) :-( I may look into getting a different set of compilers (or doing my PowerPC builds natively). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2971 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/ipv4/fou.c: In function 'gue_gro_receive': net/ipv4/fou.c:451:35: error: passing argument 2 of 'skb_gro_flush_final_remcsum' from incompatible pointer type [-Werror=incompatible-pointer-types] skb_gro_flush_final_remcsum(skb, pp, flush, &grc); ^~ In file included from include/net/inet_sock.h:23:0, from include/linux/udp.h:20, from net/ipv4/fou.c:6: include/linux/netdevice.h:2799:20: note: expected 'struct sk_buff **' but argument is of type 'struct sk_buff *' static inline void skb_gro_flush_final_remcsum(struct sk_buff *skb, ^~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/vxlan.c: In function 'vxlan_gro_receive': drivers/net/vxlan.c:627:35: error: passing argument 2 of 'skb_gro_flush_final_remcsum' from incompatible pointer type [-Werror=incompatible-pointer-types] skb_gro_flush_final_remcsum(skb, pp, flush, &grc); ^~ In file included from include/net/inet_sock.h:23:0, from include/linux/udp.h:20, from drivers/net/vxlan.c:17: include/linux/netdevice.h:2799:20: note: expected 'struct sk_buff **' but argument is of type 'struct sk_buff *' static inline void skb_gro_flush_final_remcsum(struct sk_buff *skb, ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Caused by commit d4546c2509b1 ("net: Convert GRO SKB handling to list_head.") from the net-next tree interacting with commit 603d4cf8fe09 ("net: fix use-after-free in GRO with ESP") from Linus' tree. I took a guess and aplied the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 3 Jul 2018 10:37:05 +1000 Subject: [PATCH] net: update for conversion of GRO SKB handling Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- include/linux/netdevice.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index e1d4084c0651..64480a0f2c16 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -2797,7 +2797,7 @@ static inline void skb_gro_flush_final(struct sk_buff *skb, struct sk_buff *pp, NAPI_GRO_CB(skb)->flush |= flush; } static inline void skb_gro_flush_final_remcsum(struct sk_buff *skb, - struct sk_buff **pp, + struct sk_buff *pp, int flush, struct gro_remcsum *grc) { @@ -2813,7 +2813,7 @@ static inline void skb_gro_flush_final(struct sk_buff *skb, struct sk_buff *pp, NAPI_GRO_CB(skb)->flush |= flush; } static inline void skb_gro_flush_final_remcsum(struct sk_buff *skb, - struct sk_buff **pp, + struct sk_buff *pp, int flush, struct gro_remcsum *grc) { -- 2.17.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
2018-07-03, 10:47:12 +1000, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > [...] > I took a guess and aplied the following merge fix patch: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 3 Jul 2018 10:37:05 +1000 > Subject: [PATCH] net: update for conversion of GRO SKB handling > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Thanks Stephen, this looks correct. -- Sabrina
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) failed like this: hns_roce_hw_v1.c:(.text.hns_roce_v1_reset+0x8c): undefined reference to `.hns_dsaf_roce_reset' hns_roce_hw_v1.c:(.text.hns_roce_v1_reset+0xdc): undefined reference to `.hns_dsaf_roce_reset' Caused by commit 336a443bd9dd ("net: hns: Make many functions static") I have applied the following patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 27 Jul 2018 20:23:20 +1000 Subject: [PATCH] net: hns: make hns_dsaf_roce_reset() not static This function is declared in a header file and used in a different source file. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c index 7afc67510569..619e6ce465c2 100644 --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c @@ -2836,7 +2836,7 @@ module_platform_driver(g_dsaf_driver); * @enable: false - request reset , true - drop reset * retuen 0 - success , negative -fail */ -static int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset) +int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset) { struct dsaf_device *dsaf_dev; struct platform_device *pdev; -- 2.18.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 2018/7/27 18:32, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > hns_roce_hw_v1.c:(.text.hns_roce_v1_reset+0x8c): undefined reference to `.hns_dsaf_roce_reset' > hns_roce_hw_v1.c:(.text.hns_roce_v1_reset+0xdc): undefined reference to `.hns_dsaf_roce_reset' > > Caused by commit > > 336a443bd9dd ("net: hns: Make many functions static") Sorry,I forgot do a allyesconfig. And I have post a fix patch, Dvaid applied it: [PATCH net-next] net: hns: make hns_dsaf_roce_reset non static https://lkml.org/lkml/2018/7/26/939 > > I have applied the following patch for today. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri, 27 Jul 2018 20:23:20 +1000 > Subject: [PATCH] net: hns: make hns_dsaf_roce_reset() not static > > This function is declared in a header file and used in a different > source file. > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c > index 7afc67510569..619e6ce465c2 100644 > --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c > +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c > @@ -2836,7 +2836,7 @@ module_platform_driver(g_dsaf_driver); > * @enable: false - request reset , true - drop reset > * retuen 0 - success , negative -fail > */ > -static int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset) > +int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset) > { > struct dsaf_device *dsaf_dev; > struct platform_device *pdev; >
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --] Hi all, After merging the net-next tree, today's linux-next build (perf) failed like this: In file included from btf.c:10:0: btf.h:25:24: error: redundant redeclaration of 'btf__type_by_id' [-Werror=redundant-decls] const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 type_id); ^~~~~~~~~~~~~~~ btf.h:20:24: note: previous declaration of 'btf__type_by_id' was here const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 id); ^~~~~~~~~~~~~~~ btf.c:405:24: error: redefinition of 'btf__type_by_id' const struct btf_type *btf__type_by_id(const struct btf *btf, ^~~~~~~~~~~~~~~ btf.c:197:24: note: previous definition of 'btf__type_by_id' was here const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 type_id) ^~~~~~~~~~~~~~~ btf.c:40:20: error: 'btf_name_by_offset' defined but not used [-Werror=unused-function] static const char *btf_name_by_offset(const struct btf *btf, __u32 offset) ^~~~~~~~~~~~~~~~~~ mv: cannot stat 'perf/.libbpf.o.tmp': No such file or directory tools/build/Makefile.build:96: recipe for target 'perf/libbpf.o' failed In file included from libbpf.c:52:0: btf.h:25:24: error: redundant redeclaration of 'btf__type_by_id' [-Werror=redundant-decls] const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 type_id); ^~~~~~~~~~~~~~~ btf.h:20:24: note: previous declaration of 'btf__type_by_id' was here const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 id); ^~~~~~~~~~~~~~~ mv: cannot stat 'perf/.libbpf.o.tmp': No such file or directory tools/build/Makefile.build:96: recipe for target 'perf/libbpf.o' failed Caused by commit 89b1698c93a9 ("Merge ra.kernel.org:/pub/scm/linux/kernel/git/davem/net") Some of the lines in tools/lib/bpf/btf.[ch] were duplicated (they existed on both sides of the merge). I have used the net-next tree from next-20180802 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, 3 Aug 2018 12:14:30 +1000, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (perf) failed > like this: > > In file included from btf.c:10:0: > btf.h:25:24: error: redundant redeclaration of 'btf__type_by_id' [-Werror=redundant-decls] > const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 type_id); > ^~~~~~~~~~~~~~~ > btf.h:20:24: note: previous declaration of 'btf__type_by_id' was here > const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 id); > ^~~~~~~~~~~~~~~ > btf.c:405:24: error: redefinition of 'btf__type_by_id' > const struct btf_type *btf__type_by_id(const struct btf *btf, > ^~~~~~~~~~~~~~~ > btf.c:197:24: note: previous definition of 'btf__type_by_id' was here > const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 type_id) > ^~~~~~~~~~~~~~~ > btf.c:40:20: error: 'btf_name_by_offset' defined but not used [-Werror=unused-function] > static const char *btf_name_by_offset(const struct btf *btf, __u32 offset) > ^~~~~~~~~~~~~~~~~~ > mv: cannot stat 'perf/.libbpf.o.tmp': No such file or directory > tools/build/Makefile.build:96: recipe for target 'perf/libbpf.o' failed > In file included from libbpf.c:52:0: > btf.h:25:24: error: redundant redeclaration of 'btf__type_by_id' [-Werror=redundant-decls] > const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 type_id); > ^~~~~~~~~~~~~~~ > btf.h:20:24: note: previous declaration of 'btf__type_by_id' was here > const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 id); > ^~~~~~~~~~~~~~~ > mv: cannot stat 'perf/.libbpf.o.tmp': No such file or directory > tools/build/Makefile.build:96: recipe for target 'perf/libbpf.o' failed > > Caused by commit > > 89b1698c93a9 ("Merge ra.kernel.org:/pub/scm/linux/kernel/git/davem/net") > > Some of the lines in tools/lib/bpf/btf.[ch] were duplicated (they existed > on both sides of the merge). > > I have used the net-next tree from next-20180802 for today. I just noticed that too, fix out: http://patchwork.ozlabs.org/patch/953018/
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 3 Aug 2018 12:14:30 +1000 > Hi all, > > After merging the net-next tree, today's linux-next build (perf) failed > like this: > > In file included from btf.c:10:0: ... > Caused by commit > > 89b1698c93a9 ("Merge ra.kernel.org:/pub/scm/linux/kernel/git/davem/net") > > Some of the lines in tools/lib/bpf/btf.[ch] were duplicated (they existed > on both sides of the merge). > > I have used the net-next tree from next-20180802 for today. My bad, I am working on fixing this now. Thanks.
[-- Attachment #1: Type: text/plain, Size: 418 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/ptp/ptp_qoriq.o: In function `qoriq_ptp_probe': ptp_qoriq.c:(.text+0xd0c): undefined reference to `__aeabi_uldivmod' Caused by commit 91305f281262 ("ptp_qoriq: support automatic configuration for ptp timer") I just reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi all, Sorry for the trouble. Just sent out the fix-up patch. https://patchwork.ozlabs.org/patch/953695/ Thanks a lot. Best regards, Yangbo Lu > -----Original Message----- > From: Stephen Rothwell [mailto:sfr@canb.auug.org.au] > Sent: Monday, August 6, 2018 10:10 AM > To: David Miller <davem@davemloft.net>; Networking > <netdev@vger.kernel.org> > Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel Mailing > List <linux-kernel@vger.kernel.org>; Y.b. Lu <yangbo.lu@nxp.com> > Subject: linux-next: build failure after merge of the net-next tree > > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > drivers/ptp/ptp_qoriq.o: In function `qoriq_ptp_probe': > ptp_qoriq.c:(.text+0xd0c): undefined reference to `__aeabi_uldivmod' > > Caused by commit > > 91305f281262 ("ptp_qoriq: support automatic configuration for ptp timer") > > I just reverted that commit for today. > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 1353 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from drivers/net/ethernet/intel/i40e/i40e_ethtool.c:9: drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function '__i40e_add_stat_strings': drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h:193:20: error: function '__i40e_add_stat_strings' can never be inlined because it uses variable argument lists static inline void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[], ^~~~~~~~~~~~~~~~~~~~~~~ Caused by commit 8fd75c58a09a ("i40e: move ethtool stats boiler plate code to i40e_ethtool_stats.h") It is not clear this patch has any value anyway as the moved functions are only used in the file they were moved from. I reverted that commit for today. The same problem would exist in drivers/net/ethernet/intel/i40evf (where a lot of code is duplicated from drivers/net/ethernet/intel/i40e) except that this function is not declared inline there. Luckily, i40e_ethtool_stats.h is only included my one file drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c, otherwise there would be multiple copies of __i40e_add_stat_strings(). Surely there is some scope for factoring out some common code between these two drivers? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --] Hi all, On Mon, 3 Sep 2018 09:47:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from drivers/net/ethernet/intel/i40e/i40e_ethtool.c:9: > drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function '__i40e_add_stat_strings': > drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h:193:20: error: function '__i40e_add_stat_strings' can never be inlined because it uses variable argument lists > static inline void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[], > ^~~~~~~~~~~~~~~~~~~~~~~ > > Caused by commit > > 8fd75c58a09a ("i40e: move ethtool stats boiler plate code to i40e_ethtool_stats.h") > > It is not clear this patch has any value anyway as the moved functions > are only used in the file they were moved from. > > I reverted that commit for today. > > The same problem would exist in drivers/net/ethernet/intel/i40evf (where > a lot of code is duplicated from drivers/net/ethernet/intel/i40e) except > that this function is not declared inline there. > Luckily, i40e_ethtool_stats.h is only included my one file > drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c, otherwise there > would be multiple copies of __i40e_add_stat_strings(). > > Surely there is some scope for factoring out some common code between > these two drivers? Ping? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Stephen Rothwell
> Sent: Thursday, September 06, 2018 5:21 PM
> To: David Miller <davem@davemloft.net>; Networking
> <netdev@vger.kernel.org>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel Mailing
> List <linux-kernel@vger.kernel.org>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; Bowers, AndrewX
> <andrewx.bowers@intel.com>
> Subject: Re: linux-next: build failure after merge of the net-next tree
>
> Hi all,
>
> On Mon, 3 Sep 2018 09:47:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
> wrote:
> >
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from drivers/net/ethernet/intel/i40e/i40e_ethtool.c:9:
> > drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function
> '__i40e_add_stat_strings':
> > drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h:193:20: error: function
> '__i40e_add_stat_strings' can never be inlined because it uses variable argument
> lists
> > static inline void __i40e_add_stat_strings(u8 **p, const struct i40e_stats
> stats[],
> > ^~~~~~~~~~~~~~~~~~~~~~~
> >
> > Caused by commit
> >
> > 8fd75c58a09a ("i40e: move ethtool stats boiler plate code to
> i40e_ethtool_stats.h")
> >
> > It is not clear this patch has any value anyway as the moved functions
> > are only used in the file they were moved from.
> >
> > I reverted that commit for today.
> >
> > The same problem would exist in drivers/net/ethernet/intel/i40evf (where
> > a lot of code is duplicated from drivers/net/ethernet/intel/i40e) except
> > that this function is not declared inline there.
> > Luckily, i40e_ethtool_stats.h is only included my one file
> > drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c, otherwise there
> > would be multiple copies of __i40e_add_stat_strings().
> >
> > Surely there is some scope for factoring out some common code between
> > these two drivers?
>
> Ping?
>
> --
> Cheers,
> Stephen Rothwell
There's some discussion about this going on in the intel-wired-lan mailing list.
Thanks,
Jake
From: "Keller, Jacob E" <jacob.e.keller@intel.com>
Date: Fri, 7 Sep 2018 15:30:42 +0000
> There's some discussion about this going on in the intel-wired-lan
> mailing list.
I really want to see a pull request in my inbox fixing this by the end
of today or I'll apply a fix directly at my discretion.
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, September 07, 2018 10:31 AM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: sfr@canb.auug.org.au; netdev@vger.kernel.org; linux-next@vger.kernel.org;
> linux-kernel@vger.kernel.org; Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>;
> Bowers, AndrewX <andrewx.bowers@intel.com>
> Subject: Re: linux-next: build failure after merge of the net-next tree
>
> From: "Keller, Jacob E" <jacob.e.keller@intel.com>
> Date: Fri, 7 Sep 2018 15:30:42 +0000
>
> > There's some discussion about this going on in the intel-wired-lan
> > mailing list.
>
> I really want to see a pull request in my inbox fixing this by the end
> of today or I'll apply a fix directly at my discretion.
Jeff is out, so I just opted to email a fix to netdev. I hope this is acceptable.
I opted to essentially revert the patch that moved code to i40e_ethtool_stats.h, rather than anything fancier, since it was fast, and correct.
There was a suggestion to only move the one offending function, but I felt that it was better to move everything back into the .c files.
Thanks,
Jake
[-- Attachment #1: Type: text/plain, Size: 1539 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/infiniband/hw/mlx5/flow.c: In function 'mlx5_ib_handler_MLX5_IB_METHOD_CREATE_FLOW': drivers/infiniband/hw/mlx5/flow.c:163:12: error: 'struct mlx5_flow_act' has no member named 'has_flow_tag'; did you mean 'flow_tag'? flow_act.has_flow_tag = true; ^~~~~~~~~~~~ flow_tag Caused by commit d5634fee245f ("net/mlx5: Add a no-append flow insertion mode") interacting with commit ba4a41198324 ("RDMA/mlx5: Add support for flow tag to raw create flow") from the rdma tree. I have applied the following merge fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 19 Oct 2018 11:10:39 +1100 Subject: [PATCH] net/mlx5: fix up for has_flow_tag changing to a flag Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/infiniband/hw/mlx5/flow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx5/flow.c b/drivers/infiniband/hw/mlx5/flow.c index e57435cb6d96..f86cdcafdafc 100644 --- a/drivers/infiniband/hw/mlx5/flow.c +++ b/drivers/infiniband/hw/mlx5/flow.c @@ -160,7 +160,7 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)( ret = -EINVAL; goto err_out; } - flow_act.has_flow_tag = true; + flow_act.flags |= FLOW_ACT_HAS_TAG; } flow_handler = mlx5_ib_raw_fs_rule_add(dev, fs_matcher, &flow_act, -- 2.18.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, Oct 19, 2018 at 3:19 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/infiniband/hw/mlx5/flow.c: In function 'mlx5_ib_handler_MLX5_IB_METHOD_CREATE_FLOW':
> drivers/infiniband/hw/mlx5/flow.c:163:12: error: 'struct mlx5_flow_act' has no member named 'has_flow_tag'; did you mean 'flow_tag'?
> flow_act.has_flow_tag = true;
> ^~~~~~~~~~~~
> flow_tag
>
> Caused by commit
>
> d5634fee245f ("net/mlx5: Add a no-append flow insertion mode")
>
> interacting with commit
>
> ba4a41198324 ("RDMA/mlx5: Add support for flow tag to raw create flow")
>
> from the rdma tree.
>
> I have applied the following merge fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 19 Oct 2018 11:10:39 +1100
> Subject: [PATCH] net/mlx5: fix up for has_flow_tag changing to a flag
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/infiniband/hw/mlx5/flow.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/flow.c b/drivers/infiniband/hw/mlx5/flow.c
> index e57435cb6d96..f86cdcafdafc 100644
> --- a/drivers/infiniband/hw/mlx5/flow.c
> +++ b/drivers/infiniband/hw/mlx5/flow.c
> @@ -160,7 +160,7 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
> ret = -EINVAL;
> goto err_out;
> }
> - flow_act.has_flow_tag = true;
> + flow_act.flags |= FLOW_ACT_HAS_TAG;
> }
>
> flow_handler = mlx5_ib_raw_fs_rule_add(dev, fs_matcher, &flow_act,
yeah, this is the correct resolution, thanks for addressing!
[-- Attachment #1: Type: text/plain, Size: 949 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: In file included from net/core/dev.c:148: net/core/dev.c: In function 'napi_gro_complete': net/core/dev.c:5364:26: error: 'inet_gro_complete' undeclared (first use in this function); did you mean 'eth_gro_complete'? ipv6_gro_complete, inet_gro_complete, ^~~~~~~~~~~~~~~~~ include/linux/indirect_call_wrapper.h:32:41: note: in definition of macro 'INDIRECT_CALL_2' #define INDIRECT_CALL_2(f, name, ...) f(__VA_ARGS__) ^~~~~~~~~~~ and on .... Caused by commit aaa5d90b395a ("net: use indirect call wrappers at GRO network layer") inet_gro_complete() is declared in include/net/inet_comon.h which is not directly included in net/core/dev.c. I have used the net-next tree from next-20181214 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi, On Mon, 2018-12-17 at 12:36 +1100, Stephen Rothwell wrote: > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > In file included from net/core/dev.c:148: > net/core/dev.c: In function 'napi_gro_complete': > net/core/dev.c:5364:26: error: 'inet_gro_complete' undeclared (first use in this function); did you mean 'eth_gro_complete'? > ipv6_gro_complete, inet_gro_complete, > ^~~~~~~~~~~~~~~~~ > include/linux/indirect_call_wrapper.h:32:41: note: in definition of macro 'INDIRECT_CALL_2' > #define INDIRECT_CALL_2(f, name, ...) f(__VA_ARGS__) > ^~~~~~~~~~~ > > and on .... > > Caused by commit > > aaa5d90b395a ("net: use indirect call wrappers at GRO network layer") > > inet_gro_complete() is declared in include/net/inet_comon.h which is > not directly included in net/core/dev.c. > > I have used the net-next tree from next-20181214 for today. My fault, I should have tested more kernel configs. This fails with CONFIG_RETPOLINE=n A fix has been posted here: https://marc.info/?l=linux-netdev&m=154504685327698&w=2 Thanks, Paolo
[-- Attachment #1: Type: text/plain, Size: 1587 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/vxlan.c: In function 'vxlan_changelink': drivers/net/vxlan.c:3763:10: error: too few arguments to function 'vxlan_fdb_update' err = vxlan_fdb_update(vxlan, all_zeros_mac, ^~~~~~~~~~~~~~~~ drivers/net/vxlan.c:830:12: note: declared here static int vxlan_fdb_update(struct vxlan_dev *vxlan, ^~~~~~~~~~~~~~~~ Caused by commit ce5e098f7a10 ("vxlan: changelink: Fix handling of default remotes") from the net tree interacting with commit 0e6160f3f5a9 ("vxlan: vxlan_fdb_notify(): Make switchdev notification configurable") from the net-next tree. I added the following merge fix patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 20 Dec 2018 13:24:05 +1100 Subject: [PATCH] vxlan: fix for vxlan_fdb_update() API change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/vxlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index efd709a5e3a8..5209ee9aac47 100644 --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -3768,7 +3768,7 @@ static int vxlan_changelink(struct net_device *dev, struct nlattr *tb[], dst->remote_vni, dst->remote_vni, dst->remote_ifindex, - NTF_SELF); + NTF_SELF, true); if (err) { spin_unlock_bh(&vxlan->hash_lock); return err; -- 2.19.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/net/vxlan.c: In function 'vxlan_changelink':
> drivers/net/vxlan.c:3763:10: error: too few arguments to function 'vxlan_fdb_update'
> err = vxlan_fdb_update(vxlan, all_zeros_mac,
> ^~~~~~~~~~~~~~~~
> drivers/net/vxlan.c:830:12: note: declared here
> static int vxlan_fdb_update(struct vxlan_dev *vxlan,
> ^~~~~~~~~~~~~~~~
>
> Caused by commit
>
> ce5e098f7a10 ("vxlan: changelink: Fix handling of default remotes")
>
> from the net tree interacting with commit
>
> 0e6160f3f5a9 ("vxlan: vxlan_fdb_notify(): Make switchdev notification configurable")
>
> from the net-next tree.
>
> I added the following merge fix patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 20 Dec 2018 13:24:05 +1100
> Subject: [PATCH] vxlan: fix for vxlan_fdb_update() API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/net/vxlan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index efd709a5e3a8..5209ee9aac47 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -3768,7 +3768,7 @@ static int vxlan_changelink(struct net_device *dev, struct nlattr *tb[],
> dst->remote_vni,
> dst->remote_vni,
> dst->remote_ifindex,
> - NTF_SELF);
> + NTF_SELF, true);
> if (err) {
> spin_unlock_bh(&vxlan->hash_lock);
> return err;
> --
> 2.19.1
Yes, that's the correct fix.
Thanks!
[-- Attachment #1: Type: text/plain, Size: 2370 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/ethernet/freescale/enetc/enetc.c: In function 'enetc_alloc_txbdr': drivers/net/ethernet/freescale/enetc/enetc.c:685:17: error: implicit declaration of function 'vzalloc'; did you mean 'kzalloc'? [-Werror=implicit-function-declaration] txr->tx_swbd = vzalloc(txr->bd_count * sizeof(struct enetc_tx_swbd)); ^~~~~~~ kzalloc drivers/net/ethernet/freescale/enetc/enetc.c:685:15: warning: assignment to 'struct enetc_tx_swbd *' from 'int' makes pointer from integer without a cast [-Wint-conversion] txr->tx_swbd = vzalloc(txr->bd_count * sizeof(struct enetc_tx_swbd)); ^ drivers/net/ethernet/freescale/enetc/enetc.c:691:3: error: implicit declaration of function 'vfree'; did you mean 'kfree'? [-Werror=implicit-function-declaration] vfree(txr->tx_swbd); ^~~~~ kfree drivers/net/ethernet/freescale/enetc/enetc.c: In function 'enetc_alloc_rxbdr': drivers/net/ethernet/freescale/enetc/enetc.c:749:15: warning: assignment to 'struct enetc_rx_swbd *' from 'int' makes pointer from integer without a cast [-Wint-conversion] rxr->rx_swbd = vzalloc(rxr->bd_count * sizeof(struct enetc_rx_swbd)); ^ Caused by commit d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") I have added the following fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 29 Jan 2019 16:13:08 +1100 Subject: [PATCH] enetc: include linux/vmalloc.h for vzalloc etc Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/freescale/enetc/enetc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c index 37b587c541ee..5bb9eb35d76d 100644 --- a/drivers/net/ethernet/freescale/enetc/enetc.c +++ b/drivers/net/ethernet/freescale/enetc/enetc.c @@ -5,6 +5,7 @@ #include <linux/tcp.h> #include <linux/udp.h> #include <linux/of_mdio.h> +#include <linux/vmalloc.h> /* ENETC overhead: optional extension BD + 1 BD gap */ #define ENETC_TXBDS_NEEDED(val) ((val) + 2) -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 29 Jan 2019 16:17:42 +1100
> I have added the following fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 29 Jan 2019 16:13:08 +1100
> Subject: [PATCH] enetc: include linux/vmalloc.h for vzalloc etc
>
> Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied to net-next.
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) failed like this: /home/sfr/next/next/net/core/sock.c: In function 'sock_setsockopt': /home/sfr/next/next/net/core/sock.c:1146:2: error: duplicate case value case SO_BINDTOIFINDEX: ^~~~ /home/sfr/next/next/net/core/sock.c:891:2: note: previously used here case SO_TIMESTAMP_NEW: ^~~~ /home/sfr/next/next/net/core/sock.c: In function 'sock_getsockopt': /home/sfr/next/next/net/core/sock.c:1493:2: error: duplicate case value case SO_BINDTOIFINDEX: ^~~~ /home/sfr/next/next/net/core/sock.c:1293:2: note: previously used here case SO_TIMESTAMP_NEW: ^~~~ Caused by commit 887feae36aee ("socket: Add SO_TIMESTAMP[NS]_NEW") I applied the following fix patch (I just update the clashing id rather than update them all, but the latter may be better). From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 4 Feb 2019 15:24:11 +1100 Subject: [PATCH] socket: fix for Add SO_TIMESTAMP[NS]_NEW Fixes: 887feae36aee ("socket: Add SO_TIMESTAMP[NS]_NEW") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/sparc/include/uapi/asm/socket.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h index 8c9f74a66b55..88fe4f978aca 100644 --- a/arch/sparc/include/uapi/asm/socket.h +++ b/arch/sparc/include/uapi/asm/socket.h @@ -108,7 +108,7 @@ #define SO_TIMESTAMPNS_OLD 0x0021 #define SO_TIMESTAMPING_OLD 0x0023 -#define SO_TIMESTAMP_NEW 0x0041 +#define SO_TIMESTAMP_NEW 0x0046 #define SO_TIMESTAMPNS_NEW 0x0042 #define SO_TIMESTAMPING_NEW 0x0043 -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 4 Feb 2019 15:34:46 +1100
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 4 Feb 2019 15:24:11 +1100
> Subject: [PATCH] socket: fix for Add SO_TIMESTAMP[NS]_NEW
>
> Fixes: 887feae36aee ("socket: Add SO_TIMESTAMP[NS]_NEW")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks for fixing this.
Applied.
[-- Attachment #1: Type: text/plain, Size: 1595 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) failed like this: net/core/sock.c: In function 'sock_gettstamp': net/core/sock.c:3007:23: error: expected '}' before ';' token .tv_sec = ts.tv_sec; ^ net/core/sock.c:3011:4: error: expected ')' before 'return' return -EFAULT; ^~~~~~ net/core/sock.c:3013:2: error: expected expression before '}' token } ^ Caused by commit c7cbdbf29f48 ("net: rework SIOCGSTAMP ioctl handling") I have applied the followinf patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 23 Apr 2019 17:12:19 +1000 Subject: [PATCH] net: fix sparc64 compilation of sock_gettstamp Fixes: c7cbdbf29f48 ("net: rework SIOCGSTAMP ioctl handling") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/core/sock.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/core/sock.c b/net/core/sock.c index 443b98d05f1e..925b84a872dd 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -3004,10 +3004,10 @@ int sock_gettstamp(struct socket *sock, void __user *userstamp, /* beware of padding in sparc64 timeval */ if (timeval && !in_compat_syscall()) { struct __kernel_old_timeval __user tv = { - .tv_sec = ts.tv_sec; - .tv_usec = ts.tv_nsec; + .tv_sec = ts.tv_sec, + .tv_usec = ts.tv_nsec, }; - if (copy_to_user(userstamp, &tv, sizeof(tv)) + if (copy_to_user(userstamp, &tv, sizeof(tv))) return -EFAULT; return 0; } -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Apr 2019 17:25:24 +1000
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 23 Apr 2019 17:12:19 +1000
> Subject: [PATCH] net: fix sparc64 compilation of sock_gettstamp
>
> Fixes: c7cbdbf29f48 ("net: rework SIOCGSTAMP ioctl handling")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks Stephen.
[-- Attachment #1: Type: text/plain, Size: 712 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from net/netfilter/utils.c:5: include/linux/netfilter_ipv6.h: In function 'nf_ipv6_br_defrag': include/linux/netfilter_ipv6.h:110:9: error: implicit declaration of function 'nf_ct_frag6_gather'; did you mean 'nf_ct_attach'? [-Werror=implicit-function-declaration] return nf_ct_frag6_gather(net, skb, user); ^~~~~~~~~~~~~~~~~~ nf_ct_attach Caused by commit 764dd163ac92 ("netfilter: nf_conntrack_bridge: add support for IPv6") CONFIG_IPV6 is not set for this build. I have reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2784 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/ethernet/ti/cpts.c: In function 'cpts_of_mux_clk_setup': drivers/net/ethernet/ti/cpts.c:567:2: error: implicit declaration of function 'of_clk_parent_fill'; did you mean 'of_clk_get_parent_name'? [-Werror=implicit-function-declaration] of_clk_parent_fill(refclk_np, parent_names, num_parents); ^~~~~~~~~~~~~~~~~~ of_clk_get_parent_name drivers/net/ethernet/ti/cpts.c:575:11: error: implicit declaration of function 'clk_hw_register_mux_table'; did you mean 'clk_hw_register_clkdev'? [-Werror=implicit-function-declaration] clk_hw = clk_hw_register_mux_table(cpts->dev, refclk_np->name, ^~~~~~~~~~~~~~~~~~~~~~~~~ clk_hw_register_clkdev drivers/net/ethernet/ti/cpts.c:575:9: warning: assignment to 'struct clk_hw *' from 'int' makes pointer from integer without a cast [-Wint-conversion] clk_hw = clk_hw_register_mux_table(cpts->dev, refclk_np->name, ^ drivers/net/ethernet/ti/cpts.c:586:29: error: 'clk_hw_unregister_mux' undeclared (first use in this function); did you mean 'clk_hw_register_clkdev'? (void(*)(void *))clk_hw_unregister_mux, ^~~~~~~~~~~~~~~~~~~~~ clk_hw_register_clkdev drivers/net/ethernet/ti/cpts.c:586:29: note: each undeclared identifier is reported only once for each function it appears in drivers/net/ethernet/ti/cpts.c:593:8: error: implicit declaration of function 'of_clk_add_hw_provider'; did you mean 'of_clk_get_from_provider'? [-Werror=implicit-function-declaration] ret = of_clk_add_hw_provider(refclk_np, of_clk_hw_simple_get, clk_hw); ^~~~~~~~~~~~~~~~~~~~~~ of_clk_get_from_provider drivers/net/ethernet/ti/cpts.c:593:42: error: 'of_clk_hw_simple_get' undeclared (first use in this function); did you mean 'ida_simple_get'? ret = of_clk_add_hw_provider(refclk_np, of_clk_hw_simple_get, clk_hw); ^~~~~~~~~~~~~~~~~~~~ ida_simple_get drivers/net/ethernet/ti/cpts.c:598:29: error: 'of_clk_del_provider' undeclared (first use in this function); did you mean 'of_clk_get_from_provider'? (void(*)(void *))of_clk_del_provider, ^~~~~~~~~~~~~~~~~~~ of_clk_get_from_provider cc1: some warnings being treated as errors Caused by commit a3047a81ba13 ("net: ethernet: ti: cpts: add support for ext rftclk selection") of_clk_parent_fill() and others above are only available if CONFIG_COMMON_CLK is set (which it is not for this build). I have reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from usr/include/linux/tc_act/tc_ctinfo.hdrtest.c:1: ./usr/include/linux/tc_act/tc_ctinfo.h:30:21: error: implicit declaration of function 'BIT' [-Werror=implicit-function-declaration] CTINFO_MODE_DSCP = BIT(0), ^~~ ./usr/include/linux/tc_act/tc_ctinfo.h:30:2: error: enumerator value for 'CTINFO_MODE_DSCP' is not an integer constant CTINFO_MODE_DSCP = BIT(0), ^~~~~~~~~~~~~~~~ ./usr/include/linux/tc_act/tc_ctinfo.h:32:1: error: enumerator value for 'CTINFO_MODE_CPMARK' is not an integer constant }; ^ Caused by commit 24ec483cec98 ("net: sched: Introduce act_ctinfo action") Presumably exposed by commit b91976b7c0e3 ("kbuild: compile-test UAPI headers to ensure they are self-contained") from the kbuild tree. I have applied the following (obvious) patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 19 Jun 2019 13:15:22 +1000 Subject: [PATCH] net: sched: don't use BIT() in uapi headers Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- include/uapi/linux/tc_act/tc_ctinfo.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/tc_act/tc_ctinfo.h b/include/uapi/linux/tc_act/tc_ctinfo.h index da803e05a89b..6166c62dd7dd 100644 --- a/include/uapi/linux/tc_act/tc_ctinfo.h +++ b/include/uapi/linux/tc_act/tc_ctinfo.h @@ -27,8 +27,8 @@ enum { #define TCA_CTINFO_MAX (__TCA_CTINFO_MAX - 1) enum { - CTINFO_MODE_DSCP = BIT(0), - CTINFO_MODE_CPMARK = BIT(1) + CTINFO_MODE_DSCP = (1UL << 0), + CTINFO_MODE_CPMARK = (1UL << 1) }; #endif -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi. On Wed, Jun 19, 2019 at 12:23 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > In file included from usr/include/linux/tc_act/tc_ctinfo.hdrtest.c:1: > ./usr/include/linux/tc_act/tc_ctinfo.h:30:21: error: implicit declaration of function 'BIT' [-Werror=implicit-function-declaration] > CTINFO_MODE_DSCP = BIT(0), > ^~~ > ./usr/include/linux/tc_act/tc_ctinfo.h:30:2: error: enumerator value for 'CTINFO_MODE_DSCP' is not an integer constant > CTINFO_MODE_DSCP = BIT(0), > ^~~~~~~~~~~~~~~~ > ./usr/include/linux/tc_act/tc_ctinfo.h:32:1: error: enumerator value for 'CTINFO_MODE_CPMARK' is not an integer constant > }; > ^ > > Caused by commit > > 24ec483cec98 ("net: sched: Introduce act_ctinfo action") > > Presumably exposed by commit > > b91976b7c0e3 ("kbuild: compile-test UAPI headers to ensure they are self-contained") > > from the kbuild tree. My commit correctly blocked the broken UAPI header, Hooray! People export more and more headers that are never able to compile in user-space. We must block new breakages from coming in. BIT() is not exported to user-space since it is not prefixed with underscore. You can use _BITUL() in user-space, which is available in include/uapi/linux/const.h Thanks. > I have applied the following (obvious) patch for today. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Wed, 19 Jun 2019 13:15:22 +1000 > Subject: [PATCH] net: sched: don't use BIT() in uapi headers > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > include/uapi/linux/tc_act/tc_ctinfo.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/uapi/linux/tc_act/tc_ctinfo.h b/include/uapi/linux/tc_act/tc_ctinfo.h > index da803e05a89b..6166c62dd7dd 100644 > --- a/include/uapi/linux/tc_act/tc_ctinfo.h > +++ b/include/uapi/linux/tc_act/tc_ctinfo.h > @@ -27,8 +27,8 @@ enum { > #define TCA_CTINFO_MAX (__TCA_CTINFO_MAX - 1) > > enum { > - CTINFO_MODE_DSCP = BIT(0), > - CTINFO_MODE_CPMARK = BIT(1) > + CTINFO_MODE_DSCP = (1UL << 0), > + CTINFO_MODE_CPMARK = (1UL << 1) > }; > > #endif > -- > 2.20.1 > > -- > Cheers, > Stephen Rothwell -- Best Regards Masahiro Yamada
On Wed, Jun 19, 2019 at 1:02 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Hi.
>
>
> On Wed, Jun 19, 2019 at 12:23 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from usr/include/linux/tc_act/tc_ctinfo.hdrtest.c:1:
> > ./usr/include/linux/tc_act/tc_ctinfo.h:30:21: error: implicit declaration of function 'BIT' [-Werror=implicit-function-declaration]
> > CTINFO_MODE_DSCP = BIT(0),
> > ^~~
> > ./usr/include/linux/tc_act/tc_ctinfo.h:30:2: error: enumerator value for 'CTINFO_MODE_DSCP' is not an integer constant
> > CTINFO_MODE_DSCP = BIT(0),
> > ^~~~~~~~~~~~~~~~
> > ./usr/include/linux/tc_act/tc_ctinfo.h:32:1: error: enumerator value for 'CTINFO_MODE_CPMARK' is not an integer constant
> > };
> > ^
> >
> > Caused by commit
> >
> > 24ec483cec98 ("net: sched: Introduce act_ctinfo action")
> >
> > Presumably exposed by commit
> >
> > b91976b7c0e3 ("kbuild: compile-test UAPI headers to ensure they are self-contained")
> >
> > from the kbuild tree.
>
>
> My commit correctly blocked the broken UAPI header, Hooray!
>
> People export more and more headers that
> are never able to compile in user-space.
>
> We must block new breakages from coming in.
>
>
> BIT() is not exported to user-space
> since it is not prefixed with underscore.
>
>
> You can use _BITUL() in user-space,
> which is available in include/uapi/linux/const.h
>
>
I just took a look at
include/uapi/linux/tc_act/tc_ctinfo.h
I just wondered why the following can be compiled:
struct tc_ctinfo {
tc_gen;
};
Then, I found 'tc_gen' is a macro.
#define tc_gen \
__u32 index; \
__u32 capab; \
int action; \
int refcnt; \
int bindcnt
What a hell.
--
Best Regards
Masahiro Yamada
[-- Attachment #1: Type: text/plain, Size: 2992 bytes --] Greetings! As the guilty party in authoring this, and also pretty new around here I’m wondering what I need to do to help clean it up? > On 19 Jun 2019, at 05:14, Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > On Wed, Jun 19, 2019 at 1:02 PM Masahiro Yamada > <yamada.masahiro@socionext.com> wrote: >> >> Hi. >> >> >> On Wed, Jun 19, 2019 at 12:23 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: >>> >>> Hi all, >>> >>> After merging the net-next tree, today's linux-next build (x86_64 >>> allmodconfig) failed like this: >>> >>> In file included from usr/include/linux/tc_act/tc_ctinfo.hdrtest.c:1: >>> ./usr/include/linux/tc_act/tc_ctinfo.h:30:21: error: implicit declaration of function 'BIT' [-Werror=implicit-function-declaration] >>> CTINFO_MODE_DSCP = BIT(0), >>> ^~~ >>> ./usr/include/linux/tc_act/tc_ctinfo.h:30:2: error: enumerator value for 'CTINFO_MODE_DSCP' is not an integer constant >>> CTINFO_MODE_DSCP = BIT(0), >>> ^~~~~~~~~~~~~~~~ >>> ./usr/include/linux/tc_act/tc_ctinfo.h:32:1: error: enumerator value for 'CTINFO_MODE_CPMARK' is not an integer constant >>> }; >>> ^ >>> >>> Caused by commit >>> >>> 24ec483cec98 ("net: sched: Introduce act_ctinfo action") >>> >>> Presumably exposed by commit >>> >>> b91976b7c0e3 ("kbuild: compile-test UAPI headers to ensure they are self-contained") >>> >>> from the kbuild tree. Stephen, thanks for the fixup - is that now in the tree or do I need to submit a fix via the normal net-next channel so it gets picked up by the iproute2 people who maintain a local copy of the uapi includes? >> >> >> My commit correctly blocked the broken UAPI header, Hooray! >> >> People export more and more headers that >> are never able to compile in user-space. >> >> We must block new breakages from coming in. >> >> >> BIT() is not exported to user-space >> since it is not prefixed with underscore. >> >> >> You can use _BITUL() in user-space, >> which is available in include/uapi/linux/const.h Thanks for the pointers. I am confused as to why I didn’t hit this issue when I built & run tested locally off the net-next tree. >> >> > > > I just took a look at > include/uapi/linux/tc_act/tc_ctinfo.h > > > I just wondered why the following can be compiled: > > struct tc_ctinfo { > tc_gen; > }; > > > Then, I found 'tc_gen' is a macro. > > #define tc_gen \ > __u32 index; \ > __u32 capab; \ > int action; \ > int refcnt; \ > int bindcnt > > > > What a hell. This is what other actions do e.g. tc_skbedit. Can you advise what I should do instead? > -- > Best Regards > Masahiro Yamada Many thanks to all for your valuable time & advice. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --]
From: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Wed, 19 Jun 2019 13:14:06 +0900
> What a hell.
I know, some serious bush league coding going on in the networking
right?
I've fixed this as follows, thanks: ==================== From 23cdf8752b26d4edbd60a6293bca492d83192d4d Mon Sep 17 00:00:00 2001 From: "David S. Miller" <davem@davemloft.net> Date: Wed, 19 Jun 2019 10:12:58 -0400 Subject: [PATCH] act_ctinfo: Don't use BIT() in UAPI headers. Use _BITUL() instead. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- include/uapi/linux/tc_act/tc_ctinfo.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/tc_act/tc_ctinfo.h b/include/uapi/linux/tc_act/tc_ctinfo.h index da803e05a89b..32337304fbe5 100644 --- a/include/uapi/linux/tc_act/tc_ctinfo.h +++ b/include/uapi/linux/tc_act/tc_ctinfo.h @@ -27,8 +27,8 @@ enum { #define TCA_CTINFO_MAX (__TCA_CTINFO_MAX - 1) enum { - CTINFO_MODE_DSCP = BIT(0), - CTINFO_MODE_CPMARK = BIT(1) + CTINFO_MODE_DSCP = _BITUL(0), + CTINFO_MODE_CPMARK = _BITUL(1) }; #endif -- 2.20.1
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --] > On 19 Jun 2019, at 15:13, David Miller <davem@davemloft.net> wrote: > > > I've fixed this as follows, thanks: > > ==================== > From 23cdf8752b26d4edbd60a6293bca492d83192d4d Mon Sep 17 00:00:00 2001 > From: "David S. Miller" <davem@davemloft.net> > Date: Wed, 19 Jun 2019 10:12:58 -0400 > Subject: [PATCH] act_ctinfo: Don't use BIT() in UAPI headers. > > Use _BITUL() instead. > > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> > Signed-off-by: David S. Miller <davem@davemloft.net> > --- > include/uapi/linux/tc_act/tc_ctinfo.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/uapi/linux/tc_act/tc_ctinfo.h b/include/uapi/linux/tc_act/tc_ctinfo.h > index da803e05a89b..32337304fbe5 100644 > --- a/include/uapi/linux/tc_act/tc_ctinfo.h > +++ b/include/uapi/linux/tc_act/tc_ctinfo.h > @@ -27,8 +27,8 @@ enum { > #define TCA_CTINFO_MAX (__TCA_CTINFO_MAX - 1) > > enum { > - CTINFO_MODE_DSCP = BIT(0), > - CTINFO_MODE_CPMARK = BIT(1) > + CTINFO_MODE_DSCP = _BITUL(0), > + CTINFO_MODE_CPMARK = _BITUL(1) > }; > > #endif > -- > 2.20.1 > Hi David, Thanks for that. Owe you a beer! Thinking out loud, doesn’t this also require: #include <linux/const.h> Or at least iproute2 would need to know about _BITUL as it doesn’t at present. Which also means iproute2’s Linux uapi shadow would also have to import linux/const.h. Or have I got wrong end of stick? Cheers, Kevin [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2062 bytes --] > On 19 Jun 2019, at 16:09, Kevin 'ldir' Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk> wrote: > > > >> On 19 Jun 2019, at 15:13, David Miller <davem@davemloft.net> wrote: >> >> >> I've fixed this as follows, thanks: >> >> ==================== >> From 23cdf8752b26d4edbd60a6293bca492d83192d4d Mon Sep 17 00:00:00 2001 >> From: "David S. Miller" <davem@davemloft.net> >> Date: Wed, 19 Jun 2019 10:12:58 -0400 >> Subject: [PATCH] act_ctinfo: Don't use BIT() in UAPI headers. >> >> Use _BITUL() instead. >> >> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> >> Signed-off-by: David S. Miller <davem@davemloft.net> >> --- >> include/uapi/linux/tc_act/tc_ctinfo.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/include/uapi/linux/tc_act/tc_ctinfo.h b/include/uapi/linux/tc_act/tc_ctinfo.h >> index da803e05a89b..32337304fbe5 100644 >> --- a/include/uapi/linux/tc_act/tc_ctinfo.h >> +++ b/include/uapi/linux/tc_act/tc_ctinfo.h >> @@ -27,8 +27,8 @@ enum { >> #define TCA_CTINFO_MAX (__TCA_CTINFO_MAX - 1) >> >> enum { >> - CTINFO_MODE_DSCP = BIT(0), >> - CTINFO_MODE_CPMARK = BIT(1) >> + CTINFO_MODE_DSCP = _BITUL(0), >> + CTINFO_MODE_CPMARK = _BITUL(1) >> }; >> >> #endif >> -- >> 2.20.1 >> > > Hi David, > > Thanks for that. Owe you a beer! > > Thinking out loud, doesn’t this also require: > > #include <linux/const.h> > > > Or at least iproute2 would need to know about _BITUL as it doesn’t at present. > Which also means iproute2’s Linux uapi shadow would also have to import > linux/const.h. Or have I got wrong end of stick? > > Cheers, > > Kevin > Whilst out walking the dog I realised I’m a moron. The CTINFO_MODE_FOO is only used within module, it shouldn’t even be exposed to user space. I’ll send a patch shortly. Sorry, I’m pretty embarrassed at how something so apparently simple on the surface has had so many issues. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3234 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/ethernet/cadence/macb_main.c:48:16: error: field 'hw' has incomplete type struct clk_hw hw; ^~ drivers/net/ethernet/cadence/macb_main.c:4003:21: error: variable 'fu540_c000_ops' has initializer but incomplete type static const struct clk_ops fu540_c000_ops = { ^~~~~~~ drivers/net/ethernet/cadence/macb_main.c:4004:3: error: 'const struct clk_ops' has no member named 'recalc_rate' .recalc_rate = fu540_macb_tx_recalc_rate, ^~~~~~~~~~~ drivers/net/ethernet/cadence/macb_main.c:4004:17: warning: excess elements in struct initializer .recalc_rate = fu540_macb_tx_recalc_rate, ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/cadence/macb_main.c:4004:17: note: (near initialization for 'fu540_c000_ops') drivers/net/ethernet/cadence/macb_main.c:4005:3: error: 'const struct clk_ops' has no member named 'round_rate' .round_rate = fu540_macb_tx_round_rate, ^~~~~~~~~~ drivers/net/ethernet/cadence/macb_main.c:4005:16: warning: excess elements in struct initializer .round_rate = fu540_macb_tx_round_rate, ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/cadence/macb_main.c:4005:16: note: (near initialization for 'fu540_c000_ops') drivers/net/ethernet/cadence/macb_main.c:4006:3: error: 'const struct clk_ops' has no member named 'set_rate' .set_rate = fu540_macb_tx_set_rate, ^~~~~~~~ drivers/net/ethernet/cadence/macb_main.c:4006:14: warning: excess elements in struct initializer .set_rate = fu540_macb_tx_set_rate, ^~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/cadence/macb_main.c:4006:14: note: (near initialization for 'fu540_c000_ops') drivers/net/ethernet/cadence/macb_main.c: In function 'fu540_c000_clk_init': drivers/net/ethernet/cadence/macb_main.c:4013:23: error: storage size of 'init' isn't known struct clk_init_data init; ^~~~ drivers/net/ethernet/cadence/macb_main.c:4032:12: error: implicit declaration of function 'clk_register'; did you mean 'sock_register'? [-Werror=implicit-function-declaration] *tx_clk = clk_register(NULL, &mgmt->hw); ^~~~~~~~~~~~ sock_register drivers/net/ethernet/cadence/macb_main.c:4013:23: warning: unused variable 'init' [-Wunused-variable] struct clk_init_data init; ^~~~ drivers/net/ethernet/cadence/macb_main.c: In function 'macb_probe': drivers/net/ethernet/cadence/macb_main.c:4366:2: error: implicit declaration of function 'clk_unregister'; did you mean 'sock_unregister'? [-Werror=implicit-function-declaration] clk_unregister(tx_clk); ^~~~~~~~~~~~~~ sock_unregister drivers/net/ethernet/cadence/macb_main.c: At top level: drivers/net/ethernet/cadence/macb_main.c:4003:29: error: storage size of 'fu540_c000_ops' isn't known static const struct clk_ops fu540_c000_ops = { ^~~~~~~~~~~~~~ Caused by commit c218ad559020 ("macb: Add support for SiFive FU540-C000") CONFIG_COMMON_CLK is not set for this build. I have reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3521 bytes --] Hi all, On Thu, 20 Jun 2019 19:13:48 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > drivers/net/ethernet/cadence/macb_main.c:48:16: error: field 'hw' has incomplete type > struct clk_hw hw; > ^~ > drivers/net/ethernet/cadence/macb_main.c:4003:21: error: variable 'fu540_c000_ops' has initializer but incomplete type > static const struct clk_ops fu540_c000_ops = { > ^~~~~~~ > drivers/net/ethernet/cadence/macb_main.c:4004:3: error: 'const struct clk_ops' has no member named 'recalc_rate' > .recalc_rate = fu540_macb_tx_recalc_rate, > ^~~~~~~~~~~ > drivers/net/ethernet/cadence/macb_main.c:4004:17: warning: excess elements in struct initializer > .recalc_rate = fu540_macb_tx_recalc_rate, > ^~~~~~~~~~~~~~~~~~~~~~~~~ > drivers/net/ethernet/cadence/macb_main.c:4004:17: note: (near initialization for 'fu540_c000_ops') > drivers/net/ethernet/cadence/macb_main.c:4005:3: error: 'const struct clk_ops' has no member named 'round_rate' > .round_rate = fu540_macb_tx_round_rate, > ^~~~~~~~~~ > drivers/net/ethernet/cadence/macb_main.c:4005:16: warning: excess elements in struct initializer > .round_rate = fu540_macb_tx_round_rate, > ^~~~~~~~~~~~~~~~~~~~~~~~ > drivers/net/ethernet/cadence/macb_main.c:4005:16: note: (near initialization for 'fu540_c000_ops') > drivers/net/ethernet/cadence/macb_main.c:4006:3: error: 'const struct clk_ops' has no member named 'set_rate' > .set_rate = fu540_macb_tx_set_rate, > ^~~~~~~~ > drivers/net/ethernet/cadence/macb_main.c:4006:14: warning: excess elements in struct initializer > .set_rate = fu540_macb_tx_set_rate, > ^~~~~~~~~~~~~~~~~~~~~~ > drivers/net/ethernet/cadence/macb_main.c:4006:14: note: (near initialization for 'fu540_c000_ops') > drivers/net/ethernet/cadence/macb_main.c: In function 'fu540_c000_clk_init': > drivers/net/ethernet/cadence/macb_main.c:4013:23: error: storage size of 'init' isn't known > struct clk_init_data init; > ^~~~ > drivers/net/ethernet/cadence/macb_main.c:4032:12: error: implicit declaration of function 'clk_register'; did you mean 'sock_register'? [-Werror=implicit-function-declaration] > *tx_clk = clk_register(NULL, &mgmt->hw); > ^~~~~~~~~~~~ > sock_register > drivers/net/ethernet/cadence/macb_main.c:4013:23: warning: unused variable 'init' [-Wunused-variable] > struct clk_init_data init; > ^~~~ > drivers/net/ethernet/cadence/macb_main.c: In function 'macb_probe': > drivers/net/ethernet/cadence/macb_main.c:4366:2: error: implicit declaration of function 'clk_unregister'; did you mean 'sock_unregister'? [-Werror=implicit-function-declaration] > clk_unregister(tx_clk); > ^~~~~~~~~~~~~~ > sock_unregister > drivers/net/ethernet/cadence/macb_main.c: At top level: > drivers/net/ethernet/cadence/macb_main.c:4003:29: error: storage size of 'fu540_c000_ops' isn't known > static const struct clk_ops fu540_c000_ops = { > ^~~~~~~~~~~~~~ > > Caused by commit > > c218ad559020 ("macb: Add support for SiFive FU540-C000") > > CONFIG_COMMON_CLK is not set for this build. > > I have reverted that commit for today. I am still reverting that commit. Has this problem been fixed in some subtle way? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Sun, 23 Jun 2019 20:12:45 PDT (-0700), Stephen Rothwell wrote: > Hi all, > > On Thu, 20 Jun 2019 19:13:48 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: >> >> After merging the net-next tree, today's linux-next build (powerpc >> allyesconfig) failed like this: >> >> drivers/net/ethernet/cadence/macb_main.c:48:16: error: field 'hw' has incomplete type >> struct clk_hw hw; >> ^~ >> drivers/net/ethernet/cadence/macb_main.c:4003:21: error: variable 'fu540_c000_ops' has initializer but incomplete type >> static const struct clk_ops fu540_c000_ops = { >> ^~~~~~~ >> drivers/net/ethernet/cadence/macb_main.c:4004:3: error: 'const struct clk_ops' has no member named 'recalc_rate' >> .recalc_rate = fu540_macb_tx_recalc_rate, >> ^~~~~~~~~~~ >> drivers/net/ethernet/cadence/macb_main.c:4004:17: warning: excess elements in struct initializer >> .recalc_rate = fu540_macb_tx_recalc_rate, >> ^~~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/net/ethernet/cadence/macb_main.c:4004:17: note: (near initialization for 'fu540_c000_ops') >> drivers/net/ethernet/cadence/macb_main.c:4005:3: error: 'const struct clk_ops' has no member named 'round_rate' >> .round_rate = fu540_macb_tx_round_rate, >> ^~~~~~~~~~ >> drivers/net/ethernet/cadence/macb_main.c:4005:16: warning: excess elements in struct initializer >> .round_rate = fu540_macb_tx_round_rate, >> ^~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/net/ethernet/cadence/macb_main.c:4005:16: note: (near initialization for 'fu540_c000_ops') >> drivers/net/ethernet/cadence/macb_main.c:4006:3: error: 'const struct clk_ops' has no member named 'set_rate' >> .set_rate = fu540_macb_tx_set_rate, >> ^~~~~~~~ >> drivers/net/ethernet/cadence/macb_main.c:4006:14: warning: excess elements in struct initializer >> .set_rate = fu540_macb_tx_set_rate, >> ^~~~~~~~~~~~~~~~~~~~~~ >> drivers/net/ethernet/cadence/macb_main.c:4006:14: note: (near initialization for 'fu540_c000_ops') >> drivers/net/ethernet/cadence/macb_main.c: In function 'fu540_c000_clk_init': >> drivers/net/ethernet/cadence/macb_main.c:4013:23: error: storage size of 'init' isn't known >> struct clk_init_data init; >> ^~~~ >> drivers/net/ethernet/cadence/macb_main.c:4032:12: error: implicit declaration of function 'clk_register'; did you mean 'sock_register'? [-Werror=implicit-function-declaration] >> *tx_clk = clk_register(NULL, &mgmt->hw); >> ^~~~~~~~~~~~ >> sock_register >> drivers/net/ethernet/cadence/macb_main.c:4013:23: warning: unused variable 'init' [-Wunused-variable] >> struct clk_init_data init; >> ^~~~ >> drivers/net/ethernet/cadence/macb_main.c: In function 'macb_probe': >> drivers/net/ethernet/cadence/macb_main.c:4366:2: error: implicit declaration of function 'clk_unregister'; did you mean 'sock_unregister'? [-Werror=implicit-function-declaration] >> clk_unregister(tx_clk); >> ^~~~~~~~~~~~~~ >> sock_unregister >> drivers/net/ethernet/cadence/macb_main.c: At top level: >> drivers/net/ethernet/cadence/macb_main.c:4003:29: error: storage size of 'fu540_c000_ops' isn't known >> static const struct clk_ops fu540_c000_ops = { >> ^~~~~~~~~~~~~~ >> >> Caused by commit >> >> c218ad559020 ("macb: Add support for SiFive FU540-C000") >> >> CONFIG_COMMON_CLK is not set for this build. >> >> I have reverted that commit for today. > > I am still reverting that commit. Has this problem been fixed in some > subtle way? I don't think so. I'm assuming something like this is necessary diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig index 1766697c9c5a..d13db9e9c818 100644 --- a/drivers/net/ethernet/cadence/Kconfig +++ b/drivers/net/ethernet/cadence/Kconfig @@ -23,6 +23,7 @@ config MACB tristate "Cadence MACB/GEM support" depends on HAS_DMA select PHYLIB + depends on COMMON_CLK ---help--- The Cadence MACB ethernet interface is found on many Atmel AT32 and AT91 parts. This driver also supports the Cadence GEM (Gigabit @@ -42,7 +43,7 @@ config MACB_USE_HWSTAMP config MACB_PCI tristate "Cadence PCI MACB/GEM support" - depends on MACB && PCI && COMMON_CLK + depends on MACB && PCI ---help--- This is PCI wrapper for MACB driver. at a minimum, though it may be saner to #ifdef support for the SiFive clock driver as that's only useful on some systems. Assuming I can reproduce the build failure (which shouldn't be too hard), I'll send out a patch that adds a Kconfig for the FU540 clock driver to avoid adding a COMMON_CLK dependency for all MACB systems.
[-- Attachment #1: Type: text/plain, Size: 803 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/infiniband/sw/siw/siw_cm.c: In function 'siw_create_listen': drivers/infiniband/sw/siw/siw_cm.c:1978:3: error: implicit declaration of function 'for_ifa'; did you mean 'fork_idle'? [-Werror=implicit-function-declaration] for_ifa(in_dev) ^~~~~~~ fork_idle drivers/infiniband/sw/siw/siw_cm.c:1978:18: error: expected ';' before '{' token for_ifa(in_dev) ^ ; { ~ Caused by commit 6c52fdc244b5 ("rdma/siw: connection management") from the rdma tree. I don't know why this didn't fail after I mereged that tree. I have marked that driver as depending on BROKEN for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Jul 09, 2019 at 01:56:36PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/infiniband/sw/siw/siw_cm.c: In function 'siw_create_listen': > drivers/infiniband/sw/siw/siw_cm.c:1978:3: error: implicit declaration of function 'for_ifa'; did you mean 'fork_idle'? [-Werror=implicit-function-declaration] > for_ifa(in_dev) > ^~~~~~~ > fork_idle > drivers/infiniband/sw/siw/siw_cm.c:1978:18: error: expected ';' before '{' token > for_ifa(in_dev) > ^ > ; > { > ~ > > Caused by commit > > 6c52fdc244b5 ("rdma/siw: connection management") > > from the rdma tree. I don't know why this didn't fail after I mereged > that tree. I had the same question, because I have this fix for a couple of days already. From 56c9e15ec670af580daa8c3ffde9503af3042d67 Mon Sep 17 00:00:00 2001 From: Leon Romanovsky <leonro@mellanox.com> Date: Sun, 7 Jul 2019 10:43:42 +0300 Subject: [PATCH] Fixup to build SIW issue Signed-off-by: Leon Romanovsky <leonro@mellanox.com> --- drivers/infiniband/sw/siw/siw_cm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/sw/siw/siw_cm.c b/drivers/infiniband/sw/siw/siw_cm.c index 8e618cb7261f..c883bf514341 100644 --- a/drivers/infiniband/sw/siw/siw_cm.c +++ b/drivers/infiniband/sw/siw/siw_cm.c @@ -1954,6 +1954,7 @@ static void siw_drop_listeners(struct iw_cm_id *id) int siw_create_listen(struct iw_cm_id *id, int backlog) { struct net_device *dev = to_siw_dev(id->device)->netdev; + const struct in_ifaddr *ifa; int rv = 0, listeners = 0; siw_dbg(id->device, "id 0x%p: backlog %d\n", id, backlog); @@ -1975,8 +1976,7 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) id, &s_laddr.sin_addr, ntohs(s_laddr.sin_port), &s_raddr->sin_addr, ntohs(s_raddr->sin_port)); - for_ifa(in_dev) - { + in_dev_for_each_ifa_rcu(ifa, in_dev) { if (ipv4_is_zeronet(s_laddr.sin_addr.s_addr) || s_laddr.sin_addr.s_addr == ifa->ifa_address) { s_laddr.sin_addr.s_addr = ifa->ifa_address; @@ -1988,7 +1988,6 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) listeners++; } } - endfor_ifa(in_dev); in_dev_put(in_dev); } else if (id->local_addr.ss_family == AF_INET6) { struct inet6_dev *in6_dev = in6_dev_get(dev); -- 2.21.0 > > I have marked that driver as depending on BROKEN for today. > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 461 bytes --] Hi Leon, On Tue, 9 Jul 2019 09:43:46 +0300 Leon Romanovsky <leon@kernel.org> wrote: > > From 56c9e15ec670af580daa8c3ffde9503af3042d67 Mon Sep 17 00:00:00 2001 > From: Leon Romanovsky <leonro@mellanox.com> > Date: Sun, 7 Jul 2019 10:43:42 +0300 > Subject: [PATCH] Fixup to build SIW issue > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com> I applied this to linux-next today and it fixes my build problems. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, Jul 10, 2019 at 02:31:58PM +1000, Stephen Rothwell wrote: > Hi Leon, > > On Tue, 9 Jul 2019 09:43:46 +0300 Leon Romanovsky <leon@kernel.org> wrote: > > > > From 56c9e15ec670af580daa8c3ffde9503af3042d67 Mon Sep 17 00:00:00 2001 > > From: Leon Romanovsky <leonro@mellanox.com> > > Date: Sun, 7 Jul 2019 10:43:42 +0300 > > Subject: [PATCH] Fixup to build SIW issue > > > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com> > > I applied this to linux-next today and it fixes my build problems. Thanks > > -- > Cheers, > Stephen Rothwell
On Tue, Jul 09, 2019 at 09:43:46AM +0300, Leon Romanovsky wrote: > On Tue, Jul 09, 2019 at 01:56:36PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > After merging the net-next tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > drivers/infiniband/sw/siw/siw_cm.c: In function 'siw_create_listen': > > drivers/infiniband/sw/siw/siw_cm.c:1978:3: error: implicit declaration of function 'for_ifa'; did you mean 'fork_idle'? [-Werror=implicit-function-declaration] > > for_ifa(in_dev) > > ^~~~~~~ > > fork_idle > > drivers/infiniband/sw/siw/siw_cm.c:1978:18: error: expected ';' before '{' token > > for_ifa(in_dev) > > ^ > > ; > > { > > ~ > > > > Caused by commit > > > > 6c52fdc244b5 ("rdma/siw: connection management") > > > > from the rdma tree. I don't know why this didn't fail after I mereged > > that tree. > > I had the same question, because I have this fix for a couple of days already. > > From 56c9e15ec670af580daa8c3ffde9503af3042d67 Mon Sep 17 00:00:00 2001 > From: Leon Romanovsky <leonro@mellanox.com> > Date: Sun, 7 Jul 2019 10:43:42 +0300 > Subject: [PATCH] Fixup to build SIW issue > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com> > drivers/infiniband/sw/siw/siw_cm.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/infiniband/sw/siw/siw_cm.c b/drivers/infiniband/sw/siw/siw_cm.c > index 8e618cb7261f..c883bf514341 100644 > +++ b/drivers/infiniband/sw/siw/siw_cm.c > @@ -1954,6 +1954,7 @@ static void siw_drop_listeners(struct iw_cm_id *id) > int siw_create_listen(struct iw_cm_id *id, int backlog) > { > struct net_device *dev = to_siw_dev(id->device)->netdev; > + const struct in_ifaddr *ifa; > int rv = 0, listeners = 0; > > siw_dbg(id->device, "id 0x%p: backlog %d\n", id, backlog); > @@ -1975,8 +1976,7 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) > id, &s_laddr.sin_addr, ntohs(s_laddr.sin_port), > &s_raddr->sin_addr, ntohs(s_raddr->sin_port)); > > - for_ifa(in_dev) > - { > + in_dev_for_each_ifa_rcu(ifa, in_dev) { > if (ipv4_is_zeronet(s_laddr.sin_addr.s_addr) || Hum. There is no rcu lock held here and we can't use RCU anyhow as siw_listen_address will sleep. I think this needs to use rtnl, as below. Bernard, please urgently confirm. Thanks diff --git a/drivers/infiniband/sw/siw/siw_cm.c b/drivers/infiniband/sw/siw/siw_cm.c index 8e618cb7261f62..ee98e96a5bfaba 100644 --- a/drivers/infiniband/sw/siw/siw_cm.c +++ b/drivers/infiniband/sw/siw/siw_cm.c @@ -1965,6 +1965,7 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) */ if (id->local_addr.ss_family == AF_INET) { struct in_device *in_dev = in_dev_get(dev); + const struct in_ifaddr *ifa; struct sockaddr_in s_laddr, *s_raddr; memcpy(&s_laddr, &id->local_addr, sizeof(s_laddr)); @@ -1975,8 +1976,8 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) id, &s_laddr.sin_addr, ntohs(s_laddr.sin_port), &s_raddr->sin_addr, ntohs(s_raddr->sin_port)); - for_ifa(in_dev) - { + rtnl_lock(); + in_dev_for_each_ifa_rtnl(ifa, in_dev) { if (ipv4_is_zeronet(s_laddr.sin_addr.s_addr) || s_laddr.sin_addr.s_addr == ifa->ifa_address) { s_laddr.sin_addr.s_addr = ifa->ifa_address; @@ -1988,7 +1989,7 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) listeners++; } } - endfor_ifa(in_dev); + rtnl_unlock(); in_dev_put(in_dev); } else if (id->local_addr.ss_family == AF_INET6) { struct inet6_dev *in6_dev = in6_dev_get(dev);
[-- Attachment #1: Type: text/plain, Size: 4311 bytes --] Hi all, On Wed, 10 Jul 2019 17:52:17 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote: > > On Tue, Jul 09, 2019 at 09:43:46AM +0300, Leon Romanovsky wrote: > > On Tue, Jul 09, 2019 at 01:56:36PM +1000, Stephen Rothwell wrote: > > > Hi all, > > > > > > After merging the net-next tree, today's linux-next build (x86_64 > > > allmodconfig) failed like this: > > > > > > drivers/infiniband/sw/siw/siw_cm.c: In function 'siw_create_listen': > > > drivers/infiniband/sw/siw/siw_cm.c:1978:3: error: implicit declaration of function 'for_ifa'; did you mean 'fork_idle'? [-Werror=implicit-function-declaration] > > > for_ifa(in_dev) > > > ^~~~~~~ > > > fork_idle > > > drivers/infiniband/sw/siw/siw_cm.c:1978:18: error: expected ';' before '{' token > > > for_ifa(in_dev) > > > ^ > > > ; > > > { > > > ~ > > > > > > Caused by commit > > > > > > 6c52fdc244b5 ("rdma/siw: connection management") > > > > > > from the rdma tree. I don't know why this didn't fail after I mereged > > > that tree. > > > > I had the same question, because I have this fix for a couple of days already. > > > > From 56c9e15ec670af580daa8c3ffde9503af3042d67 Mon Sep 17 00:00:00 2001 > > From: Leon Romanovsky <leonro@mellanox.com> > > Date: Sun, 7 Jul 2019 10:43:42 +0300 > > Subject: [PATCH] Fixup to build SIW issue > > > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com> > > drivers/infiniband/sw/siw/siw_cm.c | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/infiniband/sw/siw/siw_cm.c b/drivers/infiniband/sw/siw/siw_cm.c > > index 8e618cb7261f..c883bf514341 100644 > > +++ b/drivers/infiniband/sw/siw/siw_cm.c > > @@ -1954,6 +1954,7 @@ static void siw_drop_listeners(struct iw_cm_id *id) > > int siw_create_listen(struct iw_cm_id *id, int backlog) > > { > > struct net_device *dev = to_siw_dev(id->device)->netdev; > > + const struct in_ifaddr *ifa; > > int rv = 0, listeners = 0; > > > > siw_dbg(id->device, "id 0x%p: backlog %d\n", id, backlog); > > @@ -1975,8 +1976,7 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) > > id, &s_laddr.sin_addr, ntohs(s_laddr.sin_port), > > &s_raddr->sin_addr, ntohs(s_raddr->sin_port)); > > > > - for_ifa(in_dev) > > - { > > + in_dev_for_each_ifa_rcu(ifa, in_dev) { > > if (ipv4_is_zeronet(s_laddr.sin_addr.s_addr) || > > Hum. There is no rcu lock held here and we can't use RCU anyhow as > siw_listen_address will sleep. > > I think this needs to use rtnl, as below. Bernard, please urgently > confirm. Thanks > > diff --git a/drivers/infiniband/sw/siw/siw_cm.c b/drivers/infiniband/sw/siw/siw_cm.c > index 8e618cb7261f62..ee98e96a5bfaba 100644 > --- a/drivers/infiniband/sw/siw/siw_cm.c > +++ b/drivers/infiniband/sw/siw/siw_cm.c > @@ -1965,6 +1965,7 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) > */ > if (id->local_addr.ss_family == AF_INET) { > struct in_device *in_dev = in_dev_get(dev); > + const struct in_ifaddr *ifa; > struct sockaddr_in s_laddr, *s_raddr; > > memcpy(&s_laddr, &id->local_addr, sizeof(s_laddr)); > @@ -1975,8 +1976,8 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) > id, &s_laddr.sin_addr, ntohs(s_laddr.sin_port), > &s_raddr->sin_addr, ntohs(s_raddr->sin_port)); > > - for_ifa(in_dev) > - { > + rtnl_lock(); > + in_dev_for_each_ifa_rtnl(ifa, in_dev) { > if (ipv4_is_zeronet(s_laddr.sin_addr.s_addr) || > s_laddr.sin_addr.s_addr == ifa->ifa_address) { > s_laddr.sin_addr.s_addr = ifa->ifa_address; > @@ -1988,7 +1989,7 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) > listeners++; > } > } > - endfor_ifa(in_dev); > + rtnl_unlock(); > in_dev_put(in_dev); > } else if (id->local_addr.ss_family == AF_INET6) { > struct inet6_dev *in6_dev = in6_dev_get(dev); So today this failed to build after I merged the rdma tree (previously it didn;t until after the net-next tree was merged (I assume a dependency changed). It failed because in_dev_for_each_ifa_rcu (and in_dev_for_each_ifa_rtnl) is only defined in a commit in the net-next tree :-( I have disabled the driver again. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote:
> So today this failed to build after I merged the rdma tree (previously
> it didn;t until after the net-next tree was merged (I assume a
> dependency changed). It failed because in_dev_for_each_ifa_rcu (and
> in_dev_for_each_ifa_rtnl) is only defined in a commit in the net-next
> tree :-(
? I'm confused..
rdma.git builds fine stand alone (I hope!)
If you merge it with netdev then the above patch is needed afer the
merge as netdev changed to ifa_rcu
I just did this a few hours ago to make and test the patch I sent
above..
Jason
[-- Attachment #1: Type: text/plain, Size: 835 bytes --] Hi Jason, On Thu, 11 Jul 2019 02:26:27 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote: > > On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote: > > > So today this failed to build after I merged the rdma tree (previously > > it didn;t until after the net-next tree was merged (I assume a > > dependency changed). It failed because in_dev_for_each_ifa_rcu (and > > in_dev_for_each_ifa_rtnl) is only defined in a commit in the net-next > > tree :-( > > ? I'm confused.. > > rdma.git builds fine stand alone (I hope!) I have "Fixup to build SIW issue" from Leon (which switches to using in_dev_for_each_ifa_rcu) included in the rmda tree merge commit because without that the rdma tree would not build for me. Are you saying that I don't need that at all, now? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --] Hi all, On Thu, 11 Jul 2019 13:13:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Thu, 11 Jul 2019 02:26:27 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote: > > > > On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote: > > > > > So today this failed to build after I merged the rdma tree (previously > > > it didn;t until after the net-next tree was merged (I assume a > > > dependency changed). It failed because in_dev_for_each_ifa_rcu (and > > > in_dev_for_each_ifa_rtnl) is only defined in a commit in the net-next > > > tree :-( > > > > ? I'm confused.. > > > > rdma.git builds fine stand alone (I hope!) > > I have "Fixup to build SIW issue" from Leon (which switches to using > in_dev_for_each_ifa_rcu) included in the rmda tree merge commit because > without that the rdma tree would not build for me. Are you saying that > I don't need that at all, now? Actually , I get it now, "Fixup to build SIW issue" is really just a fixup for the net-next and rdma trees merge ... OK, I will fix that up tomorrow. Sorry for my confusion. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --] Hi all, On Thu, 11 Jul 2019 13:16:03 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Thu, 11 Jul 2019 13:13:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Thu, 11 Jul 2019 02:26:27 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote: > > > > > > On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote: > > > > > > > So today this failed to build after I merged the rdma tree (previously > > > > it didn;t until after the net-next tree was merged (I assume a > > > > dependency changed). It failed because in_dev_for_each_ifa_rcu (and > > > > in_dev_for_each_ifa_rtnl) is only defined in a commit in the net-next > > > > tree :-( > > > > > > ? I'm confused.. > > > > > > rdma.git builds fine stand alone (I hope!) > > > > I have "Fixup to build SIW issue" from Leon (which switches to using > > in_dev_for_each_ifa_rcu) included in the rmda tree merge commit because > > without that the rdma tree would not build for me. Are you saying that > > I don't need that at all, now? > > Actually , I get it now, "Fixup to build SIW issue" is really just a > fixup for the net-next and rdma trees merge ... OK, I will fix that up > tomorrow. Sorry for my confusion. Actually, I have rewound my tree and am starting from the merge of the rdma tree again, so hopefully it should all be good today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Jul 11, 2019 at 01:16:03PM +1000, Stephen Rothwell wrote: > Hi all, > > On Thu, 11 Jul 2019 13:13:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Thu, 11 Jul 2019 02:26:27 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote: > > > > > > On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote: > > > > > > > So today this failed to build after I merged the rdma tree (previously > > > > it didn;t until after the net-next tree was merged (I assume a > > > > dependency changed). It failed because in_dev_for_each_ifa_rcu (and > > > > in_dev_for_each_ifa_rtnl) is only defined in a commit in the net-next > > > > tree :-( > > > > > > ? I'm confused.. > > > > > > rdma.git builds fine stand alone (I hope!) > > > > I have "Fixup to build SIW issue" from Leon (which switches to using > > in_dev_for_each_ifa_rcu) included in the rmda tree merge commit because > > without that the rdma tree would not build for me. Are you saying that > > I don't need that at all, now? > > Actually , I get it now, "Fixup to build SIW issue" is really just a > fixup for the net-next and rdma trees merge ... OK, I will fix that up > tomorrow. Sorry for my confusion. Yes, it was for build only. > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 1888 bytes --] Hi Jason, On Thu, 11 Jul 2019 14:33:07 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote: > > I've added this patch to the rdma tree to fix the missing locking. > > The merge resolution will be simply swapping > for_ifa to in_dev_for_each_ifa_rtnl. OK, I added the below merge resolution patch to the merge of the rdma tree today (since Linus' has merged the net-next tree now). From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 12 Jul 2019 11:28:30 +1000 Subject: [PATCH] RDMA: fix for removal of for_ifa() Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/infiniband/sw/siw/siw_cm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/sw/siw/siw_cm.c b/drivers/infiniband/sw/siw/siw_cm.c index 43f7f12e5f7f..cbea46ff6dd1 100644 --- a/drivers/infiniband/sw/siw/siw_cm.c +++ b/drivers/infiniband/sw/siw/siw_cm.c @@ -1951,6 +1951,7 @@ static void siw_drop_listeners(struct iw_cm_id *id) int siw_create_listen(struct iw_cm_id *id, int backlog) { struct net_device *dev = to_siw_dev(id->device)->netdev; + const struct in_ifaddr *ifa; int rv = 0, listeners = 0; siw_dbg(id->device, "id 0x%p: backlog %d\n", id, backlog); @@ -1973,8 +1974,7 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) &s_raddr->sin_addr, ntohs(s_raddr->sin_port)); rtnl_lock(); - for_ifa(in_dev) - { + in_dev_for_each_ifa_rtnl(ifa, in_dev) { if (ipv4_is_zeronet(s_laddr.sin_addr.s_addr) || s_laddr.sin_addr.s_addr == ifa->ifa_address) { s_laddr.sin_addr.s_addr = ifa->ifa_address; @@ -1986,7 +1986,6 @@ int siw_create_listen(struct iw_cm_id *id, int backlog) listeners++; } } - endfor_ifa(in_dev); rtnl_unlock(); in_dev_put(in_dev); } else if (id->local_addr.ss_family == AF_INET6) { -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, Jul 12, 2019 at 11:45:57AM +1000, Stephen Rothwell wrote:
> Hi Jason,
>
> On Thu, 11 Jul 2019 14:33:07 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:
> >
> > I've added this patch to the rdma tree to fix the missing locking.
> >
> > The merge resolution will be simply swapping
> > for_ifa to in_dev_for_each_ifa_rtnl.
>
> OK, I added the below merge resolution patch to the merge of the rdma
> tree today (since Linus' has merged the net-next tree now).
Yes, this is what I'm planning on using
Thanks,
Jason
[-- Attachment #1: Type: text/plain, Size: 412 bytes --] Hi all, After merging the net-next tree, today's linux-next build (mips cavium_octeon_defconfig) failed like this: drivers/staging/octeon/ethernet-tx.c:287:23: error: implicit declaration of function 'skb_drag_size'; did you mean 'skb_frag_size'? [-Werror=implicit-function-declaration] Caused by commit 92493a2f8a8d ("Build fixes for skb_frag_size conversion") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powepc allmodconfig) failed like this: ld: drivers/net/ethernet/stmicro/stmmac/stmmac_pci.o: in function `.stmmac_pci_remove': stmmac_pci.c:(.text.stmmac_pci_remove+0x68): undefined reference to `.clk_unregister_fixed_rate' ld: drivers/net/ethernet/stmicro/stmmac/stmmac_pci.o: in function `.intel_mgbe_common_data': stmmac_pci.c:(.text.intel_mgbe_common_data+0x2a8): undefined reference to `.clk_register_fixed_rate' Caused by commit 190f73ab4c43 ("net: stmmac: setup higher frequency clk support for EHL & TGL") CONFIG_COMMON_CLK is not set for this build. I have added the following patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 29 Aug 2019 19:49:27 +1000 Subject: [PATCH] net: stmmac: depend on COMMON_CLK Fixes: 190f73ab4c43 ("net: stmmac: setup higher frequency clk support for EHL & TGL") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig index 2325b40dff6e..338e25a6374e 100644 --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig @@ -200,6 +200,7 @@ endif config STMMAC_PCI tristate "STMMAC PCI bus support" depends on STMMAC_ETH && PCI + depends on COMMON_CLK ---help--- This selects the platform specific bus support for the stmmac driver. This driver was tested on XLINX XC2V3000 FF1152AMT0221 -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 29 Aug 2019 20:05:46 +1000
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 29 Aug 2019 19:49:27 +1000
> Subject: [PATCH] net: stmmac: depend on COMMON_CLK
>
> Fixes: 190f73ab4c43 ("net: stmmac: setup higher frequency clk support for EHL & TGL")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied.
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: scripts/link-vmlinux.sh: 74: Bad substitution Caused by commit 341dfcf8d78e ("btf: expose BTF info through sysfs") interacting with commit 1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension") from the kbuild tree. The change in the net-next tree turned link-vmlinux.sh into a bash script (I think). I have applied the following patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 4 Sep 2019 15:43:41 +1000 Subject: [PATCH] link-vmlinux.sh is now a bash script Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- Makefile | 4 ++-- scripts/link-vmlinux.sh | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index ac97fb282d99..523d12c5cebe 100644 --- a/Makefile +++ b/Makefile @@ -1087,7 +1087,7 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink) # Final link of vmlinux with optional arch pass after final link cmd_link-vmlinux = \ - $(CONFIG_SHELL) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ + $(BASH) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true) vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE @@ -1403,7 +1403,7 @@ clean: rm-files := $(CLEAN_FILES) PHONY += archclean vmlinuxclean vmlinuxclean: - $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean + $(Q)$(BASH) $(srctree)/scripts/link-vmlinux.sh clean $(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean) clean: archclean vmlinuxclean diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh index f7edb75f9806..ea1f8673869d 100755 --- a/scripts/link-vmlinux.sh +++ b/scripts/link-vmlinux.sh @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash # SPDX-License-Identifier: GPL-2.0 # # link vmlinux -- 2.23.0.rc1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, Sep 4, 2019 at 3:00 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > scripts/link-vmlinux.sh: 74: Bad substitution > > Caused by commit > > 341dfcf8d78e ("btf: expose BTF info through sysfs") > > interacting with commit > > 1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension") > > from the kbuild tree. I knew that they were using bash-extension in the #!/bin/sh script. :-D In fact, I wrote my patch in order to break their code and make btf people realize that they were doing wrong. > The change in the net-next tree turned link-vmlinux.sh into a bash script > (I think). > > I have applied the following patch for today: But, this is a temporary fix only for linux-next. scripts/link-vmlinux.sh does not need to use the bash-extension ${@:2} in the first place. I hope btf people will write the correct code. Thanks. > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Wed, 4 Sep 2019 15:43:41 +1000 > Subject: [PATCH] link-vmlinux.sh is now a bash script > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > Makefile | 4 ++-- > scripts/link-vmlinux.sh | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index ac97fb282d99..523d12c5cebe 100644 > --- a/Makefile > +++ b/Makefile > @@ -1087,7 +1087,7 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink) > > # Final link of vmlinux with optional arch pass after final link > cmd_link-vmlinux = \ > - $(CONFIG_SHELL) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ > + $(BASH) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true) > > vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE > @@ -1403,7 +1403,7 @@ clean: rm-files := $(CLEAN_FILES) > PHONY += archclean vmlinuxclean > > vmlinuxclean: > - $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean > + $(Q)$(BASH) $(srctree)/scripts/link-vmlinux.sh clean > $(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean) > > clean: archclean vmlinuxclean > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > index f7edb75f9806..ea1f8673869d 100755 > --- a/scripts/link-vmlinux.sh > +++ b/scripts/link-vmlinux.sh > @@ -1,4 +1,4 @@ > -#!/bin/sh > +#!/bin/bash > # SPDX-License-Identifier: GPL-2.0 > # > # link vmlinux > -- > 2.23.0.rc1 > > -- > Cheers, > Stephen Rothwell -- Best Regards Masahiro Yamada
On 9/3/19 11:00 PM, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > scripts/link-vmlinux.sh: 74: Bad substitution > > Caused by commit > > 341dfcf8d78e ("btf: expose BTF info through sysfs") > > interacting with commit > > 1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension") > > from the kbuild tree. > > The change in the net-next tree turned link-vmlinux.sh into a bash script > (I think). Hi Stephen, Sorry about this breakage. Indeed, ${@:2} is BASH-specific extension, unfortunately. I'm verifying a simple fix with shift and $@, I'll post and CC you as soon as I've verified everything. With that your temporary fix shouldn't be necessary. > > I have applied the following patch for today: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Wed, 4 Sep 2019 15:43:41 +1000 > Subject: [PATCH] link-vmlinux.sh is now a bash script > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > Makefile | 4 ++-- > scripts/link-vmlinux.sh | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index ac97fb282d99..523d12c5cebe 100644 > --- a/Makefile > +++ b/Makefile > @@ -1087,7 +1087,7 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink) > > # Final link of vmlinux with optional arch pass after final link > cmd_link-vmlinux = \ > - $(CONFIG_SHELL) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ > + $(BASH) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true) > > vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE > @@ -1403,7 +1403,7 @@ clean: rm-files := $(CLEAN_FILES) > PHONY += archclean vmlinuxclean > > vmlinuxclean: > - $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean > + $(Q)$(BASH) $(srctree)/scripts/link-vmlinux.sh clean > $(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean) > > clean: archclean vmlinuxclean > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > index f7edb75f9806..ea1f8673869d 100755 > --- a/scripts/link-vmlinux.sh > +++ b/scripts/link-vmlinux.sh > @@ -1,4 +1,4 @@ > -#!/bin/sh > +#!/bin/bash > # SPDX-License-Identifier: GPL-2.0 > # > # link vmlinux >
On Tue, Sep 3, 2019 at 11:20 PM Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > On Wed, Sep 4, 2019 at 3:00 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > Hi all, > > > > After merging the net-next tree, today's linux-next build (arm > > multi_v7_defconfig) failed like this: > > > > scripts/link-vmlinux.sh: 74: Bad substitution > > > > Caused by commit > > > > 341dfcf8d78e ("btf: expose BTF info through sysfs") > > > > interacting with commit > > > > 1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension") > > > > from the kbuild tree. > > > I knew that they were using bash-extension > in the #!/bin/sh script. :-D > > In fact, I wrote my patch in order to break their code > and make btf people realize that they were doing wrong. Was there a specific reason to wait until this would break during Stephen's merge, instead of giving me a heads up (or just replying on original patch) and letting me fix it and save everyone's time and efforts? Either way, I've fixed the issue in https://patchwork.ozlabs.org/patch/1158620/ and will pay way more attention to BASH-specific features going forward (I found it pretty hard to verify stuff like this, unfortunately). But again, code review process is the best place to catch this and I really hope in the future we can keep this process productive. Thanks! > > > > > The change in the net-next tree turned link-vmlinux.sh into a bash script > > (I think). > > > > I have applied the following patch for today: > > > But, this is a temporary fix only for linux-next. > > scripts/link-vmlinux.sh does not need to use the > bash-extension ${@:2} in the first place. > > I hope btf people will write the correct code. I replaced ${@:2} with shift and ${@}, I hope that's a correct fix, but if you think it's not, please reply on the patch and let me know. > > Thanks. > > > > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > Date: Wed, 4 Sep 2019 15:43:41 +1000 > > Subject: [PATCH] link-vmlinux.sh is now a bash script > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > --- > > Makefile | 4 ++-- > > scripts/link-vmlinux.sh | 2 +- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index ac97fb282d99..523d12c5cebe 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1087,7 +1087,7 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink) > > > > # Final link of vmlinux with optional arch pass after final link > > cmd_link-vmlinux = \ > > - $(CONFIG_SHELL) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ > > + $(BASH) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ > > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true) > > > > vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE > > @@ -1403,7 +1403,7 @@ clean: rm-files := $(CLEAN_FILES) > > PHONY += archclean vmlinuxclean > > > > vmlinuxclean: > > - $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean > > + $(Q)$(BASH) $(srctree)/scripts/link-vmlinux.sh clean > > $(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean) > > > > clean: archclean vmlinuxclean > > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > > index f7edb75f9806..ea1f8673869d 100755 > > --- a/scripts/link-vmlinux.sh > > +++ b/scripts/link-vmlinux.sh > > @@ -1,4 +1,4 @@ > > -#!/bin/sh > > +#!/bin/bash > > # SPDX-License-Identifier: GPL-2.0 > > # > > # link vmlinux > > -- > > 2.23.0.rc1 > > > > -- > > Cheers, > > Stephen Rothwell > > > > -- > Best Regards > Masahiro Yamada
On Fri, Sep 6, 2019 at 4:26 AM Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > On Tue, Sep 3, 2019 at 11:20 PM Masahiro Yamada > <yamada.masahiro@socionext.com> wrote: > > > > On Wed, Sep 4, 2019 at 3:00 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > Hi all, > > > > > > After merging the net-next tree, today's linux-next build (arm > > > multi_v7_defconfig) failed like this: > > > > > > scripts/link-vmlinux.sh: 74: Bad substitution > > > > > > Caused by commit > > > > > > 341dfcf8d78e ("btf: expose BTF info through sysfs") > > > > > > interacting with commit > > > > > > 1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension") > > > > > > from the kbuild tree. > > > > > > I knew that they were using bash-extension > > in the #!/bin/sh script. :-D > > > > In fact, I wrote my patch in order to break their code > > and make btf people realize that they were doing wrong. > > Was there a specific reason to wait until this would break during > Stephen's merge, instead of giving me a heads up (or just replying on > original patch) and letting me fix it and save everyone's time and > efforts? > > Either way, I've fixed the issue in > https://patchwork.ozlabs.org/patch/1158620/ and will pay way more > attention to BASH-specific features going forward (I found it pretty > hard to verify stuff like this, unfortunately). But again, code review > process is the best place to catch this and I really hope in the > future we can keep this process productive. Thanks! I could have pointed it out if I had noticed it in the review process. I actually noticed your patch by Stephen's former email. (i.e. when it appeared in linux-next) (I try my best to check kbuild ML, and also search for my name in LKML in case I am explicitly addressed, but a large number of emails fall off my filter) It was somewhat too late when I noticed it. Of course, I still could email you afterward, or even send a patch to btf ML, but I did not fix a particular instance of breakage because there are already the same type of breakages in code base. Then, I applied the all-or-nothing checker because I thought it was the only way to address the root cause of the problems. I admit I could have done the process better. Sorry if I made people uncomfortable and waste time. Thanks. > > > > > > > > > The change in the net-next tree turned link-vmlinux.sh into a bash script > > > (I think). > > > > > > I have applied the following patch for today: > > > > > > But, this is a temporary fix only for linux-next. > > > > scripts/link-vmlinux.sh does not need to use the > > bash-extension ${@:2} in the first place. > > > > I hope btf people will write the correct code. > > I replaced ${@:2} with shift and ${@}, I hope that's a correct fix, > but if you think it's not, please reply on the patch and let me know. > > > > > > Thanks. > > > > > > > > > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > > Date: Wed, 4 Sep 2019 15:43:41 +1000 > > > Subject: [PATCH] link-vmlinux.sh is now a bash script > > > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > > --- > > > Makefile | 4 ++-- > > > scripts/link-vmlinux.sh | 2 +- > > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/Makefile b/Makefile > > > index ac97fb282d99..523d12c5cebe 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -1087,7 +1087,7 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink) > > > > > > # Final link of vmlinux with optional arch pass after final link > > > cmd_link-vmlinux = \ > > > - $(CONFIG_SHELL) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ > > > + $(BASH) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ > > > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true) > > > > > > vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE > > > @@ -1403,7 +1403,7 @@ clean: rm-files := $(CLEAN_FILES) > > > PHONY += archclean vmlinuxclean > > > > > > vmlinuxclean: > > > - $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean > > > + $(Q)$(BASH) $(srctree)/scripts/link-vmlinux.sh clean > > > $(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean) > > > > > > clean: archclean vmlinuxclean > > > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > > > index f7edb75f9806..ea1f8673869d 100755 > > > --- a/scripts/link-vmlinux.sh > > > +++ b/scripts/link-vmlinux.sh > > > @@ -1,4 +1,4 @@ > > > -#!/bin/sh > > > +#!/bin/bash > > > # SPDX-License-Identifier: GPL-2.0 > > > # > > > # link vmlinux > > > -- > > > 2.23.0.rc1 > > > > > > -- > > > Cheers, > > > Stephen Rothwell > > > > > > > > -- > > Best Regards > > Masahiro Yamada -- Best Regards Masahiro Yamada
On Thu, Sep 5, 2019 at 7:53 PM Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > On Fri, Sep 6, 2019 at 4:26 AM Andrii Nakryiko > <andrii.nakryiko@gmail.com> wrote: > > > > On Tue, Sep 3, 2019 at 11:20 PM Masahiro Yamada > > <yamada.masahiro@socionext.com> wrote: > > > > > > On Wed, Sep 4, 2019 at 3:00 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > > > Hi all, > > > > > > > > After merging the net-next tree, today's linux-next build (arm > > > > multi_v7_defconfig) failed like this: > > > > > > > > scripts/link-vmlinux.sh: 74: Bad substitution > > > > > > > > Caused by commit > > > > > > > > 341dfcf8d78e ("btf: expose BTF info through sysfs") > > > > > > > > interacting with commit > > > > > > > > 1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension") > > > > > > > > from the kbuild tree. > > > > > > > > > I knew that they were using bash-extension > > > in the #!/bin/sh script. :-D > > > > > > In fact, I wrote my patch in order to break their code > > > and make btf people realize that they were doing wrong. > > > > Was there a specific reason to wait until this would break during > > Stephen's merge, instead of giving me a heads up (or just replying on > > original patch) and letting me fix it and save everyone's time and > > efforts? > > > > Either way, I've fixed the issue in > > https://patchwork.ozlabs.org/patch/1158620/ and will pay way more > > attention to BASH-specific features going forward (I found it pretty > > hard to verify stuff like this, unfortunately). But again, code review > > process is the best place to catch this and I really hope in the > > future we can keep this process productive. Thanks! > > I could have pointed it out if I had noticed > it in the review process. > > I actually noticed your patch by Stephen's > former email. (i.e. when it appeared in linux-next) > > (I try my best to check kbuild ML, and also search for > my name in LKML in case I am explicitly addressed, > but a large number of emails fall off my filter) > > It was somewhat too late when I noticed it. > Of course, I still could email you afterward, or even send a patch to btf ML, > but I did not fix a particular instance of breakage > because there are already the same type of breakages in code base. > > Then, I applied the all-or-nothing checker because I thought it was > the only way to address the root cause of the problems. > > I admit I could have done the process better. > Sorry if I made people uncomfortable and waste time. No worries. Thanks for candid answer. I just wanted to make sure there are no hard feelings and I can engage your expertise effectively in the future for kbuild stuff to ensure issues like this don't slip through, if we ever have to do anything like this for BPF-related things again. I'll keep CC'ing you and will add kbuild ML as well. Thanks! > > Thanks. > > > > > > > > > > > > > > > > > The change in the net-next tree turned link-vmlinux.sh into a bash script > > > > (I think). > > > > > > > > I have applied the following patch for today: > > > > > > > > > But, this is a temporary fix only for linux-next. > > > > > > scripts/link-vmlinux.sh does not need to use the > > > bash-extension ${@:2} in the first place. > > > > > > I hope btf people will write the correct code. > > > > I replaced ${@:2} with shift and ${@}, I hope that's a correct fix, > > but if you think it's not, please reply on the patch and let me know. > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > > > Date: Wed, 4 Sep 2019 15:43:41 +1000 > > > > Subject: [PATCH] link-vmlinux.sh is now a bash script > > > > > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > > > --- > > > > Makefile | 4 ++-- > > > > scripts/link-vmlinux.sh | 2 +- > > > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/Makefile b/Makefile > > > > index ac97fb282d99..523d12c5cebe 100644 > > > > --- a/Makefile > > > > +++ b/Makefile > > > > @@ -1087,7 +1087,7 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink) > > > > > > > > # Final link of vmlinux with optional arch pass after final link > > > > cmd_link-vmlinux = \ > > > > - $(CONFIG_SHELL) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ > > > > + $(BASH) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ; \ > > > > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true) > > > > > > > > vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE > > > > @@ -1403,7 +1403,7 @@ clean: rm-files := $(CLEAN_FILES) > > > > PHONY += archclean vmlinuxclean > > > > > > > > vmlinuxclean: > > > > - $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean > > > > + $(Q)$(BASH) $(srctree)/scripts/link-vmlinux.sh clean > > > > $(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean) > > > > > > > > clean: archclean vmlinuxclean > > > > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > > > > index f7edb75f9806..ea1f8673869d 100755 > > > > --- a/scripts/link-vmlinux.sh > > > > +++ b/scripts/link-vmlinux.sh > > > > @@ -1,4 +1,4 @@ > > > > -#!/bin/sh > > > > +#!/bin/bash > > > > # SPDX-License-Identifier: GPL-2.0 > > > > # > > > > # link vmlinux > > > > -- > > > > 2.23.0.rc1 > > > > > > > > -- > > > > Cheers, > > > > Stephen Rothwell > > > > > > > > > > > > -- > > > Best Regards > > > Masahiro Yamada > > > > -- > Best Regards > Masahiro Yamada
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powepc ppc44x_defconfig) failed like this: Caused by commit 0c65b2b90d13 ("net: of_get_phy_mode: Change API to solve int/unit warnings") I applied the following patch, but there is probably a nicer and more complete way to fix this. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 5 Nov 2019 19:49:55 +1100 Subject: [PATCH] fix up for "net: of_get_phy_mode: Change API to solve int/unit warnings" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/ibm/emac/core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c index 2e40425d8a34..8cb682754bd4 100644 --- a/drivers/net/ethernet/ibm/emac/core.c +++ b/drivers/net/ethernet/ibm/emac/core.c @@ -2850,6 +2850,7 @@ static int emac_init_config(struct emac_instance *dev) struct device_node *np = dev->ofdev->dev.of_node; const void *p; int err; + phy_interface_t phy_mode; /* Read config from device-tree */ if (emac_read_uint_prop(np, "mal-device", &dev->mal_ph, 1)) @@ -2898,9 +2899,11 @@ static int emac_init_config(struct emac_instance *dev) dev->mal_burst_size = 256; /* PHY mode needs some decoding */ - err = of_get_phy_mode(np, &dev->phy_mode); + err = of_get_phy_mode(np, &phy_mode); if (err) dev->phy_mode = PHY_INTERFACE_MODE_NA; + else + dev->phy_mode = phy_mode; /* Check EMAC version */ if (of_device_is_compatible(np, "ibm,emac4sync")) { -- 2.23.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Nov 05, 2019 at 07:53:41PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powepc > ppc44x_defconfig) failed like this: > > > Caused by commit > > 0c65b2b90d13 ("net: of_get_phy_mode: Change API to solve int/unit warnings") > > I applied the following patch, but there is probably a nicer and more > complete way to fix this. Hi Stephen I just received the 0-day about this. I did not know David had merged it! What you have works. So: Reviewed-by: Andrew Lunn <andrew@lunn.ch> The nicer way is a bit bigger. Is this too big to go in via you? Should i submit it via netdev, and you can drop your fix once this arrives? Andrew rom e4a023829b53e2a918df8d8486c65c3650af0690 Mon Sep 17 00:00:00 2001 From: Andrew Lunn <andrew@lunn.ch> Date: Tue, 5 Nov 2019 07:43:53 -0600 Subject: [PATCH] net: ethernet: emac: Fix phy mode type Pass a phy_interface_t to of_get_phy_mode(), by changing the type of phy_mode in the device structure. This then requires that zmii_attach() is also changes, since it takes a pointer to phy_mode. Signed-off-by: Andrew Lunn <andrew@lunn.ch> --- drivers/net/ethernet/ibm/emac/core.h | 2 +- drivers/net/ethernet/ibm/emac/zmii.c | 3 ++- drivers/net/ethernet/ibm/emac/zmii.h | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/ibm/emac/core.h b/drivers/net/ethernet/ibm/emac/core.h index e9cda024cbf6..89a1b0fea158 100644 --- a/drivers/net/ethernet/ibm/emac/core.h +++ b/drivers/net/ethernet/ibm/emac/core.h @@ -171,7 +171,7 @@ struct emac_instance { struct mal_commac commac; /* PHY infos */ - int phy_mode; + phy_interface_t phy_mode; u32 phy_map; u32 phy_address; u32 phy_feat_exc; diff --git a/drivers/net/ethernet/ibm/emac/zmii.c b/drivers/net/ethernet/ibm/emac/zmii.c index b9e821de2ac6..57a25c7a9e70 100644 --- a/drivers/net/ethernet/ibm/emac/zmii.c +++ b/drivers/net/ethernet/ibm/emac/zmii.c @@ -78,7 +78,8 @@ static inline u32 zmii_mode_mask(int mode, int input) } } -int zmii_attach(struct platform_device *ofdev, int input, int *mode) +int zmii_attach(struct platform_device *ofdev, int input, + phy_interface_t *mode) { struct zmii_instance *dev = platform_get_drvdata(ofdev); struct zmii_regs __iomem *p = dev->base; diff --git a/drivers/net/ethernet/ibm/emac/zmii.h b/drivers/net/ethernet/ibm/emac/zmii.h index 41d46e9b87ba..65daedc78594 100644 --- a/drivers/net/ethernet/ibm/emac/zmii.h +++ b/drivers/net/ethernet/ibm/emac/zmii.h @@ -50,7 +50,8 @@ struct zmii_instance { int zmii_init(void); void zmii_exit(void); -int zmii_attach(struct platform_device *ofdev, int input, int *mode); +int zmii_attach(struct platform_device *ofdev, int input, + phy_interface_t *mode); void zmii_detach(struct platform_device *ofdev, int input); void zmii_get_mdio(struct platform_device *ofdev, int input); void zmii_put_mdio(struct platform_device *ofdev, int input); -- 2.24.0.rc0 Andrew
[-- Attachment #1: Type: text/plain, Size: 930 bytes --] Hi Andrew, On Tue, 5 Nov 2019 14:50:54 +0100 Andrew Lunn <andrew@lunn.ch> wrote: > > On Tue, Nov 05, 2019 at 07:53:41PM +1100, Stephen Rothwell wrote: > > > > After merging the net-next tree, today's linux-next build (powepc > > ppc44x_defconfig) failed like this: > > > > Sorry about leaving the error out :-( > > Caused by commit > > > > 0c65b2b90d13 ("net: of_get_phy_mode: Change API to solve int/unit warnings") > > > > I applied the following patch, but there is probably a nicer and more > > complete way to fix this. > > I just received the 0-day about this. I did not know David had merged > it! > > What you have works. So: > > Reviewed-by: Andrew Lunn <andrew@lunn.ch> > > The nicer way is a bit bigger. Is this too big to go in via you? > Should i submit it via netdev, and you can drop your fix once this > arrives? via Dave, thanks. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 571 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: arm-linux-gnueabi-ld: drivers/net/ethernet/stmicro/stmmac/stmmac_tc.o: in function `tc_setup_taprio': stmmac_tc.c:(.text+0x4e8): undefined reference to `__aeabi_uldivmod' arm-linux-gnueabi-ld: stmmac_tc.c:(.text+0x508): undefined reference to `__aeabi_uldivmod' Caused by commit b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") I have used the net-nest tree from next-20191218 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Dec/18/2019, 22:32:18 (UTC+00:00)
> Hi all,
>
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> arm-linux-gnueabi-ld: drivers/net/ethernet/stmicro/stmmac/stmmac_tc.o: in function `tc_setup_taprio':
> stmmac_tc.c:(.text+0x4e8): undefined reference to `__aeabi_uldivmod'
> arm-linux-gnueabi-ld: stmmac_tc.c:(.text+0x508): undefined reference to `__aeabi_uldivmod'
>
> Caused by commit
>
> b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API")
>
> I have used the net-nest tree from next-20191218 for today.
> --
> Cheers,
> Stephen Rothwell
Hi Stephen,
I'll try to fix it still today. Sorry for the mess.
---
Thanks,
Jose Miguel Abreu
From: Jose Abreu <joabreu@synopsys.com> Date: Dec/18/2019, 22:38:15 (UTC+00:00) > I'll try to fix it still today. Please check if following patch makes it work: https://marc.info/?l=linux -netdev&m=157670971305055&w=2 Unfortunately, I don't have an ARM compiled tree right now to test. --- Thanks, Jose Miguel Abreu
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c: In function '__mlxsw_sp_qdisc_ets_graft': drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c:770:7: error: 'p' undeclared (first use in this function); did you mean 'up'? 770 | if (!p->child_handle) { | ^ | up Caused by commit 345457a6e2cd ("Merge remote-tracking branch 'net-next/master'") i.e. an incorrect automatic merge between commit 3971a535b839 ("mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO") from Linus' tree and commit 7917f52ae188 ("mlxsw: spectrum_qdisc: Generalize PRIO offload to support ETS") from the net-next tree. I have applied the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 10 Jan 2020 10:52:33 +1100 Subject: [PATCH] mlxws: fix up for "mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c index 17b29e2d19ed..54807b4930fe 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c @@ -767,7 +767,7 @@ __mlxsw_sp_qdisc_ets_graft(struct mlxsw_sp_port *mlxsw_sp_port, mlxsw_sp_port->tclass_qdiscs[tclass_num].handle == child_handle) return 0; - if (!p->child_handle) { + if (!child_handle) { /* This is an invisible FIFO replacing the original Qdisc. * Ignore it--the original Qdisc's destroy will follow. */ -- 2.24.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 10 Jan 2020 10:57:38 +1100
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c
> index 17b29e2d19ed..54807b4930fe 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c
> @@ -767,7 +767,7 @@ __mlxsw_sp_qdisc_ets_graft(struct mlxsw_sp_port *mlxsw_sp_port,
> mlxsw_sp_port->tclass_qdiscs[tclass_num].handle == child_handle)
> return 0;
>
> - if (!p->child_handle) {
> + if (!child_handle) {
> /* This is an invisible FIFO replacing the original Qdisc.
> * Ignore it--the original Qdisc's destroy will follow.
> */
> --
> 2.24.0
Yep, this is the merge resolution you will find in net-next at commit:
commit a2d6d7ae591c47ebc04926cb29a840adfdde49e6
Merge: b1daa4d19473 e69ec487b2c7
Author: David S. Miller <davem@davemloft.net>
Date: Thu Jan 9 12:10:26 2020 -0800
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
The ungrafting from PRIO bug fixes in net, when merged into net-next,
merge cleanly but create a build failure. The resolution used here is
from Petr Machata.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --cc drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c
index 81a2c087f534,46d43cfd04e9..54807b4930fe
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c
@@@ -681,92 -631,33 +681,99 @@@ static struct mlxsw_sp_qdisc_ops mlxsw_
.clean_stats = mlxsw_sp_setup_tc_qdisc_prio_clean_stats,
};
-/* Grafting is not supported in mlxsw. It will result in un-offloading of the
- * grafted qdisc as well as the qdisc in the qdisc new location.
- * (However, if the graft is to the location where the qdisc is already at, it
- * will be ignored completely and won't cause un-offloading).
+static int
+mlxsw_sp_qdisc_ets_check_params(struct mlxsw_sp_port *mlxsw_sp_port,
+ struct mlxsw_sp_qdisc *mlxsw_sp_qdisc,
+ void *params)
+{
+ struct tc_ets_qopt_offload_replace_params *p = params;
+
+ return __mlxsw_sp_qdisc_ets_check_params(p->bands);
+}
+
+static int
+mlxsw_sp_qdisc_ets_replace(struct mlxsw_sp_port *mlxsw_sp_port,
+ struct mlxsw_sp_qdisc *mlxsw_sp_qdisc,
+ void *params)
+{
+ struct tc_ets_qopt_offload_replace_params *p = params;
+
+ return __mlxsw_sp_qdisc_ets_replace(mlxsw_sp_port, p->bands,
+ p->quanta, p->weights, p->priomap);
+}
+
+static void
+mlxsw_sp_qdisc_ets_unoffload(struct mlxsw_sp_port *mlxsw_sp_port,
+ struct mlxsw_sp_qdisc *mlxsw_sp_qdisc,
+ void *params)
+{
+ struct tc_ets_qopt_offload_replace_params *p = params;
+
+ __mlxsw_sp_qdisc_ets_unoffload(mlxsw_sp_port, mlxsw_sp_qdisc,
+ p->qstats);
+}
+
+static int
+mlxsw_sp_qdisc_ets_destroy(struct mlxsw_sp_port *mlxsw_sp_port,
+ struct mlxsw_sp_qdisc *mlxsw_sp_qdisc)
+{
+ return __mlxsw_sp_qdisc_ets_destroy(mlxsw_sp_port);
+}
+
+static struct mlxsw_sp_qdisc_ops mlxsw_sp_qdisc_ops_ets = {
+ .type = MLXSW_SP_QDISC_ETS,
+ .check_params = mlxsw_sp_qdisc_ets_check_params,
+ .replace = mlxsw_sp_qdisc_ets_replace,
+ .unoffload = mlxsw_sp_qdisc_ets_unoffload,
+ .destroy = mlxsw_sp_qdisc_ets_destroy,
+ .get_stats = mlxsw_sp_qdisc_get_prio_stats,
+ .clean_stats = mlxsw_sp_setup_tc_qdisc_prio_clean_stats,
+};
+
+/* Linux allows linking of Qdiscs to arbitrary classes (so long as the resulting
+ * graph is free of cycles). These operations do not change the parent handle
+ * though, which means it can be incomplete (if there is more than one class
+ * where the Qdisc in question is grafted) or outright wrong (if the Qdisc was
+ * linked to a different class and then removed from the original class).
+ *
+ * E.g. consider this sequence of operations:
+ *
+ * # tc qdisc add dev swp1 root handle 1: prio
+ * # tc qdisc add dev swp1 parent 1:3 handle 13: red limit 1000000 avpkt 10000
+ * RED: set bandwidth to 10Mbit
+ * # tc qdisc link dev swp1 handle 13: parent 1:2
+ *
+ * At this point, both 1:2 and 1:3 have the same RED Qdisc instance as their
+ * child. But RED will still only claim that 1:3 is its parent. If it's removed
+ * from that band, its only parent will be 1:2, but it will continue to claim
+ * that it is in fact 1:3.
+ *
+ * The notification for child Qdisc replace (e.g. TC_RED_REPLACE) comes before
+ * the notification for parent graft (e.g. TC_PRIO_GRAFT). We take the replace
+ * notification to offload the child Qdisc, based on its parent handle, and use
+ * the graft operation to validate that the class where the child is actually
+ * grafted corresponds to the parent handle. If the two don't match, we
+ * unoffload the child.
*/
static int
-mlxsw_sp_qdisc_prio_graft(struct mlxsw_sp_port *mlxsw_sp_port,
- struct mlxsw_sp_qdisc *mlxsw_sp_qdisc,
- struct tc_prio_qopt_offload_graft_params *p)
+__mlxsw_sp_qdisc_ets_graft(struct mlxsw_sp_port *mlxsw_sp_port,
+ struct mlxsw_sp_qdisc *mlxsw_sp_qdisc,
+ u8 band, u32 child_handle)
{
- int tclass_num = MLXSW_SP_PRIO_BAND_TO_TCLASS(p->band);
+ int tclass_num = MLXSW_SP_PRIO_BAND_TO_TCLASS(band);
struct mlxsw_sp_qdisc *old_qdisc;
- /* Check if the grafted qdisc is already in its "new" location. If so -
- * nothing needs to be done.
- */
- if (p->band < IEEE_8021QAZ_MAX_TCS &&
- mlxsw_sp_port->tclass_qdiscs[tclass_num].handle == p->child_handle)
+ if (band < IEEE_8021QAZ_MAX_TCS &&
+ mlxsw_sp_port->tclass_qdiscs[tclass_num].handle == child_handle)
return 0;
- if (!p->child_handle) {
++ if (!child_handle) {
+ /* This is an invisible FIFO replacing the original Qdisc.
+ * Ignore it--the original Qdisc's destroy will follow.
+ */
+ return 0;
+ }
+
/* See if the grafted qdisc is already offloaded on any tclass. If so,
* unoffload it.
*/
[-- Attachment #1: Type: text/plain, Size: 336 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc defconfig) failed like this: ERROR: "__umoddi3" [net/core/pktgen.ko] undefined! Caused by commit 7786a1af2a6b ("pktgen: Allow configuration of IPv6 source address range") I have reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 16 Jan 2020 18:53:37 +1100
> After merging the net-next tree, today's linux-next build (sparc
> defconfig) failed like this:
>
> ERROR: "__umoddi3" [net/core/pktgen.ko] undefined!
>
> Caused by commit
>
> 7786a1af2a6b ("pktgen: Allow configuration of IPv6 source address range")
>
> I have reverted that commit for today.
Niu Xilei, you must fix this or else I will have to revert your pktgen
changes.
You cannot do direct division or modulus on 64-bit integer values,
instead you must use the various div*() helper macros so that it works
on all 32-bit systems too.
Thank you.
[-- Attachment #1: Type: text/plain, Size: 800 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/bridge/br_netlink_tunnel.c: In function '__vlan_tunnel_handle_range': net/bridge/br_netlink_tunnel.c:271:26: error: implicit declaration of function 'br_vlan_can_enter_range'; did you mean 'br_vlan_valid_range'? [-Werror=implicit-function-declaration] 271 | if (v && curr_change && br_vlan_can_enter_range(v, *v_end)) { | ^~~~~~~~~~~~~~~~~~~~~~~ | br_vlan_valid_range Caused by commit 94339443686b ("net: bridge: notify on vlan tunnel changes done via the old api") CONFIG_BRIDGE_VLAN_FILTERING is not set for this build. I have reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 13/07/2020 04:54, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/bridge/br_netlink_tunnel.c: In function '__vlan_tunnel_handle_range':
> net/bridge/br_netlink_tunnel.c:271:26: error: implicit declaration of function 'br_vlan_can_enter_range'; did you mean 'br_vlan_valid_range'? [-Werror=implicit-function-declaration]
> 271 | if (v && curr_change && br_vlan_can_enter_range(v, *v_end)) {
> | ^~~~~~~~~~~~~~~~~~~~~~~
> | br_vlan_valid_range
>
> Caused by commit
>
> 94339443686b ("net: bridge: notify on vlan tunnel changes done via the old api")
>
> CONFIG_BRIDGE_VLAN_FILTERING is not set for this build.
>
> I have reverted that commit for today.
>
Oops, sorry that's my bad. I mixed br_netlink_tunnel with br_vlan_tunnel, the latter is compiled only
when bridge vlan filtering is defined.
Anyway, I'll post a fix ASAP.
Thanks.
[-- Attachment #1: Type: text/plain, Size: 938 bytes --] Hi all, After merging the net-next tree, today's linux-next build (i386 defconfig) failed like this: x86_64-linux-gnu-ld: net/core/fib_rules.o: in function `fib_rules_lookup': fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match' x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to `fib6_rule_match' x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to `fib6_rule_action' x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to `fib6_rule_action' x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to `fib6_rule_suppress' x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to `fib6_rule_suppress' Caused by commit b9aaec8f0be5 ("fib: use indirect call wrappers in the most common fib_rules_ops") # CONFIG_IPV6_MULTIPLE_TABLES is not set I have reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen, thanks for reaching out and reporting the issue. I have just sent the fix for review in net-next: http://patchwork.ozlabs.org/project/netdev/patch/20200729181018.3221288-1-brianvv@google.com/ cheers, Brian On Wed, Jul 29, 2020 at 4:27 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (i386 defconfig) > failed like this: > > x86_64-linux-gnu-ld: net/core/fib_rules.o: in function `fib_rules_lookup': > fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match' > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to `fib6_rule_match' > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to `fib6_rule_action' > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to `fib6_rule_action' > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to `fib6_rule_suppress' > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to `fib6_rule_suppress' > > Caused by commit > > b9aaec8f0be5 ("fib: use indirect call wrappers in the most common fib_rules_ops") > > # CONFIG_IPV6_MULTIPLE_TABLES is not set > > I have reverted that commit for today. > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 380 bytes --] Hi all, After merging the net-next tree, today's linux-next build (s390 defconfig) failed like this: net/ipv4/ip_tunnel_core.c:335:2: error: implicit declaration of function 'csum_ipv6_magic' [-Werror=implicit-function-declaration] Caused by commit 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, 5 Aug 2020 22:31:21 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (s390 defconfig)
> failed like this:
>
> net/ipv4/ip_tunnel_core.c:335:2: error: implicit declaration of function 'csum_ipv6_magic' [-Werror=implicit-function-declaration]
>
> Caused by commit
>
> 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets")
Ouch, sorry for that.
I'm getting a few of them by the way:
---
net/core/skbuff.o: In function `skb_checksum_setup_ipv6':
/home/sbrivio/net-next/net/core/skbuff.c:4980: undefined reference to `csum_ipv6_magic'
net/core/netpoll.o: In function `netpoll_send_udp':
/home/sbrivio/net-next/net/core/netpoll.c:419: undefined reference to `csum_ipv6_magic'
net/netfilter/utils.o: In function `nf_ip6_checksum':
/home/sbrivio/net-next/net/netfilter/utils.c:74: undefined reference to `csum_ipv6_magic'
/home/sbrivio/net-next/net/netfilter/utils.c:84: undefined reference to `csum_ipv6_magic'
net/netfilter/utils.o: In function `nf_ip6_checksum_partial':
/home/sbrivio/net-next/net/netfilter/utils.c:112: undefined reference to `csum_ipv6_magic'
net/ipv4/ip_tunnel_core.o:/home/sbrivio/net-next/net/ipv4/ip_tunnel_core.c:335: more undefined references to `csum_ipv6_magic' follow
---
...checking how it should be fixed now.
Heiko, by the way, do we want to provide a s390 version similar to the
existing csum_partial() implementation in
arch/s390/include/asm/checksum.h right away? Otherwise, I'll just take
care of the ifdeffery.
--
Stefano
On Wed, Aug 05, 2020 at 03:06:27PM +0200, Stefano Brivio wrote:
> On Wed, 5 Aug 2020 22:31:21 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (s390 defconfig)
> > failed like this:
> >
> > net/ipv4/ip_tunnel_core.c:335:2: error: implicit declaration of function 'csum_ipv6_magic' [-Werror=implicit-function-declaration]
> >
> > Caused by commit
> >
> > 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets")
>
> Ouch, sorry for that.
>
> I'm getting a few of them by the way:
>
> ---
> net/core/skbuff.o: In function `skb_checksum_setup_ipv6':
> /home/sbrivio/net-next/net/core/skbuff.c:4980: undefined reference to `csum_ipv6_magic'
> net/core/netpoll.o: In function `netpoll_send_udp':
> /home/sbrivio/net-next/net/core/netpoll.c:419: undefined reference to `csum_ipv6_magic'
> net/netfilter/utils.o: In function `nf_ip6_checksum':
> /home/sbrivio/net-next/net/netfilter/utils.c:74: undefined reference to `csum_ipv6_magic'
> /home/sbrivio/net-next/net/netfilter/utils.c:84: undefined reference to `csum_ipv6_magic'
> net/netfilter/utils.o: In function `nf_ip6_checksum_partial':
> /home/sbrivio/net-next/net/netfilter/utils.c:112: undefined reference to `csum_ipv6_magic'
> net/ipv4/ip_tunnel_core.o:/home/sbrivio/net-next/net/ipv4/ip_tunnel_core.c:335: more undefined references to `csum_ipv6_magic' follow
> ---
>
> ...checking how it should be fixed now.
>
> Heiko, by the way, do we want to provide a s390 version similar to the
> existing csum_partial() implementation in
> arch/s390/include/asm/checksum.h right away? Otherwise, I'll just take
> care of the ifdeffery.
You probably only need to include include/net/ip6_checksum.h which
contains the default implementation.
And yes, I put it on my todo list that we need to provide an s390
variant as well.
On Wed, 5 Aug 2020 15:21:44 +0200
Heiko Carstens <hca@linux.ibm.com> wrote:
> On Wed, Aug 05, 2020 at 03:06:27PM +0200, Stefano Brivio wrote:
> > On Wed, 5 Aug 2020 22:31:21 +1000
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Hi all,
> > >
> > > After merging the net-next tree, today's linux-next build (s390 defconfig)
> > > failed like this:
> > >
> > > net/ipv4/ip_tunnel_core.c:335:2: error: implicit declaration of function 'csum_ipv6_magic' [-Werror=implicit-function-declaration]
> > >
> > > Caused by commit
> > >
> > > 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets")
> >
> > Ouch, sorry for that.
> >
> > I'm getting a few of them by the way:
> >
> > ---
> > net/core/skbuff.o: In function `skb_checksum_setup_ipv6':
> > /home/sbrivio/net-next/net/core/skbuff.c:4980: undefined reference to `csum_ipv6_magic'
> > net/core/netpoll.o: In function `netpoll_send_udp':
> > /home/sbrivio/net-next/net/core/netpoll.c:419: undefined reference to `csum_ipv6_magic'
> > net/netfilter/utils.o: In function `nf_ip6_checksum':
> > /home/sbrivio/net-next/net/netfilter/utils.c:74: undefined reference to `csum_ipv6_magic'
> > /home/sbrivio/net-next/net/netfilter/utils.c:84: undefined reference to `csum_ipv6_magic'
> > net/netfilter/utils.o: In function `nf_ip6_checksum_partial':
> > /home/sbrivio/net-next/net/netfilter/utils.c:112: undefined reference to `csum_ipv6_magic'
> > net/ipv4/ip_tunnel_core.o:/home/sbrivio/net-next/net/ipv4/ip_tunnel_core.c:335: more undefined references to `csum_ipv6_magic' follow
> > ---
> >
> > ...checking how it should be fixed now.
> >
> > Heiko, by the way, do we want to provide a s390 version similar to the
> > existing csum_partial() implementation in
> > arch/s390/include/asm/checksum.h right away? Otherwise, I'll just take
> > care of the ifdeffery.
>
> You probably only need to include include/net/ip6_checksum.h which
> contains the default implementation.
Yes, patch already sent a couple of minutes ago, still waiting for it to
reach the lists. Thanks!
--
Stefano
On 2020-07-29 21:27 +1000, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (i386 defconfig) > failed like this: > > x86_64-linux-gnu-ld: net/core/fib_rules.o: in function `fib_rules_lookup': > fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match' > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to `fib6_rule_match' > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to `fib6_rule_action' > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to `fib6_rule_action' > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to `fib6_rule_suppress' > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to `fib6_rule_suppress' FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was apparently not sufficient. ,---- | $ grep IPV6 .config | CONFIG_IPV6=m | # CONFIG_IPV6_ROUTER_PREF is not set | # CONFIG_IPV6_OPTIMISTIC_DAD is not set | # CONFIG_IPV6_MIP6 is not set | # CONFIG_IPV6_ILA is not set | # CONFIG_IPV6_VTI is not set | CONFIG_IPV6_SIT=m | # CONFIG_IPV6_SIT_6RD is not set | CONFIG_IPV6_NDISC_NODETYPE=y | CONFIG_IPV6_TUNNEL=m | CONFIG_IPV6_MULTIPLE_TABLES=y | # CONFIG_IPV6_SUBTREES is not set | # CONFIG_IPV6_MROUTE is not set | # CONFIG_IPV6_SEG6_LWTUNNEL is not set | # CONFIG_IPV6_SEG6_HMAC is not set | # CONFIG_IPV6_RPL_LWTUNNEL is not set | # CONFIG_NF_SOCKET_IPV6 is not set | # CONFIG_NF_TPROXY_IPV6 is not set | # CONFIG_NF_DUP_IPV6 is not set | # CONFIG_NF_REJECT_IPV6 is not set | # CONFIG_NF_LOG_IPV6 is not set | CONFIG_NF_DEFRAG_IPV6=m `---- > Caused by commit > > b9aaec8f0be5 ("fib: use indirect call wrappers in the most common fib_rules_ops") > > # CONFIG_IPV6_MULTIPLE_TABLES is not set > > I have reverted that commit for today. Cheers, Sven
On 2020-08-21 09:23 -0700, Brian Vazquez wrote: > Hi Sven, > > Sorry for the late reply, did you still see this after: > https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaibing@huawei.com/ > ?? That patch is apparently already in 5.9-rc1 as commit 80fbbb1672e7, so yes I'm still seeing it. Cheers, Sven > On Mon, Aug 17, 2020 at 12:21 AM Sven Joachim <svenjoac@gmx.de> wrote: > >> On 2020-07-29 21:27 +1000, Stephen Rothwell wrote: >> >> > Hi all, >> > >> > After merging the net-next tree, today's linux-next build (i386 >> defconfig) >> > failed like this: >> > >> > x86_64-linux-gnu-ld: net/core/fib_rules.o: in function >> `fib_rules_lookup': >> > fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match' >> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to >> `fib6_rule_match' >> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to >> `fib6_rule_action' >> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to >> `fib6_rule_action' >> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to >> `fib6_rule_suppress' >> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to >> `fib6_rule_suppress' >> >> FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit >> 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was >> apparently not sufficient. >> >> ,---- >> | $ grep IPV6 .config >> | CONFIG_IPV6=m >> | # CONFIG_IPV6_ROUTER_PREF is not set >> | # CONFIG_IPV6_OPTIMISTIC_DAD is not set >> | # CONFIG_IPV6_MIP6 is not set >> | # CONFIG_IPV6_ILA is not set >> | # CONFIG_IPV6_VTI is not set >> | CONFIG_IPV6_SIT=m >> | # CONFIG_IPV6_SIT_6RD is not set >> | CONFIG_IPV6_NDISC_NODETYPE=y >> | CONFIG_IPV6_TUNNEL=m >> | CONFIG_IPV6_MULTIPLE_TABLES=y >> | # CONFIG_IPV6_SUBTREES is not set >> | # CONFIG_IPV6_MROUTE is not set >> | # CONFIG_IPV6_SEG6_LWTUNNEL is not set >> | # CONFIG_IPV6_SEG6_HMAC is not set >> | # CONFIG_IPV6_RPL_LWTUNNEL is not set >> | # CONFIG_NF_SOCKET_IPV6 is not set >> | # CONFIG_NF_TPROXY_IPV6 is not set >> | # CONFIG_NF_DUP_IPV6 is not set >> | # CONFIG_NF_REJECT_IPV6 is not set >> | # CONFIG_NF_LOG_IPV6 is not set >> | CONFIG_NF_DEFRAG_IPV6=m >> `---- >> >> > Caused by commit >> > >> > b9aaec8f0be5 ("fib: use indirect call wrappers in the most common >> fib_rules_ops") >> > >> > # CONFIG_IPV6_MULTIPLE_TABLES is not set >> > >> > I have reverted that commit for today. >> >> Cheers, >> Sven >>
[-- Attachment #1: Type: text/plain, Size: 750 bytes --] On 2020-08-22 08:16 +0200, Sven Joachim wrote: > On 2020-08-21 09:23 -0700, Brian Vazquez wrote: > >> Hi Sven, >> >> Sorry for the late reply, did you still see this after: >> https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaibing@huawei.com/ >> ?? > > That patch is apparently already in 5.9-rc1 as commit 80fbbb1672e7, so > yes I'm still seeing it. Still present in 5.9-rc2 as of today, I have attached my .config for reference. Note that I have CONFIG_IPV6_MULTIPLE_TABLES=y, but CONFIG_IP_MULTIPLE_TABLES is not mentioned at all there. To build the kernel, I have now deselected IPV6_MULTIPLE_TABLES. Not sure why this was enabled in my .config which has grown organically over many years. Cheers, Sven [-- Attachment #2: .config.xz --] [-- Type: application/x-xz, Size: 22188 bytes --] [-- Attachment #3: Type: text/plain, Size: 2239 bytes --] >> On Mon, Aug 17, 2020 at 12:21 AM Sven Joachim <svenjoac@gmx.de> wrote: >> >>> On 2020-07-29 21:27 +1000, Stephen Rothwell wrote: >>> >>> > Hi all, >>> > >>> > After merging the net-next tree, today's linux-next build (i386 >>> defconfig) >>> > failed like this: >>> > >>> > x86_64-linux-gnu-ld: net/core/fib_rules.o: in function >>> `fib_rules_lookup': >>> > fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match' >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to >>> `fib6_rule_match' >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to >>> `fib6_rule_action' >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to >>> `fib6_rule_action' >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to >>> `fib6_rule_suppress' >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to >>> `fib6_rule_suppress' >>> >>> FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit >>> 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was >>> apparently not sufficient. >>> >>> ,---- >>> | $ grep IPV6 .config >>> | CONFIG_IPV6=m >>> | # CONFIG_IPV6_ROUTER_PREF is not set >>> | # CONFIG_IPV6_OPTIMISTIC_DAD is not set >>> | # CONFIG_IPV6_MIP6 is not set >>> | # CONFIG_IPV6_ILA is not set >>> | # CONFIG_IPV6_VTI is not set >>> | CONFIG_IPV6_SIT=m >>> | # CONFIG_IPV6_SIT_6RD is not set >>> | CONFIG_IPV6_NDISC_NODETYPE=y >>> | CONFIG_IPV6_TUNNEL=m >>> | CONFIG_IPV6_MULTIPLE_TABLES=y >>> | # CONFIG_IPV6_SUBTREES is not set >>> | # CONFIG_IPV6_MROUTE is not set >>> | # CONFIG_IPV6_SEG6_LWTUNNEL is not set >>> | # CONFIG_IPV6_SEG6_HMAC is not set >>> | # CONFIG_IPV6_RPL_LWTUNNEL is not set >>> | # CONFIG_NF_SOCKET_IPV6 is not set >>> | # CONFIG_NF_TPROXY_IPV6 is not set >>> | # CONFIG_NF_DUP_IPV6 is not set >>> | # CONFIG_NF_REJECT_IPV6 is not set >>> | # CONFIG_NF_LOG_IPV6 is not set >>> | CONFIG_NF_DEFRAG_IPV6=m >>> `---- >>> >>> > Caused by commit >>> > >>> > b9aaec8f0be5 ("fib: use indirect call wrappers in the most common >>> fib_rules_ops") >>> > >>> > # CONFIG_IPV6_MULTIPLE_TABLES is not set >>> > >>> > I have reverted that commit for today. >>> >>> Cheers, >>> Sven >>>
Hi Sven,
I've been trying to reproduce it with your config but I didn't
succeed. I also looked at the file after the preprocessor and it
looked good:
ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ?
fib6_rule_match(rule, fl, flags) : ops->match(rule, fl, flags); })
Note that fib4_rule_match doesn't appear as the
CONFIG_IP_MULTIPLE_TABLES is not there.
Could you share more details on how you're compiling it and what
compiler you're using??
Thanks,
Brian
On Mon, Aug 24, 2020 at 1:08 AM Sven Joachim <svenjoac@gmx.de> wrote:
>
> On 2020-08-22 08:16 +0200, Sven Joachim wrote:
>
> > On 2020-08-21 09:23 -0700, Brian Vazquez wrote:
> >
> >> Hi Sven,
> >>
> >> Sorry for the late reply, did you still see this after:
> >> https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaibing@huawei.com/
> >> ??
> >
> > That patch is apparently already in 5.9-rc1 as commit 80fbbb1672e7, so
> > yes I'm still seeing it.
>
> Still present in 5.9-rc2 as of today, I have attached my .config for
> reference. Note that I have CONFIG_IPV6_MULTIPLE_TABLES=y, but
> CONFIG_IP_MULTIPLE_TABLES is not mentioned at all there.
>
> To build the kernel, I have now deselected IPV6_MULTIPLE_TABLES. Not
> sure why this was enabled in my .config which has grown organically over
> many years.
>
> Cheers,
> Sven
>
>
> >> On Mon, Aug 17, 2020 at 12:21 AM Sven Joachim <svenjoac@gmx.de> wrote:
> >>
> >>> On 2020-07-29 21:27 +1000, Stephen Rothwell wrote:
> >>>
> >>> > Hi all,
> >>> >
> >>> > After merging the net-next tree, today's linux-next build (i386
> >>> defconfig)
> >>> > failed like this:
> >>> >
> >>> > x86_64-linux-gnu-ld: net/core/fib_rules.o: in function
> >>> `fib_rules_lookup':
> >>> > fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match'
> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to
> >>> `fib6_rule_match'
> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to
> >>> `fib6_rule_action'
> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to
> >>> `fib6_rule_action'
> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to
> >>> `fib6_rule_suppress'
> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to
> >>> `fib6_rule_suppress'
> >>>
> >>> FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit
> >>> 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was
> >>> apparently not sufficient.
> >>>
> >>> ,----
> >>> | $ grep IPV6 .config
> >>> | CONFIG_IPV6=m
> >>> | # CONFIG_IPV6_ROUTER_PREF is not set
> >>> | # CONFIG_IPV6_OPTIMISTIC_DAD is not set
> >>> | # CONFIG_IPV6_MIP6 is not set
> >>> | # CONFIG_IPV6_ILA is not set
> >>> | # CONFIG_IPV6_VTI is not set
> >>> | CONFIG_IPV6_SIT=m
> >>> | # CONFIG_IPV6_SIT_6RD is not set
> >>> | CONFIG_IPV6_NDISC_NODETYPE=y
> >>> | CONFIG_IPV6_TUNNEL=m
> >>> | CONFIG_IPV6_MULTIPLE_TABLES=y
> >>> | # CONFIG_IPV6_SUBTREES is not set
> >>> | # CONFIG_IPV6_MROUTE is not set
> >>> | # CONFIG_IPV6_SEG6_LWTUNNEL is not set
> >>> | # CONFIG_IPV6_SEG6_HMAC is not set
> >>> | # CONFIG_IPV6_RPL_LWTUNNEL is not set
> >>> | # CONFIG_NF_SOCKET_IPV6 is not set
> >>> | # CONFIG_NF_TPROXY_IPV6 is not set
> >>> | # CONFIG_NF_DUP_IPV6 is not set
> >>> | # CONFIG_NF_REJECT_IPV6 is not set
> >>> | # CONFIG_NF_LOG_IPV6 is not set
> >>> | CONFIG_NF_DEFRAG_IPV6=m
> >>> `----
> >>>
> >>> > Caused by commit
> >>> >
> >>> > b9aaec8f0be5 ("fib: use indirect call wrappers in the most common
> >>> fib_rules_ops")
> >>> >
> >>> > # CONFIG_IPV6_MULTIPLE_TABLES is not set
> >>> >
> >>> > I have reverted that commit for today.
> >>>
> >>> Cheers,
> >>> Sven
> >>>
On 2020-08-27 11:12 -0700, Brian Vazquez wrote: > I've been trying to reproduce it with your config but I didn't > succeed. I also looked at the file after the preprocessor and it > looked good: > > ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ? > fib6_rule_match(rule, fl, flags) : ops->match(rule, fl, flags); }) However, in my configuration I have CONFIG_IPV6=m, and so fib6_rule_match is not available as a builtin. I think that's why ld is complaining about the undefined reference. Changing the configuration to CONFIG_IPV6=y helps, FWIW. > Note that fib4_rule_match doesn't appear as the > CONFIG_IP_MULTIPLE_TABLES is not there. > > Could you share more details on how you're compiling it and what > compiler you're using?? Tried with both gcc 9 and gcc 10 under Debian unstable, binutils 2.35. I usually use "make bindebpkg", but just running "make" is sufficient to reproduce the problem, as it happens when linking vmlinux. Cheers, Sven > On Mon, Aug 24, 2020 at 1:08 AM Sven Joachim <svenjoac@gmx.de> wrote: >> >> On 2020-08-22 08:16 +0200, Sven Joachim wrote: >> >> > On 2020-08-21 09:23 -0700, Brian Vazquez wrote: >> > >> >> Hi Sven, >> >> >> >> Sorry for the late reply, did you still see this after: >> >> https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaibing@huawei.com/ >> >> ?? >> > >> > That patch is apparently already in 5.9-rc1 as commit 80fbbb1672e7, so >> > yes I'm still seeing it. >> >> Still present in 5.9-rc2 as of today, I have attached my .config for >> reference. Note that I have CONFIG_IPV6_MULTIPLE_TABLES=y, but >> CONFIG_IP_MULTIPLE_TABLES is not mentioned at all there. >> >> To build the kernel, I have now deselected IPV6_MULTIPLE_TABLES. Not >> sure why this was enabled in my .config which has grown organically over >> many years. >> >> Cheers, >> Sven >> >> >> >> On Mon, Aug 17, 2020 at 12:21 AM Sven Joachim <svenjoac@gmx.de> wrote: >> >> >> >>> On 2020-07-29 21:27 +1000, Stephen Rothwell wrote: >> >>> >> >>> > Hi all, >> >>> > >> >>> > After merging the net-next tree, today's linux-next build (i386 >> >>> defconfig) >> >>> > failed like this: >> >>> > >> >>> > x86_64-linux-gnu-ld: net/core/fib_rules.o: in function >> >>> `fib_rules_lookup': >> >>> > fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match' >> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to >> >>> `fib6_rule_match' >> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to >> >>> `fib6_rule_action' >> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to >> >>> `fib6_rule_action' >> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to >> >>> `fib6_rule_suppress' >> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to >> >>> `fib6_rule_suppress' >> >>> >> >>> FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit >> >>> 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was >> >>> apparently not sufficient. >> >>> >> >>> ,---- >> >>> | $ grep IPV6 .config >> >>> | CONFIG_IPV6=m >> >>> | # CONFIG_IPV6_ROUTER_PREF is not set >> >>> | # CONFIG_IPV6_OPTIMISTIC_DAD is not set >> >>> | # CONFIG_IPV6_MIP6 is not set >> >>> | # CONFIG_IPV6_ILA is not set >> >>> | # CONFIG_IPV6_VTI is not set >> >>> | CONFIG_IPV6_SIT=m >> >>> | # CONFIG_IPV6_SIT_6RD is not set >> >>> | CONFIG_IPV6_NDISC_NODETYPE=y >> >>> | CONFIG_IPV6_TUNNEL=m >> >>> | CONFIG_IPV6_MULTIPLE_TABLES=y >> >>> | # CONFIG_IPV6_SUBTREES is not set >> >>> | # CONFIG_IPV6_MROUTE is not set >> >>> | # CONFIG_IPV6_SEG6_LWTUNNEL is not set >> >>> | # CONFIG_IPV6_SEG6_HMAC is not set >> >>> | # CONFIG_IPV6_RPL_LWTUNNEL is not set >> >>> | # CONFIG_NF_SOCKET_IPV6 is not set >> >>> | # CONFIG_NF_TPROXY_IPV6 is not set >> >>> | # CONFIG_NF_DUP_IPV6 is not set >> >>> | # CONFIG_NF_REJECT_IPV6 is not set >> >>> | # CONFIG_NF_LOG_IPV6 is not set >> >>> | CONFIG_NF_DEFRAG_IPV6=m >> >>> `---- >> >>> >> >>> > Caused by commit >> >>> > >> >>> > b9aaec8f0be5 ("fib: use indirect call wrappers in the most common >> >>> fib_rules_ops") >> >>> > >> >>> > # CONFIG_IPV6_MULTIPLE_TABLES is not set >> >>> > >> >>> > I have reverted that commit for today. >> >>> >> >>> Cheers, >> >>> Sven >> >>>
On 8/28/20 8:09 AM, Sven Joachim wrote: > On 2020-08-27 11:12 -0700, Brian Vazquez wrote: > >> I've been trying to reproduce it with your config but I didn't >> succeed. I also looked at the file after the preprocessor and it >> looked good: >> >> ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ? >> fib6_rule_match(rule, fl, flags) : ops->match(rule, fl, flags); }) > > However, in my configuration I have CONFIG_IPV6=m, and so > fib6_rule_match is not available as a builtin. I think that's why ld is > complaining about the undefined reference. Same here FWIW. CONFIG_IPV6=m. > Changing the configuration to CONFIG_IPV6=y helps, FWIW. > >> Note that fib4_rule_match doesn't appear as the >> CONFIG_IP_MULTIPLE_TABLES is not there. >> >> Could you share more details on how you're compiling it and what >> compiler you're using?? > > Tried with both gcc 9 and gcc 10 under Debian unstable, binutils 2.35. > I usually use "make bindebpkg", but just running "make" is sufficient to > reproduce the problem, as it happens when linking vmlinux. > > Cheers, > Sven > > >> On Mon, Aug 24, 2020 at 1:08 AM Sven Joachim <svenjoac@gmx.de> wrote: >>> >>> On 2020-08-22 08:16 +0200, Sven Joachim wrote: >>> >>>> On 2020-08-21 09:23 -0700, Brian Vazquez wrote: >>>> >>>>> Hi Sven, >>>>> >>>>> Sorry for the late reply, did you still see this after: >>>>> https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaibing@huawei.com/ >>>>> ?? >>>> >>>> That patch is apparently already in 5.9-rc1 as commit 80fbbb1672e7, so >>>> yes I'm still seeing it. >>> >>> Still present in 5.9-rc2 as of today, I have attached my .config for >>> reference. Note that I have CONFIG_IPV6_MULTIPLE_TABLES=y, but >>> CONFIG_IP_MULTIPLE_TABLES is not mentioned at all there. >>> >>> To build the kernel, I have now deselected IPV6_MULTIPLE_TABLES. Not >>> sure why this was enabled in my .config which has grown organically over >>> many years. >>> >>> Cheers, >>> Sven >>> >>> >>>>> On Mon, Aug 17, 2020 at 12:21 AM Sven Joachim <svenjoac@gmx.de> wrote: >>>>> >>>>>> On 2020-07-29 21:27 +1000, Stephen Rothwell wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> After merging the net-next tree, today's linux-next build (i386 >>>>>> defconfig) >>>>>>> failed like this: >>>>>>> >>>>>>> x86_64-linux-gnu-ld: net/core/fib_rules.o: in function >>>>>> `fib_rules_lookup': >>>>>>> fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match' >>>>>>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to >>>>>> `fib6_rule_match' >>>>>>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to >>>>>> `fib6_rule_action' >>>>>>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to >>>>>> `fib6_rule_action' >>>>>>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to >>>>>> `fib6_rule_suppress' >>>>>>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to >>>>>> `fib6_rule_suppress' >>>>>> >>>>>> FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit >>>>>> 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was >>>>>> apparently not sufficient. >>>>>> >>>>>> ,---- >>>>>> | $ grep IPV6 .config >>>>>> | CONFIG_IPV6=m >>>>>> | # CONFIG_IPV6_ROUTER_PREF is not set >>>>>> | # CONFIG_IPV6_OPTIMISTIC_DAD is not set >>>>>> | # CONFIG_IPV6_MIP6 is not set >>>>>> | # CONFIG_IPV6_ILA is not set >>>>>> | # CONFIG_IPV6_VTI is not set >>>>>> | CONFIG_IPV6_SIT=m >>>>>> | # CONFIG_IPV6_SIT_6RD is not set >>>>>> | CONFIG_IPV6_NDISC_NODETYPE=y >>>>>> | CONFIG_IPV6_TUNNEL=m >>>>>> | CONFIG_IPV6_MULTIPLE_TABLES=y >>>>>> | # CONFIG_IPV6_SUBTREES is not set >>>>>> | # CONFIG_IPV6_MROUTE is not set >>>>>> | # CONFIG_IPV6_SEG6_LWTUNNEL is not set >>>>>> | # CONFIG_IPV6_SEG6_HMAC is not set >>>>>> | # CONFIG_IPV6_RPL_LWTUNNEL is not set >>>>>> | # CONFIG_NF_SOCKET_IPV6 is not set >>>>>> | # CONFIG_NF_TPROXY_IPV6 is not set >>>>>> | # CONFIG_NF_DUP_IPV6 is not set >>>>>> | # CONFIG_NF_REJECT_IPV6 is not set >>>>>> | # CONFIG_NF_LOG_IPV6 is not set >>>>>> | CONFIG_NF_DEFRAG_IPV6=m >>>>>> `---- >>>>>> >>>>>>> Caused by commit >>>>>>> >>>>>>> b9aaec8f0be5 ("fib: use indirect call wrappers in the most common >>>>>> fib_rules_ops") >>>>>>> >>>>>>> # CONFIG_IPV6_MULTIPLE_TABLES is not set >>>>>>> >>>>>>> I have reverted that commit for today. >>>>>> >>>>>> Cheers, >>>>>> Sven -- ~Randy
On Fri, Aug 28, 2020 at 8:12 AM Randy Dunlap <rdunlap@infradead.org> wrote: > > On 8/28/20 8:09 AM, Sven Joachim wrote: > > On 2020-08-27 11:12 -0700, Brian Vazquez wrote: > > > >> I've been trying to reproduce it with your config but I didn't > >> succeed. I also looked at the file after the preprocessor and it > >> looked good: > >> > >> ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ? > >> fib6_rule_match(rule, fl, flags) : ops->match(rule, fl, flags); }) > > > > However, in my configuration I have CONFIG_IPV6=m, and so > > fib6_rule_match is not available as a builtin. I think that's why ld is > > complaining about the undefined reference. > > Same here FWIW. CONFIG_IPV6=m. Oh I see, I tried this and it seems to work fine for me, does this also fix your problem? if so, I'll prepare the patch, and thanks for helping! diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c index 51678a528f85..40dfd1f55899 100644 --- a/net/core/fib_rules.c +++ b/net/core/fib_rules.c @@ -16,7 +16,7 @@ #include <net/ip_tunnels.h> #include <linux/indirect_call_wrapper.h> -#ifdef CONFIG_IPV6_MULTIPLE_TABLES +#if defined(CONFIG_IPV6_MULTIPLE_TABLES) && defined(CONFIG_IPV6) > > > > Changing the configuration to CONFIG_IPV6=y helps, FWIW. > > > >> Note that fib4_rule_match doesn't appear as the > >> CONFIG_IP_MULTIPLE_TABLES is not there. > >> > >> Could you share more details on how you're compiling it and what > >> compiler you're using?? > > > > Tried with both gcc 9 and gcc 10 under Debian unstable, binutils 2.35. > > I usually use "make bindebpkg", but just running "make" is sufficient to > > reproduce the problem, as it happens when linking vmlinux. > > > > Cheers, > > Sven > > > > > >> On Mon, Aug 24, 2020 at 1:08 AM Sven Joachim <svenjoac@gmx.de> wrote: > >>> > >>> On 2020-08-22 08:16 +0200, Sven Joachim wrote: > >>> > >>>> On 2020-08-21 09:23 -0700, Brian Vazquez wrote: > >>>> > >>>>> Hi Sven, > >>>>> > >>>>> Sorry for the late reply, did you still see this after: > >>>>> https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaibing@huawei.com/ > >>>>> ?? > >>>> > >>>> That patch is apparently already in 5.9-rc1 as commit 80fbbb1672e7, so > >>>> yes I'm still seeing it. > >>> > >>> Still present in 5.9-rc2 as of today, I have attached my .config for > >>> reference. Note that I have CONFIG_IPV6_MULTIPLE_TABLES=y, but > >>> CONFIG_IP_MULTIPLE_TABLES is not mentioned at all there. > >>> > >>> To build the kernel, I have now deselected IPV6_MULTIPLE_TABLES. Not > >>> sure why this was enabled in my .config which has grown organically over > >>> many years. > >>> > >>> Cheers, > >>> Sven > >>> > >>> > >>>>> On Mon, Aug 17, 2020 at 12:21 AM Sven Joachim <svenjoac@gmx.de> wrote: > >>>>> > >>>>>> On 2020-07-29 21:27 +1000, Stephen Rothwell wrote: > >>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> After merging the net-next tree, today's linux-next build (i386 > >>>>>> defconfig) > >>>>>>> failed like this: > >>>>>>> > >>>>>>> x86_64-linux-gnu-ld: net/core/fib_rules.o: in function > >>>>>> `fib_rules_lookup': > >>>>>>> fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match' > >>>>>>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to > >>>>>> `fib6_rule_match' > >>>>>>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to > >>>>>> `fib6_rule_action' > >>>>>>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to > >>>>>> `fib6_rule_action' > >>>>>>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to > >>>>>> `fib6_rule_suppress' > >>>>>>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to > >>>>>> `fib6_rule_suppress' > >>>>>> > >>>>>> FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit > >>>>>> 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was > >>>>>> apparently not sufficient. > >>>>>> > >>>>>> ,---- > >>>>>> | $ grep IPV6 .config > >>>>>> | CONFIG_IPV6=m > >>>>>> | # CONFIG_IPV6_ROUTER_PREF is not set > >>>>>> | # CONFIG_IPV6_OPTIMISTIC_DAD is not set > >>>>>> | # CONFIG_IPV6_MIP6 is not set > >>>>>> | # CONFIG_IPV6_ILA is not set > >>>>>> | # CONFIG_IPV6_VTI is not set > >>>>>> | CONFIG_IPV6_SIT=m > >>>>>> | # CONFIG_IPV6_SIT_6RD is not set > >>>>>> | CONFIG_IPV6_NDISC_NODETYPE=y > >>>>>> | CONFIG_IPV6_TUNNEL=m > >>>>>> | CONFIG_IPV6_MULTIPLE_TABLES=y > >>>>>> | # CONFIG_IPV6_SUBTREES is not set > >>>>>> | # CONFIG_IPV6_MROUTE is not set > >>>>>> | # CONFIG_IPV6_SEG6_LWTUNNEL is not set > >>>>>> | # CONFIG_IPV6_SEG6_HMAC is not set > >>>>>> | # CONFIG_IPV6_RPL_LWTUNNEL is not set > >>>>>> | # CONFIG_NF_SOCKET_IPV6 is not set > >>>>>> | # CONFIG_NF_TPROXY_IPV6 is not set > >>>>>> | # CONFIG_NF_DUP_IPV6 is not set > >>>>>> | # CONFIG_NF_REJECT_IPV6 is not set > >>>>>> | # CONFIG_NF_LOG_IPV6 is not set > >>>>>> | CONFIG_NF_DEFRAG_IPV6=m > >>>>>> `---- > >>>>>> > >>>>>>> Caused by commit > >>>>>>> > >>>>>>> b9aaec8f0be5 ("fib: use indirect call wrappers in the most common > >>>>>> fib_rules_ops") > >>>>>>> > >>>>>>> # CONFIG_IPV6_MULTIPLE_TABLES is not set > >>>>>>> > >>>>>>> I have reverted that commit for today. > >>>>>> > >>>>>> Cheers, > >>>>>> Sven > > > -- > ~Randy >
On 8/28/20 4:16 PM, Brian Vazquez wrote:
> On Fri, Aug 28, 2020 at 8:12 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>> On 8/28/20 8:09 AM, Sven Joachim wrote:
>>> On 2020-08-27 11:12 -0700, Brian Vazquez wrote:
>>>
>>>> I've been trying to reproduce it with your config but I didn't
>>>> succeed. I also looked at the file after the preprocessor and it
>>>> looked good:
>>>>
>>>> ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ?
>>>> fib6_rule_match(rule, fl, flags) : ops->match(rule, fl, flags); })
>>>
>>> However, in my configuration I have CONFIG_IPV6=m, and so
>>> fib6_rule_match is not available as a builtin. I think that's why ld is
>>> complaining about the undefined reference.
>>
>> Same here FWIW. CONFIG_IPV6=m.
>
> Oh I see,
> I tried this and it seems to work fine for me, does this also fix your
> problem? if so, I'll prepare the patch, and thanks for helping!
> diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
> index 51678a528f85..40dfd1f55899 100644
> --- a/net/core/fib_rules.c
> +++ b/net/core/fib_rules.c
> @@ -16,7 +16,7 @@
> #include <net/ip_tunnels.h>
> #include <linux/indirect_call_wrapper.h>
>
> -#ifdef CONFIG_IPV6_MULTIPLE_TABLES
> +#if defined(CONFIG_IPV6_MULTIPLE_TABLES) && defined(CONFIG_IPV6)
Yes, that works for me.
You can add this to your patch:
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
thanks.
--
~Randy
On 2020-08-28 16:42 -0700, Randy Dunlap wrote:
> On 8/28/20 4:16 PM, Brian Vazquez wrote:
>> On Fri, Aug 28, 2020 at 8:12 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>>>
>>> On 8/28/20 8:09 AM, Sven Joachim wrote:
>>>> On 2020-08-27 11:12 -0700, Brian Vazquez wrote:
>>>>
>>>>> I've been trying to reproduce it with your config but I didn't
>>>>> succeed. I also looked at the file after the preprocessor and it
>>>>> looked good:
>>>>>
>>>>> ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ?
>>>>> fib6_rule_match(rule, fl, flags) : ops->match(rule, fl, flags); })
>>>>
>>>> However, in my configuration I have CONFIG_IPV6=m, and so
>>>> fib6_rule_match is not available as a builtin. I think that's why ld is
>>>> complaining about the undefined reference.
>>>
>>> Same here FWIW. CONFIG_IPV6=m.
>>
>> Oh I see,
>> I tried this and it seems to work fine for me, does this also fix your
>> problem? if so, I'll prepare the patch, and thanks for helping!
>> diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
>> index 51678a528f85..40dfd1f55899 100644
>> --- a/net/core/fib_rules.c
>> +++ b/net/core/fib_rules.c
>> @@ -16,7 +16,7 @@
>> #include <net/ip_tunnels.h>
>> #include <linux/indirect_call_wrapper.h>
>>
>> -#ifdef CONFIG_IPV6_MULTIPLE_TABLES
>> +#if defined(CONFIG_IPV6_MULTIPLE_TABLES) && defined(CONFIG_IPV6)
>
>
> Yes, that works for me.
> You can add this to your patch:
>
> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Works for me as well.
Cheers,
Sven
[-- Attachment #1: Type: text/plain, Size: 4112 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/ethernet/marvell/prestera/prestera_main.c: In function 'prestera_port_dev_lower_find': drivers/net/ethernet/marvell/prestera/prestera_main.c:504:33: error: passing argument 2 of 'netdev_walk_all_lower_dev' from incompatible pointer type [-Werror=incompatible-pointer-types] 504 | netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, &port); | ^~~~~~~~~~~~~~~~~~~~~~~ | | | int (*)(struct net_device *, void *) In file included from include/linux/etherdevice.h:21, from drivers/net/ethernet/marvell/prestera/prestera_main.c:4: include/linux/netdevice.h:4571:16: note: expected 'int (*)(struct net_device *, struct netdev_nested_priv *)' but argument is of type 'int (*)(struct net_device *, void *)' 4571 | int (*fn)(struct net_device *lower_dev, | ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4572 | struct netdev_nested_priv *priv), | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/marvell/prestera/prestera_main.c:504:58: error: passing argument 3 of 'netdev_walk_all_lower_dev' from incompatible pointer type [-Werror=incompatible-pointer-types] 504 | netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, &port); | ^~~~~ | | | struct prestera_port ** In file included from include/linux/etherdevice.h:21, from drivers/net/ethernet/marvell/prestera/prestera_main.c:4: include/linux/netdevice.h:4573:37: note: expected 'struct netdev_nested_priv *' but argument is of type 'struct prestera_port **' 4573 | struct netdev_nested_priv *priv); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ cc1: some warnings being treated as errors Caused by commit eff7423365a6 ("net: core: introduce struct netdev_nested_priv for nested interface infrastructure") interacting with commit e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver implementation") also in the net-next tree. I applied the following fix patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 29 Sep 2020 12:57:59 +1000 Subject: [PATCH] fix up for "net: core: introduce struct netdev_nested_priv for nested interface infrastructure" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/marvell/prestera/prestera_main.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/marvell/prestera/prestera_main.c b/drivers/net/ethernet/marvell/prestera/prestera_main.c index 9bd57b89d1d0..633d8770be35 100644 --- a/drivers/net/ethernet/marvell/prestera/prestera_main.c +++ b/drivers/net/ethernet/marvell/prestera/prestera_main.c @@ -482,9 +482,10 @@ bool prestera_netdev_check(const struct net_device *dev) return dev->netdev_ops == &prestera_netdev_ops; } -static int prestera_lower_dev_walk(struct net_device *dev, void *data) +static int prestera_lower_dev_walk(struct net_device *dev, + struct netdev_nested_priv *priv) { - struct prestera_port **pport = data; + struct prestera_port **pport = (struct prestera_port **)priv->data; if (prestera_netdev_check(dev)) { *pport = netdev_priv(dev); @@ -497,11 +498,13 @@ static int prestera_lower_dev_walk(struct net_device *dev, void *data) struct prestera_port *prestera_port_dev_lower_find(struct net_device *dev) { struct prestera_port *port = NULL; + struct netdev_nested_priv priv; if (prestera_netdev_check(dev)) return netdev_priv(dev); - netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, &port); + priv.data = (void *)&port; + netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, &priv); return port; } -- 2.28.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 4392 bytes --] Hi all, On Tue, 29 Sep 2020 13:04:46 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/net/ethernet/marvell/prestera/prestera_main.c: In function 'prestera_port_dev_lower_find': > drivers/net/ethernet/marvell/prestera/prestera_main.c:504:33: error: passing argument 2 of 'netdev_walk_all_lower_dev' from incompatible pointer type [-Werror=incompatible-pointer-types] > 504 | netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, &port); > | ^~~~~~~~~~~~~~~~~~~~~~~ > | | > | int (*)(struct net_device *, void *) > In file included from include/linux/etherdevice.h:21, > from drivers/net/ethernet/marvell/prestera/prestera_main.c:4: > include/linux/netdevice.h:4571:16: note: expected 'int (*)(struct net_device *, struct netdev_nested_priv *)' but argument is of type 'int (*)(struct net_device *, void *)' > 4571 | int (*fn)(struct net_device *lower_dev, > | ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 4572 | struct netdev_nested_priv *priv), > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > drivers/net/ethernet/marvell/prestera/prestera_main.c:504:58: error: passing argument 3 of 'netdev_walk_all_lower_dev' from incompatible pointer type [-Werror=incompatible-pointer-types] > 504 | netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, &port); > | ^~~~~ > | | > | struct prestera_port ** > In file included from include/linux/etherdevice.h:21, > from drivers/net/ethernet/marvell/prestera/prestera_main.c:4: > include/linux/netdevice.h:4573:37: note: expected 'struct netdev_nested_priv *' but argument is of type 'struct prestera_port **' > 4573 | struct netdev_nested_priv *priv); > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ > cc1: some warnings being treated as errors > > Caused by commit > > eff7423365a6 ("net: core: introduce struct netdev_nested_priv for nested interface infrastructure") > > interacting with commit > > e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver implementation") > > also in the net-next tree. > > I applied the following fix patch. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 29 Sep 2020 12:57:59 +1000 > Subject: [PATCH] fix up for "net: core: introduce struct netdev_nested_priv for nested interface infrastructure" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/net/ethernet/marvell/prestera/prestera_main.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/marvell/prestera/prestera_main.c b/drivers/net/ethernet/marvell/prestera/prestera_main.c > index 9bd57b89d1d0..633d8770be35 100644 > --- a/drivers/net/ethernet/marvell/prestera/prestera_main.c > +++ b/drivers/net/ethernet/marvell/prestera/prestera_main.c > @@ -482,9 +482,10 @@ bool prestera_netdev_check(const struct net_device *dev) > return dev->netdev_ops == &prestera_netdev_ops; > } > > -static int prestera_lower_dev_walk(struct net_device *dev, void *data) > +static int prestera_lower_dev_walk(struct net_device *dev, > + struct netdev_nested_priv *priv) > { > - struct prestera_port **pport = data; > + struct prestera_port **pport = (struct prestera_port **)priv->data; > > if (prestera_netdev_check(dev)) { > *pport = netdev_priv(dev); > @@ -497,11 +498,13 @@ static int prestera_lower_dev_walk(struct net_device *dev, void *data) > struct prestera_port *prestera_port_dev_lower_find(struct net_device *dev) > { > struct prestera_port *port = NULL; > + struct netdev_nested_priv priv; > > if (prestera_netdev_check(dev)) > return netdev_priv(dev); > > - netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, &port); > + priv.data = (void *)&port; > + netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, &priv); > > return port; > } I am still getting this build failure ... -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen, On Thu, Oct 01, 2020 at 08:09:16AM +1000, Stephen Rothwell wrote: > Hi all, > [CUT] > > I am still getting this build failure ... > > -- I just 've checked linux-next/master and it builds fine at least with my custom config, do/how I need to handle this case ? I see the changes you applied already in linux-next/master. > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 828 bytes --] Hi Vadym, On Thu, 1 Oct 2020 02:06:05 +0300 Vadym Kochan <vadym.kochan@plvision.eu> wrote: > > On Thu, Oct 01, 2020 at 08:09:16AM +1000, Stephen Rothwell wrote: > > Hi all, > > > [CUT] > > > > I am still getting this build failure ... > > > > -- > > I just 've checked linux-next/master and it builds fine at least with my custom > config, do/how I need to handle this case ? If you take the net-next tree alone and do an x86_64 allmodconfig build, it currently fails, right? > I see the changes you applied already in linux-next/master. Linux-next builds fine because it contains the fix patch I posted (I added it to the net-next merge). It needs to be explicitly fixed in the net-next tree either using my patch or something more correct (if necessary). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 29 Sep 2020 13:04:46 +1000
> Caused by commit
>
> eff7423365a6 ("net: core: introduce struct netdev_nested_priv for nested interface infrastructure")
>
> interacting with commit
>
> e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver implementation")
>
> also in the net-next tree.
I would argue against that "also" as the first commit is only in the
'net' tree right now. :-)
This is simply something I'll have to resolve the next time net is merged
into net-next.
Thanks.
[-- Attachment #1: Type: text/plain, Size: 842 bytes --] Hi Dave, On Thu, 01 Oct 2020 18:40:13 -0700 (PDT) David Miller <davem@davemloft.net> wrote: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 29 Sep 2020 13:04:46 +1000 > > > Caused by commit > > > > eff7423365a6 ("net: core: introduce struct netdev_nested_priv for nested interface infrastructure") > > > > interacting with commit > > > > e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver implementation") > > > > also in the net-next tree. > > I would argue against that "also" as the first commit is only in the > 'net' tree right now. :-) Sorry, my mistake. I was wondering why your testing did not seem to be affected. > This is simply something I'll have to resolve the next time net is merged > into net-next. Absolutely, no problem. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/xdp/xsk_buff_pool.c:7:10: fatal error: linux/dma-noncoherent.h: No such file or directory 7 | #include <linux/dma-noncoherent.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~ Caused by commit 1c1efc2af158 ("xsk: Create and free buffer pool independently from umem") interacting with commit a3cf77774abf ("dma-mapping: merge <linux/dma-noncoherent.h> into <linux/dma-map-ops.h>") from the dma-mapping tree. I have applied teh following merge fix patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 6 Oct 2020 14:53:30 +1100 Subject: [PATCH] xsk: fix up for "dma-mapping: merge <linux/dma-noncoherent.h> into <linux/dma-map-ops.h>" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/xdp/xsk_buff_pool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c index e63fadd000db..dbed16648607 100644 --- a/net/xdp/xsk_buff_pool.c +++ b/net/xdp/xsk_buff_pool.c @@ -4,7 +4,7 @@ #include <net/xdp_sock.h> #include <net/xdp_sock_drv.h> #include <linux/dma-direct.h> -#include <linux/dma-noncoherent.h> +#include <linux/dma-map-ops.h> #include <linux/swiotlb.h> #include "xsk_queue.h" -- 2.28.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Oct 06, 2020 at 02:58:47PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
It actually doesn't need that or the two other internal headers.
Bjoern has a fixed, and it was supposed to be queued up according to
patchwork.
[-- Attachment #1: Type: text/plain, Size: 563 bytes --] Hi Christoph, On Tue, 6 Oct 2020 07:13:01 +0200 Christoph Hellwig <hch@lst.de> wrote: > > On Tue, Oct 06, 2020 at 02:58:47PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > After merging the net-next tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > It actually doesn't need that or the two other internal headers. > Bjoern has a fixed, and it was supposed to be queued up according to > patchwork. Yeah, it is in the bpf-next tree but not merged into the net-next tree yet. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 10/6/20 7:41 AM, Stephen Rothwell wrote:
> On Tue, 6 Oct 2020 07:13:01 +0200 Christoph Hellwig <hch@lst.de> wrote:
>>
>> On Tue, Oct 06, 2020 at 02:58:47PM +1100, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> After merging the net-next tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>
>> It actually doesn't need that or the two other internal headers.
>> Bjoern has a fixed, and it was supposed to be queued up according to
>> patchwork.
>
> Yeah, it is in the bpf-next tree but not merged into the net-next tree
> yet.
Yep, applied yesterday. Given a3cf77774abf ("dma-mapping: merge <linux/dma-noncoherent.h>
into <linux/dma-map-ops.h>") is in dma-mapping tree and not yet affecting bpf-next
nor net-next, we were planning to ship bpf-next at the usual cadence this week, so it'll
be in net-next end of week for sure. (If there is urgent reason to have it in net-next
today, please let us know of course.)
Thanks,
Daniel
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/core/xdp.c: In function 'xdp_return_frame_bulk': net/core/xdp.c:417:3: error: too few arguments to function '__xdp_return' 417 | __xdp_return(xdpf->data, &xdpf->mem, false); | ^~~~~~~~~~~~ net/core/xdp.c:340:13: note: declared here 340 | static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct, | ^~~~~~~~~~~~ Caused by commit 8965398713d8 ("net: xdp: Introduce bulking for xdp tx return path") interacting with commit ed1182dc004d ("xdp: Handle MEM_TYPE_XSK_BUFF_POOL correctly in xdp_return_buff()") from the bpf tree. I applied the following merge fix patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 2 Dec 2020 12:33:14 +1100 Subject: [PATCH] fix up for "xdp: Handle MEM_TYPE_XSK_BUFF_POOL correctly in xdp_return_buff()" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/core/xdp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/xdp.c b/net/core/xdp.c index f2cdacd81d43..3100f9711eae 100644 --- a/net/core/xdp.c +++ b/net/core/xdp.c @@ -414,7 +414,7 @@ void xdp_return_frame_bulk(struct xdp_frame *xdpf, struct xdp_mem_allocator *xa; if (mem->type != MEM_TYPE_PAGE_POOL) { - __xdp_return(xdpf->data, &xdpf->mem, false); + __xdp_return(xdpf->data, &xdpf->mem, false, NULL); return; } -- 2.29.2 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1726 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: fs/cifs/cifs_swn.c: In function 'cifs_swn_notify': fs/cifs/cifs_swn.c:450:4: error: implicit declaration of function 'nla_strlcpy'; did you mean 'nla_strscpy'? [-Werror=implicit-function-declaration] 450 | nla_strlcpy(name, info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME], | ^~~~~~~~~~~ | nla_strscpy Caused by commit 872f69034194 ("treewide: rename nla_strlcpy to nla_strscpy.") interacting with commit 27228d73f4d2 ("cifs: Set witness notification handler for messages from userspace daemon") from the cifs tree. I have applied the following merge fix patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 14 Dec 2020 13:09:27 +1100 Subject: [PATCH] fixup for "treewide: rename nla_strlcpy to nla_strscpy." conflicting with "cifs: Set witness notification handler for messages from userspace daemon" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- fs/cifs/cifs_swn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/cifs_swn.c b/fs/cifs/cifs_swn.c index 642c9eedc8ab..d762d442dfa5 100644 --- a/fs/cifs/cifs_swn.c +++ b/fs/cifs/cifs_swn.c @@ -447,7 +447,7 @@ int cifs_swn_notify(struct sk_buff *skb, struct genl_info *info) int state; if (info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME]) { - nla_strlcpy(name, info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME], + nla_strscpy(name, info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME], sizeof(name)); } else { cifs_dbg(FYI, "%s: missing resource name attribute\n", __func__); -- 2.29.2 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1968 bytes --] Hi all, On Mon, 14 Dec 2020 13:14:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > fs/cifs/cifs_swn.c: In function 'cifs_swn_notify': > fs/cifs/cifs_swn.c:450:4: error: implicit declaration of function 'nla_strlcpy'; did you mean 'nla_strscpy'? [-Werror=implicit-function-declaration] > 450 | nla_strlcpy(name, info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME], > | ^~~~~~~~~~~ > | nla_strscpy > > Caused by commit > > 872f69034194 ("treewide: rename nla_strlcpy to nla_strscpy.") > > interacting with commit > > 27228d73f4d2 ("cifs: Set witness notification handler for messages from userspace daemon") > > from the cifs tree. > > I have applied the following merge fix patch. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 14 Dec 2020 13:09:27 +1100 > Subject: [PATCH] fixup for "treewide: rename nla_strlcpy to nla_strscpy." > > conflicting with > > "cifs: Set witness notification handler for messages from userspace daemon" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > fs/cifs/cifs_swn.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/cifs/cifs_swn.c b/fs/cifs/cifs_swn.c > index 642c9eedc8ab..d762d442dfa5 100644 > --- a/fs/cifs/cifs_swn.c > +++ b/fs/cifs/cifs_swn.c > @@ -447,7 +447,7 @@ int cifs_swn_notify(struct sk_buff *skb, struct genl_info *info) > int state; > > if (info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME]) { > - nla_strlcpy(name, info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME], > + nla_strscpy(name, info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME], > sizeof(name)); > } else { > cifs_dbg(FYI, "%s: missing resource name attribute\n", __func__); This fixup is now needed when the cifs tree is merged with Linus' tree. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 647 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: ERROR: modpost: "ip6_dst_check" [vmlinux] is a static EXPORT_SYMBOL ERROR: modpost: "ipv4_dst_check" [vmlinux] is a static EXPORT_SYMBOL ERROR: modpost: "ipv4_mtu" [vmlinux] is a static EXPORT_SYMBOL ERROR: modpost: "ip6_mtu" [vmlinux] is a static EXPORT_SYMBOL Caused by commits f67fbeaebdc0 ("net: use indirect call helpers for dst_mtu") bbd807dfbf20 ("net: indirect call helpers for ipv4/ipv6 dst_check functions") I have used the net-next tree from next-20210203 fot today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen, thanks for the report. I'm having trouble trying to compile for ppc, but I believe this should fix the problem, could you test this patch, please? Thanks! diff --git a/include/linux/indirect_call_wrapper.h b/include/linux/indirect_call_wrapper.h index 54c02c84906a..077f96be65c6 100644 --- a/include/linux/indirect_call_wrapper.h +++ b/include/linux/indirect_call_wrapper.h @@ -36,6 +36,7 @@ #define INDIRECT_CALLABLE_DECLARE(f) f #define INDIRECT_CALLABLE_SCOPE +#define INDIRECT_CALLABLE_EXPORT(f) EXPORT_SYMBOL(f) #else #define INDIRECT_CALL_1(f, f1, ...) f(__VA_ARGS__) @@ -44,6 +45,7 @@ #define INDIRECT_CALL_4(f, f4, f3, f2, f1, ...) f(__VA_ARGS__) #define INDIRECT_CALLABLE_DECLARE(f) #define INDIRECT_CALLABLE_SCOPE static +#define INDIRECT_CALLABLE_EXPORT(f) #endif /* diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 9e6537709794..9dd8ff3887b7 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1206,7 +1206,7 @@ INDIRECT_CALLABLE_SCOPE struct dst_entry *ipv4_dst_check(struct dst_entry *dst, return NULL; return dst; } -EXPORT_SYMBOL(ipv4_dst_check); +INDIRECT_CALLABLE_EXPORT(ipv4_dst_check); static void ipv4_send_dest_unreach(struct sk_buff *skb) { @@ -1337,7 +1337,7 @@ INDIRECT_CALLABLE_SCOPE unsigned int ipv4_mtu(const struct dst_entry *dst) return mtu - lwtunnel_headroom(dst->lwtstate, mtu); } -EXPORT_SYMBOL(ipv4_mtu); +INDIRECT_CALLABLE_EXPORT(ipv4_mtu); static void ip_del_fnhe(struct fib_nh_common *nhc, __be32 daddr) { diff --git a/net/ipv6/route.c b/net/ipv6/route.c index f447f82e6819..75d6a0db1fa6 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -2644,7 +2644,7 @@ INDIRECT_CALLABLE_SCOPE struct dst_entry *ip6_dst_check(struct dst_entry *dst, return dst_ret; } -EXPORT_SYMBOL(ip6_dst_check); +INDIRECT_CALLABLE_EXPORT(ip6_dst_check); static struct dst_entry *ip6_negative_advice(struct dst_entry *dst) { @@ -3115,7 +3115,7 @@ INDIRECT_CALLABLE_SCOPE unsigned int ip6_mtu(const struct dst_entry *dst) return mtu - lwtunnel_headroom(dst->lwtstate, mtu); } -EXPORT_SYMBOL(ip6_mtu); +INDIRECT_CALLABLE_EXPORT(ip6_mtu); /* MTU selection: * 1. mtu on route is locked - use it On Wed, Feb 3, 2021 at 5:33 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > ERROR: modpost: "ip6_dst_check" [vmlinux] is a static EXPORT_SYMBOL > ERROR: modpost: "ipv4_dst_check" [vmlinux] is a static EXPORT_SYMBOL > ERROR: modpost: "ipv4_mtu" [vmlinux] is a static EXPORT_SYMBOL > ERROR: modpost: "ip6_mtu" [vmlinux] is a static EXPORT_SYMBOL > > Caused by commits > > f67fbeaebdc0 ("net: use indirect call helpers for dst_mtu") > bbd807dfbf20 ("net: indirect call helpers for ipv4/ipv6 dst_check functions") > > I have used the net-next tree from next-20210203 fot today. > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 393 bytes --] Hi Brian, On Wed, 3 Feb 2021 19:52:08 -0800 Brian Vazquez <brianvv@google.com> wrote: > > Hi Stephen, thanks for the report. I'm having trouble trying to > compile for ppc, but I believe this should fix the problem, could you > test this patch, please? Thanks! That fixed it, thanks (though the patch was badly wrapped and whitespace damaged :-)) -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi everyone, On Thu, Feb 04, 2021 at 20:38, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > On Wed, 3 Feb 2021 19:52:08 -0800 Brian Vazquez <brianvv@google.com> wrote: >> Hi Stephen, thanks for the report. I'm having trouble trying to >> compile for ppc, but I believe this should fix the problem, could you >> test this patch, please? Thanks! > That fixed it, thanks (though the patch was badly wrapped and > whitespace damaged :-)) can confirm, that patch fixes building from latest net-next also for me. Here's an updated version. Regards /Joachim diff --git a/include/linux/indirect_call_wrapper.h b/include/linux/indirect_call_wrapper.h index 54c02c84906a..551e515b405b 100644 --- a/include/linux/indirect_call_wrapper.h +++ b/include/linux/indirect_call_wrapper.h @@ -36,6 +36,7 @@ #define INDIRECT_CALLABLE_DECLARE(f) f #define INDIRECT_CALLABLE_SCOPE +#define INDIRECT_CALLABLE_EXPORT(f) EXPORT_SYMBOL(f) #else #define INDIRECT_CALL_1(f, f1, ...) f(__VA_ARGS__) @@ -44,6 +45,7 @@ #define INDIRECT_CALL_4(f, f4, f3, f2, f1, ...) f(__VA_ARGS__) #define INDIRECT_CALLABLE_DECLARE(f) #define INDIRECT_CALLABLE_SCOPE static +#define INDIRECT_CALLABLE_EXPORT(f) #endif /* diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 9e6537709794..9dd8ff3887b7 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1206,7 +1206,7 @@ INDIRECT_CALLABLE_SCOPE struct dst_entry *ipv4_dst_check(struct dst_entry *dst, return NULL; return dst; } -EXPORT_SYMBOL(ipv4_dst_check); +INDIRECT_CALLABLE_EXPORT(ipv4_dst_check); static void ipv4_send_dest_unreach(struct sk_buff *skb) { @@ -1337,7 +1337,7 @@ INDIRECT_CALLABLE_SCOPE unsigned int ipv4_mtu(const struct dst_entry *dst) return mtu - lwtunnel_headroom(dst->lwtstate, mtu); } -EXPORT_SYMBOL(ipv4_mtu); +INDIRECT_CALLABLE_EXPORT(ipv4_mtu); static void ip_del_fnhe(struct fib_nh_common *nhc, __be32 daddr) { diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 8d9e053dc071..f0e9b07b92b7 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -2644,7 +2644,7 @@ INDIRECT_CALLABLE_SCOPE struct dst_entry *ip6_dst_check(struct dst_entry *dst, return dst_ret; } -EXPORT_SYMBOL(ip6_dst_check); +INDIRECT_CALLABLE_EXPORT(ip6_dst_check); static struct dst_entry *ip6_negative_advice(struct dst_entry *dst) { @@ -3115,7 +3115,7 @@ INDIRECT_CALLABLE_SCOPE unsigned int ip6_mtu(const struct dst_entry *dst) return mtu - lwtunnel_headroom(dst->lwtstate, mtu); } -EXPORT_SYMBOL(ip6_mtu); +INDIRECT_CALLABLE_EXPORT(ip6_mtu); /* MTU selection: * 1. mtu on route is locked - use it
Hi Brian,
On Wed, Feb 03, 2021 at 07:52:08PM -0800, Brian Vazquez wrote:
> Hi Stephen, thanks for the report. I'm having trouble trying to
> compile for ppc, but I believe this should fix the problem, could you
> test this patch, please? Thanks!
Could you please submit the patch formally to net-next? Thanks.
Hi all, I've just sent the patch series: https://patchwork.kernel.org/project/netdevbpf/list/?series=428099. Thanks, Brian On Thu, Feb 4, 2021 at 7:36 AM Vladimir Oltean <olteanv@gmail.com> wrote: > > Hi Brian, > > On Wed, Feb 03, 2021 at 07:52:08PM -0800, Brian Vazquez wrote: > > Hi Stephen, thanks for the report. I'm having trouble trying to > > compile for ppc, but I believe this should fix the problem, could you > > test this patch, please? Thanks! > > Could you please submit the patch formally to net-next? Thanks.
[-- Attachment #1: Type: text/plain, Size: 7391 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/asm-generic/bug.h:20, from arch/x86/include/asm/bug.h:93, from include/linux/bug.h:5, from include/linux/mmdebug.h:5, from include/linux/gfp.h:5, from include/linux/umh.h:4, from include/linux/kmod.h:9, from net/bridge/netfilter/ebtables.c:14: net/bridge/netfilter/ebtables.c: In function '__ebt_find_table': net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member named 'tables' 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { | ^ include/linux/kernel.h:708:26: note: in definition of macro 'container_of' 708 | void *__mptr = (void *)(ptr); \ | ^~~ include/linux/list.h:522:2: note: in expansion of macro 'list_entry' 522 | list_entry((ptr)->next, type, member) | ^~~~~~~~~~ include/linux/list.h:628:13: note: in expansion of macro 'list_first_entry' 628 | for (pos = list_first_entry(head, typeof(*pos), member); \ | ^~~~~~~~~~~~~~~~ net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro 'list_for_each_entry' 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { | ^~~~~~~~~~~~~~~~~~~ In file included from <command-line>: net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member named 'tables' 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { | ^ include/linux/compiler_types.h:300:9: note: in definition of macro '__compiletime_assert' 300 | if (!(condition)) \ | ^~~~~~~~~ include/linux/compiler_types.h:320:2: note: in expansion of macro '_compiletime_assert' 320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~~~~~~~~~~~~~~~~~ include/linux/kernel.h:709:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 709 | BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ | ^~~~~~~~~~~~~~~~ include/linux/kernel.h:709:20: note: in expansion of macro '__same_type' 709 | BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ | ^~~~~~~~~~~ include/linux/list.h:511:2: note: in expansion of macro 'container_of' 511 | container_of(ptr, type, member) | ^~~~~~~~~~~~ include/linux/list.h:522:2: note: in expansion of macro 'list_entry' 522 | list_entry((ptr)->next, type, member) | ^~~~~~~~~~ include/linux/list.h:628:13: note: in expansion of macro 'list_first_entry' 628 | for (pos = list_first_entry(head, typeof(*pos), member); \ | ^~~~~~~~~~~~~~~~ net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro 'list_for_each_entry' 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { | ^~~~~~~~~~~~~~~~~~~ net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member named 'tables' 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { | ^ include/linux/compiler_types.h:300:9: note: in definition of macro '__compiletime_assert' 300 | if (!(condition)) \ | ^~~~~~~~~ include/linux/compiler_types.h:320:2: note: in expansion of macro '_compiletime_assert' 320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~~~~~~~~~~~~~~~~~ include/linux/kernel.h:709:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 709 | BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ | ^~~~~~~~~~~~~~~~ include/linux/kernel.h:710:6: note: in expansion of macro '__same_type' 710 | !__same_type(*(ptr), void), \ | ^~~~~~~~~~~ include/linux/list.h:511:2: note: in expansion of macro 'container_of' 511 | container_of(ptr, type, member) | ^~~~~~~~~~~~ include/linux/list.h:522:2: note: in expansion of macro 'list_entry' 522 | list_entry((ptr)->next, type, member) | ^~~~~~~~~~ include/linux/list.h:628:13: note: in expansion of macro 'list_first_entry' 628 | for (pos = list_first_entry(head, typeof(*pos), member); \ | ^~~~~~~~~~~~~~~~ net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro 'list_for_each_entry' 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { | ^~~~~~~~~~~~~~~~~~~ In file included from include/linux/preempt.h:11, from include/linux/spinlock.h:51, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/umh.h:4, from include/linux/kmod.h:9, from net/bridge/netfilter/ebtables.c:14: net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member named 'tables' 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { | ^ include/linux/list.h:619:20: note: in definition of macro 'list_entry_is_head' 619 | (&pos->member == (head)) | ^~~~ net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro 'list_for_each_entry' 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { | ^~~~~~~~~~~~~~~~~~~ Caused by commit 5b53951cfc85 ("netfilter: ebtables: use net_generic infra") interacting with commit 7ee3c61dcd28 ("netfilter: bridge: add pre_exit hooks for ebtable unregistration") from the netfilter tree. I have applied the following merge fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 12 Apr 2021 14:58:20 +1000 Subject: [PATCH] merger fix for "netfilter: bridge: add pre_exit hooks for ebtable unregistration" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/bridge/netfilter/ebtables.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c index bbc46149bbb2..96d789c8d1c7 100644 --- a/net/bridge/netfilter/ebtables.c +++ b/net/bridge/netfilter/ebtables.c @@ -1241,11 +1241,12 @@ int ebt_register_table(struct net *net, const struct ebt_table *input_table, static struct ebt_table *__ebt_find_table(struct net *net, const char *name) { + struct ebt_pernet *ebt_net = net_generic(net, ebt_pernet_id); struct ebt_table *t; mutex_lock(&ebt_mutex); - list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { + list_for_each_entry(t, &ebt_net->tables, list) { if (strcmp(t->name, name) == 0) { mutex_unlock(&ebt_mutex); return t; -- 2.30.2 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member named 'tables'
> 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) {
> | ^
> include/linux/list.h:619:20: note: in definition of macro 'list_entry_is_head'
> 619 | (&pos->member == (head))
> | ^~~~
> net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro 'list_for_each_entry'
> 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) {
> | ^~~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
> 5b53951cfc85 ("netfilter: ebtables: use net_generic infra")
>
> interacting with commit
>
> 7ee3c61dcd28 ("netfilter: bridge: add pre_exit hooks for ebtable unregistration")
Right, the fixup is correct.
[-- Attachment #1: Type: text/plain, Size: 6861 bytes --] On Mon, Apr 12, 2021 at 03:04:16PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > In file included from include/asm-generic/bug.h:20, > from arch/x86/include/asm/bug.h:93, > from include/linux/bug.h:5, > from include/linux/mmdebug.h:5, > from include/linux/gfp.h:5, > from include/linux/umh.h:4, > from include/linux/kmod.h:9, > from net/bridge/netfilter/ebtables.c:14: > net/bridge/netfilter/ebtables.c: In function '__ebt_find_table': > net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member named 'tables' > 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { > | ^ > include/linux/kernel.h:708:26: note: in definition of macro 'container_of' > 708 | void *__mptr = (void *)(ptr); \ > | ^~~ > include/linux/list.h:522:2: note: in expansion of macro 'list_entry' > 522 | list_entry((ptr)->next, type, member) > | ^~~~~~~~~~ > include/linux/list.h:628:13: note: in expansion of macro 'list_first_entry' > 628 | for (pos = list_first_entry(head, typeof(*pos), member); \ > | ^~~~~~~~~~~~~~~~ > net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro 'list_for_each_entry' > 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { > | ^~~~~~~~~~~~~~~~~~~ > In file included from <command-line>: > net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member named 'tables' > 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { > | ^ > include/linux/compiler_types.h:300:9: note: in definition of macro '__compiletime_assert' > 300 | if (!(condition)) \ > | ^~~~~~~~~ > include/linux/compiler_types.h:320:2: note: in expansion of macro '_compiletime_assert' > 320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > | ^~~~~~~~~~~~~~~~~~~ > include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' > 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > | ^~~~~~~~~~~~~~~~~~ > include/linux/kernel.h:709:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' > 709 | BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ > | ^~~~~~~~~~~~~~~~ > include/linux/kernel.h:709:20: note: in expansion of macro '__same_type' > 709 | BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ > | ^~~~~~~~~~~ > include/linux/list.h:511:2: note: in expansion of macro 'container_of' > 511 | container_of(ptr, type, member) > | ^~~~~~~~~~~~ > include/linux/list.h:522:2: note: in expansion of macro 'list_entry' > 522 | list_entry((ptr)->next, type, member) > | ^~~~~~~~~~ > include/linux/list.h:628:13: note: in expansion of macro 'list_first_entry' > 628 | for (pos = list_first_entry(head, typeof(*pos), member); \ > | ^~~~~~~~~~~~~~~~ > net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro 'list_for_each_entry' > 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { > | ^~~~~~~~~~~~~~~~~~~ > net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member named 'tables' > 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { > | ^ > include/linux/compiler_types.h:300:9: note: in definition of macro '__compiletime_assert' > 300 | if (!(condition)) \ > | ^~~~~~~~~ > include/linux/compiler_types.h:320:2: note: in expansion of macro '_compiletime_assert' > 320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > | ^~~~~~~~~~~~~~~~~~~ > include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' > 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > | ^~~~~~~~~~~~~~~~~~ > include/linux/kernel.h:709:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' > 709 | BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ > | ^~~~~~~~~~~~~~~~ > include/linux/kernel.h:710:6: note: in expansion of macro '__same_type' > 710 | !__same_type(*(ptr), void), \ > | ^~~~~~~~~~~ > include/linux/list.h:511:2: note: in expansion of macro 'container_of' > 511 | container_of(ptr, type, member) > | ^~~~~~~~~~~~ > include/linux/list.h:522:2: note: in expansion of macro 'list_entry' > 522 | list_entry((ptr)->next, type, member) > | ^~~~~~~~~~ > include/linux/list.h:628:13: note: in expansion of macro 'list_first_entry' > 628 | for (pos = list_first_entry(head, typeof(*pos), member); \ > | ^~~~~~~~~~~~~~~~ > net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro 'list_for_each_entry' > 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { > | ^~~~~~~~~~~~~~~~~~~ > In file included from include/linux/preempt.h:11, > from include/linux/spinlock.h:51, > from include/linux/mmzone.h:8, > from include/linux/gfp.h:6, > from include/linux/umh.h:4, > from include/linux/kmod.h:9, > from net/bridge/netfilter/ebtables.c:14: > net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member named 'tables' > 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { > | ^ > include/linux/list.h:619:20: note: in definition of macro 'list_entry_is_head' > 619 | (&pos->member == (head)) > | ^~~~ > net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro 'list_for_each_entry' > 1248 | list_for_each_entry(t, &net->xt.tables[NFPROTO_BRIDGE], list) { > | ^~~~~~~~~~~~~~~~~~~ > > Caused by commit > > 5b53951cfc85 ("netfilter: ebtables: use net_generic infra") > > interacting with commit > > 7ee3c61dcd28 ("netfilter: bridge: add pre_exit hooks for ebtable unregistration") > > from the netfilter tree. > > I have applied the following merge fix patch for today: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 12 Apr 2021 14:58:20 +1000 > Subject: [PATCH] merger fix for "netfilter: bridge: add pre_exit hooks for > ebtable unregistration" Thanks. I'll include this merge conflict in my next pull request. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 702 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/usb/class/cdc-wdm.c: In function 'wdm_wwan_port_stop': drivers/usb/class/cdc-wdm.c:858:2: error: implicit declaration of function 'kill_urbs' [-Werror=implicit-function-declaration] 858 | kill_urbs(desc); | ^~~~~~~~~ Caused by commit cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") kill_urbs() was removed by commit 18abf8743674 ("cdc-wdm: untangle a circular dependency between callback and softint") Which is included in v5.13-rc1. I have used the net-next tree from next-20210511 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 967 bytes --] Hi Stephen, On Wed, 12 May 2021 09:52:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/usb/class/cdc-wdm.c: In function 'wdm_wwan_port_stop': > drivers/usb/class/cdc-wdm.c:858:2: error: implicit declaration of function 'kill_urbs' [-Werror=implicit-function-declaration] > 858 | kill_urbs(desc); > | ^~~~~~~~~ > > Caused by commit > > cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") > > kill_urbs() was removed by commit > > 18abf8743674 ("cdc-wdm: untangle a circular dependency between callback and softint") > > Which is included in v5.13-rc1. Sorry, that commit is only in linux-next (from the usb.current tree). I will do a merge fix up tomorrow - unless someone provides one. > I have used the net-next tree from next-20210511 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2083 bytes --] Hi all, On Wed, 12 May 2021 09:54:18 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Wed, 12 May 2021 09:52:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > After merging the net-next tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > drivers/usb/class/cdc-wdm.c: In function 'wdm_wwan_port_stop': > > drivers/usb/class/cdc-wdm.c:858:2: error: implicit declaration of function 'kill_urbs' [-Werror=implicit-function-declaration] > > 858 | kill_urbs(desc); > > | ^~~~~~~~~ > > > > Caused by commit > > > > cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") > > > > kill_urbs() was removed by commit > > > > 18abf8743674 ("cdc-wdm: untangle a circular dependency between callback and softint") > > > > Which is included in v5.13-rc1. > > Sorry, that commit is only in linux-next (from the usb.current tree). > I will do a merge fix up tomorrow - unless someone provides one. > > > I have used the net-next tree from next-20210511 for today. I have used the following merge fix patch for today. I don't know if this is sufficient (or even correct), but it does build. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 13 May 2021 11:04:09 +1000 Subject: [PATCH] usb: class: cdc-wdm: fix for kill_urbs() removal Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/usb/class/cdc-wdm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c index c88dcc4b6618..489b0e049402 100644 --- a/drivers/usb/class/cdc-wdm.c +++ b/drivers/usb/class/cdc-wdm.c @@ -855,7 +855,7 @@ static void wdm_wwan_port_stop(struct wwan_port *port) struct wdm_device *desc = wwan_port_get_drvdata(port); /* Stop all transfers and disable WWAN mode */ - kill_urbs(desc); + poison_urbs(desc); desc->manage_power(desc->intf, 0); clear_bit(WDM_READ, &desc->flags); clear_bit(WDM_WWAN_IN_USE, &desc->flags); -- 2.30.2 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen, On Thu, 13 May 2021 at 03:11, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > On Wed, 12 May 2021 09:54:18 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Wed, 12 May 2021 09:52:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > After merging the net-next tree, today's linux-next build (x86_64 > > > allmodconfig) failed like this: > > > > > > drivers/usb/class/cdc-wdm.c: In function 'wdm_wwan_port_stop': > > > drivers/usb/class/cdc-wdm.c:858:2: error: implicit declaration of function 'kill_urbs' [-Werror=implicit-function-declaration] > > > 858 | kill_urbs(desc); > > > | ^~~~~~~~~ > > > > > > Caused by commit > > > > > > cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") > > > > > > kill_urbs() was removed by commit > > > > > > 18abf8743674 ("cdc-wdm: untangle a circular dependency between callback and softint") > > > > > > Which is included in v5.13-rc1. > > > > Sorry, that commit is only in linux-next (from the usb.current tree). > > I will do a merge fix up tomorrow - unless someone provides one. > > > > > I have used the net-next tree from next-20210511 for today. > > I have used the following merge fix patch for today. I don't know if > this is sufficient (or even correct), but it does build. Thanks for working on this. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Thu, 13 May 2021 11:04:09 +1000 > Subject: [PATCH] usb: class: cdc-wdm: fix for kill_urbs() removal > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/usb/class/cdc-wdm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c > index c88dcc4b6618..489b0e049402 100644 > --- a/drivers/usb/class/cdc-wdm.c > +++ b/drivers/usb/class/cdc-wdm.c > @@ -855,7 +855,7 @@ static void wdm_wwan_port_stop(struct wwan_port *port) > struct wdm_device *desc = wwan_port_get_drvdata(port); > > /* Stop all transfers and disable WWAN mode */ > - kill_urbs(desc); > + poison_urbs(desc); > desc->manage_power(desc->intf, 0); > clear_bit(WDM_READ, &desc->flags); > clear_bit(WDM_WWAN_IN_USE, &desc->flags); AFAIU, each poison call must be balanced with unpoison call. So you probably want to call unpoison_urbs right here, similarly to wdm_release or wdm_suspend. Regards, Loic > -- > 2.30.2 > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 2757 bytes --] Hi Loic, On Thu, 13 May 2021 08:35:50 +0200 Loic Poulain <loic.poulain@linaro.org> wrote: > > On Thu, 13 May 2021 at 03:11, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Wed, 12 May 2021 09:54:18 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > On Wed, 12 May 2021 09:52:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > > > After merging the net-next tree, today's linux-next build (x86_64 > > > > allmodconfig) failed like this: > > > > > > > > drivers/usb/class/cdc-wdm.c: In function 'wdm_wwan_port_stop': > > > > drivers/usb/class/cdc-wdm.c:858:2: error: implicit declaration of function 'kill_urbs' [-Werror=implicit-function-declaration] > > > > 858 | kill_urbs(desc); > > > > | ^~~~~~~~~ > > > > > > > > Caused by commit > > > > > > > > cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") > > > > > > > > kill_urbs() was removed by commit > > > > > > > > 18abf8743674 ("cdc-wdm: untangle a circular dependency between callback and softint") > > > > > > > > Which is included in v5.13-rc1. > > > > > > Sorry, that commit is only in linux-next (from the usb.current tree). > > > I will do a merge fix up tomorrow - unless someone provides one. > > > > > > > I have used the net-next tree from next-20210511 for today. > > > > I have used the following merge fix patch for today. I don't know if > > this is sufficient (or even correct), but it does build. > > Thanks for working on this. > > > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > Date: Thu, 13 May 2021 11:04:09 +1000 > > Subject: [PATCH] usb: class: cdc-wdm: fix for kill_urbs() removal > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > --- > > drivers/usb/class/cdc-wdm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c > > index c88dcc4b6618..489b0e049402 100644 > > --- a/drivers/usb/class/cdc-wdm.c > > +++ b/drivers/usb/class/cdc-wdm.c > > @@ -855,7 +855,7 @@ static void wdm_wwan_port_stop(struct wwan_port *port) > > struct wdm_device *desc = wwan_port_get_drvdata(port); > > > > /* Stop all transfers and disable WWAN mode */ > > - kill_urbs(desc); > > + poison_urbs(desc); > > desc->manage_power(desc->intf, 0); > > clear_bit(WDM_READ, &desc->flags); > > clear_bit(WDM_WWAN_IN_USE, &desc->flags); > > AFAIU, each poison call must be balanced with unpoison call. > So you probably want to call unpoison_urbs right here, similarly to > wdm_release or wdm_suspend. I have added that call today. Thanks for the feedback. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc pseries_le_defconfig) failed like this: net/bridge/br_multicast.c: In function '__br_multicast_enable_port': net/bridge/br_multicast.c:1743:3: error: implicit declaration of function 'br_ip6_multicast_add_router'; did you mean 'br_ip4_multicast_add_router'? [-Werror=implicit-function-declaration] 1743 | br_ip6_multicast_add_router(br, port); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ | br_ip4_multicast_add_router net/bridge/br_multicast.c: At top level: net/bridge/br_multicast.c:2804:13: warning: conflicting types for 'br_ip6_multicast_add_router' 2804 | static void br_ip6_multicast_add_router(struct net_bridge *br, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ net/bridge/br_multicast.c:2804:13: error: static declaration of 'br_ip6_multicast_add_router' follows non-static declaration net/bridge/br_multicast.c:1743:3: note: previous implicit declaration of 'br_ip6_multicast_add_router' was here 1743 | br_ip6_multicast_add_router(br, port); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Caused by commit a3c02e769efe ("net: bridge: mcast: split multicast router state for IPv4 and IPv6") # CONFIG_IPV6 is not set I have reverted that commit for today (along with commit 3b85f9ba3480 ("net: bridge: mcast: export multicast router presence adjacent to a port") in case it depends on a3c02e769efe). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 774 bytes --] Hi all, Today's linux-next build (x86_64 modules_install) failed like this: depmod: ../tools/depmod.c:1792: depmod_report_cycles_from_root: Assertion `is < stack_size' failed. Caused by commit 62a6ef6a996f ("net: mdiobus: Introduce fwnode_mdbiobus_register()") (I bisected to there and tested the commit before.) The actual build is an x86_64 allmodconfig, followed by a modules_install. This happens in my cross build environment as well as a native build. $ gcc --version gcc (Debian 10.2.1-6) 10.2.1 20210110 $ ld --version GNU ld (GNU Binutils for Debian) 2.35.2 $ /sbin/depmod --version kmod version 28 -ZSTD +XZ -ZLIB +LIBCRYPTO -EXPERIMENTAL I have no idea why that commit should caused this failure. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen,
czw., 24 cze 2021 o 00:29 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a):
>
> Hi all,
>
> Today's linux-next build (x86_64 modules_install) failed like this:
>
> depmod: ../tools/depmod.c:1792: depmod_report_cycles_from_root: Assertion `is < stack_size' failed.
>
> Caused by commit
>
> 62a6ef6a996f ("net: mdiobus: Introduce fwnode_mdbiobus_register()")
>
> (I bisected to there and tested the commit before.)
>
> The actual build is an x86_64 allmodconfig, followed by a
> modules_install. This happens in my cross build environment as well as
> a native build.
>
> $ gcc --version
> gcc (Debian 10.2.1-6) 10.2.1 20210110
> $ ld --version
> GNU ld (GNU Binutils for Debian) 2.35.2
> $ /sbin/depmod --version
> kmod version 28
> -ZSTD +XZ -ZLIB +LIBCRYPTO -EXPERIMENTAL
>
> I have no idea why that commit should caused this failure.
Thank you for letting us know. Not sure if related, but I just found
out that this code won't compile for the !CONFIG_FWNODE_MDIO. Below
one-liner fixes it:
--- a/include/linux/fwnode_mdio.h
+++ b/include/linux/fwnode_mdio.h
@@ -40,7 +40,7 @@ static inline int fwnode_mdiobus_register(struct mii_bus *bus,
* This way, we don't have to keep compat bits around in drivers.
*/
- return mdiobus_register(mdio);
+ return mdiobus_register(bus);
}
#endif
I'm curious if this is the case. Tomorrow I'll resubmit with above, so
I'd appreciate recheck.
Thanks,
Marcin
> -----Original Message----- > From: Marcin Wojtas <mw@semihalf.com> > Sent: Thursday, June 24, 2021 6:47 AM > To: Stephen Rothwell <sfr@canb.auug.org.au> > Cc: David Miller <davem@davemloft.net>; Networking > <netdev@vger.kernel.org>; Linux Kernel Mailing List <linux- > kernel@vger.kernel.org>; Linux Next Mailing List <linux- > next@vger.kernel.org> > Subject: Re: linux-next: build failure after merge of the net-next tree > > Hi Stephen, > > czw., 24 cze 2021 o 00:29 Stephen Rothwell <sfr@canb.auug.org.au> > napisał(a): > > > > Hi all, > > > > Today's linux-next build (x86_64 modules_install) failed like this: > > > > depmod: ../tools/depmod.c:1792: depmod_report_cycles_from_root: > Assertion `is < stack_size' failed. > > > > Caused by commit > > > > 62a6ef6a996f ("net: mdiobus: Introduce fwnode_mdbiobus_register()") > > > > (I bisected to there and tested the commit before.) > > > > The actual build is an x86_64 allmodconfig, followed by a > > modules_install. This happens in my cross build environment as well > > as a native build. > > > > $ gcc --version > > gcc (Debian 10.2.1-6) 10.2.1 20210110 > > $ ld --version > > GNU ld (GNU Binutils for Debian) 2.35.2 $ /sbin/depmod --version kmod > > version 28 -ZSTD +XZ -ZLIB +LIBCRYPTO -EXPERIMENTAL > > > > I have no idea why that commit should caused this failure. > > Thank you for letting us know. Not sure if related, but I just found out that > this code won't compile for the !CONFIG_FWNODE_MDIO. Below one-liner > fixes it: > > --- a/include/linux/fwnode_mdio.h > +++ b/include/linux/fwnode_mdio.h > @@ -40,7 +40,7 @@ static inline int fwnode_mdiobus_register(struct > mii_bus *bus, > * This way, we don't have to keep compat bits around in drivers. > */ > > - return mdiobus_register(mdio); > + return mdiobus_register(bus); > } > #endif > > I'm curious if this is the case. Tomorrow I'll resubmit with above, so I'd > appreciate recheck. Hi Marcin, At my side, I got this error. I applied the suggested change, still the issue persist. depmod: ERROR: Cycle detected: acpi_mdio -> fwnode_mdio -> acpi_mdio depmod: ERROR: Found 2 modules in dependency cycles! Makefile:1773: recipe for target 'modules_install' failed make: *** [modules_install] Error 1 Regards, Athari > > Thanks, > Marcin
On Thu, Jun 24, 2021 at 12:46:48AM +0200, Marcin Wojtas wrote: > Hi Stephen, > > czw., 24 cze 2021 o 00:29 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a): > > > > Hi all, > > > > Today's linux-next build (x86_64 modules_install) failed like this: > > > > depmod: ../tools/depmod.c:1792: depmod_report_cycles_from_root: Assertion `is < stack_size' failed. > > > > Caused by commit > > > > 62a6ef6a996f ("net: mdiobus: Introduce fwnode_mdbiobus_register()") > > > > (I bisected to there and tested the commit before.) > > > > The actual build is an x86_64 allmodconfig, followed by a > > modules_install. This happens in my cross build environment as well as > > a native build. > > > > $ gcc --version > > gcc (Debian 10.2.1-6) 10.2.1 20210110 > > $ ld --version > > GNU ld (GNU Binutils for Debian) 2.35.2 > > $ /sbin/depmod --version > > kmod version 28 > > -ZSTD +XZ -ZLIB +LIBCRYPTO -EXPERIMENTAL > > > > I have no idea why that commit should caused this failure. > > Thank you for letting us know. Not sure if related, but I just found > out that this code won't compile for the !CONFIG_FWNODE_MDIO. Below > one-liner fixes it: > > --- a/include/linux/fwnode_mdio.h > +++ b/include/linux/fwnode_mdio.h > @@ -40,7 +40,7 @@ static inline int fwnode_mdiobus_register(struct mii_bus *bus, > * This way, we don't have to keep compat bits around in drivers. > */ > > - return mdiobus_register(mdio); > + return mdiobus_register(bus); > } > #endif > > I'm curious if this is the case. Tomorrow I'll resubmit with above, so > I'd appreciate recheck. I wonder if this message that I see with Arch Linux's config is related and maybe explains the issue a little bit more: $ curl -LSso .config https://raw.githubusercontent.com/archlinux/svntogit-packages/packages/linux/trunk/config # do not require pahole $ scripts/config -d DEBUG_INFO_BTF $ make -skj"$(nproc)" INSTALL_MOD_PATH=rootfs olddefconfig all modules_install ... depmod: ERROR: Cycle detected: acpi_mdio -> fwnode_mdio -> acpi_mdio depmod: ERROR: Found 2 modules in dependency cycles! ... Reverting all the patches in that series fixes the issue for me. Cheers, Nathan
Hi Marcin, On Thu, 24 Jun 2021 at 07:59, Nathan Chancellor <nathan@kernel.org> wrote: > > On Thu, Jun 24, 2021 at 12:46:48AM +0200, Marcin Wojtas wrote: > > Hi Stephen, > > > > czw., 24 cze 2021 o 00:29 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a): > > > > > > Hi all, > > > > > > Today's linux-next build (x86_64 modules_install) failed like this: > > > > > > depmod: ../tools/depmod.c:1792: depmod_report_cycles_from_root: Assertion `is < stack_size' failed. LKFT test farm found this build error. Regressions found on mips: - build/gcc-9-malta_defconfig - build/gcc-10-malta_defconfig - build/gcc-8-malta_defconfig depmod: ERROR: Cycle detected: fwnode_mdio -> of_mdio -> fwnode_mdio depmod: ERROR: Found 2 modules in dependency cycles! make[1]: *** [/builds/linux/Makefile:1875: modules_install] Error 1 > > Thank you for letting us know. Not sure if related, but I just found > > out that this code won't compile for the !CONFIG_FWNODE_MDIO. Below > > one-liner fixes it: > > > > --- a/include/linux/fwnode_mdio.h > > +++ b/include/linux/fwnode_mdio.h > > @@ -40,7 +40,7 @@ static inline int fwnode_mdiobus_register(struct mii_bus *bus, > > * This way, we don't have to keep compat bits around in drivers. > > */ > > > > - return mdiobus_register(mdio); > > + return mdiobus_register(bus); > > } > > #endif > > > > I'm curious if this is the case. Tomorrow I'll resubmit with above, so > > I'd appreciate recheck. This proposed fix did not work. > Reverting all the patches in that series fixes the issue for me. Yes. Reverting all the (6) patches in that series fixed this build problem. git log --oneline | head 3752a7bfe73e Revert "Documentation: ACPI: DSD: describe additional MAC configuration" da53528ed548 Revert "net: mdiobus: Introduce fwnode_mdbiobus_register()" 479b72ae8b68 Revert "net/fsl: switch to fwnode_mdiobus_register" 92f85677aff4 Revert "net: mvmdio: add ACPI support" 3d725ff0f271 Revert "net: mvpp2: enable using phylink with ACPI" ffa8c267d44e Revert "net: mvpp2: remove unused 'has_phy' field" d61c8b66c840 Add linux-next specific files for 20210623 steps to reproduce, config and build log located here in this link, https://builds.tuxbuild.com/1uNjGjPUAI4XwwcwKFr5FUxkwzy/ # TuxMake is a command line tool and Python library that provides # portable and repeatable Linux kernel builds across a variety of # architectures, toolchains, kernel configurations, and make targets. # # TuxMake supports the concept of runtimes. # See https://docs.tuxmake.org/runtimes/, for that to work it requires # that you install podman or docker on your system. # # To install tuxmake on your system globally: # sudo pip3 install -U tuxmake # # See https://docs.tuxmake.org/ for complete documentation. tuxmake --runtime podman --target-arch mips --toolchain gcc-10 --kconfig malta_defconfig - Naresh
Hi All, czw., 24 cze 2021 o 08:13 Naresh Kamboju <naresh.kamboju@linaro.org> napisał(a): > > Hi Marcin, > > On Thu, 24 Jun 2021 at 07:59, Nathan Chancellor <nathan@kernel.org> wrote: > > > > On Thu, Jun 24, 2021 at 12:46:48AM +0200, Marcin Wojtas wrote: > > > Hi Stephen, > > > > > > czw., 24 cze 2021 o 00:29 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a): > > > > > > > > Hi all, > > > > > > > > Today's linux-next build (x86_64 modules_install) failed like this: > > > > > > > > depmod: ../tools/depmod.c:1792: depmod_report_cycles_from_root: Assertion `is < stack_size' failed. > > LKFT test farm found this build error. > > Regressions found on mips: > > - build/gcc-9-malta_defconfig > - build/gcc-10-malta_defconfig > - build/gcc-8-malta_defconfig > > depmod: ERROR: Cycle detected: fwnode_mdio -> of_mdio -> fwnode_mdio > depmod: ERROR: Found 2 modules in dependency cycles! > make[1]: *** [/builds/linux/Makefile:1875: modules_install] Error 1 > > > > Thank you for letting us know. Not sure if related, but I just found > > > out that this code won't compile for the !CONFIG_FWNODE_MDIO. Below > > > one-liner fixes it: > > > > > > --- a/include/linux/fwnode_mdio.h > > > +++ b/include/linux/fwnode_mdio.h > > > @@ -40,7 +40,7 @@ static inline int fwnode_mdiobus_register(struct mii_bus *bus, > > > * This way, we don't have to keep compat bits around in drivers. > > > */ > > > > > > - return mdiobus_register(mdio); > > > + return mdiobus_register(bus); > > > } > > > #endif > > > > > > I'm curious if this is the case. Tomorrow I'll resubmit with above, so > > > I'd appreciate recheck. > > This proposed fix did not work. > > > Reverting all the patches in that series fixes the issue for me. > > Yes. > Reverting all the (6) patches in that series fixed this build problem. > > git log --oneline | head > 3752a7bfe73e Revert "Documentation: ACPI: DSD: describe additional MAC > configuration" > da53528ed548 Revert "net: mdiobus: Introduce fwnode_mdbiobus_register()" > 479b72ae8b68 Revert "net/fsl: switch to fwnode_mdiobus_register" > 92f85677aff4 Revert "net: mvmdio: add ACPI support" > 3d725ff0f271 Revert "net: mvpp2: enable using phylink with ACPI" > ffa8c267d44e Revert "net: mvpp2: remove unused 'has_phy' field" > d61c8b66c840 Add linux-next specific files for 20210623 > > steps to reproduce, config and build log located here in this link, > https://builds.tuxbuild.com/1uNjGjPUAI4XwwcwKFr5FUxkwzy/ > Thank you for your reports. I'm currently trying to reproduce and come back with a fix asap. Best regards, Marcin > > # TuxMake is a command line tool and Python library that provides > # portable and repeatable Linux kernel builds across a variety of > # architectures, toolchains, kernel configurations, and make targets. > # > # TuxMake supports the concept of runtimes. > # See https://docs.tuxmake.org/runtimes/, for that to work it requires > # that you install podman or docker on your system. > # > # To install tuxmake on your system globally: > # sudo pip3 install -U tuxmake > # > # See https://docs.tuxmake.org/ for complete documentation. > > > tuxmake --runtime podman --target-arch mips --toolchain gcc-10 > --kconfig malta_defconfig > > > - Naresh
[-- Attachment #1: Type: text/plain, Size: 2520 bytes --] Hi all, On Thu, 24 Jun 2021 11:43:14 +0530 Naresh Kamboju <naresh.kamboju@linaro.org> wrote: > > On Thu, 24 Jun 2021 at 07:59, Nathan Chancellor <nathan@kernel.org> wrote: > > > > On Thu, Jun 24, 2021 at 12:46:48AM +0200, Marcin Wojtas wrote: > > > Hi Stephen, > > > > > > czw., 24 cze 2021 o 00:29 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a): > > > > > > > > Hi all, > > > > > > > > Today's linux-next build (x86_64 modules_install) failed like this: > > > > > > > > depmod: ../tools/depmod.c:1792: depmod_report_cycles_from_root: Assertion `is < stack_size' failed. > > LKFT test farm found this build error. > > Regressions found on mips: > > - build/gcc-9-malta_defconfig > - build/gcc-10-malta_defconfig > - build/gcc-8-malta_defconfig > > depmod: ERROR: Cycle detected: fwnode_mdio -> of_mdio -> fwnode_mdio > depmod: ERROR: Found 2 modules in dependency cycles! > make[1]: *** [/builds/linux/Makefile:1875: modules_install] Error 1 > > > > Thank you for letting us know. Not sure if related, but I just found > > > out that this code won't compile for the !CONFIG_FWNODE_MDIO. Below > > > one-liner fixes it: > > > > > > --- a/include/linux/fwnode_mdio.h > > > +++ b/include/linux/fwnode_mdio.h > > > @@ -40,7 +40,7 @@ static inline int fwnode_mdiobus_register(struct mii_bus *bus, > > > * This way, we don't have to keep compat bits around in drivers. > > > */ > > > > > > - return mdiobus_register(mdio); > > > + return mdiobus_register(bus); > > > } > > > #endif > > > > > > I'm curious if this is the case. Tomorrow I'll resubmit with above, so > > > I'd appreciate recheck. > > This proposed fix did not work. > > > Reverting all the patches in that series fixes the issue for me. > > Yes. > Reverting all the (6) patches in that series fixed this build problem. > > git log --oneline | head > 3752a7bfe73e Revert "Documentation: ACPI: DSD: describe additional MAC > configuration" > da53528ed548 Revert "net: mdiobus: Introduce fwnode_mdbiobus_register()" > 479b72ae8b68 Revert "net/fsl: switch to fwnode_mdiobus_register" > 92f85677aff4 Revert "net: mvmdio: add ACPI support" > 3d725ff0f271 Revert "net: mvpp2: enable using phylink with ACPI" > ffa8c267d44e Revert "net: mvpp2: remove unused 'has_phy' field" > d61c8b66c840 Add linux-next specific files for 20210623 So I have reverted the merge of that topic branch from linux-next for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen,
czw., 24 cze 2021 o 10:54 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a):
>
> Hi all,
>
> On Thu, 24 Jun 2021 11:43:14 +0530 Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
> > On Thu, 24 Jun 2021 at 07:59, Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > On Thu, Jun 24, 2021 at 12:46:48AM +0200, Marcin Wojtas wrote:
> > > > Hi Stephen,
> > > >
> > > > czw., 24 cze 2021 o 00:29 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a):
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Today's linux-next build (x86_64 modules_install) failed like this:
> > > > >
> > > > > depmod: ../tools/depmod.c:1792: depmod_report_cycles_from_root: Assertion `is < stack_size' failed.
> >
> > LKFT test farm found this build error.
> >
> > Regressions found on mips:
> >
> > - build/gcc-9-malta_defconfig
> > - build/gcc-10-malta_defconfig
> > - build/gcc-8-malta_defconfig
> >
> > depmod: ERROR: Cycle detected: fwnode_mdio -> of_mdio -> fwnode_mdio
> > depmod: ERROR: Found 2 modules in dependency cycles!
> > make[1]: *** [/builds/linux/Makefile:1875: modules_install] Error 1
> >
> > > > Thank you for letting us know. Not sure if related, but I just found
> > > > out that this code won't compile for the !CONFIG_FWNODE_MDIO. Below
> > > > one-liner fixes it:
> > > >
> > > > --- a/include/linux/fwnode_mdio.h
> > > > +++ b/include/linux/fwnode_mdio.h
> > > > @@ -40,7 +40,7 @@ static inline int fwnode_mdiobus_register(struct mii_bus *bus,
> > > > * This way, we don't have to keep compat bits around in drivers.
> > > > */
> > > >
> > > > - return mdiobus_register(mdio);
> > > > + return mdiobus_register(bus);
> > > > }
> > > > #endif
> > > >
> > > > I'm curious if this is the case. Tomorrow I'll resubmit with above, so
> > > > I'd appreciate recheck.
> >
> > This proposed fix did not work.
> >
> > > Reverting all the patches in that series fixes the issue for me.
> >
> > Yes.
> > Reverting all the (6) patches in that series fixed this build problem.
> >
> > git log --oneline | head
> > 3752a7bfe73e Revert "Documentation: ACPI: DSD: describe additional MAC
> > configuration"
> > da53528ed548 Revert "net: mdiobus: Introduce fwnode_mdbiobus_register()"
> > 479b72ae8b68 Revert "net/fsl: switch to fwnode_mdiobus_register"
> > 92f85677aff4 Revert "net: mvmdio: add ACPI support"
> > 3d725ff0f271 Revert "net: mvpp2: enable using phylink with ACPI"
> > ffa8c267d44e Revert "net: mvpp2: remove unused 'has_phy' field"
> > d61c8b66c840 Add linux-next specific files for 20210623
>
> So I have reverted the merge of that topic branch from linux-next for
> today.
Just to understand correctly - you reverted merge from the local
branch (I still see the commits on Dave M's net-next/master). I see a
quick solution, but I'm wondering how I should proceed. Submit a
correction patch to the mailing lists against the net-next? Or the
branch is going to be reverted and I should resubmit everything as v4?
Best regards,
Marcin
Hi Marcin,
On 6/24/2021 7:25 AM, Marcin Wojtas wrote:
> Hi Stephen,
>
> czw., 24 cze 2021 o 10:54 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a):
>>
>> Hi all,
>>
>> On Thu, 24 Jun 2021 11:43:14 +0530 Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>>>
>>> On Thu, 24 Jun 2021 at 07:59, Nathan Chancellor <nathan@kernel.org> wrote:
>>>>
>>>> On Thu, Jun 24, 2021 at 12:46:48AM +0200, Marcin Wojtas wrote:
>>>>> Hi Stephen,
>>>>>
>>>>> czw., 24 cze 2021 o 00:29 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a):
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Today's linux-next build (x86_64 modules_install) failed like this:
>>>>>>
>>>>>> depmod: ../tools/depmod.c:1792: depmod_report_cycles_from_root: Assertion `is < stack_size' failed.
>>>
>>> LKFT test farm found this build error.
>>>
>>> Regressions found on mips:
>>>
>>> - build/gcc-9-malta_defconfig
>>> - build/gcc-10-malta_defconfig
>>> - build/gcc-8-malta_defconfig
>>>
>>> depmod: ERROR: Cycle detected: fwnode_mdio -> of_mdio -> fwnode_mdio
>>> depmod: ERROR: Found 2 modules in dependency cycles!
>>> make[1]: *** [/builds/linux/Makefile:1875: modules_install] Error 1
>>>
>>>>> Thank you for letting us know. Not sure if related, but I just found
>>>>> out that this code won't compile for the !CONFIG_FWNODE_MDIO. Below
>>>>> one-liner fixes it:
>>>>>
>>>>> --- a/include/linux/fwnode_mdio.h
>>>>> +++ b/include/linux/fwnode_mdio.h
>>>>> @@ -40,7 +40,7 @@ static inline int fwnode_mdiobus_register(struct mii_bus *bus,
>>>>> * This way, we don't have to keep compat bits around in drivers.
>>>>> */
>>>>>
>>>>> - return mdiobus_register(mdio);
>>>>> + return mdiobus_register(bus);
>>>>> }
>>>>> #endif
>>>>>
>>>>> I'm curious if this is the case. Tomorrow I'll resubmit with above, so
>>>>> I'd appreciate recheck.
>>>
>>> This proposed fix did not work.
>>>
>>>> Reverting all the patches in that series fixes the issue for me.
>>>
>>> Yes.
>>> Reverting all the (6) patches in that series fixed this build problem.
>>>
>>> git log --oneline | head
>>> 3752a7bfe73e Revert "Documentation: ACPI: DSD: describe additional MAC
>>> configuration"
>>> da53528ed548 Revert "net: mdiobus: Introduce fwnode_mdbiobus_register()"
>>> 479b72ae8b68 Revert "net/fsl: switch to fwnode_mdiobus_register"
>>> 92f85677aff4 Revert "net: mvmdio: add ACPI support"
>>> 3d725ff0f271 Revert "net: mvpp2: enable using phylink with ACPI"
>>> ffa8c267d44e Revert "net: mvpp2: remove unused 'has_phy' field"
>>> d61c8b66c840 Add linux-next specific files for 20210623
>>
>> So I have reverted the merge of that topic branch from linux-next for
>> today.
>
> Just to understand correctly - you reverted merge from the local
> branch (I still see the commits on Dave M's net-next/master). I see a
> quick solution, but I'm wondering how I should proceed. Submit a
> correction patch to the mailing lists against the net-next? Or the
> branch is going to be reverted and I should resubmit everything as v4?
As far as I am aware, net and net-next are not rebased so you would need
to submit a fixup patch against the current net-next with a proper
Fixes: tag.
Cheers,
Nathan
Hi David & Jakub,
czw., 24 cze 2021 o 18:40 Nathan Chancellor <nathan@kernel.org> napisał(a):
>
> Hi Marcin,
>
> On 6/24/2021 7:25 AM, Marcin Wojtas wrote:
> > Hi Stephen,
> >
> > czw., 24 cze 2021 o 10:54 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a):
> >>
> >> Hi all,
> >>
> >> On Thu, 24 Jun 2021 11:43:14 +0530 Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >>>
> >>> On Thu, 24 Jun 2021 at 07:59, Nathan Chancellor <nathan@kernel.org> wrote:
> >>>>
> >>>> On Thu, Jun 24, 2021 at 12:46:48AM +0200, Marcin Wojtas wrote:
> >>>>> Hi Stephen,
> >>>>>
> >>>>> czw., 24 cze 2021 o 00:29 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a):
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> Today's linux-next build (x86_64 modules_install) failed like this:
> >>>>>>
> >>>>>> depmod: ../tools/depmod.c:1792: depmod_report_cycles_from_root: Assertion `is < stack_size' failed.
> >>>
> >>> LKFT test farm found this build error.
> >>>
> >>> Regressions found on mips:
> >>>
> >>> - build/gcc-9-malta_defconfig
> >>> - build/gcc-10-malta_defconfig
> >>> - build/gcc-8-malta_defconfig
> >>>
> >>> depmod: ERROR: Cycle detected: fwnode_mdio -> of_mdio -> fwnode_mdio
> >>> depmod: ERROR: Found 2 modules in dependency cycles!
> >>> make[1]: *** [/builds/linux/Makefile:1875: modules_install] Error 1
> >>>
> >>>>> Thank you for letting us know. Not sure if related, but I just found
> >>>>> out that this code won't compile for the !CONFIG_FWNODE_MDIO. Below
> >>>>> one-liner fixes it:
> >>>>>
> >>>>> --- a/include/linux/fwnode_mdio.h
> >>>>> +++ b/include/linux/fwnode_mdio.h
> >>>>> @@ -40,7 +40,7 @@ static inline int fwnode_mdiobus_register(struct mii_bus *bus,
> >>>>> * This way, we don't have to keep compat bits around in drivers.
> >>>>> */
> >>>>>
> >>>>> - return mdiobus_register(mdio);
> >>>>> + return mdiobus_register(bus);
> >>>>> }
> >>>>> #endif
> >>>>>
> >>>>> I'm curious if this is the case. Tomorrow I'll resubmit with above, so
> >>>>> I'd appreciate recheck.
> >>>
> >>> This proposed fix did not work.
> >>>
> >>>> Reverting all the patches in that series fixes the issue for me.
> >>>
> >>> Yes.
> >>> Reverting all the (6) patches in that series fixed this build problem.
> >>>
> >>> git log --oneline | head
> >>> 3752a7bfe73e Revert "Documentation: ACPI: DSD: describe additional MAC
> >>> configuration"
> >>> da53528ed548 Revert "net: mdiobus: Introduce fwnode_mdbiobus_register()"
> >>> 479b72ae8b68 Revert "net/fsl: switch to fwnode_mdiobus_register"
> >>> 92f85677aff4 Revert "net: mvmdio: add ACPI support"
> >>> 3d725ff0f271 Revert "net: mvpp2: enable using phylink with ACPI"
> >>> ffa8c267d44e Revert "net: mvpp2: remove unused 'has_phy' field"
> >>> d61c8b66c840 Add linux-next specific files for 20210623
> >>
> >> So I have reverted the merge of that topic branch from linux-next for
> >> today.
> >
> > Just to understand correctly - you reverted merge from the local
> > branch (I still see the commits on Dave M's net-next/master). I see a
> > quick solution, but I'm wondering how I should proceed. Submit a
> > correction patch to the mailing lists against the net-next? Or the
> > branch is going to be reverted and I should resubmit everything as v4?
>
> As far as I am aware, net and net-next are not rebased so you would need
> to submit a fixup patch against the current net-next with a proper
> Fixes: tag.
>
TL;DR, we need to get rid of a helper routine (introduced so that to
address review comments of v1), as it causes a depmod cycles when
fwnode_/of_/acpi_mdio are built as modules.
It can be done twofold:
a. 3 commits, i.e:
Revert "net: mdiobus: Introduce fwnode_mdbiobus_register()"
Revert "net/fsl: switch to fwnode_mdiobus_register"
net: mvmdio: resign from fwnode_mdiobus_register
b. Same diff but squashed.
Please let me know your preference, so that I can do it properly up front.
Thanks,
Marcin
On Thu, 24 Jun 2021 20:15:00 +0200 Marcin Wojtas wrote:
> TL;DR, we need to get rid of a helper routine (introduced so that to
> address review comments of v1), as it causes a depmod cycles when
> fwnode_/of_/acpi_mdio are built as modules.
> It can be done twofold:
> a. 3 commits, i.e:
> Revert "net: mdiobus: Introduce fwnode_mdbiobus_register()"
> Revert "net/fsl: switch to fwnode_mdiobus_register"
> net: mvmdio: resign from fwnode_mdiobus_register
> b. Same diff but squashed.
>
> Please let me know your preference, so that I can do it properly up front.
Not sure if Dave will notice this mid-thread question. It probably
doesn't matter as long as (1) doesn't introduce further transient
build failures.
Hi Jakub,
Thanks for your prompt response.
czw., 24 cze 2021 o 21:14 Jakub Kicinski <kuba@kernel.org> napisał(a):
>
> On Thu, 24 Jun 2021 20:15:00 +0200 Marcin Wojtas wrote:
> > TL;DR, we need to get rid of a helper routine (introduced so that to
> > address review comments of v1), as it causes a depmod cycles when
> > fwnode_/of_/acpi_mdio are built as modules.
> > It can be done twofold:
> > a. 3 commits, i.e:
> > Revert "net: mdiobus: Introduce fwnode_mdbiobus_register()"
> > Revert "net/fsl: switch to fwnode_mdiobus_register"
> > net: mvmdio: resign from fwnode_mdiobus_register
> > b. Same diff but squashed.
> >
> > Please let me know your preference, so that I can do it properly up front.
>
> Not sure if Dave will notice this mid-thread question. It probably
> doesn't matter as long as (1) doesn't introduce further transient
> build failures.
I think I'll go with the squashed rollback commit that removes the
problematic helper, as it may be easier to apply. I'll double check
modules_install before.
Best regards,
Marcin
[-- Attachment #1: Type: text/plain, Size: 566 bytes --] Hi Marcin, On Thu, 24 Jun 2021 16:25:57 +0200 Marcin Wojtas <mw@semihalf.com> wrote: > > Just to understand correctly - you reverted merge from the local > branch (I still see the commits on Dave M's net-next/master). I see a Yes, I reverted the merge in linux-next only. > quick solution, but I'm wondering how I should proceed. Submit a > correction patch to the mailing lists against the net-next? Or the > branch is going to be reverted and I should resubmit everything as v4? I see others have answered this. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen, pt., 25 cze 2021 o 00:41 Stephen Rothwell <sfr@canb.auug.org.au> napisał(a): > > Hi Marcin, > > On Thu, 24 Jun 2021 16:25:57 +0200 Marcin Wojtas <mw@semihalf.com> wrote: > > > > Just to understand correctly - you reverted merge from the local > > branch (I still see the commits on Dave M's net-next/master). I see a > > Yes, I reverted the merge in linux-next only. Would it be possible to re-integrate 'marvell-mdio-ACPI' branch along with the 2 fixes that resolve the reported depmod issue? c88c192dc3ea - net: mdiobus: fix fwnode_mdbiobus_register() fallback case ac53c26433b5 - net: mdiobus: withdraw fwnode_mdbiobus_register The first one is needed to apply the second without conflicts. Best regards, Marcin > > > quick solution, but I'm wondering how I should proceed. Submit a > > correction patch to the mailing lists against the net-next? Or the > > branch is going to be reverted and I should resubmit everything as v4? > > I see others have answered this. >
[-- Attachment #1: Type: text/plain, Size: 3076 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from include/net/dsa.h:23, from net/ethernet/eth.c:59: include/net/switchdev.h:410:1: error: expected identifier or '(' before '{' token 410 | { | ^ include/net/switchdev.h:399:1: warning: 'switchdev_handle_fdb_del_to_device' declared 'static' but never defined [-Wunused-function] 399 | switchdev_handle_fdb_del_to_device(struct net_device *dev, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/net/dsa.h:23, from net/core/flow_dissector.c:8: include/net/switchdev.h:410:1: error: expected identifier or '(' before '{' token 410 | { | ^ include/net/switchdev.h:399:1: warning: 'switchdev_handle_fdb_del_to_device' declared 'static' but never defined [-Wunused-function] 399 | switchdev_handle_fdb_del_to_device(struct net_device *dev, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/net/dsa.h:23, from net/core/dev.c:102: include/net/switchdev.h:410:1: error: expected identifier or '(' before '{' token 410 | { | ^ include/net/switchdev.h:399:1: warning: 'switchdev_handle_fdb_del_to_device' declared 'static' but never defined [-Wunused-function] 399 | switchdev_handle_fdb_del_to_device(struct net_device *dev, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/net/vxlan.h:9, from drivers/net/ethernet/emulex/benet/be_main.c:22: include/net/switchdev.h:410:1: error: expected identifier or '(' before '{' token 410 | { | ^ include/net/switchdev.h:399:1: warning: 'switchdev_handle_fdb_del_to_device' declared 'static' but never defined [-Wunused-function] 399 | switchdev_handle_fdb_del_to_device(struct net_device *dev, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/net/vxlan.h:9, from drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:37: include/net/switchdev.h:410:1: error: expected identifier or '(' before '{' token 410 | { | ^ include/net/switchdev.h:399:1: warning: 'switchdev_handle_fdb_del_to_device' declared 'static' but never defined [-Wunused-function] 399 | switchdev_handle_fdb_del_to_device(struct net_device *dev, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/net/vxlan.h:9, from drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:50: include/net/switchdev.h:410:1: error: expected identifier or '(' before '{' token 410 | { | ^ include/net/switchdev.h:399:1: warning: 'switchdev_handle_fdb_del_to_device' declared 'static' but never defined [-Wunused-function] 399 | switchdev_handle_fdb_del_to_device(struct net_device *dev, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Caused by commit 8ca07176ab00 ("net: switchdev: introduce a fanout helper for SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE") I have used the net-next tree from next-20210720 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, Jul 21, 2021 at 11:26:52AM +1000, Stephen Rothwell wrote: > include/net/switchdev.h:399:1: warning: 'switchdev_handle_fdb_del_to_device' declared 'static' but never defined [-Wunused-function] > 399 | switchdev_handle_fdb_del_to_device(struct net_device *dev, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sorry for the breakage. https://patchwork.kernel.org/project/netdevbpf/patch/20210720173557.999534-2-vladimir.oltean@nxp.com/
Hi all, After merging the mac80211-next tree, today's linux-next build (x86 allmodconfig) failed like this: /tmp/next/build/drivers/net/wwan/mhi_wwan_mbim.c: In function 'mhi_mbim_probe': /tmp/next/build/drivers/net/wwan/mhi_wwan_mbim.c:611:8: error: too few arguments to function 'mhi_prepare_for_transfer' err = mhi_prepare_for_transfer(mhi_dev); ^~~~~~~~~~~~~~~~~~~~~~~~ In file included from /tmp/next/build/drivers/net/wwan/mhi_wwan_mbim.c:18: /tmp/next/build/include/linux/mhi.h:726:5: note: declared here int mhi_prepare_for_transfer(struct mhi_device *mhi_dev, ^~~~~~~~~~~~~~~~~~~~~~~~ Caused by commit aa730a9905b7b079ef2ff ("net: wwan: Add MHI MBIM network driver") That API has been modified in ce78ffa3ef16810 ("net: really fix the build...") in the net tree. I've used the net-next tree from yesterday.
From: Mark Brown <broonie@kernel.org>
Date: Thu, 5 Aug 2021 13:01:38 +0100
> Hi all,
>
> After merging the mac80211-next tree, today's linux-next build
> (x86 allmodconfig) failed like this:
>
> /tmp/next/build/drivers/net/wwan/mhi_wwan_mbim.c: In function 'mhi_mbim_probe':
> /tmp/next/build/drivers/net/wwan/mhi_wwan_mbim.c:611:8: error: too few arguments to function 'mhi_prepare_for_transfer'
> err = mhi_prepare_for_transfer(mhi_dev);
> ^~~~~~~~~~~~~~~~~~~~~~~~
> In file included from /tmp/next/build/drivers/net/wwan/mhi_wwan_mbim.c:18:
> /tmp/next/build/include/linux/mhi.h:726:5: note: declared here
> int mhi_prepare_for_transfer(struct mhi_device *mhi_dev,
> ^~~~~~~~~~~~~~~~~~~~~~~~
> Caused by commit
>
> aa730a9905b7b079ef2ff ("net: wwan: Add MHI MBIM network driver")
>
> That API has been modified in ce78ffa3ef16810 ("net: really fix the
> build...") in the net tree. I've used the net-next tree from yesterday.
Should be fixed now, thanks.
On Thu, 5 Aug 2021 at 14:01, Mark Brown <broonie@kernel.org> wrote: > > Hi all, > > After merging the mac80211-next tree, today's linux-next build > (x86 allmodconfig) failed like this: > > /tmp/next/build/drivers/net/wwan/mhi_wwan_mbim.c: In function 'mhi_mbim_probe': > /tmp/next/build/drivers/net/wwan/mhi_wwan_mbim.c:611:8: error: too few arguments to function 'mhi_prepare_for_transfer' > err = mhi_prepare_for_transfer(mhi_dev); > ^~~~~~~~~~~~~~~~~~~~~~~~ > In file included from /tmp/next/build/drivers/net/wwan/mhi_wwan_mbim.c:18: > /tmp/next/build/include/linux/mhi.h:726:5: note: declared here > int mhi_prepare_for_transfer(struct mhi_device *mhi_dev, > ^~~~~~~~~~~~~~~~~~~~~~~~ > > > Caused by commit > > aa730a9905b7b079ef2ff ("net: wwan: Add MHI MBIM network driver") Thanks for reporting, I see David already fixed the issue in net-next tree. Actually, we also need the same change for mhi_net driver to fix 7ffa7542eca6 ("net: mhi: Remove MBIM protocol"). diff --git a/drivers/net/mhi_net.c b/drivers/net/mhi_net.c index d127eb6..975f7f9 100644 --- a/drivers/net/mhi_net.c +++ b/drivers/net/mhi_net.c @@ -319,7 +319,7 @@ static int mhi_net_newlink(struct mhi_device *mhi_dev, struct net_device *ndev) u64_stats_init(&mhi_netdev->stats.tx_syncp); /* Start MHI channels */ - err = mhi_prepare_for_transfer(mhi_dev); + err = mhi_prepare_for_transfer(mhi_dev, 0); if (err) goto out_err; Regards, Loic > > That API has been modified in ce78ffa3ef16810 ("net: really fix the > build...") in the net tree. I've used the net-next tree from yesterday.
[-- Attachment #1: Type: text/plain, Size: 1394 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/ethernet/cirrus/cs89x0.c: In function 'net_open': drivers/net/ethernet/cirrus/cs89x0.c:897:20: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration] 897 | (unsigned long)isa_virt_to_bus(lp->dma_buff)); | ^~~~~~~~~~~~~~~ include/linux/dynamic_debug.h:134:15: note: in definition of macro '__dynamic_func_call' 134 | func(&id, ##__VA_ARGS__); \ | ^~~~~~~~~~~ include/linux/dynamic_debug.h:162:2: note: in expansion of macro '_dynamic_func_call' 162 | _dynamic_func_call(fmt, __dynamic_pr_debug, \ | ^~~~~~~~~~~~~~~~~~ include/linux/printk.h:570:2: note: in expansion of macro 'dynamic_pr_debug' 570 | dynamic_pr_debug(fmt, ##__VA_ARGS__) | ^~~~~~~~~~~~~~~~ drivers/net/ethernet/cirrus/cs89x0.c:86:3: note: in expansion of macro 'pr_debug' 86 | pr_##level(fmt, ##__VA_ARGS__); \ | ^~~ drivers/net/ethernet/cirrus/cs89x0.c:894:3: note: in expansion of macro 'cs89_dbg' 894 | cs89_dbg(1, debug, "%s: dma %lx %lx\n", | ^~~~~~~~ Caused by commit 47fd22f2b847 ("cs89x0: rework driver configuration") I have removed the COMPILE_TEST from NET_VENDOR_CIRRUS for now. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Mon, Aug 9, 2021 at 12:20 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/net/ethernet/cirrus/cs89x0.c: In function 'net_open':
> drivers/net/ethernet/cirrus/cs89x0.c:897:20: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration]
> 897 | (unsigned long)isa_virt_to_bus(lp->dma_buff));
> | ^~~~~~~~~~~~~~~
Thank you for the report! I already sent a patch for m68knommu running into
this issue, but it seems there are other architectures that still have it.
The driver checks CONFIG_ISA_DMA_API at compile time to determine
whether isa_virt_to_bus(), set_dma_mode(), set_dma_addr(), ... are all
defined.
It seems that isa_virt_to_bus() is only implemented on most of the
architectures that set ISA_DMA_API: alpha, arm, mips, parisc and x86,
but not on m68k/coldfire and powerpc.
Before my patch, the platform driver could only be built on ARM,
so maybe we should just go back to that dependency or something
like
depends on ARM || ((X86 || !ISA_DMA_API) && COMPILE_TEST)
for extra build coverage. Then again, it's hard to find any machine
actually using these: we have a couple of s3c24xx machines that
use the wrong device name, so the device never gets probed, the imx
machines that used to work are gone, and the ep7211-edb7211.dts
is missing a device node for it. Most likely, neither the platform nor
the ISA driver are actually used by anyone.
Arnd
[-- Attachment #1: Type: text/plain, Size: 1852 bytes --] Hi all, On Mon, 9 Aug 2021 15:21:41 +0200 Arnd Bergmann <arnd@arndb.de> wrote: > > On Mon, Aug 9, 2021 at 12:20 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > After merging the net-next tree, today's linux-next build (powerpc > > allyesconfig) failed like this: > > > > drivers/net/ethernet/cirrus/cs89x0.c: In function 'net_open': > > drivers/net/ethernet/cirrus/cs89x0.c:897:20: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration] > > 897 | (unsigned long)isa_virt_to_bus(lp->dma_buff)); > > | ^~~~~~~~~~~~~~~ > > Thank you for the report! I already sent a patch for m68knommu running into > this issue, but it seems there are other architectures that still have it. > > The driver checks CONFIG_ISA_DMA_API at compile time to determine > whether isa_virt_to_bus(), set_dma_mode(), set_dma_addr(), ... are all > defined. > > It seems that isa_virt_to_bus() is only implemented on most of the > architectures that set ISA_DMA_API: alpha, arm, mips, parisc and x86, > but not on m68k/coldfire and powerpc. > > Before my patch, the platform driver could only be built on ARM, > so maybe we should just go back to that dependency or something > like > > depends on ARM || ((X86 || !ISA_DMA_API) && COMPILE_TEST) > > for extra build coverage. Then again, it's hard to find any machine > actually using these: we have a couple of s3c24xx machines that > use the wrong device name, so the device never gets probed, the imx > machines that used to work are gone, and the ep7211-edb7211.dts > is missing a device node for it. Most likely, neither the platform nor > the ISA driver are actually used by anyone. I am still applying my patch removing COMPILE_TEST from this driver .. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2061 bytes --] Hi all, On Sun, 15 Aug 2021 22:04:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Mon, 9 Aug 2021 15:21:41 +0200 Arnd Bergmann <arnd@arndb.de> wrote: > > > > On Mon, Aug 9, 2021 at 12:20 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > After merging the net-next tree, today's linux-next build (powerpc > > > allyesconfig) failed like this: > > > > > > drivers/net/ethernet/cirrus/cs89x0.c: In function 'net_open': > > > drivers/net/ethernet/cirrus/cs89x0.c:897:20: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration] > > > 897 | (unsigned long)isa_virt_to_bus(lp->dma_buff)); > > > | ^~~~~~~~~~~~~~~ > > > > Thank you for the report! I already sent a patch for m68knommu running into > > this issue, but it seems there are other architectures that still have it. > > > > The driver checks CONFIG_ISA_DMA_API at compile time to determine > > whether isa_virt_to_bus(), set_dma_mode(), set_dma_addr(), ... are all > > defined. > > > > It seems that isa_virt_to_bus() is only implemented on most of the > > architectures that set ISA_DMA_API: alpha, arm, mips, parisc and x86, > > but not on m68k/coldfire and powerpc. > > > > Before my patch, the platform driver could only be built on ARM, > > so maybe we should just go back to that dependency or something > > like > > > > depends on ARM || ((X86 || !ISA_DMA_API) && COMPILE_TEST) > > > > for extra build coverage. Then again, it's hard to find any machine > > actually using these: we have a couple of s3c24xx machines that > > use the wrong device name, so the device never gets probed, the imx > > machines that used to work are gone, and the ep7211-edb7211.dts > > is missing a device node for it. Most likely, neither the platform nor > > the ISA driver are actually used by anyone. > > I am still applying my patch removing COMPILE_TEST from this driver .. Ping? Did I miss a fix being merged? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 730 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/net/ethernet/broadcom/bnx2.c: In function 'bnx2_read_vpd_fw_ver': drivers/net/ethernet/broadcom/bnx2.c:8055:6: error: implicit declaration of function 'pci_vpd_find_ro_info_keyword'; did you mean 'pci_vpd_find_info_keyword'? [-Werror=implicit-function-declaration] 8055 | j = pci_vpd_find_ro_info_keyword(data, BNX2_VPD_LEN, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ | pci_vpd_find_info_keyword Caused by commit ddc122aac91f ("bnx2: Search VPD with pci_vpd_find_ro_info_keyword()") I have used the net-next tree from next-20210820 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 23.08.2021 04:09, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/net/ethernet/broadcom/bnx2.c: In function 'bnx2_read_vpd_fw_ver':
> drivers/net/ethernet/broadcom/bnx2.c:8055:6: error: implicit declaration of function 'pci_vpd_find_ro_info_keyword'; did you mean 'pci_vpd_find_info_keyword'? [-Werror=implicit-function-declaration]
> 8055 | j = pci_vpd_find_ro_info_keyword(data, BNX2_VPD_LEN,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | pci_vpd_find_info_keyword
>
> Caused by commit
>
> ddc122aac91f ("bnx2: Search VPD with pci_vpd_find_ro_info_keyword()")
>
> I have used the net-next tree from next-20210820 for today.
>
This series was supposed to go through the PCI tree. It builds on recent patches
that are in the PCI tree, but not in linux-next yet.
I mentioned this dependency in the cover letter for the last series, but forgot
it this time. Sorry.
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 23 Aug 2021 08:34:53 +0200
> On 23.08.2021 04:09, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the net-next tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> drivers/net/ethernet/broadcom/bnx2.c: In function 'bnx2_read_vpd_fw_ver':
>> drivers/net/ethernet/broadcom/bnx2.c:8055:6: error: implicit declaration of function 'pci_vpd_find_ro_info_keyword'; did you mean 'pci_vpd_find_info_keyword'? [-Werror=implicit-function-declaration]
>> 8055 | j = pci_vpd_find_ro_info_keyword(data, BNX2_VPD_LEN,
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> | pci_vpd_find_info_keyword
>>
>> Caused by commit
>>
>> ddc122aac91f ("bnx2: Search VPD with pci_vpd_find_ro_info_keyword()")
>>
>> I have used the net-next tree from next-20210820 for today.
>>
> This series was supposed to go through the PCI tree. It builds on recent patches
> that are in the PCI tree, but not in linux-next yet.
> I mentioned this dependency in the cover letter for the last series, but forgot
> it this time. Sorry.
I reverted it all, please don't forget the cover letter like this.
Thanks.
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/wwan/mhi_wwan_mbim.c: In function 'mhi_mbim_probe': drivers/net/wwan/mhi_wwan_mbim.c:612:8: error: too many arguments to function 'mhi_prepare_for_transfer' 612 | err = mhi_prepare_for_transfer(mhi_dev, 0); | ^~~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/net/wwan/mhi_wwan_mbim.c:18: include/linux/mhi.h:725:5: note: declared here 725 | int mhi_prepare_for_transfer(struct mhi_device *mhi_dev); | ^~~~~~~~~~~~~~~~~~~~~~~~ Caused by commits aa730a9905b7 ("net: wwan: Add MHI MBIM network driver") ab996c420508 ("wwan: mhi: Fix build.") a85b99ab6abb ("Revert "wwan: mhi: Fix build."") 0ca8d3ca4561 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") interacting with commit 9ebc2758d0bb ("Revert "net: really fix the build..."") from Linus' tree. I have applied the following merge fix patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 27 Aug 2021 12:02:29 +1000 Subject: [PATCH] fix for commit 9ebc2758d0bb "Revert "net: really fix the build..."" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/wwan/mhi_wwan_mbim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wwan/mhi_wwan_mbim.c b/drivers/net/wwan/mhi_wwan_mbim.c index 377529bbf124..71bf9b4f769f 100644 --- a/drivers/net/wwan/mhi_wwan_mbim.c +++ b/drivers/net/wwan/mhi_wwan_mbim.c @@ -609,7 +609,7 @@ static int mhi_mbim_probe(struct mhi_device *mhi_dev, const struct mhi_device_id INIT_DELAYED_WORK(&mbim->rx_refill, mhi_net_rx_refill_work); /* Start MHI channels */ - err = mhi_prepare_for_transfer(mhi_dev, 0); + err = mhi_prepare_for_transfer(mhi_dev); if (err) return err; -- 2.32.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2355 bytes --] Hi all, After merging the net-next tree, today's linux-next build (X86_64 allnoconfig) failed like this: arch/x86/kernel/setup.c: In function 'setup_arch': arch/x86/kernel/setup.c:916:6: error: implicit declaration of function 'acpi_mps_check' [-Werror=implicit-function-declaration] 916 | if (acpi_mps_check()) { | ^~~~~~~~~~~~~~ arch/x86/kernel/setup.c:1110:2: error: implicit declaration of function 'acpi_table_upgrade' [-Werror=implicit-function-declaration] 1110 | acpi_table_upgrade(); | ^~~~~~~~~~~~~~~~~~ arch/x86/kernel/setup.c:1112:2: error: implicit declaration of function 'acpi_boot_table_init' [-Werror=implicit-function-declaration] 1112 | acpi_boot_table_init(); | ^~~~~~~~~~~~~~~~~~~~ arch/x86/kernel/setup.c:1120:2: error: implicit declaration of function 'early_acpi_boot_init'; did you mean 'early_cpu_init'? [-Werror=implicit-function-declaration] 1120 | early_acpi_boot_init(); | ^~~~~~~~~~~~~~~~~~~~ | early_cpu_init arch/x86/kernel/setup.c:1162:2: error: implicit declaration of function 'acpi_boot_init' [-Werror=implicit-function-declaration] 1162 | acpi_boot_init(); | ^~~~~~~~~~~~~~ Caused by commit 342f43af70db ("iscsi_ibft: fix crash due to KASLR physical memory remapping") Unfortunately that commit has now been merged into Linus' tree as well. I have added the following fix patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 1 Sep 2021 16:31:32 +1000 Subject: [PATCH] x86: include acpi.h when using acpi functions The removal of the include of linux/acpi.h from include/linux/iscsi_ibft.h by commit 342f43af70db ("iscsi_ibft: fix crash due to KASLR physical memory remapping") exposed this build failure. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/x86/kernel/setup.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 63b20536c8d2..da0a4b64880f 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -13,6 +13,7 @@ #include <linux/init_ohci1394_dma.h> #include <linux/initrd.h> #include <linux/iscsi_ibft.h> +#include <linux/acpi.h> #include <linux/memblock.h> #include <linux/panic_notifier.h> #include <linux/pci.h> -- 2.32.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2375 bytes --] Hi all, On Fri, 20 Aug 2021 09:16:27 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Sun, 15 Aug 2021 22:04:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Mon, 9 Aug 2021 15:21:41 +0200 Arnd Bergmann <arnd@arndb.de> wrote: > > > > > > On Mon, Aug 9, 2021 at 12:20 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > > > After merging the net-next tree, today's linux-next build (powerpc > > > > allyesconfig) failed like this: > > > > > > > > drivers/net/ethernet/cirrus/cs89x0.c: In function 'net_open': > > > > drivers/net/ethernet/cirrus/cs89x0.c:897:20: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration] > > > > 897 | (unsigned long)isa_virt_to_bus(lp->dma_buff)); > > > > | ^~~~~~~~~~~~~~~ > > > > > > Thank you for the report! I already sent a patch for m68knommu running into > > > this issue, but it seems there are other architectures that still have it. > > > > > > The driver checks CONFIG_ISA_DMA_API at compile time to determine > > > whether isa_virt_to_bus(), set_dma_mode(), set_dma_addr(), ... are all > > > defined. > > > > > > It seems that isa_virt_to_bus() is only implemented on most of the > > > architectures that set ISA_DMA_API: alpha, arm, mips, parisc and x86, > > > but not on m68k/coldfire and powerpc. > > > > > > Before my patch, the platform driver could only be built on ARM, > > > so maybe we should just go back to that dependency or something > > > like > > > > > > depends on ARM || ((X86 || !ISA_DMA_API) && COMPILE_TEST) > > > > > > for extra build coverage. Then again, it's hard to find any machine > > > actually using these: we have a couple of s3c24xx machines that > > > use the wrong device name, so the device never gets probed, the imx > > > machines that used to work are gone, and the ep7211-edb7211.dts > > > is missing a device node for it. Most likely, neither the platform nor > > > the ISA driver are actually used by anyone. > > > > I am still applying my patch removing COMPILE_TEST from this driver .. > > Ping? Did I miss a fix being merged? Ping, again. The net=next tree has now been merged by Linus, so has this been fixed? Or is Linus' tree now broken for this build? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1843 bytes --] Hi all, This was not actually the net-next tree (except that the net-next tree was updated before I merged it to include a whole new section of Linus' tree after Linus merged the net-next tree). Sorry about that. On Wed, 1 Sep 2021 16:38:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (X86_64 > allnoconfig) failed like this: > > arch/x86/kernel/setup.c: In function 'setup_arch': > arch/x86/kernel/setup.c:916:6: error: implicit declaration of function 'acpi_mps_check' [-Werror=implicit-function-declaration] > 916 | if (acpi_mps_check()) { > | ^~~~~~~~~~~~~~ > arch/x86/kernel/setup.c:1110:2: error: implicit declaration of function 'acpi_table_upgrade' [-Werror=implicit-function-declaration] > 1110 | acpi_table_upgrade(); > | ^~~~~~~~~~~~~~~~~~ > arch/x86/kernel/setup.c:1112:2: error: implicit declaration of function 'acpi_boot_table_init' [-Werror=implicit-function-declaration] > 1112 | acpi_boot_table_init(); > | ^~~~~~~~~~~~~~~~~~~~ > arch/x86/kernel/setup.c:1120:2: error: implicit declaration of function 'early_acpi_boot_init'; did you mean 'early_cpu_init'? [-Werror=implicit-function-declaration] > 1120 | early_acpi_boot_init(); > | ^~~~~~~~~~~~~~~~~~~~ > | early_cpu_init > arch/x86/kernel/setup.c:1162:2: error: implicit declaration of function 'acpi_boot_init' [-Werror=implicit-function-declaration] > 1162 | acpi_boot_init(); > | ^~~~~~~~~~~~~~ > > Caused by commit > > 342f43af70db ("iscsi_ibft: fix crash due to KASLR physical memory remapping") > > Unfortunately that commit has now been merged into Linus' tree as well. And. unfortunately, that commit had not been in linux-next until today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1533 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/net/wwan/iosm/iosm_ipc_task_queue.c:6: drivers/net/wwan/iosm/iosm_ipc_imem.h:10:10: fatal error: stdbool.h: No such file or directory 10 | #include <stdbool.h> | ^~~~~~~~~~~ In file included from drivers/net/wwan/iosm/iosm_ipc_protocol.h:9, from drivers/net/wwan/iosm/iosm_ipc_mux.h:9, from drivers/net/wwan/iosm/iosm_ipc_chnl_cfg.h:9, from drivers/net/wwan/iosm/iosm_ipc_imem_ops.c:8: drivers/net/wwan/iosm/iosm_ipc_imem.h:10:10: fatal error: stdbool.h: No such file or directory 10 | #include <stdbool.h> | ^~~~~~~~~~~ In file included from drivers/net/wwan/iosm/iosm_ipc_protocol.h:9, from drivers/net/wwan/iosm/iosm_ipc_mux.h:9, from drivers/net/wwan/iosm/iosm_ipc_chnl_cfg.h:9, from drivers/net/wwan/iosm/iosm_ipc_imem.c:8: drivers/net/wwan/iosm/iosm_ipc_imem.h:10:10: fatal error: stdbool.h: No such file or directory 10 | #include <stdbool.h> | ^~~~~~~~~~~ Caused by commit 13bb8429ca98 ("net: wwan: iosm: firmware flashing and coredump collection") interacting with commit 0666a64a1f48 ("isystem: delete global -isystem compile option") from the kbuild tree. I have reverted the kbuild tree commit for today. Please provide a merge resolution patch. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Sep 14, 2021 at 11:15 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > In file included from drivers/net/wwan/iosm/iosm_ipc_task_queue.c:6: > drivers/net/wwan/iosm/iosm_ipc_imem.h:10:10: fatal error: stdbool.h: No such file or directory > 10 | #include <stdbool.h> > | ^~~~~~~~~~~ > In file included from drivers/net/wwan/iosm/iosm_ipc_protocol.h:9, > from drivers/net/wwan/iosm/iosm_ipc_mux.h:9, > from drivers/net/wwan/iosm/iosm_ipc_chnl_cfg.h:9, > from drivers/net/wwan/iosm/iosm_ipc_imem_ops.c:8: > drivers/net/wwan/iosm/iosm_ipc_imem.h:10:10: fatal error: stdbool.h: No such file or directory > 10 | #include <stdbool.h> > | ^~~~~~~~~~~ > In file included from drivers/net/wwan/iosm/iosm_ipc_protocol.h:9, > from drivers/net/wwan/iosm/iosm_ipc_mux.h:9, > from drivers/net/wwan/iosm/iosm_ipc_chnl_cfg.h:9, > from drivers/net/wwan/iosm/iosm_ipc_imem.c:8: > drivers/net/wwan/iosm/iosm_ipc_imem.h:10:10: fatal error: stdbool.h: No such file or directory > 10 | #include <stdbool.h> > | ^~~~~~~~~~~ > > Caused by commit > > 13bb8429ca98 ("net: wwan: iosm: firmware flashing and coredump collection") > > interacting with commit > > 0666a64a1f48 ("isystem: delete global -isystem compile option") > > from the kbuild tree. > > I have reverted the kbuild tree commit for today. Please provide a > merge resolution patch. I am sad to see the kbuild change reverted, not the net one. 13bb8429ca98 is apparently doing wrong. Including <linux/types.h> should be fine. > -- > Cheers, > Stephen Rothwell -- Best Regards Masahiro Yamada
[-- Attachment #1: Type: text/plain, Size: 335 bytes --] Hi Masahiro, On Thu, 16 Sep 2021 18:03:26 +0900 Masahiro Yamada <masahiroy@kernel.org> wrote: > > I am sad to see the kbuild change reverted, not the net one. > > 13bb8429ca98 is apparently doing wrong. > > Including <linux/types.h> should be fine. This was fixed in the net-next tree. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3133 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) failed like this: net/core/sock.c: In function 'sock_setsockopt': net/core/sock.c:1417:7: error: 'SO_RESERVE_MEM' undeclared (first use in this function); did you mean 'IORESOURCE_MEM'? case SO_RESERVE_MEM: ^~~~~~~~~~~~~~ IORESOURCE_MEM net/core/sock.c:1417:7: note: each undeclared identifier is reported only once for each function it appears in net/core/sock.c: In function 'sock_getsockopt': net/core/sock.c:1817:7: error: 'SO_RESERVE_MEM' undeclared (first use in this function); did you mean 'IORESOURCE_MEM'? case SO_RESERVE_MEM: ^~~~~~~~~~~~~~ IORESOURCE_MEM Caused by commit 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") arch/sparc/include/uapi/socket.h does not include uapi/asm/socket.h and some other architectures do not as well. I have added the following patch for today (I searched for SO_BUF_LOCK and, of these architectures, I have only compile tested sparc64 and sparc): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 1 Oct 2021 15:51:50 +1000 Subject: [PATCH] fix up for "net: add new socket option SO_RESERVE_MEM" Some architectures do not include uapi/asm/socket.h Fixes: 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/alpha/include/uapi/asm/socket.h | 2 ++ arch/mips/include/uapi/asm/socket.h | 2 ++ arch/parisc/include/uapi/asm/socket.h | 2 ++ arch/sparc/include/uapi/asm/socket.h | 2 ++ 4 files changed, 8 insertions(+) diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h index 1dd9baf4a6c2..284d28755b8d 100644 --- a/arch/alpha/include/uapi/asm/socket.h +++ b/arch/alpha/include/uapi/asm/socket.h @@ -131,6 +131,8 @@ #define SO_BUF_LOCK 72 +#define SO_RESERVE_MEM 73 + #if !defined(__KERNEL__) #if __BITS_PER_LONG == 64 diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h index 1eaf6a1ca561..24e0efb360f6 100644 --- a/arch/mips/include/uapi/asm/socket.h +++ b/arch/mips/include/uapi/asm/socket.h @@ -142,6 +142,8 @@ #define SO_BUF_LOCK 72 +#define SO_RESERVE_MEM 73 + #if !defined(__KERNEL__) #if __BITS_PER_LONG == 64 diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h index 8baaad52d799..845ddc63c882 100644 --- a/arch/parisc/include/uapi/asm/socket.h +++ b/arch/parisc/include/uapi/asm/socket.h @@ -123,6 +123,8 @@ #define SO_BUF_LOCK 0x4046 +#define SO_RESERVE_MEM 0x4047 + #if !defined(__KERNEL__) #if __BITS_PER_LONG == 64 diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h index e80ee8641ac3..9e9ceee6358f 100644 --- a/arch/sparc/include/uapi/asm/socket.h +++ b/arch/sparc/include/uapi/asm/socket.h @@ -124,6 +124,8 @@ #define SO_BUF_LOCK 0x0051 +#define SO_RESERVE_MEM 0x0052 + #if !defined(__KERNEL__) -- 2.33.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 1 Oct 2021 16:18:49 +1000
> Hi all,
>
> After merging the net-next tree, today's linux-next build (sparc64
> defconfig) failed like this:
>
> net/core/sock.c: In function 'sock_setsockopt':
> net/core/sock.c:1417:7: error: 'SO_RESERVE_MEM' undeclared (first use in this function); did you mean 'IORESOURCE_MEM'?
> case SO_RESERVE_MEM:
> ^~~~~~~~~~~~~~
> IORESOURCE_MEM
> net/core/sock.c:1417:7: note: each undeclared identifier is reported only once for each function it appears in
> net/core/sock.c: In function 'sock_getsockopt':
> net/core/sock.c:1817:7: error: 'SO_RESERVE_MEM' undeclared (first use in this function); did you mean 'IORESOURCE_MEM'?
> case SO_RESERVE_MEM:
> ^~~~~~~~~~~~~~
> IORESOURCE_MEM
>
> Caused by commit
>
> 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM")
>
> arch/sparc/include/uapi/socket.h does not include uapi/asm/socket.h and
> some other architectures do not as well.
>
> I have added the following patch for today (I searched for SO_BUF_LOCK
> and, of these architectures, I have only compile tested sparc64 and
> sparc):
I committed the sparc part into net-next today, thanks.
From: David Miller <davem@davemloft.net>
Date: Fri, 01 Oct 2021 14:40:46 +0100 (BST)
> I committed the sparc part into net-next today, thanks.
I put the rest into the tree now too, thank you.
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'ehea_setup_single_port': drivers/net/ethernet/ibm/ehea/ehea_main.c:2989:23: error: passing argument 2 of 'eth_hw_addr_set' from incompatible pointer type [-Werror=incompatible-pointer-types] 2989 | eth_hw_addr_set(dev, &port->mac_addr); | ^~~~~~~~~~~~~~~ | | | u64 * {aka long long unsigned int *} In file included from include/linux/if_vlan.h:11, from include/linux/filter.h:19, from include/net/sock.h:59, from include/linux/tcp.h:19, from drivers/net/ethernet/ibm/ehea/ehea_main.c:20: include/linux/etherdevice.h:309:70: note: expected 'const u8 *' {aka 'const unsigned char *'} but argument is of type 'u64 *' {aka 'long long unsigned int *'} 309 | static inline void eth_hw_addr_set(struct net_device *dev, const u8 *addr) | ~~~~~~~~~~^~~~ cc1: some warnings being treated as errors Caused by commit a96d317fb1a3 ("ethernet: use eth_hw_addr_set()") I have used the net-next tree from next-20211001 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1616 bytes --] Hi Dave, On Fri, 01 Oct 2021 14:40:46 +0100 (BST) David Miller <davem@davemloft.net> wrote: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri, 1 Oct 2021 16:18:49 +1000 > > > Hi all, > > > > After merging the net-next tree, today's linux-next build (sparc64 > > defconfig) failed like this: > > > > net/core/sock.c: In function 'sock_setsockopt': > > net/core/sock.c:1417:7: error: 'SO_RESERVE_MEM' undeclared (first use in this function); did you mean 'IORESOURCE_MEM'? > > case SO_RESERVE_MEM: > > ^~~~~~~~~~~~~~ > > IORESOURCE_MEM > > net/core/sock.c:1417:7: note: each undeclared identifier is reported only once for each function it appears in > > net/core/sock.c: In function 'sock_getsockopt': > > net/core/sock.c:1817:7: error: 'SO_RESERVE_MEM' undeclared (first use in this function); did you mean 'IORESOURCE_MEM'? > > case SO_RESERVE_MEM: > > ^~~~~~~~~~~~~~ > > IORESOURCE_MEM > > > > Caused by commit > > > > 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") > > > > arch/sparc/include/uapi/socket.h does not include uapi/asm/socket.h and > > some other architectures do not as well. > > > > I have added the following patch for today (I searched for SO_BUF_LOCK > > and, of these architectures, I have only compile tested sparc64 and > > sparc): > > I committed the sparc part into net-next today, thanks. Unfortunately, there is a typo in what you committed in bfaf03935f74 ("sparc: add SO_RESERVE_MEM definition."), SO_RESEVE_MEM instead of SO_RESERVE_MEM ... -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --] Hi all, On Tue, 5 Oct 2021 11:56:37 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'ehea_setup_single_port': > drivers/net/ethernet/ibm/ehea/ehea_main.c:2989:23: error: passing argument 2 of 'eth_hw_addr_set' from incompatible pointer type [-Werror=incompatible-pointer-types] > 2989 | eth_hw_addr_set(dev, &port->mac_addr); > | ^~~~~~~~~~~~~~~ > | | > | u64 * {aka long long unsigned int *} > In file included from include/linux/if_vlan.h:11, > from include/linux/filter.h:19, > from include/net/sock.h:59, > from include/linux/tcp.h:19, > from drivers/net/ethernet/ibm/ehea/ehea_main.c:20: > include/linux/etherdevice.h:309:70: note: expected 'const u8 *' {aka 'const unsigned char *'} but argument is of type 'u64 *' {aka 'long long unsigned int *'} > 309 | static inline void eth_hw_addr_set(struct net_device *dev, const u8 *addr) > | ~~~~~~~~~~^~~~ > cc1: some warnings being treated as errors > > Caused by commit > > a96d317fb1a3 ("ethernet: use eth_hw_addr_set()") > > I have used the net-next tree from next-20211001 for today. I also had to use the next-20211001 version if the bpf-next tree (since it had been reset past the broken commit in the net-next tree). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1838 bytes --] Hi all, On Tue, 5 Oct 2021 12:24:07 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > On Tue, 5 Oct 2021 11:56:37 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > After merging the net-next tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > > > drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'ehea_setup_single_port': > > drivers/net/ethernet/ibm/ehea/ehea_main.c:2989:23: error: passing argument 2 of 'eth_hw_addr_set' from incompatible pointer type [-Werror=incompatible-pointer-types] > > 2989 | eth_hw_addr_set(dev, &port->mac_addr); > > | ^~~~~~~~~~~~~~~ > > | | > > | u64 * {aka long long unsigned int *} > > In file included from include/linux/if_vlan.h:11, > > from include/linux/filter.h:19, > > from include/net/sock.h:59, > > from include/linux/tcp.h:19, > > from drivers/net/ethernet/ibm/ehea/ehea_main.c:20: > > include/linux/etherdevice.h:309:70: note: expected 'const u8 *' {aka 'const unsigned char *'} but argument is of type 'u64 *' {aka 'long long unsigned int *'} > > 309 | static inline void eth_hw_addr_set(struct net_device *dev, const u8 *addr) > > | ~~~~~~~~~~^~~~ > > cc1: some warnings being treated as errors > > > > Caused by commit > > > > a96d317fb1a3 ("ethernet: use eth_hw_addr_set()") > > > > I have used the net-next tree from next-20211001 for today. > > I also had to use the next-20211001 version if the bpf-next tree (since > it had been reset past the broken commit in the net-next tree). And the bluetooth tree similarly. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Mon, Oct 4, 2021 at 6:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi Dave, > > On Fri, 01 Oct 2021 14:40:46 +0100 (BST) David Miller <davem@davemloft.net> wrote: > > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > Date: Fri, 1 Oct 2021 16:18:49 +1000 > > > > > Hi all, > > > > > > After merging the net-next tree, today's linux-next build (sparc64 > > > defconfig) failed like this: > > > > > > net/core/sock.c: In function 'sock_setsockopt': > > > net/core/sock.c:1417:7: error: 'SO_RESERVE_MEM' undeclared (first use in this function); did you mean 'IORESOURCE_MEM'? > > > case SO_RESERVE_MEM: > > > ^~~~~~~~~~~~~~ > > > IORESOURCE_MEM > > > net/core/sock.c:1417:7: note: each undeclared identifier is reported only once for each function it appears in > > > net/core/sock.c: In function 'sock_getsockopt': > > > net/core/sock.c:1817:7: error: 'SO_RESERVE_MEM' undeclared (first use in this function); did you mean 'IORESOURCE_MEM'? > > > case SO_RESERVE_MEM: > > > ^~~~~~~~~~~~~~ > > > IORESOURCE_MEM > > > > > > Caused by commit > > > > > > 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") > > > > > > arch/sparc/include/uapi/socket.h does not include uapi/asm/socket.h and > > > some other architectures do not as well. > > > > > > I have added the following patch for today (I searched for SO_BUF_LOCK > > > and, of these architectures, I have only compile tested sparc64 and > > > sparc): > > > > I committed the sparc part into net-next today, thanks. > > Unfortunately, there is a typo in what you committed in bfaf03935f74 > ("sparc: add SO_RESERVE_MEM definition."), SO_RESEVE_MEM instead of > SO_RESERVE_MEM ... > Thanks Stephen for the report and thanks a lot David for submitting the fix. Let me know if I need to do the fix. > -- > Cheers, > Stephen Rothwell
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 5 Oct 2021 12:11:54 +1100
> Unfortunately, there is a typo in what you committed in bfaf03935f74
> ("sparc: add SO_RESERVE_MEM definition."), SO_RESEVE_MEM instead of
> SO_RESERVE_MEM ...
Thanks for catching that. Should be fixed now.
Thanks again.
[-- Attachment #1: Type: text/plain, Size: 2078 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/net/ethernet/toshiba/ps3_gelic_net.c: In function 'gelic_net_setup_netdev': drivers/net/ethernet/toshiba/ps3_gelic_net.c:1480:26: error: passing argument 2 of 'eth_hw_addr_set' from incompatible pointer type [-Werror=incompatible-pointer-types] 1480 | eth_hw_addr_set(netdev, &v1); | ^~~ | | | u64 * {aka long long unsigned int *} In file included from drivers/net/ethernet/toshiba/ps3_gelic_net.c:23: include/linux/etherdevice.h:309:70: note: expected 'const u8 *' {aka 'const unsigned char *'} but argument is of type 'u64 *' {aka 'long long unsigned int *'} 309 | static inline void eth_hw_addr_set(struct net_device *dev, const u8 *addr) | ~~~~~~~~~~^~~~ Caused by commit a96d317fb1a3 ("ethernet: use eth_hw_addr_set()") I have applied the following patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 6 Oct 2021 12:19:08 +1100 Subject: [PATCH] ethernet: fix up ps3_gelic_net.c for "ethernet: use eth_hw_addr_set()" Fixes: a96d317fb1a3 ("ethernet: use eth_hw_addr_set()") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c index 1425623b868e..3dbfb1b20649 100644 --- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c +++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c @@ -1477,7 +1477,7 @@ int gelic_net_setup_netdev(struct net_device *netdev, struct gelic_card *card) __func__, status); return -EINVAL; } - eth_hw_addr_set(netdev, &v1); + eth_hw_addr_set(netdev, (u8 *)&v1); if (card->vlan_required) { netdev->hard_header_len += VLAN_HLEN; -- 2.33.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, 6 Oct 2021 12:23:15 +1100 Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/net/ethernet/toshiba/ps3_gelic_net.c: In function 'gelic_net_setup_netdev':
> drivers/net/ethernet/toshiba/ps3_gelic_net.c:1480:26: error: passing argument 2 of 'eth_hw_addr_set' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 1480 | eth_hw_addr_set(netdev, &v1);
> | ^~~
> | |
> | u64 * {aka long long unsigned int *}
> In file included from drivers/net/ethernet/toshiba/ps3_gelic_net.c:23:
> include/linux/etherdevice.h:309:70: note: expected 'const u8 *' {aka 'const unsigned char *'} but argument is of type 'u64 *' {aka 'long long unsigned int *'}
> 309 | static inline void eth_hw_addr_set(struct net_device *dev, const u8 *addr)
> | ~~~~~~~~~~^~~~
>
> Caused by commit
>
> a96d317fb1a3 ("ethernet: use eth_hw_addr_set()")
>
> I have applied the following patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 6 Oct 2021 12:19:08 +1100
> Subject: [PATCH] ethernet: fix up ps3_gelic_net.c for "ethernet: use
> eth_hw_addr_set()"
>
> Fixes: a96d317fb1a3 ("ethernet: use eth_hw_addr_set()")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> index 1425623b868e..3dbfb1b20649 100644
> --- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> +++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> @@ -1477,7 +1477,7 @@ int gelic_net_setup_netdev(struct net_device *netdev, struct gelic_card *card)
> __func__, status);
> return -EINVAL;
> }
> - eth_hw_addr_set(netdev, &v1);
> + eth_hw_addr_set(netdev, (u8 *)&v1);
>
> if (card->vlan_required) {
> netdev->hard_header_len += VLAN_HLEN;
Applied, thanks. Is this the last one? ;)
I wonder what happened to the kbuild bot :S
[-- Attachment #1: Type: text/plain, Size: 260 bytes --] Hi Jakub, On Tue, 5 Oct 2021 18:52:17 -0700 Jakub Kicinski <kuba@kernel.org> wrote: > > Applied, thanks. Is this the last one? ;) No idea :-( > I wonder what happened to the kbuild bot :S Does it do ppc builds? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, 6 Oct 2021 14:43:22 +1100 Stephen Rothwell wrote:
> On Tue, 5 Oct 2021 18:52:17 -0700 Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > Applied, thanks. Is this the last one? ;)
>
> No idea :-(
>
> > I wonder what happened to the kbuild bot :S
>
> Does it do ppc builds?
I thought it did, I get a build status email periodically with a list
of 135 builds. PPC is well represented there.
[-- Attachment #1: Type: text/plain, Size: 1614 bytes --] Hi all, After merging the net-next tree, today's linux-next build (xtensa, m68k allmodconfig) failed like this: In file included from <command-line>:0:0: In function 'ath11k_peer_assoc_h_smps', inlined from 'ath11k_peer_assoc_prepare' at drivers/net/wireless/ath/ath11k/mac.c:2362:2: include/linux/compiler_types.h:317:38: error: call to '__compiletime_assert_650' declared with attribute error: FIELD_GET: type of reg too small for mask _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ include/linux/compiler_types.h:298:4: note: in definition of macro '__compiletime_assert' prefix ## suffix(); \ ^ include/linux/compiler_types.h:317:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^ include/linux/bitfield.h:52:3: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG((_mask) > (typeof(_reg))~0ull, \ ^ include/linux/bitfield.h:108:3: note: in expansion of macro '__BF_FIELD_CHECK' __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \ ^ drivers/net/wireless/ath/ath11k/mac.c:2079:10: note: in expansion of macro 'FIELD_GET' smps = FIELD_GET(IEEE80211_HE_6GHZ_CAP_SM_PS, ^ Caused by commit 6f4d70308e5e ("ath11k: support SMPS configuration for 6 GHz") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> writes: > After merging the net-next tree, today's linux-next build (xtensa, > m68k allmodconfig) failed like this: > > In file included from <command-line>:0:0: > In function 'ath11k_peer_assoc_h_smps', > inlined from 'ath11k_peer_assoc_prepare' at drivers/net/wireless/ath/ath11k/mac.c:2362:2: > include/linux/compiler_types.h:317:38: error: call to '__compiletime_assert_650' declared with attribute error: FIELD_GET: type of reg too small for mask > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > include/linux/compiler_types.h:298:4: note: in definition of macro '__compiletime_assert' > prefix ## suffix(); \ > ^ > include/linux/compiler_types.h:317:2: note: in expansion of macro '_compiletime_assert' > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > ^ > include/linux/bitfield.h:52:3: note: in expansion of macro 'BUILD_BUG_ON_MSG' > BUILD_BUG_ON_MSG((_mask) > (typeof(_reg))~0ull, \ > ^ > include/linux/bitfield.h:108:3: note: in expansion of macro '__BF_FIELD_CHECK' > __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \ > ^ > drivers/net/wireless/ath/ath11k/mac.c:2079:10: note: in expansion of macro 'FIELD_GET' > smps = FIELD_GET(IEEE80211_HE_6GHZ_CAP_SM_PS, > ^ > > Caused by commit > > 6f4d70308e5e ("ath11k: support SMPS configuration for 6 GHz") Thanks for the report, weird that I don't see it on x86. I can't look at this in detail now, maybe later today, but I wonder if the diff below fixes the issue? At least it's cleaner than using FIELD_GET(), actually ath11k should be cleaned up to use xx_get_bits() all over. Kalle diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c index d897020dd52d..3e7e569f284b 100644 --- a/drivers/net/wireless/ath/ath11k/mac.c +++ b/drivers/net/wireless/ath/ath11k/mac.c @@ -2076,8 +2076,8 @@ static void ath11k_peer_assoc_h_smps(struct ieee80211_sta *sta, smps = ht_cap->cap & IEEE80211_HT_CAP_SM_PS; smps >>= IEEE80211_HT_CAP_SM_PS_SHIFT; } else { - smps = FIELD_GET(IEEE80211_HE_6GHZ_CAP_SM_PS, - le16_to_cpu(sta->he_6ghz_capa.capa)); + smps = le16_get_bits(sta->he_6ghz_capa.capa, + IEEE80211_HE_6GHZ_CAP_SM_PS); } switch (smps) {
Hi Kalle, On Fri, Oct 8, 2021 at 7:55 AM Kalle Valo <kvalo@codeaurora.org> wrote: > Stephen Rothwell <sfr@canb.auug.org.au> writes: > > > After merging the net-next tree, today's linux-next build (xtensa, > > m68k allmodconfig) failed like this: > > > > In file included from <command-line>:0:0: > > In function 'ath11k_peer_assoc_h_smps', > > inlined from 'ath11k_peer_assoc_prepare' at drivers/net/wireless/ath/ath11k/mac.c:2362:2: > > include/linux/compiler_types.h:317:38: error: call to '__compiletime_assert_650' declared with attribute error: FIELD_GET: type of reg too small for mask > > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > > ^ > > include/linux/compiler_types.h:298:4: note: in definition of macro '__compiletime_assert' > > prefix ## suffix(); \ > > ^ > > include/linux/compiler_types.h:317:2: note: in expansion of macro '_compiletime_assert' > > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > > ^ > > include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' > > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > > ^ > > include/linux/bitfield.h:52:3: note: in expansion of macro 'BUILD_BUG_ON_MSG' > > BUILD_BUG_ON_MSG((_mask) > (typeof(_reg))~0ull, \ > > ^ > > include/linux/bitfield.h:108:3: note: in expansion of macro '__BF_FIELD_CHECK' > > __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \ > > ^ > > drivers/net/wireless/ath/ath11k/mac.c:2079:10: note: in expansion of macro 'FIELD_GET' > > smps = FIELD_GET(IEEE80211_HE_6GHZ_CAP_SM_PS, > > ^ > > > > Caused by commit > > > > 6f4d70308e5e ("ath11k: support SMPS configuration for 6 GHz") > > Thanks for the report, weird that I don't see it on x86. I can't look at > this in detail now, maybe later today, but I wonder if the diff below > fixes the issue? It seems to be related to passing "le16_to_cpu(sta->he_6ghz_capa.capa)". Probably typeof(le16_to_cpu(sta->he_6ghz_capa.capa)) goes berserk. le16_to_cpu() is a complex macro on big-endian. I had expected to see a similar issue on powerpc, but I don't. Using an intermediate "u16 capa = le16_to_cpu(sta->he_6ghz_capa.capa)" fixes the problem. > At least it's cleaner than using FIELD_GET(), actually ath11k should be > cleaned up to use xx_get_bits() all over. > > Kalle > > diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c > index d897020dd52d..3e7e569f284b 100644 > --- a/drivers/net/wireless/ath/ath11k/mac.c > +++ b/drivers/net/wireless/ath/ath11k/mac.c > @@ -2076,8 +2076,8 @@ static void ath11k_peer_assoc_h_smps(struct ieee80211_sta *sta, > smps = ht_cap->cap & IEEE80211_HT_CAP_SM_PS; > smps >>= IEEE80211_HT_CAP_SM_PS_SHIFT; > } else { > - smps = FIELD_GET(IEEE80211_HE_6GHZ_CAP_SM_PS, > - le16_to_cpu(sta->he_6ghz_capa.capa)); > + smps = le16_get_bits(sta->he_6ghz_capa.capa, > + IEEE80211_HE_6GHZ_CAP_SM_PS); > } Thanks, that works, too, so (compile) Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, Geert Uytterhoeven <geert@linux-m68k.org> writes: > On Fri, Oct 8, 2021 at 7:55 AM Kalle Valo <kvalo@codeaurora.org> wrote: >> Stephen Rothwell <sfr@canb.auug.org.au> writes: >> >> > After merging the net-next tree, today's linux-next build (xtensa, >> > m68k allmodconfig) failed like this: >> > >> > In file included from <command-line>:0:0: >> > In function 'ath11k_peer_assoc_h_smps', >> > inlined from 'ath11k_peer_assoc_prepare' at drivers/net/wireless/ath/ath11k/mac.c:2362:2: >> > include/linux/compiler_types.h:317:38: error: call to '__compiletime_assert_650' declared with attribute error: FIELD_GET: type of reg too small for mask >> > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) >> > ^ >> > include/linux/compiler_types.h:298:4: note: in definition of macro '__compiletime_assert' >> > prefix ## suffix(); \ >> > ^ >> > include/linux/compiler_types.h:317:2: note: in expansion of macro '_compiletime_assert' >> > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) >> > ^ >> > include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' >> > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) >> > ^ >> > include/linux/bitfield.h:52:3: note: in expansion of macro 'BUILD_BUG_ON_MSG' >> > BUILD_BUG_ON_MSG((_mask) > (typeof(_reg))~0ull, \ >> > ^ >> > include/linux/bitfield.h:108:3: note: in expansion of macro '__BF_FIELD_CHECK' >> > __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \ >> > ^ >> > drivers/net/wireless/ath/ath11k/mac.c:2079:10: note: in expansion of macro 'FIELD_GET' >> > smps = FIELD_GET(IEEE80211_HE_6GHZ_CAP_SM_PS, >> > ^ >> > >> > Caused by commit >> > >> > 6f4d70308e5e ("ath11k: support SMPS configuration for 6 GHz") >> >> Thanks for the report, weird that I don't see it on x86. I can't look at >> this in detail now, maybe later today, but I wonder if the diff below >> fixes the issue? > > It seems to be related to passing "le16_to_cpu(sta->he_6ghz_capa.capa)". > Probably typeof(le16_to_cpu(sta->he_6ghz_capa.capa)) goes berserk. > le16_to_cpu() is a complex macro on big-endian. I had expected to see > a similar issue on powerpc, but I don't. > Using an intermediate "u16 capa = le16_to_cpu(sta->he_6ghz_capa.capa)" > fixes the problem. > >> At least it's cleaner than using FIELD_GET(), actually ath11k should be >> cleaned up to use xx_get_bits() all over. >> >> Kalle >> >> diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c >> index d897020dd52d..3e7e569f284b 100644 >> --- a/drivers/net/wireless/ath/ath11k/mac.c >> +++ b/drivers/net/wireless/ath/ath11k/mac.c >> @@ -2076,8 +2076,8 @@ static void ath11k_peer_assoc_h_smps(struct ieee80211_sta *sta, >> smps = ht_cap->cap & IEEE80211_HT_CAP_SM_PS; >> smps >>= IEEE80211_HT_CAP_SM_PS_SHIFT; >> } else { >> - smps = FIELD_GET(IEEE80211_HE_6GHZ_CAP_SM_PS, >> - le16_to_cpu(sta->he_6ghz_capa.capa)); >> + smps = le16_get_bits(sta->he_6ghz_capa.capa, >> + IEEE80211_HE_6GHZ_CAP_SM_PS); >> } > > Thanks, that works, too, so (compile) > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Thanks Geert, you helped a lot! I now submitted a patch to netdev: https://patchwork.kernel.org/project/netdevbpf/patch/20211008143932.23884-1-kvalo@codeaurora.org/ Dave & Jakub, if you can please take the patch directly to net-next. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
From: Kalle Valo <kvalo@codeaurora.org>
Date: Fri, 08 Oct 2021 17:43:39 +0300
> Thanks Geert, you helped a lot! I now submitted a patch to netdev:
>
> https://patchwork.kernel.org/project/netdevbpf/patch/20211008143932.23884-1-kvalo@codeaurora.org/
>
> Dave & Jakub, if you can please take the patch directly to net-next.
Done.
[-- Attachment #1: Type: text/plain, Size: 1700 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) failed like this: drivers/net/ethernet/sun/ldmvsw.c: In function 'vsw_alloc_netdev': drivers/net/ethernet/sun/ldmvsw.c:243:2: error: expected ';' before 'sprintf' sprintf(dev->name, "vif%d.%d", (int)handle, (int)port_id); ^~~~~~~ Caused by commit a7639279c93c ("ethernet: sun: remove direct netdev->dev_addr writes") I have applied the following fix patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 11 Oct 2021 17:24:43 +1100 Subject: [PATCH] ethernet: sun: fix for "remove direct netdev->dev_addr writes" Fix for this build problem: drivers/net/ethernet/sun/ldmvsw.c: In function 'vsw_alloc_netdev': drivers/net/ethernet/sun/ldmvsw.c:243:2: error: expected ';' before 'sprintf' sprintf(dev->name, "vif%d.%d", (int)handle, (int)port_id); ^~~~~~~ Fixes: a7639279c93c ("ethernet: sun: remove direct netdev->dev_addr writes") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/sun/ldmvsw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/sun/ldmvsw.c b/drivers/net/ethernet/sun/ldmvsw.c index 074c5407c86b..6b59b14e74b1 100644 --- a/drivers/net/ethernet/sun/ldmvsw.c +++ b/drivers/net/ethernet/sun/ldmvsw.c @@ -238,7 +238,7 @@ static struct net_device *vsw_alloc_netdev(u8 hwaddr[], dev->needed_tailroom = 8; eth_hw_addr_set(dev, hwaddr); - ether_addr_copy(dev->perm_addr, dev->dev_addr) + ether_addr_copy(dev->perm_addr, dev->dev_addr); sprintf(dev->name, "vif%d.%d", (int)handle, (int)port_id); -- 2.33.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2267 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:71:10: fatal error: lag.h: No such file or directory 71 | #include "lag.h" | ^~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c:13:10: fatal error: lag.h: No such file or directory 13 | #include "lag.h" | ^~~~~~~ Caused by commit 3d677735d3b7 ("net/mlx5: Lag, move lag files into directory") interacting with commit 14fe2471c628 ("net/mlx5: Lag, change multipath and bonding to be mutually exclusive") from the net tree. I have applied the following merge fix patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 22 Oct 2021 11:10:06 +1100 Subject: [PATCH] fixup for "net/mlx5: Lag, move lag files into directory" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 4 ++-- drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c index b7461c17d601..d7e613d0139a 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c @@ -10,8 +10,8 @@ #include "en_tc.h" #include "rep/tc.h" #include "rep/neigh.h" -#include "lag.h" -#include "lag_mp.h" +#include "lag/lag.h" +#include "lag/mp.h" struct mlx5e_tc_tun_route_attr { struct net_device *out_dev; diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c index 57369925a788..3af3da214a5b 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c @@ -68,8 +68,8 @@ #include "lib/fs_chains.h" #include "diag/en_tc_tracepoint.h" #include <asm/div64.h> -#include "lag.h" -#include "lag_mp.h" +#include "lag/lag.h" +#include "lag/mp.h" #define nic_chains(priv) ((priv)->fs.tc.chains) #define MLX5_MH_ACT_SZ MLX5_UN_SZ_BYTES(set_add_copy_action_in_auto) -- 2.33.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hello: This patch was applied to netdev/net-next.git (master) by Jakub Kicinski <kuba@kernel.org>: On Fri, 22 Oct 2021 11:24:36 +1100 you wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:71:10: fatal error: lag.h: No such file or directory > 71 | #include "lag.h" > | ^~~~~~~ > drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c:13:10: fatal error: lag.h: No such file or directory > 13 | #include "lag.h" > | ^~~~~~~ > > [...] Here is the summary with links: - linux-next: build failure after merge of the net-next tree https://git.kernel.org/netdev/net-next/c/016c89460d34 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
[-- Attachment #1: Type: text/plain, Size: 5206 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.h:11, from drivers/net/ethernet/mellanox/mlx5/core/eswitch.h:48, from drivers/net/ethernet/mellanox/mlx5/core/main.c:59: drivers/net/ethernet/mellanox/mlx5/core/en.h:646:24: error: field 'mkey' has incomplete type 646 | struct mlx5_core_mkey mkey; | ^~~~ In file included from drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.h:11, from drivers/net/ethernet/mellanox/mlx5/core/eswitch.h:48, from drivers/net/ethernet/mellanox/mlx5/core/eq.c:18: drivers/net/ethernet/mellanox/mlx5/core/en.h:646:24: error: field 'mkey' has incomplete type 646 | struct mlx5_core_mkey mkey; | ^~~~ drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 'mlx5e_build_shampo_hd_umr': drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:547:45: error: request for member 'key' in something not a structure or union 547 | u32 lkey = rq->mdev->mlx5e_res.hw_objs.mkey.key; | ^ Caused by commits e5ca8fb08ab2 ("net/mlx5e: Add control path for SHAMPO feature") 64509b052525 ("net/mlx5e: Add data path for SHAMPO feature") interacting with commit 83fec3f12a59 ("RDMA/mlx5: Replace struct mlx5_core_mkey by u32 key") from the rmda tree. I have applied the following merge fix patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 28 Oct 2021 12:36:29 +1100 Subject: [PATCH] fixup for "RDMA/mlx5: Replace struct mlx5_core_mkey by u32 key" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 11 +++++------ drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 2 +- 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h index 5083a8a7eceb..f0ac6b0d9653 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h @@ -643,7 +643,7 @@ struct mlx5e_rq_frags_info { }; struct mlx5e_shampo_hd { - struct mlx5_core_mkey mkey; + u32 mkey; struct mlx5e_dma_info *info; struct page *last_page; u16 hd_per_wq; diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c index 43b7a1e6a482..9febe4a916df 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c @@ -323,8 +323,7 @@ static int mlx5e_create_umr_mtt_mkey(struct mlx5_core_dev *mdev, } static int mlx5e_create_umr_klm_mkey(struct mlx5_core_dev *mdev, - u64 nentries, - struct mlx5_core_mkey *umr_mkey) + u64 nentries, u32 *umr_mkey) { int inlen; void *mkc; @@ -518,7 +517,7 @@ static int mlx5_rq_shampo_alloc(struct mlx5_core_dev *mdev, goto err_hw_gro_data; } rq->mpwqe.shampo->key = - cpu_to_be32(rq->mpwqe.shampo->mkey.key); + cpu_to_be32(rq->mpwqe.shampo->mkey); rq->mpwqe.shampo->hd_per_wqe = mlx5e_shampo_hd_per_wqe(mdev, params, rqp); wq_size = BIT(MLX5_GET(wq, wqc, log_wq_sz)); @@ -529,7 +528,7 @@ static int mlx5_rq_shampo_alloc(struct mlx5_core_dev *mdev, err_hw_gro_data: mlx5e_rq_shampo_hd_info_free(rq); err_shampo_info: - mlx5_core_destroy_mkey(mdev, &rq->mpwqe.shampo->mkey); + mlx5_core_destroy_mkey(mdev, rq->mpwqe.shampo->mkey); err_shampo_hd: mlx5e_rq_shampo_hd_free(rq); out: @@ -543,7 +542,7 @@ static void mlx5e_rq_free_shampo(struct mlx5e_rq *rq) kvfree(rq->hw_gro_data); mlx5e_rq_shampo_hd_info_free(rq); - mlx5_core_destroy_mkey(rq->mdev, &rq->mpwqe.shampo->mkey); + mlx5_core_destroy_mkey(rq->mdev, rq->mpwqe.shampo->mkey); mlx5e_rq_shampo_hd_free(rq); } @@ -819,7 +818,7 @@ int mlx5e_create_rq(struct mlx5e_rq *rq, struct mlx5e_rq_param *param) if (test_bit(MLX5E_RQ_STATE_SHAMPO, &rq->state)) { MLX5_SET(wq, wq, log_headers_buffer_entry_num, order_base_2(rq->mpwqe.shampo->hd_per_wq)); - MLX5_SET(wq, wq, headers_mkey, rq->mpwqe.shampo->mkey.key); + MLX5_SET(wq, wq, headers_mkey, rq->mpwqe.shampo->mkey); } mlx5_fill_page_frag_array(&rq->wq_ctrl.buf, diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c index fe979edd96dc..f63c8ff3ef3f 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c @@ -544,7 +544,7 @@ static int mlx5e_build_shampo_hd_umr(struct mlx5e_rq *rq, { struct mlx5e_shampo_hd *shampo = rq->mpwqe.shampo; u16 entries, pi, i, header_offset, err, wqe_bbs, new_entries; - u32 lkey = rq->mdev->mlx5e_res.hw_objs.mkey.key; + u32 lkey = rq->mdev->mlx5e_res.hw_objs.mkey; struct page *page = shampo->last_page; u64 addr = shampo->last_addr; struct mlx5e_dma_info *dma_info; -- 2.33.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, 2021-10-28 at 12:56 +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > In file included from > drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.h:11, > from > drivers/net/ethernet/mellanox/mlx5/core/eswitch.h:48, > from > drivers/net/ethernet/mellanox/mlx5/core/main.c:59: > drivers/net/ethernet/mellanox/mlx5/core/en.h:646:24: error: field > 'mkey' has incomplete type > 646 | struct mlx5_core_mkey mkey; > | ^~~~ > In file included from > drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.h:11, > from > drivers/net/ethernet/mellanox/mlx5/core/eswitch.h:48, > from drivers/net/ethernet/mellanox/mlx5/core/eq.c:18: > drivers/net/ethernet/mellanox/mlx5/core/en.h:646:24: error: field > 'mkey' has incomplete type > 646 | struct mlx5_core_mkey mkey; > | ^~~~ > drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function > 'mlx5e_build_shampo_hd_umr': > drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:547:45: error: request > for member 'key' in something not a structure or union > 547 | u32 lkey = rq->mdev->mlx5e_res.hw_objs.mkey.key; > | ^ > > Caused by commits > > e5ca8fb08ab2 ("net/mlx5e: Add control path for SHAMPO feature") > 64509b052525 ("net/mlx5e: Add data path for SHAMPO feature") > > interacting with commit > > 83fec3f12a59 ("RDMA/mlx5: Replace struct mlx5_core_mkey by u32 key") > > from the rmda tree. > > I have applied the following merge fix patch. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Thu, 28 Oct 2021 12:36:29 +1100 > Subject: [PATCH] fixup for "RDMA/mlx5: Replace struct mlx5_core_mkey by > u32 key" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- Hi Stephen, the merge conflict and build failure can be avoided by the following merge commit to net-next, already sent to Dave, hope it will be merge in net-next soon https://lore.kernel.org/netdev/20211028052104.1071670-1-saeed@kernel.org/T/#u
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/bitmap.h:9, from include/linux/cpumask.h:12, from arch/x86/include/asm/cpumask.h:5, from arch/x86/include/asm/msr.h:11, from arch/x86/include/asm/processor.h:22, from arch/x86/include/asm/timex.h:5, from include/linux/timex.h:65, from include/linux/time32.h:13, from include/linux/time.h:60, from include/linux/skbuff.h:15, from include/linux/if_ether.h:19, from include/linux/etherdevice.h:20, from drivers/net/ethernet/marvell/octeontx2/af/mbox.h:11, from drivers/net/ethernet/marvell/octeontx2/af/cgx.h:11, from drivers/net/ethernet/marvell/octeontx2/af/rpm.c:8: drivers/net/ethernet/marvell/octeontx2/af/rpm.c: In function 'rpm_cfg_pfc_quanta_thresh': include/linux/find.h:40:23: error: array subscript 'long unsigned int[0]' is partly outside array bounds of 'u16[1]' {aka 'short unsigned int[1]'} [-Werror=array-bounds] 40 | val = *addr & GENMASK(size - 1, offset); | ^~~~~ drivers/net/ethernet/marvell/octeontx2/af/rpm.c:144:68: note: while referencing 'pfc_en' 144 | static void rpm_cfg_pfc_quanta_thresh(rpm_t *rpm, int lmac_id, u16 pfc_en, | ~~~~^~~~~~ Caused by commit 1121f6b02e7a ("octeontx2-af: Priority flow control configuration support") I have used the net-next tree frm next-20220209 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 367 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: Caused by commit 12bbb0d163a9 ("net/smc: add sysctl for autocorking") ( or maybe commit dcd2cf5f2fc0 ("net/smc: add autocorking support") ) I have used the net-next tree from next-20220301 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, 2 Mar 2022 11:56:46 +1100 Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
>
> Caused by commit
>
> 12bbb0d163a9 ("net/smc: add sysctl for autocorking")
>
> ( or maybe commit
>
> dcd2cf5f2fc0 ("net/smc: add autocorking support")
> )
>
> I have used the net-next tree from next-20220301 for today.
Probably fixed by just pushed commit ef739f1dd3ac ("net: smc: fix
different types in min()") ? Sorry about that.
[-- Attachment #1: Type: text/plain, Size: 567 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm64 allmodconfig) failed like this: drivers/net/ethernet/intel/ice/ice_xsk.c: In function 'ice_xmit_pkt_batch': drivers/net/ethernet/intel/ice/ice_xsk.c:801:0: error: ignoring #pragma GCC unroll [-Werror=unknown-pragmas] loop_unrolled_for(i = 0; i < PKTS_PER_BATCH; i++) { ^ cc1: all warnings being treated as errors Caused by commit 126cdfe1007a ("ice: xsk: Improve AF_XDP ZC Tx and use batching API") This build was done with gcc v5.4. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 374 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allmodconfig) failed like this: ERROR: modpost: ".local_memory_node" [drivers/net/ethernet/fungible/funeth/funeth.ko] undefined! Caused by commits ee6373ddf3a9 ("net/funeth: probing and netdev ops") db37bc177dae ("net/funeth: add the data path") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Mon, Mar 7, 2022 at 2:45 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > allmodconfig) failed like this: > > ERROR: modpost: ".local_memory_node" [drivers/net/ethernet/fungible/funeth/funeth.ko] undefined! I will take a look at this. > Caused by commits > > ee6373ddf3a9 ("net/funeth: probing and netdev ops") > db37bc177dae ("net/funeth: add the data path") > > -- > Cheers, > Stephen Rothwell
On Mon, Mar 07, 2022 at 09:36:59PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (arm64 > allmodconfig) failed like this: > > drivers/net/ethernet/intel/ice/ice_xsk.c: In function 'ice_xmit_pkt_batch': > drivers/net/ethernet/intel/ice/ice_xsk.c:801:0: error: ignoring #pragma GCC unroll [-Werror=unknown-pragmas] > loop_unrolled_for(i = 0; i < PKTS_PER_BATCH; i++) { > ^ > cc1: all warnings being treated as errors > > Caused by commit > > 126cdfe1007a ("ice: xsk: Improve AF_XDP ZC Tx and use batching API") > > This build was done with gcc v5.4. Hey Stephen, thanks for a report, I'll send a fix to net-next immediately. Maciej > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm64 defconfig) failed like this: drivers/net/ethernet/mscc/ocelot.c: In function 'ocelot_port_set_default_prio': drivers/net/ethernet/mscc/ocelot.c:2920:21: error: 'IEEE_8021QAZ_MAX_TCS' undeclared (first use in this function) 2920 | if (prio >= IEEE_8021QAZ_MAX_TCS) | ^~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mscc/ocelot.c:2920:21: note: each undeclared identifier is reported only once for each function it appears in drivers/net/ethernet/mscc/ocelot.c: In function 'ocelot_port_add_dscp_prio': drivers/net/ethernet/mscc/ocelot.c:2962:21: error: 'IEEE_8021QAZ_MAX_TCS' undeclared (first use in this function) 2962 | if (prio >= IEEE_8021QAZ_MAX_TCS) | ^~~~~~~~~~~~~~~~~~~~ Caused by commit 978777d0fb06 ("net: dsa: felix: configure default-prio and dscp priorities") I have applied the following fix up patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 15 Mar 2022 22:34:25 +1100 Subject: [PATCH] fixup for "net: dsa: felix: configure default-prio and dscp priorities" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/mscc/ocelot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c index 41dbb1e326c4..7c4bd3f8e7ec 100644 --- a/drivers/net/ethernet/mscc/ocelot.c +++ b/drivers/net/ethernet/mscc/ocelot.c @@ -7,6 +7,7 @@ #include <linux/dsa/ocelot.h> #include <linux/if_bridge.h> #include <linux/ptp_classify.h> +#include <net/dcbnl.h> #include <soc/mscc/ocelot_vcap.h> #include "ocelot.h" #include "ocelot_vcap.h" -- 2.34.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Mar 15, 2022 at 10:44:21PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (arm64 > defconfig) failed like this: > > drivers/net/ethernet/mscc/ocelot.c: In function 'ocelot_port_set_default_prio': > drivers/net/ethernet/mscc/ocelot.c:2920:21: error: 'IEEE_8021QAZ_MAX_TCS' undeclared (first use in this function) > 2920 | if (prio >= IEEE_8021QAZ_MAX_TCS) > | ^~~~~~~~~~~~~~~~~~~~ > drivers/net/ethernet/mscc/ocelot.c:2920:21: note: each undeclared identifier is reported only once for each function it appears in > drivers/net/ethernet/mscc/ocelot.c: In function 'ocelot_port_add_dscp_prio': > drivers/net/ethernet/mscc/ocelot.c:2962:21: error: 'IEEE_8021QAZ_MAX_TCS' undeclared (first use in this function) > 2962 | if (prio >= IEEE_8021QAZ_MAX_TCS) > | ^~~~~~~~~~~~~~~~~~~~ > > Caused by commit > > 978777d0fb06 ("net: dsa: felix: configure default-prio and dscp priorities") > > I have applied the following fix up patch for today. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 15 Mar 2022 22:34:25 +1100 > Subject: [PATCH] fixup for "net: dsa: felix: configure default-prio and dscp priorities" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/net/ethernet/mscc/ocelot.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c > index 41dbb1e326c4..7c4bd3f8e7ec 100644 > --- a/drivers/net/ethernet/mscc/ocelot.c > +++ b/drivers/net/ethernet/mscc/ocelot.c > @@ -7,6 +7,7 @@ > #include <linux/dsa/ocelot.h> > #include <linux/if_bridge.h> > #include <linux/ptp_classify.h> > +#include <net/dcbnl.h> > #include <soc/mscc/ocelot_vcap.h> > #include "ocelot.h" > #include "ocelot_vcap.h" > -- > 2.34.1 > > > > -- > Cheers, > Stephen Rothwell Thanks. I've sent this patch: https://patchwork.kernel.org/project/netdevbpf/patch/20220315131215.273450-1-vladimir.oltean@nxp.com/
[-- Attachment #1: Type: text/plain, Size: 3426 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/string.h:253, from include/linux/bitmap.h:11, from include/linux/cpumask.h:12, from arch/x86/include/asm/cpumask.h:5, from arch/x86/include/asm/msr.h:11, from arch/x86/include/asm/processor.h:22, from arch/x86/include/asm/timex.h:5, from include/linux/timex.h:65, from include/linux/time32.h:13, from include/linux/time.h:60, from include/linux/ktime.h:24, from include/linux/timer.h:6, from include/linux/netdevice.h:24, from include/trace/events/xdp.h:8, from include/linux/bpf_trace.h:5, from drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:33: In function 'fortify_memset_chk', inlined from 'mlx5e_xmit_xdp_frame' at drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:438:3: include/linux/fortify-string.h:242:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 242 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Caused by commit 9ded70fa1d81 ("net/mlx5e: Don't prefill WQEs in XDP SQ in the multi buffer mode") exposed by the kspp tree. I have applied the following fix patch for today (a better one is probably possible). From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 21 Mar 2022 18:29:24 +1100 Subject: [PATCH] fxup for "net/mlx5e: Don't prefill WQEs in XDP SQ in the multi buffer mode" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 3 +-- include/linux/mlx5/qp.h | 5 +++++ 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c index f35b62ce4c07..8f321a6c0809 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c @@ -435,8 +435,7 @@ mlx5e_xmit_xdp_frame(struct mlx5e_xdpsq *sq, struct mlx5e_xmit_data *xdptxd, u8 num_pkts = 1 + num_frags; int i; - memset(&cseg->signature, 0, sizeof(*cseg) - - sizeof(cseg->opmod_idx_opcode) - sizeof(cseg->qpn_ds)); + memset(&cseg->trailer, 0, sizeof(cseg->trailer)); memset(eseg, 0, sizeof(*eseg) - sizeof(eseg->trailer)); eseg->inline_hdr.sz = cpu_to_be16(inline_hdr_sz); diff --git a/include/linux/mlx5/qp.h b/include/linux/mlx5/qp.h index 61e48d459b23..8bda3ba5b109 100644 --- a/include/linux/mlx5/qp.h +++ b/include/linux/mlx5/qp.h @@ -202,6 +202,9 @@ struct mlx5_wqe_fmr_seg { struct mlx5_wqe_ctrl_seg { __be32 opmod_idx_opcode; __be32 qpn_ds; + + struct_group(trailer, + u8 signature; u8 rsvd[2]; u8 fm_ce_se; @@ -211,6 +214,8 @@ struct mlx5_wqe_ctrl_seg { __be32 umr_mkey; __be32 tis_tir_num; }; + + ); /* end of trailer group */ }; #define MLX5_WQE_CTRL_DS_MASK 0x3f -- 2.34.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Mon, 21 Mar 2022 18:39:41 +1100 Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > In file included from include/linux/string.h:253, > from include/linux/bitmap.h:11, > from include/linux/cpumask.h:12, > from arch/x86/include/asm/cpumask.h:5, > from arch/x86/include/asm/msr.h:11, > from arch/x86/include/asm/processor.h:22, > from arch/x86/include/asm/timex.h:5, > from include/linux/timex.h:65, > from include/linux/time32.h:13, > from include/linux/time.h:60, > from include/linux/ktime.h:24, > from include/linux/timer.h:6, > from include/linux/netdevice.h:24, > from include/trace/events/xdp.h:8, > from include/linux/bpf_trace.h:5, > from drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:33: > In function 'fortify_memset_chk', > inlined from 'mlx5e_xmit_xdp_frame' at drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:438:3: > include/linux/fortify-string.h:242:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] > 242 | __write_overflow_field(p_size_field, size); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Caused by commit > > 9ded70fa1d81 ("net/mlx5e: Don't prefill WQEs in XDP SQ in the multi buffer mode") > > exposed by the kspp tree. > > I have applied the following fix patch for today (a better one is > probably possible). Hi Saeed, thoughts? Would be great to get this sorted by tomorrow. > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 21 Mar 2022 18:29:24 +1100 > Subject: [PATCH] fxup for "net/mlx5e: Don't prefill WQEs in XDP SQ in the multi buffer mode" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 3 +-- > include/linux/mlx5/qp.h | 5 +++++ > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c > index f35b62ce4c07..8f321a6c0809 100644 > --- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c > @@ -435,8 +435,7 @@ mlx5e_xmit_xdp_frame(struct mlx5e_xdpsq *sq, struct mlx5e_xmit_data *xdptxd, > u8 num_pkts = 1 + num_frags; > int i; > > - memset(&cseg->signature, 0, sizeof(*cseg) - > - sizeof(cseg->opmod_idx_opcode) - sizeof(cseg->qpn_ds)); > + memset(&cseg->trailer, 0, sizeof(cseg->trailer)); > memset(eseg, 0, sizeof(*eseg) - sizeof(eseg->trailer)); > > eseg->inline_hdr.sz = cpu_to_be16(inline_hdr_sz); > diff --git a/include/linux/mlx5/qp.h b/include/linux/mlx5/qp.h > index 61e48d459b23..8bda3ba5b109 100644 > --- a/include/linux/mlx5/qp.h > +++ b/include/linux/mlx5/qp.h > @@ -202,6 +202,9 @@ struct mlx5_wqe_fmr_seg { > struct mlx5_wqe_ctrl_seg { > __be32 opmod_idx_opcode; > __be32 qpn_ds; > + > + struct_group(trailer, > + > u8 signature; > u8 rsvd[2]; > u8 fm_ce_se; > @@ -211,6 +214,8 @@ struct mlx5_wqe_ctrl_seg { > __be32 umr_mkey; > __be32 tis_tir_num; > }; > + > + ); /* end of trailer group */ > }; > > #define MLX5_WQE_CTRL_DS_MASK 0x3f
On 21 Mar 14:45, Jakub Kicinski wrote:
>On Mon, 21 Mar 2022 18:39:41 +1100 Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the net-next tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> In file included from include/linux/string.h:253,
>> from include/linux/bitmap.h:11,
>> from include/linux/cpumask.h:12,
>> from arch/x86/include/asm/cpumask.h:5,
>> from arch/x86/include/asm/msr.h:11,
>> from arch/x86/include/asm/processor.h:22,
>> from arch/x86/include/asm/timex.h:5,
>> from include/linux/timex.h:65,
>> from include/linux/time32.h:13,
>> from include/linux/time.h:60,
>> from include/linux/ktime.h:24,
>> from include/linux/timer.h:6,
>> from include/linux/netdevice.h:24,
>> from include/trace/events/xdp.h:8,
>> from include/linux/bpf_trace.h:5,
>> from drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:33:
>> In function 'fortify_memset_chk',
>> inlined from 'mlx5e_xmit_xdp_frame' at drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:438:3:
>> include/linux/fortify-string.h:242:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
>> 242 | __write_overflow_field(p_size_field, size);
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Caused by commit
>>
>> 9ded70fa1d81 ("net/mlx5e: Don't prefill WQEs in XDP SQ in the multi buffer mode")
>>
>> exposed by the kspp tree.
>>
>> I have applied the following fix patch for today (a better one is
>> probably possible).
>
>Hi Saeed,
>
>thoughts?
>
I forgot about this warning in net :-/ we did a similar patch to net to
avoid it, Stephen's patch is correct,
I will submit his fixup to net-next in the morning.
[-- Attachment #1: Type: text/plain, Size: 2380 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/ethernet/sfc/ptp.c:2191:35: error: 'efx_copy_channel' undeclared here (not in a function); did you mean 'efx_ptp_channel'? 2191 | .copy = efx_copy_channel, | ^~~~~~~~~~~~~~~~ | efx_ptp_channel Caused by commit 54fccfdd7c66 ("sfc: efx_default_channel_type APIs can be static") interacting with commit 49e6123c65da ("net: sfc: fix memory leak due to ptp channel") from the net tree. I have added the following merge fix patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 10 May 2022 12:56:18 +1000 Subject: [PATCH] fix up for "net: sfc: fix memory leak due to ptp channel" This is a partial revert of 54fccfdd7c66 ("sfc: efx_default_channel_type APIs can be static") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/sfc/efx_channels.c | 1 - drivers/net/ethernet/sfc/efx_channels.h | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/sfc/efx_channels.c b/drivers/net/ethernet/sfc/efx_channels.c index ec913f62790b..79df636d6df8 100644 --- a/drivers/net/ethernet/sfc/efx_channels.c +++ b/drivers/net/ethernet/sfc/efx_channels.c @@ -598,7 +598,6 @@ void efx_fini_channels(struct efx_nic *efx) /* Allocate and initialise a channel structure, copying parameters * (but not resources) from an old channel structure. */ -static struct efx_channel *efx_copy_channel(const struct efx_channel *old_channel) { struct efx_rx_queue *rx_queue; diff --git a/drivers/net/ethernet/sfc/efx_channels.h b/drivers/net/ethernet/sfc/efx_channels.h index 64abb99a56b8..46b702648721 100644 --- a/drivers/net/ethernet/sfc/efx_channels.h +++ b/drivers/net/ethernet/sfc/efx_channels.h @@ -39,6 +39,7 @@ int efx_set_channels(struct efx_nic *efx); void efx_remove_channel(struct efx_channel *channel); void efx_remove_channels(struct efx_nic *efx); void efx_fini_channels(struct efx_nic *efx); +struct efx_channel *efx_copy_channel(const struct efx_channel *old_channel); void efx_start_channels(struct efx_nic *efx); void efx_stop_channels(struct efx_nic *efx); -- 2.35.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2563 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/ethernet/mediatek/mtk_ppe_offload.c: In function 'mtk_flow_get_wdma_info': drivers/net/ethernet/mediatek/mtk_ppe_offload.c:93:26: error: initialization of 'unsigned char' from 'const u8 *' {aka 'const unsigned char *'} makes integer from pointer without a cast [-Werror=int-conversion] 93 | .daddr = addr, | ^~~~ drivers/net/ethernet/mediatek/mtk_ppe_offload.c:93:26: note: (near initialization for 'ctx.daddr[0]') drivers/net/ethernet/mediatek/mtk_ppe_offload.c:91:42: error: missing braces around initializer [-Werror=missing-braces] 91 | struct net_device_path_ctx ctx = { | ^ 92 | .dev = dev, 93 | .daddr = addr, | { 94 | }; | } Caused by commit cf2df74e202d ("net: fix dev_fill_forward_path with pppoe + bridge") from Linus' tree interacting with commit a333215e10cb ("net: ethernet: mtk_eth_soc: implement flow offloading to WED devices") from the net-next tree. I have applied the following merge fix patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 20 May 2022 14:49:44 +1000 Subject: [PATCH] fis up for "net: fix dev_fill_forward_path with pppoe + bridge" interacting with commit a333215e10cb "net: ethernet: mtk_eth_soc: implement flow offloading to WED devices" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/mediatek/mtk_ppe_offload.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c index 1fe31058b0f2..d4a0126082f2 100644 --- a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c +++ b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c @@ -90,7 +90,6 @@ mtk_flow_get_wdma_info(struct net_device *dev, const u8 *addr, struct mtk_wdma_i { struct net_device_path_ctx ctx = { .dev = dev, - .daddr = addr, }; struct net_device_path path = {}; @@ -100,6 +99,7 @@ mtk_flow_get_wdma_info(struct net_device *dev, const u8 *addr, struct mtk_wdma_i if (!dev->netdev_ops->ndo_fill_forward_path) return -1; + memcpy(ctx.daddr, addr, sizeof(ctx.daddr)); if (dev->netdev_ops->ndo_fill_forward_path(&ctx, &path)) return -1; -- 2.35.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, 20 May 2022 14:59:57 +1000 Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
FWIW just merged the fix, if you pull again you'll get this and a fix
for the netfilter warning about ctnetlink_dump_one_entry().
On Thu, May 19, 2022 at 10:20:44PM -0700, Jakub Kicinski wrote:
> On Fri, 20 May 2022 14:59:57 +1000 Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
>
> FWIW just merged the fix, if you pull again you'll get this and a fix
> for the netfilter warning about ctnetlink_dump_one_entry().
Thanks.
Felix forgot to include the update for the mtk driver in his batch it
seems.
On 20.05.22 09:39, Pablo Neira Ayuso wrote:
> On Thu, May 19, 2022 at 10:20:44PM -0700, Jakub Kicinski wrote:
>> On Fri, 20 May 2022 14:59:57 +1000 Stephen Rothwell wrote:
>> > Hi all,
>> >
>> > After merging the net-next tree, today's linux-next build (x86_64
>> > allmodconfig) failed like this:
>>
>> FWIW just merged the fix, if you pull again you'll get this and a fix
>> for the netfilter warning about ctnetlink_dump_one_entry().
>
> Thanks.
>
> Felix forgot to include the update for the mtk driver in his batch it
> seems.
I didn't forget. It was in the series I posted for -next but I had to
remove it to rebase the patch onto nf (as requested by you).
The affected code didn't exist in nf.git.
- Felix
On Fri, May 20, 2022 at 03:49:36PM +0200, Felix Fietkau wrote:
>
> On 20.05.22 09:39, Pablo Neira Ayuso wrote:
> > On Thu, May 19, 2022 at 10:20:44PM -0700, Jakub Kicinski wrote:
> > > On Fri, 20 May 2022 14:59:57 +1000 Stephen Rothwell wrote:
> > > > Hi all,
> > > > > After merging the net-next tree, today's linux-next build
> > > (x86_64
> > > > allmodconfig) failed like this:
> > >
> > > FWIW just merged the fix, if you pull again you'll get this and a fix
> > > for the netfilter warning about ctnetlink_dump_one_entry().
> >
> > Thanks.
> >
> > Felix forgot to include the update for the mtk driver in his batch it
> > seems.
>
> I didn't forget. It was in the series I posted for -next but I had to remove
> it to rebase the patch onto nf (as requested by you).
> The affected code didn't exist in nf.git.
Next time better if all the patches are handled through the same tree.
[-- Attachment #1: Type: text/plain, Size: 1716 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/ipv4/raw.c: In function 'raw_icmp_error': net/ipv4/raw.c:266:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] 266 | struct hlist_nulls_head *hlist; | ^~~~~~ cc1: all warnings being treated as errors Introduced by commit ba44f8182ec2 ("raw: use more conventional iterators") I have applied the following patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 20 Jun 2022 09:21:01 +1000 Subject: [PATCH] raw: fix build error The linux-next x86_64 allmodconfig build produced this error: net/ipv4/raw.c: In function 'raw_icmp_error': net/ipv4/raw.c:266:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] 266 | struct hlist_nulls_head *hlist; | ^~~~~~ cc1: all warnings being treated as errors Fixes: ba44f8182ec2 ("raw: use more conventional iterators") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/ipv4/raw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c index d28bf0b901a2..b3b255db9021 100644 --- a/net/ipv4/raw.c +++ b/net/ipv4/raw.c @@ -262,7 +262,7 @@ static void raw_err(struct sock *sk, struct sk_buff *skb, u32 info) void raw_icmp_error(struct sk_buff *skb, int protocol, u32 info) { - struct net *net = dev_net(skb->dev);; + struct net *net = dev_net(skb->dev); struct hlist_nulls_head *hlist; struct hlist_nulls_node *hnode; int dif = skb->dev->ifindex; -- 2.35.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Date: Mon, 20 Jun 2022 09:34:24 +1000 From: Stephen Rothwell <sfr@canb.auug.org.au> > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/ipv4/raw.c: In function 'raw_icmp_error': > net/ipv4/raw.c:266:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] > 266 | struct hlist_nulls_head *hlist; > | ^~~~~~ > cc1: all warnings being treated as errors > > Introduced by commit > > ba44f8182ec2 ("raw: use more conventional iterators") > > I have applied the following patch for today. I have posted the same patch just few minutes ago, https://lore.kernel.org/netdev/20220619232927.54259-2-kuniyu@amazon.com/ > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 20 Jun 2022 09:21:01 +1000 > Subject: [PATCH] raw: fix build error > > The linux-next x86_64 allmodconfig build produced this error: > > net/ipv4/raw.c: In function 'raw_icmp_error': > net/ipv4/raw.c:266:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] > 266 | struct hlist_nulls_head *hlist; > | ^~~~~~ > cc1: all warnings being treated as errors > > Fixes: ba44f8182ec2 ("raw: use more conventional iterators") > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > net/ipv4/raw.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c > index d28bf0b901a2..b3b255db9021 100644 > --- a/net/ipv4/raw.c > +++ b/net/ipv4/raw.c > @@ -262,7 +262,7 @@ static void raw_err(struct sock *sk, struct sk_buff *skb, u32 info) > > void raw_icmp_error(struct sk_buff *skb, int protocol, u32 info) > { > - struct net *net = dev_net(skb->dev);; > + struct net *net = dev_net(skb->dev); > struct hlist_nulls_head *hlist; > struct hlist_nulls_node *hnode; > int dif = skb->dev->ifindex; > -- > 2.35.1 > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 1521 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c:14: drivers/net/ethernet/marvell/octeontx2/af/npc_profile.h:15120:28: error: 'npc_mkex_default' defined but not used [-Werror=unused-variable] 15120 | static struct npc_mcam_kex npc_mkex_default = { | ^~~~~~~~~~~~~~~~ drivers/net/ethernet/marvell/octeontx2/af/npc_profile.h:15000:30: error: 'npc_lt_defaults' defined but not used [-Werror=unused-variable] 15000 | static struct npc_lt_def_cfg npc_lt_defaults = { | ^~~~~~~~~~~~~~~ drivers/net/ethernet/marvell/octeontx2/af/npc_profile.h:14901:31: error: 'npc_kpu_profiles' defined but not used [-Werror=unused-variable] 14901 | static struct npc_kpu_profile npc_kpu_profiles[] = { | ^~~~~~~~~~~~~~~~ drivers/net/ethernet/marvell/octeontx2/af/npc_profile.h:483:38: error: 'ikpu_action_entries' defined but not used [-Werror=unused-variable] 483 | static struct npc_kpu_profile_action ikpu_action_entries[] = { | ^~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Caused by commit c6238bc0614d ("octeontx2-af: Drop rules for NPC MCAM") I do wonder why static structs are declared in a header file ... I have used the net-next tree from next-20220706 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 288 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc pseries_le_defconfig) failed like this: Caused by commit d9282e48c608 ("tcp: Add listening address to SYN flood message") CONFIG_IPV6 is not set for this build. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, 16 Nov 2022 at 17:34, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > pseries_le_defconfig) failed like this: > > > Caused by commit > > d9282e48c608 ("tcp: Add listening address to SYN flood message") > > CONFIG_IPV6 is not set for this build. > > -- > Cheers, > Stephen Rothwell Yes, Geert already sent a patch: tcp: Fix tcp_syn_flood_action() if CONFIG_IPV6=n https://lore.kernel.org/netdev/d1ecf500f07e063d4e8e34f4045ddca55416c686.1668507036.git.geert+renesas@glider.be/ Jamie
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_cmdline_opt': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7591:28: error: too many arguments to function 'sysfs_streq' 7591 | } else if (sysfs_streq(opt, "pause:", 6)) { | ^~~~~~~~~~~ In file included from include/linux/bitmap.h:11, from include/linux/cpumask.h:12, from include/linux/smp.h:13, from include/linux/lockdep.h:14, from include/linux/mutex.h:17, from include/linux/notifier.h:14, from include/linux/clk.h:14, from drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:17: include/linux/string.h:185:13: note: declared here 185 | extern bool sysfs_streq(const char *s1, const char *s2); | ^~~~~~~~~~~ Caused by commit f72cd76b05ea ("net: stmmac: use sysfs_streq() instead of strncmp()") I have used the net-next tree from next-20221125 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2511 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from net/ethtool/netlink.c:6: net/ethtool/netlink.h:177:20: error: redefinition of 'ethnl_update_bool' 177 | static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, | ^~~~~~~~~~~~~~~~~ net/ethtool/netlink.h:125:20: note: previous definition of 'ethnl_update_bool' with type 'void(bool *, const struct nlattr *, bool *)' {aka 'void(_Bool *, const struct nlattr *, _Bool *)'} 125 | static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, | ^~~~~~~~~~~~~~~~~ Caused by commit dc0b98a1758f ("ethtool: Add and use ethnl_update_bool.") merging badly with commit 7c494a7749a7 ("net: ethtool: netlink: introduce ethnl_update_bool()") from the net tree. I applied the following merge fix up. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 24 Jan 2023 09:58:16 +1100 Subject: [PATCH] fix up for "ethtool: Add and use ethnl_update_bool." interacting with "net: ethtool: netlink: introduce ethnl_update_bool()" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/ethtool/netlink.h | 26 -------------------------- 1 file changed, 26 deletions(-) diff --git a/net/ethtool/netlink.h b/net/ethtool/netlink.h index 4992fab0d06b..b01f7cd542c4 100644 --- a/net/ethtool/netlink.h +++ b/net/ethtool/netlink.h @@ -111,32 +111,6 @@ static inline void ethnl_update_u8(u8 *dst, const struct nlattr *attr, *mod = true; } -/** - * ethnl_update_bool() - update bool from NLA_U8 attribute - * @dst: value to update - * @attr: netlink attribute with new value or null - * @mod: pointer to bool for modification tracking - * - * Use the u8 value from NLA_U8 netlink attribute @attr to set bool variable - * pointed to by @dst to false (if zero) or 1 (if not); do nothing if @attr is - * null. Bool pointed to by @mod is set to true if this function changed the - * logical value of *dst, otherwise it is left as is. - */ -static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, - bool *mod) -{ - u8 val; - - if (!attr) - return; - val = !!nla_get_u8(attr); - if (*dst == val) - return; - - *dst = val; - *mod = true; -} - /** * ethnl_update_bool32() - update u32 used as bool from NLA_U8 attribute * @dst: value to update -- 2.35.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3093 bytes --] Hi Stephen, On 24/01/2023 00:02, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from net/ethtool/netlink.c:6: > net/ethtool/netlink.h:177:20: error: redefinition of 'ethnl_update_bool' > 177 | static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, > | ^~~~~~~~~~~~~~~~~ > net/ethtool/netlink.h:125:20: note: previous definition of 'ethnl_update_bool' with type 'void(bool *, const struct nlattr *, bool *)' {aka 'void(_Bool *, const struct nlattr *, _Bool *)'} > 125 | static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, > | ^~~~~~~~~~~~~~~~~ Thank you for the patch, we had the same issue in MPTCP tree when merging net and net-next. > Caused by commit > > dc0b98a1758f ("ethtool: Add and use ethnl_update_bool.") > > merging badly with commit > > 7c494a7749a7 ("net: ethtool: netlink: introduce ethnl_update_bool()") > > from the net tree. > > I applied the following merge fix up. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 24 Jan 2023 09:58:16 +1100 > Subject: [PATCH] fix up for "ethtool: Add and use ethnl_update_bool." > > interacting with "net: ethtool: netlink: introduce ethnl_update_bool()" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > net/ethtool/netlink.h | 26 -------------------------- > 1 file changed, 26 deletions(-) > > diff --git a/net/ethtool/netlink.h b/net/ethtool/netlink.h > index 4992fab0d06b..b01f7cd542c4 100644 > --- a/net/ethtool/netlink.h > +++ b/net/ethtool/netlink.h > @@ -111,32 +111,6 @@ static inline void ethnl_update_u8(u8 *dst, const struct nlattr *attr, > *mod = true; > } > > -/** > - * ethnl_update_bool() - update bool from NLA_U8 attribute > - * @dst: value to update > - * @attr: netlink attribute with new value or null > - * @mod: pointer to bool for modification tracking > - * > - * Use the u8 value from NLA_U8 netlink attribute @attr to set bool variable > - * pointed to by @dst to false (if zero) or 1 (if not); do nothing if @attr is > - * null. Bool pointed to by @mod is set to true if this function changed the > - * logical value of *dst, otherwise it is left as is. > - */ > -static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, > - bool *mod) > -{ > - u8 val; > - > - if (!attr) > - return; > - val = !!nla_get_u8(attr); > - if (*dst == val) > - return; > - > - *dst = val; > - *mod = true; > -} Small detail: should we not remove the other one -- introduced by commit dc0b98a1758f ("ethtool: Add and use ethnl_update_bool.") -- instead? The other one has some typos in the description and is using "!!*dst" while it is not needed if I'm not mistaken. In MPTCP tree for the moment, I removed the other one but I will follow up on which one I need to discard :) Just in case, I attached the patch I used. I can send it properly if needed. Cheers, Matt -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net [-- Attachment #2: 0001-net-ethtool-fix-up-for-ethtool-Add-and-use-ethnl_upd.patch --] [-- Type: text/x-patch, Size: 2753 bytes --] From dca3dbf90a4fdf4191122adde227fc31807264eb Mon Sep 17 00:00:00 2001 From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 24 Jan 2023 10:02:49 +1100 Subject: [PATCH net-next] net: ethtool: fix up for "ethtool: Add and use ethnl_update_bool." After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from net/ethtool/netlink.c:6: net/ethtool/netlink.h:177:20: error: redefinition of 'ethnl_update_bool' 177 | static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, | ^~~~~~~~~~~~~~~~~ net/ethtool/netlink.h:125:20: note: previous definition of 'ethnl_update_bool' with type 'void(bool *, const struct nlattr *, bool *)' {aka 'void(_Bool *, const struct nlattr *, _Bool *)'} 125 | static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, | ^~~~~~~~~~~~~~~~~ Caused by: commit dc0b98a1758f ("ethtool: Add and use ethnl_update_bool.") merging badly with: commit 7c494a7749a7 ("net: ethtool: netlink: introduce ethnl_update_bool()") from the net tree. The version from net-next -- commit 7c494a7749a7 ("net: ethtool: netlink: introduce ethnl_update_bool()") -- has been taken, keeping the one from net. Fixes: dc0b98a1758f ("ethtool: Add and use ethnl_update_bool.") Co-developed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/ethtool/netlink.h | 26 -------------------------- 1 file changed, 26 deletions(-) diff --git a/net/ethtool/netlink.h b/net/ethtool/netlink.h index 4992fab0d06b..29aef39476eb 100644 --- a/net/ethtool/netlink.h +++ b/net/ethtool/netlink.h @@ -163,32 +163,6 @@ static inline void ethnl_update_bool32(u32 *dst, const struct nlattr *attr, *mod = true; } -/** - * ethnl_update_bool() - updateb bool used as bool from NLA_U8 attribute - * @dst: value to update - * @attr: netlink attribute with new value or null - * @mod: pointer to bool for modification tracking - * - * Use the bool value from NLA_U8 netlink attribute @attr to set bool variable - * pointed to by @dst to 0 (if zero) or 1 (if not); do nothing if @attr is - * null. Bool pointed to by @mod is set to true if this function changed the - * logical value of *dst, otherwise it is left as is. - */ -static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, - bool *mod) -{ - u8 val; - - if (!attr) - return; - val = !!nla_get_u8(attr); - if (!!*dst == val) - return; - - *dst = val; - *mod = true; -} - /** * ethnl_update_binary() - update binary data from NLA_BINARY attribute * @dst: value to update -- 2.38.1
Hello: This patch was applied to netdev/net.git (master) by Paolo Abeni <pabeni@redhat.com>: On Tue, 24 Jan 2023 10:02:49 +1100 you wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from net/ethtool/netlink.c:6: > net/ethtool/netlink.h:177:20: error: redefinition of 'ethnl_update_bool' > 177 | static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, > | ^~~~~~~~~~~~~~~~~ > net/ethtool/netlink.h:125:20: note: previous definition of 'ethnl_update_bool' with type 'void(bool *, const struct nlattr *, bool *)' {aka 'void(_Bool *, const struct nlattr *, _Bool *)'} > 125 | static inline void ethnl_update_bool(bool *dst, const struct nlattr *attr, > | ^~~~~~~~~~~~~~~~~ > > [...] Here is the summary with links: - linux-next: build failure after merge of the net-next tree https://git.kernel.org/netdev/net/c/d968117a7e8e You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
[-- Attachment #1: Type: text/plain, Size: 3224 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/notifier.h:14, from arch/x86/include/asm/uprobes.h:13, from include/linux/uprobes.h:49, from include/linux/mm_types.h:16, from include/linux/buildid.h:5, from include/linux/module.h:14, from net/smc/af_smc.c:22: net/smc/af_smc.c: In function 'smcr_serv_conf_first_link': net/smc/af_smc.c:1842:20: error: passing argument 1 of 'mutex_lock_nested' from incompatible pointer type [-Werror=incompatible-pointer-types] 1842 | mutex_lock(&link->lgr->llc_conf_mutex); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | | | struct rw_semaphore * include/linux/mutex.h:187:44: note: in definition of macro 'mutex_lock' 187 | #define mutex_lock(lock) mutex_lock_nested(lock, 0) | ^~~~ include/linux/mutex.h:178:45: note: expected 'struct mutex *' but argument is of type 'struct rw_semaphore *' 178 | extern void mutex_lock_nested(struct mutex *lock, unsigned int subclass); | ~~~~~~~~~~~~~~^~~~ net/smc/af_smc.c:1845:22: error: passing argument 1 of 'mutex_unlock' from incompatible pointer type [-Werror=incompatible-pointer-types] 1845 | mutex_unlock(&link->lgr->llc_conf_mutex); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | | | struct rw_semaphore * include/linux/mutex.h:218:40: note: expected 'struct mutex *' but argument is of type 'struct rw_semaphore *' 218 | extern void mutex_unlock(struct mutex *lock); | ~~~~~~~~~~~~~~^~~~ Caused by commit b5dd4d698171 ("net/smc: llc_conf_mutex refactor, replace it with rw_semaphore") interacting with commit e40b801b3603 ("net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()") from the net tree. I applied the following merge resolution patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 21 Feb 2023 12:30:46 +1100 Subject: [PATCH] fix up for "net/smc: llc_conf_mutex refactor, replace it with rw_semaphore" interacting with "net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/smc/af_smc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c index 0f6a61e44e93..a4cccdfdc00a 100644 --- a/net/smc/af_smc.c +++ b/net/smc/af_smc.c @@ -1839,10 +1839,10 @@ static int smcr_serv_conf_first_link(struct smc_sock *smc) smc_llc_link_active(link); smcr_lgr_set_type(link->lgr, SMC_LGR_SINGLE); - mutex_lock(&link->lgr->llc_conf_mutex); + down_write(&link->lgr->llc_conf_mutex); /* initial contact - try to establish second link */ smc_llc_srv_add_link(link, NULL); - mutex_unlock(&link->lgr->llc_conf_mutex); + up_write(&link->lgr->llc_conf_mutex); return 0; } -- 2.39.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1776 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) failed like this: drivers/net/ethernet/sun/sunvnet_common.c: In function 'vnet_handle_offloads': drivers/net/ethernet/sun/sunvnet_common.c:1277:16: error: implicit declaration of function 'skb_gso_segment'; did you mean 'skb_gso_reset'? [-Werror=implicit-function-declaration] 1277 | segs = skb_gso_segment(skb, dev->features & ~NETIF_F_TSO); | ^~~~~~~~~~~~~~~ | skb_gso_reset drivers/net/ethernet/sun/sunvnet_common.c:1277:14: warning: assignment to 'struct sk_buff *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 1277 | segs = skb_gso_segment(skb, dev->features & ~NETIF_F_TSO); | ^ Caused by commit d457a0e329b0 ("net: move gso declarations and functions to their own files") I have applied the following patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 13 Jun 2023 16:38:10 +1000 Subject: [PATCH] Fix a sparc64 use of the gso functions This was missed when they were moved. Fixes: d457a0e329b0 ("net: move gso declarations and functions to their own files") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/ethernet/sun/sunvnet_common.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/sun/sunvnet_common.c b/drivers/net/ethernet/sun/sunvnet_common.c index a6211b95ed17..3525d5c0d694 100644 --- a/drivers/net/ethernet/sun/sunvnet_common.c +++ b/drivers/net/ethernet/sun/sunvnet_common.c @@ -25,6 +25,7 @@ #endif #include <net/ip.h> +#include <net/gso.h> #include <net/icmp.h> #include <net/route.h> -- 2.39.2 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Jun 13, 2023 at 04:46:39PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (sparc64 > defconfig) failed like this: > > drivers/net/ethernet/sun/sunvnet_common.c: In function 'vnet_handle_offloads': > drivers/net/ethernet/sun/sunvnet_common.c:1277:16: error: implicit declaration of function 'skb_gso_segment'; did you mean 'skb_gso_reset'? [-Werror=implicit-function-declaration] > 1277 | segs = skb_gso_segment(skb, dev->features & ~NETIF_F_TSO); > | ^~~~~~~~~~~~~~~ > | skb_gso_reset > drivers/net/ethernet/sun/sunvnet_common.c:1277:14: warning: assignment to 'struct sk_buff *' from 'int' makes pointer from integer without a cast [-Wint-conversion] > 1277 | segs = skb_gso_segment(skb, dev->features & ~NETIF_F_TSO); > | ^ > > Caused by commit > > d457a0e329b0 ("net: move gso declarations and functions to their own files") > > I have applied the following patch for today. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 13 Jun 2023 16:38:10 +1000 > Subject: [PATCH] Fix a sparc64 use of the gso functions > > This was missed when they were moved. > > Fixes: d457a0e329b0 ("net: move gso declarations and functions to their own files") > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Thanks Stephen, I agree that this is a correct fix. I've tried to conduct an audit of the symbols changed in the above mentioned patch and confirm that compilation is successful. Your patch addresses the only failure I uncovered during that activity. Sorry for not doing this before the patch hit net-next. Reviewed-by: Simon Horman <simon.horman@corigine.com> > --- > drivers/net/ethernet/sun/sunvnet_common.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/ethernet/sun/sunvnet_common.c b/drivers/net/ethernet/sun/sunvnet_common.c > index a6211b95ed17..3525d5c0d694 100644 > --- a/drivers/net/ethernet/sun/sunvnet_common.c > +++ b/drivers/net/ethernet/sun/sunvnet_common.c > @@ -25,6 +25,7 @@ > #endif > > #include <net/ip.h> > +#include <net/gso.h> > #include <net/icmp.h> > #include <net/route.h> > > -- > 2.39.2 > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 1993 bytes --] Hi all, On Tue, 13 Jun 2023 16:46:39 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (sparc64 > defconfig) failed like this: > > drivers/net/ethernet/sun/sunvnet_common.c: In function 'vnet_handle_offloads': > drivers/net/ethernet/sun/sunvnet_common.c:1277:16: error: implicit declaration of function 'skb_gso_segment'; did you mean 'skb_gso_reset'? [-Werror=implicit-function-declaration] > 1277 | segs = skb_gso_segment(skb, dev->features & ~NETIF_F_TSO); > | ^~~~~~~~~~~~~~~ > | skb_gso_reset > drivers/net/ethernet/sun/sunvnet_common.c:1277:14: warning: assignment to 'struct sk_buff *' from 'int' makes pointer from integer without a cast [-Wint-conversion] > 1277 | segs = skb_gso_segment(skb, dev->features & ~NETIF_F_TSO); > | ^ > > Caused by commit > > d457a0e329b0 ("net: move gso declarations and functions to their own files") > > I have applied the following patch for today. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 13 Jun 2023 16:38:10 +1000 > Subject: [PATCH] Fix a sparc64 use of the gso functions > > This was missed when they were moved. > > Fixes: d457a0e329b0 ("net: move gso declarations and functions to their own files") > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/net/ethernet/sun/sunvnet_common.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/ethernet/sun/sunvnet_common.c b/drivers/net/ethernet/sun/sunvnet_common.c > index a6211b95ed17..3525d5c0d694 100644 > --- a/drivers/net/ethernet/sun/sunvnet_common.c > +++ b/drivers/net/ethernet/sun/sunvnet_common.c > @@ -25,6 +25,7 @@ > #endif > > #include <net/ip.h> > +#include <net/gso.h> > #include <net/icmp.h> > #include <net/route.h> > I am still applying that patch to the net-next tree merge. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hello: This patch was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba@kernel.org>: On Tue, 13 Jun 2023 16:46:39 +1000 you wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (sparc64 > defconfig) failed like this: > > drivers/net/ethernet/sun/sunvnet_common.c: In function 'vnet_handle_offloads': > drivers/net/ethernet/sun/sunvnet_common.c:1277:16: error: implicit declaration of function 'skb_gso_segment'; did you mean 'skb_gso_reset'? [-Werror=implicit-function-declaration] > 1277 | segs = skb_gso_segment(skb, dev->features & ~NETIF_F_TSO); > | ^~~~~~~~~~~~~~~ > | skb_gso_reset > drivers/net/ethernet/sun/sunvnet_common.c:1277:14: warning: assignment to 'struct sk_buff *' from 'int' makes pointer from integer without a cast [-Wint-conversion] > 1277 | segs = skb_gso_segment(skb, dev->features & ~NETIF_F_TSO); > | ^ > > [...] Here is the summary with links: - linux-next: build failure after merge of the net-next tree https://git.kernel.org/netdev/net-next/c/d9ffa069e006 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
On Fri, Jun 16, 2023 at 08:30:33AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 13 Jun 2023 16:46:39 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the net-next tree, today's linux-next build (sparc64
> > defconfig) failed like this:
> >
> > drivers/net/ethernet/sun/sunvnet_common.c: In function 'vnet_handle_offloads':
> > drivers/net/ethernet/sun/sunvnet_common.c:1277:16: error: implicit declaration of function 'skb_gso_segment'; did you mean 'skb_gso_reset'? [-Werror=implicit-function-declaration]
> > 1277 | segs = skb_gso_segment(skb, dev->features & ~NETIF_F_TSO);
> > | ^~~~~~~~~~~~~~~
> > | skb_gso_reset
> > drivers/net/ethernet/sun/sunvnet_common.c:1277:14: warning: assignment to 'struct sk_buff *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
> > 1277 | segs = skb_gso_segment(skb, dev->features & ~NETIF_F_TSO);
> > | ^
> >
> > Caused by commit
> >
> > d457a0e329b0 ("net: move gso declarations and functions to their own files")
> >
> > I have applied the following patch for today.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Tue, 13 Jun 2023 16:38:10 +1000
> > Subject: [PATCH] Fix a sparc64 use of the gso functions
> >
> > This was missed when they were moved.
> >
> > Fixes: d457a0e329b0 ("net: move gso declarations and functions to their own files")
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > drivers/net/ethernet/sun/sunvnet_common.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/ethernet/sun/sunvnet_common.c b/drivers/net/ethernet/sun/sunvnet_common.c
> > index a6211b95ed17..3525d5c0d694 100644
> > --- a/drivers/net/ethernet/sun/sunvnet_common.c
> > +++ b/drivers/net/ethernet/sun/sunvnet_common.c
> > @@ -25,6 +25,7 @@
> > #endif
> >
> > #include <net/ip.h>
> > +#include <net/gso.h>
> > #include <net/icmp.h>
> > #include <net/route.h>
> >
>
> I am still applying that patch to the net-next tree merge.
Hi Stephen,
I guess it was applied after you pulled net-next.
In any case, for the record, I see it there now as:
d9ffa069e006 ("sunvnet: fix sparc64 build error after gso code split")
[-- Attachment #1: Type: text/plain, Size: 1114 bytes --] Hi all, After merging the net-next tree, today's linux-next build (native perf) failed like this: In file included from builtin-trace.c:907: trace/beauty/msg_flags.c: In function 'syscall_arg__scnprintf_msg_flags': trace/beauty/msg_flags.c:28:21: error: 'MSG_SPLICE_PAGES' undeclared (first use in this function) 28 | if (flags & MSG_##n) { \ | ^~~~ trace/beauty/msg_flags.c:50:9: note: in expansion of macro 'P_MSG_FLAG' 50 | P_MSG_FLAG(SPLICE_PAGES); | ^~~~~~~~~~ trace/beauty/msg_flags.c:28:21: note: each undeclared identifier is reported only once for each function it appears in 28 | if (flags & MSG_##n) { \ | ^~~~ trace/beauty/msg_flags.c:50:9: note: in expansion of macro 'P_MSG_FLAG' 50 | P_MSG_FLAG(SPLICE_PAGES); | ^~~~~~~~~~ Caused by commit b848b26c6672 ("net: Kill MSG_SENDPAGE_NOTLAST") There is no MSG_SPLICE_PAGES in tools/perf/trace/beauty/include/linux/socket.h I have reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> wrote: > After merging the net-next tree, today's linux-next build (native perf) > failed like this: > > In file included from builtin-trace.c:907: > trace/beauty/msg_flags.c: In function 'syscall_arg__scnprintf_msg_flags': > trace/beauty/msg_flags.c:28:21: error: 'MSG_SPLICE_PAGES' undeclared (first use in this function) I tried applying the attached patch, but it doesn't make any difference. Any idea what I've missed? Also, why do we have duplicates of all the kernel headers in the tools/ directory? David --- commit 878ff45f5f746f6773224ff952c490b5812462f2 Author: David Howells <dhowells@redhat.com> Date: Mon Jun 26 08:08:12 2023 +0100 tools: Fix MSG_SPLICE_PAGES build error in trace tools Fix the following error: In file included from builtin-trace.c:907: trace/beauty/msg_flags.c: In function 'syscall_arg__scnprintf_msg_flags': trace/beauty/msg_flags.c:28:21: error: 'MSG_SPLICE_PAGES' undeclared (first use in this function) 28 | if (flags & MSG_##n) { \ | ^~~~ trace/beauty/msg_flags.c:50:9: note: in expansion of macro 'P_MSG_FLAG' 50 | P_MSG_FLAG(SPLICE_PAGES); | ^~~~~~~~~~ trace/beauty/msg_flags.c:28:21: note: each undeclared identifier is reported only once for each function it appears in 28 | if (flags & MSG_##n) { \ | ^~~~ trace/beauty/msg_flags.c:50:9: note: in expansion of macro 'P_MSG_FLAG' 50 | P_MSG_FLAG(SPLICE_PAGES); | ^~~~~~~~~~ There is no MSG_SPLICE_PAGES in tools/perf/trace/beauty/include/linux/socket.h Fixes: b848b26c6672 ("net: Kill MSG_SENDPAGE_NOTLAST") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/r/20230626112847.2ef3d422@canb.auug.org.au/ Signed-off-by: David Howells <dhowells@redhat.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: Jens Axboe <axboe@kernel.dk> cc: Matthew Wilcox <willy@infradead.org> cc: bpf@vger.kernel.org cc: dccp@vger.kernel.org cc: linux-afs@lists.infradead.org cc: linux-arm-msm@vger.kernel.org cc: linux-can@vger.kernel.org cc: linux-crypto@vger.kernel.org cc: linux-doc@vger.kernel.org cc: linux-hams@vger.kernel.org cc: linux-perf-users@vger.kernel.org cc: linux-rdma@vger.kernel.org cc: linux-sctp@vger.kernel.org cc: linux-wpan@vger.kernel.org cc: linux-x25@vger.kernel.org cc: mptcp@lists.linux.dev cc: netdev@vger.kernel.org cc: rds-devel@oss.oracle.com cc: tipc-discussion@lists.sourceforge.net cc: virtualization@lists.linux-foundation.org diff --git a/tools/perf/trace/beauty/include/linux/socket.h b/tools/perf/trace/beauty/include/linux/socket.h index 3bef212a24d7..77cb707a566a 100644 --- a/tools/perf/trace/beauty/include/linux/socket.h +++ b/tools/perf/trace/beauty/include/linux/socket.h @@ -326,6 +326,7 @@ struct ucred { */ #define MSG_ZEROCOPY 0x4000000 /* Use user data in kernel path */ +#define MSG_SPLICE_PAGES 0x8000000 /* Splice the pages from the iterator in sendmsg() */ #define MSG_FASTOPEN 0x20000000 /* Send data in TCP SYN */ #define MSG_CMSG_CLOEXEC 0x40000000 /* Set close_on_exec for file descriptor received through
[-- Attachment #1: Type: text/plain, Size: 687 bytes --] Hi David, On Mon, 26 Jun 2023 08:48:26 +0100 David Howells <dhowells@redhat.com> wrote: > > Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > After merging the net-next tree, today's linux-next build (native perf) > > failed like this: > > > > In file included from builtin-trace.c:907: > > trace/beauty/msg_flags.c: In function 'syscall_arg__scnprintf_msg_flags': > > trace/beauty/msg_flags.c:28:21: error: 'MSG_SPLICE_PAGES' undeclared (first use in this function) > > I tried applying the attached patch, but it doesn't make any difference. I wonder if it is using the system headers? Or depends on "make headers-install"? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3174 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/phy/aquantia/aquantia_firmware.c: In function 'aqr_fw_load_memory': drivers/net/phy/aquantia/aquantia_firmware.c:135:23: error: implicit declaration of function 'crc_ccitt_false'; did you mean 'crc_ccitt_byte'? [-Werror=implicit-function-declaration] 135 | crc = crc_ccitt_false(crc, crc_data, sizeof(crc_data)); | ^~~~~~~~~~~~~~~ | crc_ccitt_byte Caused by commit e93984ebc1c8 ("net: phy: aquantia: add firmware load support") interacting with commit 56ded2dd1a43 ("lib: crc_ccitt_false() is identical to crc_itu_t()") from the mm tree. I have applied the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 21 Dec 2023 12:49:11 +1100 Subject: [PATCH] fix up for "net: phy: aquantia: add firmware load support" interacting with commit 56ded2dd1a43 ("lib: crc_ccitt_false() is identical to crc_itu_t()") from the mm tree. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/phy/aquantia/Kconfig | 2 +- drivers/net/phy/aquantia/aquantia_firmware.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/phy/aquantia/Kconfig b/drivers/net/phy/aquantia/Kconfig index a35de4b9b554..1a65678583cf 100644 --- a/drivers/net/phy/aquantia/Kconfig +++ b/drivers/net/phy/aquantia/Kconfig @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only config AQUANTIA_PHY tristate "Aquantia PHYs" - select CRC_CCITT + select CRC_ITU_T help Currently supports the Aquantia AQ1202, AQ2104, AQR105, AQR405 diff --git a/drivers/net/phy/aquantia/aquantia_firmware.c b/drivers/net/phy/aquantia/aquantia_firmware.c index ff34d00d5a0e..0c9640ef153b 100644 --- a/drivers/net/phy/aquantia/aquantia_firmware.c +++ b/drivers/net/phy/aquantia/aquantia_firmware.c @@ -3,7 +3,7 @@ #include <linux/bitfield.h> #include <linux/of.h> #include <linux/firmware.h> -#include <linux/crc-ccitt.h> +#include <linux/crc-itu-t.h> #include <linux/nvmem-consumer.h> #include <asm/unaligned.h> @@ -132,7 +132,7 @@ static int aqr_fw_load_memory(struct phy_device *phydev, u32 addr, crc_data[3] = word; /* ...calculate CRC as we load data... */ - crc = crc_ccitt_false(crc, crc_data, sizeof(crc_data)); + crc = crc_itu_t(crc, crc_data, sizeof(crc_data)); } /* ...gets CRC from MAILBOX after we have loaded the entire section... */ up_crc = phy_read_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE2); @@ -164,7 +164,7 @@ static int aqr_fw_boot(struct phy_device *phydev, const u8 *data, size_t size, phydev_err(phydev, "bad firmware CRC in firmware\n"); return ret; } - calculated_crc = crc_ccitt_false(0, data, size - sizeof(u16)); + calculated_crc = crc_itu_t(0, data, size - sizeof(u16)); if (read_crc != calculated_crc) { phydev_err(phydev, "bad firmware CRC: file 0x%04x calculated 0x%04x\n", read_crc, calculated_crc); -- 2.43.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Dec 21, 2023 at 01:09:46PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/net/phy/aquantia/aquantia_firmware.c: In function 'aqr_fw_load_memory': > drivers/net/phy/aquantia/aquantia_firmware.c:135:23: error: implicit declaration of function 'crc_ccitt_false'; did you mean 'crc_ccitt_byte'? [-Werror=implicit-function-declaration] > 135 | crc = crc_ccitt_false(crc, crc_data, sizeof(crc_data)); > | ^~~~~~~~~~~~~~~ > | crc_ccitt_byte > > Caused by commit > > e93984ebc1c8 ("net: phy: aquantia: add firmware load support") > > interacting with commit > > 56ded2dd1a43 ("lib: crc_ccitt_false() is identical to crc_itu_t()") > > from the mm tree. > > I have applied the following merge fix patch: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Thu, 21 Dec 2023 12:49:11 +1100 > Subject: [PATCH] fix up for "net: phy: aquantia: add firmware load support" > > interacting with commit > > 56ded2dd1a43 ("lib: crc_ccitt_false() is identical to crc_itu_t()") > > from the mm tree. > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Thanks can confirm the conversion is correct. > --- > drivers/net/phy/aquantia/Kconfig | 2 +- > drivers/net/phy/aquantia/aquantia_firmware.c | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/phy/aquantia/Kconfig b/drivers/net/phy/aquantia/Kconfig > index a35de4b9b554..1a65678583cf 100644 > --- a/drivers/net/phy/aquantia/Kconfig > +++ b/drivers/net/phy/aquantia/Kconfig > @@ -1,6 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0-only > config AQUANTIA_PHY > tristate "Aquantia PHYs" > - select CRC_CCITT > + select CRC_ITU_T > help > Currently supports the Aquantia AQ1202, AQ2104, AQR105, AQR405 > diff --git a/drivers/net/phy/aquantia/aquantia_firmware.c b/drivers/net/phy/aquantia/aquantia_firmware.c > index ff34d00d5a0e..0c9640ef153b 100644 > --- a/drivers/net/phy/aquantia/aquantia_firmware.c > +++ b/drivers/net/phy/aquantia/aquantia_firmware.c > @@ -3,7 +3,7 @@ > #include <linux/bitfield.h> > #include <linux/of.h> > #include <linux/firmware.h> > -#include <linux/crc-ccitt.h> > +#include <linux/crc-itu-t.h> > #include <linux/nvmem-consumer.h> > > #include <asm/unaligned.h> > @@ -132,7 +132,7 @@ static int aqr_fw_load_memory(struct phy_device *phydev, u32 addr, > crc_data[3] = word; > > /* ...calculate CRC as we load data... */ > - crc = crc_ccitt_false(crc, crc_data, sizeof(crc_data)); > + crc = crc_itu_t(crc, crc_data, sizeof(crc_data)); > } > /* ...gets CRC from MAILBOX after we have loaded the entire section... */ > up_crc = phy_read_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE2); > @@ -164,7 +164,7 @@ static int aqr_fw_boot(struct phy_device *phydev, const u8 *data, size_t size, > phydev_err(phydev, "bad firmware CRC in firmware\n"); > return ret; > } > - calculated_crc = crc_ccitt_false(0, data, size - sizeof(u16)); > + calculated_crc = crc_itu_t(0, data, size - sizeof(u16)); > if (read_crc != calculated_crc) { > phydev_err(phydev, "bad firmware CRC: file 0x%04x calculated 0x%04x\n", > read_crc, calculated_crc); > -- > 2.43.0 > > -- > Cheers, > Stephen Rothwell -- Ansuel
On Thu, 21 Dec 2023 13:09:46 +1100 Stephen Rothwell wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 21 Dec 2023 12:49:11 +1100
> Subject: [PATCH] fix up for "net: phy: aquantia: add firmware load support"
>
> interacting with commit
>
> 56ded2dd1a43 ("lib: crc_ccitt_false() is identical to crc_itu_t()")
>
> from the mm tree.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied to net-next with a massaged commit msg, thanks!
[-- Attachment #1: Type: text/plain, Size: 2076 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: In file included from <command-line>: In function 'tcp_struct_check', inlined from 'tcp_init' at net/ipv4/tcp.c:4700:2: include/linux/compiler_types.h:442:45: error: call to '__compiletime_assert_940' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct tcp_sock, __cacheline_group_end__tcp_sock_write_rx) - offsetofend(struct tcp_sock, __cacheline_group_begin__tcp_sock_write_rx) > 99 442 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ include/linux/compiler_types.h:423:25: note: in definition of macro '__compiletime_assert' 423 | prefix ## suffix(); \ | ^~~~~~ include/linux/compiler_types.h:442:9: note: in expansion of macro '_compiletime_assert' 442 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~~~~~~~~~~~~~ include/linux/cache.h:108:9: note: in expansion of macro 'BUILD_BUG_ON' 108 | BUILD_BUG_ON(offsetof(TYPE, __cacheline_group_end__##GROUP) - \ | ^~~~~~~~~~~~ net/ipv4/tcp.c:4687:9: note: in expansion of macro 'CACHELINE_ASSERT_GROUP_SIZE' 4687 | CACHELINE_ASSERT_GROUP_SIZE(struct tcp_sock, tcp_sock_write_rx, 99); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Caused by commit 99123622050f ("tcp: remove some holes in struct tcp_sock") I have reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, Mar 1, 2024 at 2:11 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from <command-line>:
> In function 'tcp_struct_check',
> inlined from 'tcp_init' at net/ipv4/tcp.c:4700:2:
> include/linux/compiler_types.h:442:45: error: call to '__compiletime_assert_940' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct tcp_sock, __cacheline_group_end__tcp_sock_write_rx) - offsetofend(struct tcp_sock, __cacheline_group_begin__tcp_sock_write_rx) > 99
> 442 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> | ^
> include/linux/compiler_types.h:423:25: note: in definition of macro '__compiletime_assert'
> 423 | prefix ## suffix(); \
> | ^~~~~~
> include/linux/compiler_types.h:442:9: note: in expansion of macro '_compiletime_assert'
> 442 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> | ^~~~~~~~~~~~~~~~~~~
> include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
> 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> | ^~~~~~~~~~~~~~~~~~
> include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
> 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> | ^~~~~~~~~~~~~~~~
> include/linux/cache.h:108:9: note: in expansion of macro 'BUILD_BUG_ON'
> 108 | BUILD_BUG_ON(offsetof(TYPE, __cacheline_group_end__##GROUP) - \
> | ^~~~~~~~~~~~
> net/ipv4/tcp.c:4687:9: note: in expansion of macro 'CACHELINE_ASSERT_GROUP_SIZE'
> 4687 | CACHELINE_ASSERT_GROUP_SIZE(struct tcp_sock, tcp_sock_write_rx, 99);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
> 99123622050f ("tcp: remove some holes in struct tcp_sock")
>
> I have reverted that commit for today.
>
I have no idea. Maybe this arch has some unusual alignments on
u64/u32/u16 fields ?
The patch should not have changed tcp_sock_write_rx group...
My patch reduced tcp_sock_write_tx on x86_64 from 113 to 105 bytes but
I did not bother changing the assert,
because the assertion triggers if the size of the group is bigger than
the numerical value.
So I could have added the following, but really did not bother.
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index c82dc42f57c65df112f79080ff407cd98d11ce68..7e1b848398d04f2da2a91c3af97b1e2e3895b8ee
100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -4651,7 +4651,7 @@ static void __init tcp_struct_check(void)
CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock,
tcp_sock_write_tx, tsorted_sent_queue);
CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock,
tcp_sock_write_tx, highest_sack);
CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock,
tcp_sock_write_tx, ecn_flags);
- CACHELINE_ASSERT_GROUP_SIZE(struct tcp_sock, tcp_sock_write_tx, 113);
+ CACHELINE_ASSERT_GROUP_SIZE(struct tcp_sock, tcp_sock_write_tx, 105);
/* TXRX read-write hotpath cache lines */
CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock,
tcp_sock_write_txrx, pred_flags);
On Fri, Mar 1, 2024 at 10:09 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Fri, Mar 1, 2024 at 2:11 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > In file included from <command-line>:
> > In function 'tcp_struct_check',
> > inlined from 'tcp_init' at net/ipv4/tcp.c:4700:2:
> > include/linux/compiler_types.h:442:45: error: call to '__compiletime_assert_940' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct tcp_sock, __cacheline_group_end__tcp_sock_write_rx) - offsetofend(struct tcp_sock, __cacheline_group_begin__tcp_sock_write_rx) > 99
> > 442 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > | ^
> > include/linux/compiler_types.h:423:25: note: in definition of macro '__compiletime_assert'
> > 423 | prefix ## suffix(); \
> > | ^~~~~~
> > include/linux/compiler_types.h:442:9: note: in expansion of macro '_compiletime_assert'
> > 442 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > | ^~~~~~~~~~~~~~~~~~~
> > include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
> > 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> > | ^~~~~~~~~~~~~~~~~~
> > include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
> > 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> > | ^~~~~~~~~~~~~~~~
> > include/linux/cache.h:108:9: note: in expansion of macro 'BUILD_BUG_ON'
> > 108 | BUILD_BUG_ON(offsetof(TYPE, __cacheline_group_end__##GROUP) - \
> > | ^~~~~~~~~~~~
> > net/ipv4/tcp.c:4687:9: note: in expansion of macro 'CACHELINE_ASSERT_GROUP_SIZE'
> > 4687 | CACHELINE_ASSERT_GROUP_SIZE(struct tcp_sock, tcp_sock_write_rx, 99);
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Caused by commit
> >
> > 99123622050f ("tcp: remove some holes in struct tcp_sock")
> >
> > I have reverted that commit for today.
> >
>
> I have no idea. Maybe this arch has some unusual alignments on
> u64/u32/u16 fields ?
>
> The patch should not have changed tcp_sock_write_rx group...
>
> My patch reduced tcp_sock_write_tx on x86_64 from 113 to 105 bytes but
> I did not bother changing the assert,
> because the assertion triggers if the size of the group is bigger than
> the numerical value.
>
OK, I think the issue is caused by a hole at the start of
tcp_sock_write_rx group
I will send this patch for review, thanks !
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 988a30ef6bfe956fa573f1f18c8284aa382dc1cc..55399ee2a57e736b55ed067fc06ea620bbe62fd3
100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -304,7 +304,7 @@ struct tcp_sock {
__cacheline_group_end(tcp_sock_write_txrx);
/* RX read-write hotpath cache lines */
- __cacheline_group_begin(tcp_sock_write_rx);
+ __cacheline_group_begin(tcp_sock_write_rx) __aligned(8);
u64 bytes_received;
/* RFC4898 tcpEStatsAppHCThruOctetsReceived
* sum(delta(rcv_nxt)), or how many bytes
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index c82dc42f57c65df112f79080ff407cd98d11ce68..7e1b848398d04f2da2a91c3af97b1e2e3895b8ee
100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -4651,7 +4651,7 @@ static void __init tcp_struct_check(void)
CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock,
tcp_sock_write_tx, tsorted_sent_queue);
CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock,
tcp_sock_write_tx, highest_sack);
CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock,
tcp_sock_write_tx, ecn_flags);
- CACHELINE_ASSERT_GROUP_SIZE(struct tcp_sock, tcp_sock_write_tx, 113);
+ CACHELINE_ASSERT_GROUP_SIZE(struct tcp_sock, tcp_sock_write_tx, 105);
/* TXRX read-write hotpath cache lines */
CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock,
tcp_sock_write_txrx, pred_flags);
[-- Attachment #1: Type: text/plain, Size: 1909 bytes --] Hi Eric, On Fri, 1 Mar 2024 10:54:19 +0100 Eric Dumazet <edumazet@google.com> wrote: > > OK, I think the issue is caused by a hole at the start of > tcp_sock_write_rx group > > I will send this patch for review, thanks ! > > diff --git a/include/linux/tcp.h b/include/linux/tcp.h > index 988a30ef6bfe956fa573f1f18c8284aa382dc1cc..55399ee2a57e736b55ed067fc06ea620bbe62fd3 > 100644 > --- a/include/linux/tcp.h > +++ b/include/linux/tcp.h > @@ -304,7 +304,7 @@ struct tcp_sock { > __cacheline_group_end(tcp_sock_write_txrx); > > /* RX read-write hotpath cache lines */ > - __cacheline_group_begin(tcp_sock_write_rx); > + __cacheline_group_begin(tcp_sock_write_rx) __aligned(8); > u64 bytes_received; > /* RFC4898 tcpEStatsAppHCThruOctetsReceived > * sum(delta(rcv_nxt)), or how many bytes > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c > index c82dc42f57c65df112f79080ff407cd98d11ce68..7e1b848398d04f2da2a91c3af97b1e2e3895b8ee > 100644 > --- a/net/ipv4/tcp.c > +++ b/net/ipv4/tcp.c > @@ -4651,7 +4651,7 @@ static void __init tcp_struct_check(void) > CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock, > tcp_sock_write_tx, tsorted_sent_queue); > CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock, > tcp_sock_write_tx, highest_sack); > CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock, > tcp_sock_write_tx, ecn_flags); > - CACHELINE_ASSERT_GROUP_SIZE(struct tcp_sock, tcp_sock_write_tx, 113); > + CACHELINE_ASSERT_GROUP_SIZE(struct tcp_sock, tcp_sock_write_tx, 105); > > /* TXRX read-write hotpath cache lines */ > CACHELINE_ASSERT_GROUP_MEMBER(struct tcp_sock, > tcp_sock_write_txrx, pred_flags); I will apply this patch to them merge of the net-next tree until it is applied there. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]