* Re: [PATCH bpf] selftests/bpf: fix sendmsg6_prog on s390
From: Daniel Borkmann @ 2019-07-22 14:23 UTC (permalink / raw)
To: Ilya Leoshkevich, bpf, netdev; +Cc: gor, heiko.carstens, rdna
In-Reply-To: <20190719090611.91743-1-iii@linux.ibm.com>
On 7/19/19 11:06 AM, Ilya Leoshkevich wrote:
> "sendmsg6: rewrite IP & port (C)" fails on s390, because the code in
> sendmsg_v6_prog() assumes that (ctx->user_ip6[0] & 0xFFFF) refers to
> leading IPv6 address digits, which is not the case on big-endian
> machines.
>
> Since checking bitwise operations doesn't seem to be the point of the
> test, replace two short comparisons with a single int comparison.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Applied, thanks!
^ permalink raw reply
* Re: [GIT PULL 0/2] libbpf build fixes
From: Daniel Borkmann @ 2019-07-22 14:23 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Alexei Starovoitov
Cc: Clark Williams, bpf, netdev, Adrian Hunter, Andrii Nakryiko,
Ingo Molnar, Jiri Olsa, Namhyung Kim
In-Reply-To: <20190719143407.20847-1-acme@kernel.org>
On 7/19/19 4:34 PM, Arnaldo Carvalho de Melo wrote:
> Hi Daniel,
>
> Please consider pulling or applying from the patches, if someone
> has any issues, please holler,
>
> - Arnaldo
>
> Arnaldo Carvalho de Melo (2):
> libbpf: Fix endianness macro usage for some compilers
> libbpf: Avoid designated initializers for unnamed union members
>
> tools/lib/bpf/btf.c | 5 +++--
> tools/lib/bpf/libbpf.c | 19 ++++++++++---------
> 2 files changed, 13 insertions(+), 11 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf v4 00/14] sockmap/tls fixes
From: Daniel Borkmann @ 2019-07-22 14:22 UTC (permalink / raw)
To: Jakub Kicinski, john.fastabend, alexei.starovoitov
Cc: edumazet, netdev, bpf, oss-drivers
In-Reply-To: <20190719103721.558d9e7d@cakuba.netronome.com>
On 7/19/19 7:37 PM, Jakub Kicinski wrote:
> On Fri, 19 Jul 2019 10:29:13 -0700, Jakub Kicinski wrote:
>> John says:
>>
>> Resolve a series of splats discovered by syzbot and an unhash
>> TLS issue noted by Eric Dumazet.
>
> Sorry for the delay, this code is quite tricky. According to my testing
> TLS SW and HW should now work, I hope I didn't regress things on the
> sockmap side.
Applied, thanks everyone!
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Andrew Lunn @ 2019-07-22 14:19 UTC (permalink / raw)
To: Jose Abreu
Cc: Ondřej Jirman, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue, Russell King,
Florian Fainelli, Heiner Kallweit
In-Reply-To: <BN8PR12MB3266678A3ABD0EBF429C9766D3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
On Mon, Jul 22, 2019 at 01:58:20PM +0000, Jose Abreu wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Jul/22/2019, 14:40:23 (UTC+00:00)
>
> > Does this mean that all stmmac variants support 1G? There are none
> > which just support Fast Ethernet?
>
> This glue logic drivers sometimes reflect a custom IP that's Synopsys
> based but modified by customer, so I can't know before-hand what's the
> supported max speed. There are some old versions that don't support 1G
> but I expect that PHY driver limits this ...
If a Fast PHY is used, then yes, it would be limited. But sometimes a
1G PHY is used because they are cheaper than a Fast PHY.
> > I'm also not sure the change fits the problem. Why did it not
> > negotiate 100FULL rather than 10Half? You are only moving the 1G
> > speeds around, so 100 speeds should of been advertised and selected.
>
> Hmm, now that I'm looking at it closer I agree with you. Maybe link
> partner or PHY doesn't support 100M ?
In the working case, ethtool shows the link partner supports 10, 100,
and 1G. So something odd is going on here.
You fix does seems reasonable, and it has been reported to fix the
issue, but it would be good to understand what is going on here.
Andrew
^ permalink raw reply
* [PATCH net] net: stmmac: Do not cut down 1G modes
From: Jose Abreu @ 2019-07-22 14:07 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel, Ondrej Jirman
Some glue logic drivers support 1G without having GMAC/GMAC4/XGMAC.
Let's allow this speed by default.
Reported-by: Ondrej Jirman <megi@xff.cz>
Tested-by: Ondrej Jirman <megi@xff.cz>
Fixes: 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: Ondrej Jirman <megi@xff.cz>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 207c3755bcc5..b0d5e5346597 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -814,20 +814,15 @@ static void stmmac_validate(struct phylink_config *config,
phylink_set(mac_supported, 10baseT_Full);
phylink_set(mac_supported, 100baseT_Half);
phylink_set(mac_supported, 100baseT_Full);
+ phylink_set(mac_supported, 1000baseT_Half);
+ phylink_set(mac_supported, 1000baseT_Full);
+ phylink_set(mac_supported, 1000baseKX_Full);
phylink_set(mac_supported, Autoneg);
phylink_set(mac_supported, Pause);
phylink_set(mac_supported, Asym_Pause);
phylink_set_port_modes(mac_supported);
- if (priv->plat->has_gmac ||
- priv->plat->has_gmac4 ||
- priv->plat->has_xgmac) {
- phylink_set(mac_supported, 1000baseT_Half);
- phylink_set(mac_supported, 1000baseT_Full);
- phylink_set(mac_supported, 1000baseKX_Full);
- }
-
/* Cut down 1G if asked to */
if ((max_speed > 0) && (max_speed < 1000)) {
phylink_set(mask, 1000baseT_Full);
--
2.7.4
^ permalink raw reply related
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-22 14:04 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, Lars Persson, Ilias Apalodimas
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai, linux-tegra
In-Reply-To: <11557fe0-0cba-cb49-0fb6-ad24792d4a53@nvidia.com>
From: Jon Hunter <jonathanh@nvidia.com>
Date: Jul/22/2019, 13:05:38 (UTC+00:00)
>
> On 22/07/2019 12:39, Jose Abreu wrote:
> > From: Lars Persson <lists@bofh.nu>
> > Date: Jul/22/2019, 12:11:50 (UTC+00:00)
> >
> >> On Mon, Jul 22, 2019 at 12:18 PM Ilias Apalodimas
> >> <ilias.apalodimas@linaro.org> wrote:
> >>>
> >>> On Thu, Jul 18, 2019 at 07:48:04AM +0000, Jose Abreu wrote:
> >>>> From: Jon Hunter <jonathanh@nvidia.com>
> >>>> Date: Jul/17/2019, 19:58:53 (UTC+00:00)
> >>>>
> >>>>> Let me know if you have any thoughts.
> >>>>
> >>>> Can you try attached patch ?
> >>>>
> >>>
> >>> The log says someone calls panic() right?
> >>> Can we trye and figure were that happens during the stmmac init phase?
> >>>
> >>
> >> The reason for the panic is hidden in this one line of the kernel logs:
> >> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> >>
> >> The init process is killed by SIGSEGV (signal 11 = 0xb).
> >>
> >> I would suggest you look for data corruption bugs in the RX path. If
> >> the code is fetched from the NFS mount then a corrupt RX buffer can
> >> trigger a crash in userspace.
> >>
> >> /Lars
> >
> >
> > Jon, I'm not familiar with ARM. Are the buffer addresses being allocated
> > in a coherent region ? Can you try attached patch which adds full memory
> > barrier before the sync ?
>
> TBH I am not sure about the buffer addresses either. The attached patch
> did not help. Same problem persists.
OK. I'm just guessing now at this stage but can you disable SMP ?
We have to narrow down if this is coherency issue but you said that
booting without NFS and then mounting manually the share works ... So,
can you share logs with same debug prints in this condition in order to
compare ?
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Jose Abreu @ 2019-07-22 13:58 UTC (permalink / raw)
To: Andrew Lunn, Jose Abreu
Cc: Ondřej Jirman, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue, Russell King,
Florian Fainelli, Heiner Kallweit
In-Reply-To: <20190722134023.GD8972@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Jul/22/2019, 14:40:23 (UTC+00:00)
> Does this mean that all stmmac variants support 1G? There are none
> which just support Fast Ethernet?
This glue logic drivers sometimes reflect a custom IP that's Synopsys
based but modified by customer, so I can't know before-hand what's the
supported max speed. There are some old versions that don't support 1G
but I expect that PHY driver limits this ...
> I'm also not sure the change fits the problem. Why did it not
> negotiate 100FULL rather than 10Half? You are only moving the 1G
> speeds around, so 100 speeds should of been advertised and selected.
Hmm, now that I'm looking at it closer I agree with you. Maybe link
partner or PHY doesn't support 100M ?
It's working for Ondrej but I got curious now ...
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Ondřej Jirman @ 2019-07-22 13:49 UTC (permalink / raw)
To: Jose Abreu
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Russell King, Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <BN8PR12MB32660B12F8E2617ED42249BBD3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 8335 bytes --]
On Mon, Jul 22, 2019 at 01:28:51PM +0000, Jose Abreu wrote:
> From: Ondřej Jirman <megi@xff.cz>
> Date: Jul/22/2019, 13:42:40 (UTC+00:00)
>
> > Hello Jose,
> >
> > On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> > > [ Hope this diff looks better (generated with --minimal) ]
> > >
> > > This converts stmmac to use phylink. Besides the code redution this will
> > > allow to gain more flexibility.
> >
> > I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
> > 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.
> >
> > After going through stmmac patches since 5.2, I think it may be realted to this
> > series, but I'm not completely sure. You'll probably have a better understanding
> > of the changes. Do you have an idea what might be wrong? Please, see some logs
> > below.
>
> Probably due to:
> 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
>
> Can you try attached patch ?
Tried, and it works!
dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062ff advertising 00,00000000,000062ff
dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0 an=1
dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/1Gbps/Full
dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Tested-by: Ondrej Jirman <megi@xff.cz>
thank you,
Ondrej
>
> >
> > thank you and regards,
> > Ondrej
> >
> > On 5.3-rc1 I see:
> >
> > [ 6.116512] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
> > [ 6.116522] dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062cf advertising 00,00000000,000062cf
> > [ 6.118714] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> > [ 6.118725] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> > [ 6.118730] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> > [ 6.118738] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
> > [ 6.118747] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062cf pause=10 link=0 an=1
> > [ 6.126099] dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
> > [ 6.276325] random: crng init done
> > [ 6.276338] random: 7 urandom warning(s) missed due to ratelimiting
> > [ 7.543987] zram0: detected capacity change from 0 to 402653184
> > [ 7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 across:393212k SS
> >
> > ... delay due to other causes ...
> >
> > [ 28.640234] dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/10Mbps/Full
> > [ 28.640295] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/10Mbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> > [ 28.640324] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx
> >
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > Supported pause frame use: Symmetric Receive-only
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > Advertised pause frame use: Symmetric Receive-only
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > Link partner advertised pause frame use: Symmetric Receive-only
> > Link partner advertised auto-negotiation: Yes
> > Link partner advertised FEC modes: Not reported
> > Speed: 10Mb/s
> > Duplex: Full
> > Port: MII
> > PHYAD: 1
> > Transceiver: internal
> > Auto-negotiation: on
> > Supports Wake-on: d
> > Wake-on: d
> > Current message level: 0x0000003f (63)
> > drv probe link timer ifdown ifup
> > Link detected: yes
> >
> > On 5.2 it looks like this:
> >
> > [ 1.153596] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> > [ 1.416221] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> > [ 1.522735] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
> > [ 1.522750] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
> > [ 1.522753] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
> > [ 1.522755] dwmac-sun8i 5020000.ethernet: COE Type 2
> > [ 1.522758] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
> > [ 1.522761] dwmac-sun8i 5020000.ethernet: Normal descriptors
> > [ 1.522763] dwmac-sun8i 5020000.ethernet: Chain mode enabled
> > [ 5.352833] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> > [ 5.352842] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> > [ 5.352846] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> > [ 10.463072] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> >
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Half 1000baseT/Full
> > Supported pause frame use: Symmetric Receive-only
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Half 1000baseT/Full
> > Advertised pause frame use: No
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Link partner advertised pause frame use: Symmetric Receive-only
> > Link partner advertised auto-negotiation: Yes
> > Link partner advertised FEC modes: Not reported
> > Speed: 1000Mb/s
> > Duplex: Full
> > Port: MII
> > PHYAD: 1
> > Transceiver: internal
> > Auto-negotiation: on
> > Supports Wake-on: d
> > Wake-on: d
> > Current message level: 0x0000003f (63)
> > drv probe link timer ifdown ifup
> > Link detected: yes
> >
> >
> > > Cc: Joao Pinto <jpinto@synopsys.com>
> > > Cc: David S. Miller <davem@davemloft.net>
> > > Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> > > Cc: Alexandre Torgue <alexandre.torgue@st.com>
> > > Cc: Russell King <linux@armlinux.org.uk>
> > > Cc: Andrew Lunn <andrew@lunn.ch>
> > > Cc: Florian Fainelli <f.fainelli@gmail.com>
> > > Cc: Heiner Kallweit <hkallweit1@gmail.com>
> > >
> > > Jose Abreu (3):
> > > net: stmmac: Prepare to convert to phylink
> > > net: stmmac: Start adding phylink support
> > > net: stmmac: Convert to phylink and remove phylib logic
> > >
> > > drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +-
> > > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +-
> > > .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
> > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 ++++++++----------
> > > .../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
> > > 5 files changed, 190 insertions(+), 313 deletions(-)
> > >
> > > --
> > > 2.21.0
> > >
>
>
> ---
> Thanks,
> Jose Miguel Abreu
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH glibc] Linux: Include <linux/sockios.h> in <bits/socket.h> under __USE_MISC
From: Szabolcs Nagy @ 2019-07-22 13:47 UTC (permalink / raw)
To: Florian Weimer
Cc: nd, Arnd Bergmann, GNU C Library, Sergei Trofimovich, Networking,
Linux Kernel Mailing List, David S. Miller, Michael Kerrisk,
linux-man
In-Reply-To: <87lfwqqj3s.fsf@oldenburg2.str.redhat.com>
On 22/07/2019 14:44, Florian Weimer wrote:
> * Szabolcs Nagy:
>
>> (note: in musl these ioctl macros are in sys/ioctl.h
>> which is not a posix header so namespace rules are
>> less strict than for sys/socket.h and users tend to
>> include it for ioctl())
>
> <sys/ioctl.h> can be confusing because some of the constants may depend
> on types that aren't declared by including the header. This makes their
> macros unusable. Defining ioctl constants in headers which also provide
> the matching types avoids that problem at least, also it can introduce
> namespace issues.
yeah, the way we deal with that is we hard code the numbers
since the size of struct is abi, they cannot change.
^ permalink raw reply
* Re: [PATCH glibc] Linux: Include <linux/sockios.h> in <bits/socket.h> under __USE_MISC
From: Florian Weimer @ 2019-07-22 13:44 UTC (permalink / raw)
To: Szabolcs Nagy
Cc: Arnd Bergmann, nd, GNU C Library, Sergei Trofimovich, Networking,
Linux Kernel Mailing List, David S. Miller, Michael Kerrisk,
linux-man
In-Reply-To: <2431941f-3aac-d31f-e6f5-8ed2ed7b2e5c@arm.com>
* Szabolcs Nagy:
> (note: in musl these ioctl macros are in sys/ioctl.h
> which is not a posix header so namespace rules are
> less strict than for sys/socket.h and users tend to
> include it for ioctl())
<sys/ioctl.h> can be confusing because some of the constants may depend
on types that aren't declared by including the header. This makes their
macros unusable. Defining ioctl constants in headers which also provide
the matching types avoids that problem at least, also it can introduce
namespace issues.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH glibc] Linux: Include <linux/sockios.h> in <bits/socket.h> under __USE_MISC
From: Szabolcs Nagy @ 2019-07-22 13:41 UTC (permalink / raw)
To: Arnd Bergmann, Florian Weimer
Cc: nd, GNU C Library, Sergei Trofimovich, Networking,
Linux Kernel Mailing List, David S. Miller, Michael Kerrisk,
linux-man
In-Reply-To: <CAK8P3a0hC4wvjwCi4=DCET3C4qARMY6c58ffjwG3b1ZPM6kr-A@mail.gmail.com>
On 22/07/2019 12:34, Arnd Bergmann wrote:
> On Mon, Jul 22, 2019 at 1:31 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> Historically, <asm/socket.h> (which is included from <bits/socket.h>)
>> provided ioctl operations for sockets. User code accessed them
>> through <sys/socket.h>. The kernel UAPI headers have removed these
>> definitions in favor of <linux/sockios.h>. This commit makes them
>> available via <sys/socket.h> again.
>
> Looks good to me.
>
> I wonder if we should still do these two changes in the kernel:
>
> - include asm/socket.h from linux/socket.h for consistency
> - move the defines that got moved from asm/sockios.h to linux/sockios.h
> back to the previous location to help anyone who is user
> newer kernel headers with older glibc headers.
does user code actually expect these in sys/socket.h
or in asm/socket.h ?
man 7 socket
mentions SIOCGSTAMP but does not say the header.
man 2 ioctl_list
specifies include/asm-i386/socket.h as the location.
if user code tends to directly include asm/socket.h
then i think it's better to undo the kernel header
change than to put things in sys/socket.h.
(note: in musl these ioctl macros are in sys/ioctl.h
which is not a posix header so namespace rules are
less strict than for sys/socket.h and users tend to
include it for ioctl())
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Andrew Lunn @ 2019-07-22 13:40 UTC (permalink / raw)
To: Jose Abreu
Cc: Ondřej Jirman, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue, Russell King,
Florian Fainelli, Heiner Kallweit
In-Reply-To: <BN8PR12MB32660B12F8E2617ED42249BBD3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
On Mon, Jul 22, 2019 at 01:28:51PM +0000, Jose Abreu wrote:
> From: Ondřej Jirman <megi@xff.cz>
> Date: Jul/22/2019, 13:42:40 (UTC+00:00)
>
> > Hello Jose,
> >
> > On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> > > [ Hope this diff looks better (generated with --minimal) ]
> > >
> > > This converts stmmac to use phylink. Besides the code redution this will
> > > allow to gain more flexibility.
> >
> > I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
> > 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.
> >
> > After going through stmmac patches since 5.2, I think it may be realted to this
> > series, but I'm not completely sure. You'll probably have a better understanding
> > of the changes. Do you have an idea what might be wrong? Please, see some logs
> > below.
>
> Probably due to:
> 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
>
> Can you try attached patch ?
>
Hi Jose
Does this mean that all stmmac variants support 1G? There are none
which just support Fast Ethernet?
I'm also not sure the change fits the problem. Why did it not
negotiate 100FULL rather than 10Half? You are only moving the 1G
speeds around, so 100 speeds should of been advertised and selected.
Thanks
Andrew
^ permalink raw reply
* RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Jose Abreu @ 2019-07-22 13:28 UTC (permalink / raw)
To: Ondřej Jirman, Jose Abreu
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Russell King, Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <20190722124240.464e73losonwb356@core.my.home>
[-- Attachment #1: Type: text/plain, Size: 6856 bytes --]
From: Ondřej Jirman <megi@xff.cz>
Date: Jul/22/2019, 13:42:40 (UTC+00:00)
> Hello Jose,
>
> On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> > [ Hope this diff looks better (generated with --minimal) ]
> >
> > This converts stmmac to use phylink. Besides the code redution this will
> > allow to gain more flexibility.
>
> I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
> 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.
>
> After going through stmmac patches since 5.2, I think it may be realted to this
> series, but I'm not completely sure. You'll probably have a better understanding
> of the changes. Do you have an idea what might be wrong? Please, see some logs
> below.
Probably due to:
5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
Can you try attached patch ?
>
> thank you and regards,
> Ondrej
>
> On 5.3-rc1 I see:
>
> [ 6.116512] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
> [ 6.116522] dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062cf advertising 00,00000000,000062cf
> [ 6.118714] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> [ 6.118725] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> [ 6.118730] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> [ 6.118738] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
> [ 6.118747] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062cf pause=10 link=0 an=1
> [ 6.126099] dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
> [ 6.276325] random: crng init done
> [ 6.276338] random: 7 urandom warning(s) missed due to ratelimiting
> [ 7.543987] zram0: detected capacity change from 0 to 402653184
> [ 7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 across:393212k SS
>
> ... delay due to other causes ...
>
> [ 28.640234] dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/10Mbps/Full
> [ 28.640295] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/10Mbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> [ 28.640324] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx
>
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Advertised pause frame use: Symmetric Receive-only
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> Link partner advertised pause frame use: Symmetric Receive-only
> Link partner advertised auto-negotiation: Yes
> Link partner advertised FEC modes: Not reported
> Speed: 10Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: d
> Wake-on: d
> Current message level: 0x0000003f (63)
> drv probe link timer ifdown ifup
> Link detected: yes
>
> On 5.2 it looks like this:
>
> [ 1.153596] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> [ 1.416221] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> [ 1.522735] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
> [ 1.522750] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
> [ 1.522753] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
> [ 1.522755] dwmac-sun8i 5020000.ethernet: COE Type 2
> [ 1.522758] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
> [ 1.522761] dwmac-sun8i 5020000.ethernet: Normal descriptors
> [ 1.522763] dwmac-sun8i 5020000.ethernet: Chain mode enabled
> [ 5.352833] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> [ 5.352842] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> [ 5.352846] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> [ 10.463072] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Link partner advertised pause frame use: Symmetric Receive-only
> Link partner advertised auto-negotiation: Yes
> Link partner advertised FEC modes: Not reported
> Speed: 1000Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: d
> Wake-on: d
> Current message level: 0x0000003f (63)
> drv probe link timer ifdown ifup
> Link detected: yes
>
>
> > Cc: Joao Pinto <jpinto@synopsys.com>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> > Cc: Alexandre Torgue <alexandre.torgue@st.com>
> > Cc: Russell King <linux@armlinux.org.uk>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Florian Fainelli <f.fainelli@gmail.com>
> > Cc: Heiner Kallweit <hkallweit1@gmail.com>
> >
> > Jose Abreu (3):
> > net: stmmac: Prepare to convert to phylink
> > net: stmmac: Start adding phylink support
> > net: stmmac: Convert to phylink and remove phylib logic
> >
> > drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +-
> > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +-
> > .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
> > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 ++++++++----------
> > .../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
> > 5 files changed, 190 insertions(+), 313 deletions(-)
> >
> > --
> > 2.21.0
> >
---
Thanks,
Jose Miguel Abreu
[-- Attachment #2: 0001-net-stmmac-Do-not-cut-down-1G-modes.patch --]
[-- Type: application/octet-stream, Size: 2316 bytes --]
From 6e94caa3b518735c8c637d58ef76cb1aabac6e09 Mon Sep 17 00:00:00 2001
Message-Id: <6e94caa3b518735c8c637d58ef76cb1aabac6e09.1563802080.git.joabreu@synopsys.com>
From: Jose Abreu <joabreu@synopsys.com>
Date: Mon, 22 Jul 2019 15:26:15 +0200
Subject: [PATCH net] net: stmmac: Do not cut down 1G modes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Some glue logic drivers support 1G without having GMAC/GMAC4/XGMAC.
Let's allow this speed by default.
Reported-by: Ondřej Jirman <megi@xff.cz>
Fixes: 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 207c3755bcc5..b0d5e5346597 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -814,20 +814,15 @@ static void stmmac_validate(struct phylink_config *config,
phylink_set(mac_supported, 10baseT_Full);
phylink_set(mac_supported, 100baseT_Half);
phylink_set(mac_supported, 100baseT_Full);
+ phylink_set(mac_supported, 1000baseT_Half);
+ phylink_set(mac_supported, 1000baseT_Full);
+ phylink_set(mac_supported, 1000baseKX_Full);
phylink_set(mac_supported, Autoneg);
phylink_set(mac_supported, Pause);
phylink_set(mac_supported, Asym_Pause);
phylink_set_port_modes(mac_supported);
- if (priv->plat->has_gmac ||
- priv->plat->has_gmac4 ||
- priv->plat->has_xgmac) {
- phylink_set(mac_supported, 1000baseT_Half);
- phylink_set(mac_supported, 1000baseT_Full);
- phylink_set(mac_supported, 1000baseKX_Full);
- }
-
/* Cut down 1G if asked to */
if ((max_speed > 0) && (max_speed < 1000)) {
phylink_set(mask, 1000baseT_Full);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] netfilter: ebtables: compat: fix a memory leak bug
From: Wenwen Wang @ 2019-07-22 12:53 UTC (permalink / raw)
To: Liam R. Howlett
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Roopa Prabhu, Nikolay Aleksandrov, David S. Miller,
open list:NETFILTER, open list:NETFILTER,
moderated list:ETHERNET BRIDGE, open list:ETHERNET BRIDGE,
open list, Wenwen Wang
In-Reply-To: <20190722123204.rvsqlqgynfgjcif7@oracle.com>
On Mon, Jul 22, 2019 at 7:34 AM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>
> Nice catch. The code that exists is confusing due to newinfo->entries
> being overwritten and then freed in the existing code path as you state
> in your commit log.
>
> * Wenwen Wang <wang6495@umn.edu> [190720 08:23]:
> > From: Wenwen Wang <wenwen@cs.uga.edu>
> >
> > In compat_do_replace(), a temporary buffer is allocated through vmalloc()
> > to hold entries copied from the user space. The buffer address is firstly
> > saved to 'newinfo->entries', and later on assigned to 'entries_tmp'. Then
> > the entries in this temporary buffer is copied to the internal kernel
> > structure through compat_copy_entries(). If this copy process fails,
> > compat_do_replace() should be terminated. However, the allocated temporary
> > buffer is not freed on this path, leading to a memory leak.
> >
> > To fix the bug, free the buffer before returning from compat_do_replace().
> >
> > Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
> > ---
> > net/bridge/netfilter/ebtables.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
> > index 963dfdc..fd84b48e 100644
> > --- a/net/bridge/netfilter/ebtables.c
> > +++ b/net/bridge/netfilter/ebtables.c
> > @@ -2261,8 +2261,10 @@ static int compat_do_replace(struct net *net, void __user *user,
> > state.buf_kern_len = size64;
> >
> > ret = compat_copy_entries(entries_tmp, tmp.entries_size, &state);
> > - if (WARN_ON(ret < 0))
> > + if (WARN_ON(ret < 0)) {
> > + vfree(entries_tmp);
> > goto out_unlock;
> > + }
>
>
> Would it be worth adding a new goto label above out_unlock and free this
> entries_tmp? It could then be used in previous failure path as well.
Yes, that would make the code much clearer and easier to understand.
Thanks!
Wenwen
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Ondřej Jirman @ 2019-07-22 12:42 UTC (permalink / raw)
To: Jose Abreu
Cc: linux-kernel, netdev, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue, Russell King, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
In-Reply-To: <cover.1560266175.git.joabreu@synopsys.com>
[-- Attachment #1: Type: text/plain, Size: 6329 bytes --]
Hello Jose,
On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> [ Hope this diff looks better (generated with --minimal) ]
>
> This converts stmmac to use phylink. Besides the code redution this will
> allow to gain more flexibility.
I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.
After going through stmmac patches since 5.2, I think it may be realted to this
series, but I'm not completely sure. You'll probably have a better understanding
of the changes. Do you have an idea what might be wrong? Please, see some logs
below.
thank you and regards,
Ondrej
On 5.3-rc1 I see:
[ 6.116512] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
[ 6.116522] dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062cf advertising 00,00000000,000062cf
[ 6.118714] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
[ 6.118725] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
[ 6.118730] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
[ 6.118738] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
[ 6.118747] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062cf pause=10 link=0 an=1
[ 6.126099] dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
[ 6.276325] random: crng init done
[ 6.276338] random: 7 urandom warning(s) missed due to ratelimiting
[ 7.543987] zram0: detected capacity change from 0 to 402653184
[ 7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 across:393212k SS
... delay due to other causes ...
[ 28.640234] dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/10Mbps/Full
[ 28.640295] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/10Mbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
[ 28.640324] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes
On 5.2 it looks like this:
[ 1.153596] dwmac-sun8i 5020000.ethernet: PTP uses main clock
[ 1.416221] dwmac-sun8i 5020000.ethernet: PTP uses main clock
[ 1.522735] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
[ 1.522750] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
[ 1.522753] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
[ 1.522755] dwmac-sun8i 5020000.ethernet: COE Type 2
[ 1.522758] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
[ 1.522761] dwmac-sun8i 5020000.ethernet: Normal descriptors
[ 1.522763] dwmac-sun8i 5020000.ethernet: Chain mode enabled
[ 5.352833] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
[ 5.352842] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
[ 5.352846] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
[ 10.463072] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
>
> Jose Abreu (3):
> net: stmmac: Prepare to convert to phylink
> net: stmmac: Start adding phylink support
> net: stmmac: Convert to phylink and remove phylib logic
>
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +-
> .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 ++++++++----------
> .../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
> 5 files changed, 190 insertions(+), 313 deletions(-)
>
> --
> 2.21.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] netfilter: ebtables: compat: fix a memory leak bug
From: Liam R. Howlett @ 2019-07-22 12:32 UTC (permalink / raw)
To: Wenwen Wang
Cc: Wenwen Wang, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Roopa Prabhu, Nikolay Aleksandrov,
David S. Miller, open list:NETFILTER, open list:NETFILTER,
moderated list:ETHERNET BRIDGE, open list:ETHERNET BRIDGE,
open list
In-Reply-To: <1563625366-3602-1-git-send-email-wang6495@umn.edu>
Nice catch. The code that exists is confusing due to newinfo->entries
being overwritten and then freed in the existing code path as you state
in your commit log.
* Wenwen Wang <wang6495@umn.edu> [190720 08:23]:
> From: Wenwen Wang <wenwen@cs.uga.edu>
>
> In compat_do_replace(), a temporary buffer is allocated through vmalloc()
> to hold entries copied from the user space. The buffer address is firstly
> saved to 'newinfo->entries', and later on assigned to 'entries_tmp'. Then
> the entries in this temporary buffer is copied to the internal kernel
> structure through compat_copy_entries(). If this copy process fails,
> compat_do_replace() should be terminated. However, the allocated temporary
> buffer is not freed on this path, leading to a memory leak.
>
> To fix the bug, free the buffer before returning from compat_do_replace().
>
> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
> ---
> net/bridge/netfilter/ebtables.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
> index 963dfdc..fd84b48e 100644
> --- a/net/bridge/netfilter/ebtables.c
> +++ b/net/bridge/netfilter/ebtables.c
> @@ -2261,8 +2261,10 @@ static int compat_do_replace(struct net *net, void __user *user,
> state.buf_kern_len = size64;
>
> ret = compat_copy_entries(entries_tmp, tmp.entries_size, &state);
> - if (WARN_ON(ret < 0))
> + if (WARN_ON(ret < 0)) {
> + vfree(entries_tmp);
> goto out_unlock;
> + }
Would it be worth adding a new goto label above out_unlock and free this
entries_tmp? It could then be used in previous failure path as well.
Thanks,
Liam
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jon Hunter @ 2019-07-22 12:05 UTC (permalink / raw)
To: Jose Abreu, Lars Persson, Ilias Apalodimas
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai, linux-tegra
In-Reply-To: <BN8PR12MB326661846D53AAEE315A7434D3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
On 22/07/2019 12:39, Jose Abreu wrote:
> From: Lars Persson <lists@bofh.nu>
> Date: Jul/22/2019, 12:11:50 (UTC+00:00)
>
>> On Mon, Jul 22, 2019 at 12:18 PM Ilias Apalodimas
>> <ilias.apalodimas@linaro.org> wrote:
>>>
>>> On Thu, Jul 18, 2019 at 07:48:04AM +0000, Jose Abreu wrote:
>>>> From: Jon Hunter <jonathanh@nvidia.com>
>>>> Date: Jul/17/2019, 19:58:53 (UTC+00:00)
>>>>
>>>>> Let me know if you have any thoughts.
>>>>
>>>> Can you try attached patch ?
>>>>
>>>
>>> The log says someone calls panic() right?
>>> Can we trye and figure were that happens during the stmmac init phase?
>>>
>>
>> The reason for the panic is hidden in this one line of the kernel logs:
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>>
>> The init process is killed by SIGSEGV (signal 11 = 0xb).
>>
>> I would suggest you look for data corruption bugs in the RX path. If
>> the code is fetched from the NFS mount then a corrupt RX buffer can
>> trigger a crash in userspace.
>>
>> /Lars
>
>
> Jon, I'm not familiar with ARM. Are the buffer addresses being allocated
> in a coherent region ? Can you try attached patch which adds full memory
> barrier before the sync ?
TBH I am not sure about the buffer addresses either. The attached patch
did not help. Same problem persists.
Jon
--
nvpublic
^ permalink raw reply
* [PATCH bpf-next v4 2/6] xdp: Refactor devmap allocation code for reuse
From: Toke Høiland-Jørgensen @ 2019-07-22 11:52 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, David Miller, Jesper Dangaard Brouer,
Jakub Kicinski, Björn Töpel, Yonghong Song
In-Reply-To: <156379636786.12332.17776973951938230698.stgit@alrua-x1>
From: Toke Høiland-Jørgensen <toke@redhat.com>
The subsequent patch to add a new devmap sub-type can re-use much of the
initialisation and allocation code, so refactor it into separate functions.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
kernel/bpf/devmap.c | 136 +++++++++++++++++++++++++++++++--------------------
1 file changed, 83 insertions(+), 53 deletions(-)
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index d83cf8ccc872..a0501266bdb8 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -60,9 +60,9 @@ struct xdp_bulk_queue {
struct bpf_dtab_netdev {
struct net_device *dev; /* must be first member, due to tracepoint */
struct bpf_dtab *dtab;
- unsigned int bit;
struct xdp_bulk_queue __percpu *bulkq;
struct rcu_head rcu;
+ unsigned int idx; /* keep track of map index for tracepoint */
};
struct bpf_dtab {
@@ -75,28 +75,21 @@ struct bpf_dtab {
static DEFINE_SPINLOCK(dev_map_lock);
static LIST_HEAD(dev_map_list);
-static struct bpf_map *dev_map_alloc(union bpf_attr *attr)
+static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
{
- struct bpf_dtab *dtab;
int err, cpu;
u64 cost;
- if (!capable(CAP_NET_ADMIN))
- return ERR_PTR(-EPERM);
-
/* check sanity of attributes */
if (attr->max_entries == 0 || attr->key_size != 4 ||
attr->value_size != 4 || attr->map_flags & ~DEV_CREATE_FLAG_MASK)
- return ERR_PTR(-EINVAL);
+ return -EINVAL;
/* Lookup returns a pointer straight to dev->ifindex, so make sure the
* verifier prevents writes from the BPF side
*/
attr->map_flags |= BPF_F_RDONLY_PROG;
- dtab = kzalloc(sizeof(*dtab), GFP_USER);
- if (!dtab)
- return ERR_PTR(-ENOMEM);
bpf_map_init_from_attr(&dtab->map, attr);
@@ -107,9 +100,7 @@ static struct bpf_map *dev_map_alloc(union bpf_attr *attr)
/* if map size is larger than memlock limit, reject it */
err = bpf_map_charge_init(&dtab->map.memory, cost);
if (err)
- goto free_dtab;
-
- err = -ENOMEM;
+ return -EINVAL;
dtab->flush_list = alloc_percpu(struct list_head);
if (!dtab->flush_list)
@@ -124,19 +115,38 @@ static struct bpf_map *dev_map_alloc(union bpf_attr *attr)
if (!dtab->netdev_map)
goto free_percpu;
- spin_lock(&dev_map_lock);
- list_add_tail_rcu(&dtab->list, &dev_map_list);
- spin_unlock(&dev_map_lock);
-
- return &dtab->map;
+ return 0;
free_percpu:
free_percpu(dtab->flush_list);
free_charge:
bpf_map_charge_finish(&dtab->map.memory);
-free_dtab:
- kfree(dtab);
- return ERR_PTR(err);
+ return -ENOMEM;
+}
+
+static struct bpf_map *dev_map_alloc(union bpf_attr *attr)
+{
+ struct bpf_dtab *dtab;
+ int err;
+
+ if (!capable(CAP_NET_ADMIN))
+ return ERR_PTR(-EPERM);
+
+ dtab = kzalloc(sizeof(*dtab), GFP_USER);
+ if (!dtab)
+ return ERR_PTR(-ENOMEM);
+
+ err = dev_map_init_map(dtab, attr);
+ if (err) {
+ kfree(dtab);
+ return ERR_PTR(err);
+ }
+
+ spin_lock(&dev_map_lock);
+ list_add_tail_rcu(&dtab->list, &dev_map_list);
+ spin_unlock(&dev_map_lock);
+
+ return &dtab->map;
}
static void dev_map_free(struct bpf_map *map)
@@ -235,7 +245,7 @@ static int bq_xmit_all(struct xdp_bulk_queue *bq, u32 flags,
out:
bq->count = 0;
- trace_xdp_devmap_xmit(&obj->dtab->map, obj->bit,
+ trace_xdp_devmap_xmit(&obj->dtab->map, obj->idx,
sent, drops, bq->dev_rx, dev, err);
bq->dev_rx = NULL;
__list_del_clearprev(&bq->flush_node);
@@ -412,17 +422,52 @@ static int dev_map_delete_elem(struct bpf_map *map, void *key)
return 0;
}
-static int dev_map_update_elem(struct bpf_map *map, void *key, void *value,
- u64 map_flags)
+static struct bpf_dtab_netdev *__dev_map_alloc_node(struct net *net,
+ struct bpf_dtab *dtab,
+ u32 ifindex,
+ unsigned int idx)
{
- struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
- struct net *net = current->nsproxy->net_ns;
gfp_t gfp = GFP_ATOMIC | __GFP_NOWARN;
+ struct bpf_dtab_netdev *dev;
+ struct xdp_bulk_queue *bq;
+ int cpu;
+
+ dev = kmalloc_node(sizeof(*dev), gfp, dtab->map.numa_node);
+ if (!dev)
+ return ERR_PTR(-ENOMEM);
+
+ dev->bulkq = __alloc_percpu_gfp(sizeof(*dev->bulkq),
+ sizeof(void *), gfp);
+ if (!dev->bulkq) {
+ kfree(dev);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ for_each_possible_cpu(cpu) {
+ bq = per_cpu_ptr(dev->bulkq, cpu);
+ bq->obj = dev;
+ }
+
+ dev->dev = dev_get_by_index(net, ifindex);
+ if (!dev->dev) {
+ free_percpu(dev->bulkq);
+ kfree(dev);
+ return ERR_PTR(-EINVAL);
+ }
+
+ dev->idx = idx;
+ dev->dtab = dtab;
+
+ return dev;
+}
+
+static int __dev_map_update_elem(struct net *net, struct bpf_map *map,
+ void *key, void *value, u64 map_flags)
+{
+ struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
struct bpf_dtab_netdev *dev, *old_dev;
u32 ifindex = *(u32 *)value;
- struct xdp_bulk_queue *bq;
u32 i = *(u32 *)key;
- int cpu;
if (unlikely(map_flags > BPF_EXIST))
return -EINVAL;
@@ -434,31 +479,9 @@ static int dev_map_update_elem(struct bpf_map *map, void *key, void *value,
if (!ifindex) {
dev = NULL;
} else {
- dev = kmalloc_node(sizeof(*dev), gfp, map->numa_node);
- if (!dev)
- return -ENOMEM;
-
- dev->bulkq = __alloc_percpu_gfp(sizeof(*dev->bulkq),
- sizeof(void *), gfp);
- if (!dev->bulkq) {
- kfree(dev);
- return -ENOMEM;
- }
-
- for_each_possible_cpu(cpu) {
- bq = per_cpu_ptr(dev->bulkq, cpu);
- bq->obj = dev;
- }
-
- dev->dev = dev_get_by_index(net, ifindex);
- if (!dev->dev) {
- free_percpu(dev->bulkq);
- kfree(dev);
- return -EINVAL;
- }
-
- dev->bit = i;
- dev->dtab = dtab;
+ dev = __dev_map_alloc_node(net, dtab, ifindex, i);
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
}
/* Use call_rcu() here to ensure rcu critical sections have completed
@@ -472,6 +495,13 @@ static int dev_map_update_elem(struct bpf_map *map, void *key, void *value,
return 0;
}
+static int dev_map_update_elem(struct bpf_map *map, void *key, void *value,
+ u64 map_flags)
+{
+ return __dev_map_update_elem(current->nsproxy->net_ns,
+ map, key, value, map_flags);
+}
+
const struct bpf_map_ops dev_map_ops = {
.map_alloc = dev_map_alloc,
.map_free = dev_map_free,
^ permalink raw reply related
* [PATCH bpf-next v4 6/6] tools: Add definitions for devmap_hash map type
From: Toke Høiland-Jørgensen @ 2019-07-22 11:52 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, David Miller, Jesper Dangaard Brouer,
Jakub Kicinski, Björn Töpel, Yonghong Song
In-Reply-To: <156379636786.12332.17776973951938230698.stgit@alrua-x1>
From: Toke Høiland-Jørgensen <toke@redhat.com>
This adds selftest and bpftool updates for the devmap_hash map type.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
---
tools/bpf/bpftool/Documentation/bpftool-map.rst | 2 +-
tools/bpf/bpftool/bash-completion/bpftool | 4 ++--
tools/bpf/bpftool/map.c | 3 ++-
tools/testing/selftests/bpf/test_maps.c | 16 ++++++++++++++++
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/tools/bpf/bpftool/Documentation/bpftool-map.rst b/tools/bpf/bpftool/Documentation/bpftool-map.rst
index 490b4501cb6e..61d1d270eb5e 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-map.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-map.rst
@@ -46,7 +46,7 @@ MAP COMMANDS
| *TYPE* := { **hash** | **array** | **prog_array** | **perf_event_array** | **percpu_hash**
| | **percpu_array** | **stack_trace** | **cgroup_array** | **lru_hash**
| | **lru_percpu_hash** | **lpm_trie** | **array_of_maps** | **hash_of_maps**
-| | **devmap** | **sockmap** | **cpumap** | **xskmap** | **sockhash**
+| | **devmap** | **devmap_hash** | **sockmap** | **cpumap** | **xskmap** | **sockhash**
| | **cgroup_storage** | **reuseport_sockarray** | **percpu_cgroup_storage**
| | **queue** | **stack** }
diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
index c8f42e1fcbc9..6b961a5ed100 100644
--- a/tools/bpf/bpftool/bash-completion/bpftool
+++ b/tools/bpf/bpftool/bash-completion/bpftool
@@ -489,8 +489,8 @@ _bpftool()
perf_event_array percpu_hash percpu_array \
stack_trace cgroup_array lru_hash \
lru_percpu_hash lpm_trie array_of_maps \
- hash_of_maps devmap sockmap cpumap xskmap \
- sockhash cgroup_storage reuseport_sockarray \
+ hash_of_maps devmap devmap_hash sockmap cpumap \
+ xskmap sockhash cgroup_storage reuseport_sockarray \
percpu_cgroup_storage queue stack' -- \
"$cur" ) )
return 0
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index 5da5a7311f13..bfbbc6b4cb83 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -37,6 +37,7 @@ const char * const map_type_name[] = {
[BPF_MAP_TYPE_ARRAY_OF_MAPS] = "array_of_maps",
[BPF_MAP_TYPE_HASH_OF_MAPS] = "hash_of_maps",
[BPF_MAP_TYPE_DEVMAP] = "devmap",
+ [BPF_MAP_TYPE_DEVMAP_HASH] = "devmap_hash",
[BPF_MAP_TYPE_SOCKMAP] = "sockmap",
[BPF_MAP_TYPE_CPUMAP] = "cpumap",
[BPF_MAP_TYPE_XSKMAP] = "xskmap",
@@ -1271,7 +1272,7 @@ static int do_help(int argc, char **argv)
" TYPE := { hash | array | prog_array | perf_event_array | percpu_hash |\n"
" percpu_array | stack_trace | cgroup_array | lru_hash |\n"
" lru_percpu_hash | lpm_trie | array_of_maps | hash_of_maps |\n"
- " devmap | sockmap | cpumap | xskmap | sockhash |\n"
+ " devmap | devmap_hash | sockmap | cpumap | xskmap | sockhash |\n"
" cgroup_storage | reuseport_sockarray | percpu_cgroup_storage }\n"
" " HELP_SPEC_OPTIONS "\n"
"",
diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
index 5443b9bd75ed..e1f1becda529 100644
--- a/tools/testing/selftests/bpf/test_maps.c
+++ b/tools/testing/selftests/bpf/test_maps.c
@@ -508,6 +508,21 @@ static void test_devmap(unsigned int task, void *data)
close(fd);
}
+static void test_devmap_hash(unsigned int task, void *data)
+{
+ int fd;
+ __u32 key, value;
+
+ fd = bpf_create_map(BPF_MAP_TYPE_DEVMAP_HASH, sizeof(key), sizeof(value),
+ 2, 0);
+ if (fd < 0) {
+ printf("Failed to create devmap_hash '%s'!\n", strerror(errno));
+ exit(1);
+ }
+
+ close(fd);
+}
+
static void test_queuemap(unsigned int task, void *data)
{
const int MAP_SIZE = 32;
@@ -1684,6 +1699,7 @@ static void run_all_tests(void)
test_arraymap_percpu_many_keys();
test_devmap(0, NULL);
+ test_devmap_hash(0, NULL);
test_sockmap(0, NULL);
test_map_large();
^ permalink raw reply related
* [PATCH bpf-next v4 5/6] tools/libbpf_probes: Add new devmap_hash type
From: Toke Høiland-Jørgensen @ 2019-07-22 11:52 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, David Miller, Jesper Dangaard Brouer,
Jakub Kicinski, Björn Töpel, Yonghong Song
In-Reply-To: <156379636786.12332.17776973951938230698.stgit@alrua-x1>
From: Toke Høiland-Jørgensen <toke@redhat.com>
This adds the definition for BPF_MAP_TYPE_DEVMAP_HASH to libbpf_probes.c in
tools/lib/bpf.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
tools/lib/bpf/libbpf_probes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/lib/bpf/libbpf_probes.c b/tools/lib/bpf/libbpf_probes.c
index ace1a0708d99..4b0b0364f5fc 100644
--- a/tools/lib/bpf/libbpf_probes.c
+++ b/tools/lib/bpf/libbpf_probes.c
@@ -244,6 +244,7 @@ bool bpf_probe_map_type(enum bpf_map_type map_type, __u32 ifindex)
case BPF_MAP_TYPE_ARRAY_OF_MAPS:
case BPF_MAP_TYPE_HASH_OF_MAPS:
case BPF_MAP_TYPE_DEVMAP:
+ case BPF_MAP_TYPE_DEVMAP_HASH:
case BPF_MAP_TYPE_SOCKMAP:
case BPF_MAP_TYPE_CPUMAP:
case BPF_MAP_TYPE_XSKMAP:
^ permalink raw reply related
* [PATCH bpf-next v4 3/6] xdp: Add devmap_hash map type for looking up devices by hashed index
From: Toke Høiland-Jørgensen @ 2019-07-22 11:52 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, David Miller, Jesper Dangaard Brouer,
Jakub Kicinski, Björn Töpel, Yonghong Song
In-Reply-To: <156379636786.12332.17776973951938230698.stgit@alrua-x1>
From: Toke Høiland-Jørgensen <toke@redhat.com>
A common pattern when using xdp_redirect_map() is to create a device map
where the lookup key is simply ifindex. Because device maps are arrays,
this leaves holes in the map, and the map has to be sized to fit the
largest ifindex, regardless of how many devices actually are actually
needed in the map.
This patch adds a second type of device map where the key is looked up
using a hashmap, instead of being used as an array index. This allows maps
to be densely packed, so they can be smaller.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
include/linux/bpf.h | 7 ++
include/linux/bpf_types.h | 1
include/trace/events/xdp.h | 3 -
include/uapi/linux/bpf.h | 1
kernel/bpf/devmap.c | 194 ++++++++++++++++++++++++++++++++++++++++++++
kernel/bpf/verifier.c | 2
net/core/filter.c | 9 ++
7 files changed, 214 insertions(+), 3 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index bfdb54dd2ad1..f9a506147c8a 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -713,6 +713,7 @@ struct xdp_buff;
struct sk_buff;
struct bpf_dtab_netdev *__dev_map_lookup_elem(struct bpf_map *map, u32 key);
+struct bpf_dtab_netdev *__dev_map_hash_lookup_elem(struct bpf_map *map, u32 key);
void __dev_map_flush(struct bpf_map *map);
int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp,
struct net_device *dev_rx);
@@ -799,6 +800,12 @@ static inline struct net_device *__dev_map_lookup_elem(struct bpf_map *map,
return NULL;
}
+static inline struct net_device *__dev_map_hash_lookup_elem(struct bpf_map *map,
+ u32 key)
+{
+ return NULL;
+}
+
static inline void __dev_map_flush(struct bpf_map *map)
{
}
diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
index eec5aeeeaf92..36a9c2325176 100644
--- a/include/linux/bpf_types.h
+++ b/include/linux/bpf_types.h
@@ -62,6 +62,7 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_ARRAY_OF_MAPS, array_of_maps_map_ops)
BPF_MAP_TYPE(BPF_MAP_TYPE_HASH_OF_MAPS, htab_of_maps_map_ops)
#ifdef CONFIG_NET
BPF_MAP_TYPE(BPF_MAP_TYPE_DEVMAP, dev_map_ops)
+BPF_MAP_TYPE(BPF_MAP_TYPE_DEVMAP_HASH, dev_map_hash_ops)
BPF_MAP_TYPE(BPF_MAP_TYPE_SK_STORAGE, sk_storage_map_ops)
#if defined(CONFIG_BPF_STREAM_PARSER)
BPF_MAP_TYPE(BPF_MAP_TYPE_SOCKMAP, sock_map_ops)
diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index 68899fdc985b..8c8420230a10 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -175,7 +175,8 @@ struct _bpf_dtab_netdev {
#endif /* __DEVMAP_OBJ_TYPE */
#define devmap_ifindex(fwd, map) \
- ((map->map_type == BPF_MAP_TYPE_DEVMAP) ? \
+ ((map->map_type == BPF_MAP_TYPE_DEVMAP || \
+ map->map_type == BPF_MAP_TYPE_DEVMAP_HASH) ? \
((struct _bpf_dtab_netdev *)fwd)->dev->ifindex : 0)
#define _trace_xdp_redirect_map(dev, xdp, fwd, map, idx) \
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 6f68438aa4ed..e6767020ebba 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -134,6 +134,7 @@ enum bpf_map_type {
BPF_MAP_TYPE_QUEUE,
BPF_MAP_TYPE_STACK,
BPF_MAP_TYPE_SK_STORAGE,
+ BPF_MAP_TYPE_DEVMAP_HASH,
};
/* Note that tracing related programs such as
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index a0501266bdb8..b47a604b4936 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -37,6 +37,12 @@
* notifier hook walks the map we know that new dev references can not be
* added by the user because core infrastructure ensures dev_get_by_index()
* calls will fail at this point.
+ *
+ * The devmap_hash type is a map type which interprets keys as ifindexes and
+ * indexes these using a hashmap. This allows maps that use ifindex as key to be
+ * densely packed instead of having holes in the lookup array for unused
+ * ifindexes. The setup and packet enqueue/send code is shared between the two
+ * types of devmap; only the lookup and insertion is different.
*/
#include <linux/bpf.h>
#include <net/xdp.h>
@@ -59,6 +65,7 @@ struct xdp_bulk_queue {
struct bpf_dtab_netdev {
struct net_device *dev; /* must be first member, due to tracepoint */
+ struct hlist_node index_hlist;
struct bpf_dtab *dtab;
struct xdp_bulk_queue __percpu *bulkq;
struct rcu_head rcu;
@@ -70,11 +77,29 @@ struct bpf_dtab {
struct bpf_dtab_netdev **netdev_map;
struct list_head __percpu *flush_list;
struct list_head list;
+
+ /* these are only used for DEVMAP_HASH type maps */
+ struct hlist_head *dev_index_head;
+ spinlock_t index_lock;
+ unsigned int items;
};
static DEFINE_SPINLOCK(dev_map_lock);
static LIST_HEAD(dev_map_list);
+static struct hlist_head *dev_map_create_hash(void)
+{
+ int i;
+ struct hlist_head *hash;
+
+ hash = kmalloc_array(NETDEV_HASHENTRIES, sizeof(*hash), GFP_KERNEL);
+ if (hash != NULL)
+ for (i = 0; i < NETDEV_HASHENTRIES; i++)
+ INIT_HLIST_HEAD(&hash[i]);
+
+ return hash;
+}
+
static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
{
int err, cpu;
@@ -97,6 +122,9 @@ static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
cost = (u64) dtab->map.max_entries * sizeof(struct bpf_dtab_netdev *);
cost += sizeof(struct list_head) * num_possible_cpus();
+ if (attr->map_type == BPF_MAP_TYPE_DEVMAP_HASH)
+ cost += sizeof(struct hlist_head) * NETDEV_HASHENTRIES;
+
/* if map size is larger than memlock limit, reject it */
err = bpf_map_charge_init(&dtab->map.memory, cost);
if (err)
@@ -115,8 +143,18 @@ static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
if (!dtab->netdev_map)
goto free_percpu;
+ if (attr->map_type == BPF_MAP_TYPE_DEVMAP_HASH) {
+ dtab->dev_index_head = dev_map_create_hash();
+ if (!dtab->dev_index_head)
+ goto free_map_area;
+
+ spin_lock_init(&dtab->index_lock);
+ }
+
return 0;
+free_map_area:
+ bpf_map_area_free(dtab->netdev_map);
free_percpu:
free_percpu(dtab->flush_list);
free_charge:
@@ -198,6 +236,7 @@ static void dev_map_free(struct bpf_map *map)
free_percpu(dtab->flush_list);
bpf_map_area_free(dtab->netdev_map);
+ kfree(dtab->dev_index_head);
kfree(dtab);
}
@@ -218,6 +257,70 @@ static int dev_map_get_next_key(struct bpf_map *map, void *key, void *next_key)
return 0;
}
+static inline struct hlist_head *dev_map_index_hash(struct bpf_dtab *dtab,
+ int idx)
+{
+ return &dtab->dev_index_head[idx & (NETDEV_HASHENTRIES - 1)];
+}
+
+struct bpf_dtab_netdev *__dev_map_hash_lookup_elem(struct bpf_map *map, u32 key)
+{
+ struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
+ struct hlist_head *head = dev_map_index_hash(dtab, key);
+ struct bpf_dtab_netdev *dev;
+
+ hlist_for_each_entry_rcu(dev, head, index_hlist)
+ if (dev->idx == key)
+ return dev;
+
+ return NULL;
+}
+
+static int dev_map_hash_get_next_key(struct bpf_map *map, void *key,
+ void *next_key)
+{
+ struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
+ u32 idx, *next = next_key;
+ struct bpf_dtab_netdev *dev, *next_dev;
+ struct hlist_head *head;
+ int i = 0;
+
+ if (!key)
+ goto find_first;
+
+ idx = *(u32 *)key;
+
+ dev = __dev_map_hash_lookup_elem(map, idx);
+ if (!dev)
+ goto find_first;
+
+ next_dev = hlist_entry_safe(rcu_dereference_raw(hlist_next_rcu(&dev->index_hlist)),
+ struct bpf_dtab_netdev, index_hlist);
+
+ if (next_dev) {
+ *next = next_dev->idx;
+ return 0;
+ }
+
+ i = idx & (NETDEV_HASHENTRIES - 1);
+ i++;
+
+ find_first:
+ for (; i < NETDEV_HASHENTRIES; i++) {
+ head = dev_map_index_hash(dtab, i);
+
+ next_dev = hlist_entry_safe(rcu_dereference_raw(hlist_first_rcu(head)),
+ struct bpf_dtab_netdev,
+ index_hlist);
+ if (next_dev) {
+ *next = next_dev->idx;
+ return 0;
+ }
+ }
+
+ return -ENOENT;
+}
+
static int bq_xmit_all(struct xdp_bulk_queue *bq, u32 flags,
bool in_napi_ctx)
{
@@ -373,6 +476,15 @@ static void *dev_map_lookup_elem(struct bpf_map *map, void *key)
return dev ? &dev->ifindex : NULL;
}
+static void *dev_map_hash_lookup_elem(struct bpf_map *map, void *key)
+{
+ struct bpf_dtab_netdev *obj = __dev_map_hash_lookup_elem(map,
+ *(u32 *)key);
+ struct net_device *dev = obj ? obj->dev : NULL;
+
+ return dev ? &dev->ifindex : NULL;
+}
+
static void dev_map_flush_old(struct bpf_dtab_netdev *dev)
{
if (dev->dev->netdev_ops->ndo_xdp_xmit) {
@@ -422,6 +534,28 @@ static int dev_map_delete_elem(struct bpf_map *map, void *key)
return 0;
}
+static int dev_map_hash_delete_elem(struct bpf_map *map, void *key)
+{
+ struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
+ struct bpf_dtab_netdev *old_dev;
+ int k = *(u32 *)key;
+ unsigned long flags;
+ int ret = -ENOENT;
+
+ spin_lock_irqsave(&dtab->index_lock, flags);
+
+ old_dev = __dev_map_hash_lookup_elem(map, k);
+ if (old_dev) {
+ dtab->items--;
+ hlist_del_init_rcu(&old_dev->index_hlist);
+ call_rcu(&old_dev->rcu, __dev_map_entry_free);
+ ret = 0;
+ }
+ spin_unlock_irqrestore(&dtab->index_lock, flags);
+
+ return ret;
+}
+
static struct bpf_dtab_netdev *__dev_map_alloc_node(struct net *net,
struct bpf_dtab *dtab,
u32 ifindex,
@@ -502,6 +636,56 @@ static int dev_map_update_elem(struct bpf_map *map, void *key, void *value,
map, key, value, map_flags);
}
+static int __dev_map_hash_update_elem(struct net *net, struct bpf_map *map,
+ void *key, void *value, u64 map_flags)
+{
+ struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
+ struct bpf_dtab_netdev *dev, *old_dev;
+ u32 ifindex = *(u32 *)value;
+ u32 idx = *(u32 *)key;
+ unsigned long flags;
+
+ if (unlikely(map_flags > BPF_EXIST || !ifindex))
+ return -EINVAL;
+
+ old_dev = __dev_map_hash_lookup_elem(map, idx);
+ if (old_dev && (map_flags & BPF_NOEXIST))
+ return -EEXIST;
+
+ dev = __dev_map_alloc_node(net, dtab, ifindex, idx);
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
+
+ spin_lock_irqsave(&dtab->index_lock, flags);
+
+ if (old_dev) {
+ hlist_del_rcu(&old_dev->index_hlist);
+ } else {
+ if (dtab->items >= dtab->map.max_entries) {
+ spin_unlock_irqrestore(&dtab->index_lock, flags);
+ call_rcu(&dev->rcu, __dev_map_entry_free);
+ return -E2BIG;
+ }
+ dtab->items++;
+ }
+
+ hlist_add_head_rcu(&dev->index_hlist,
+ dev_map_index_hash(dtab, idx));
+ spin_unlock_irqrestore(&dtab->index_lock, flags);
+
+ if (old_dev)
+ call_rcu(&old_dev->rcu, __dev_map_entry_free);
+
+ return 0;
+}
+
+static int dev_map_hash_update_elem(struct bpf_map *map, void *key, void *value,
+ u64 map_flags)
+{
+ return __dev_map_hash_update_elem(current->nsproxy->net_ns,
+ map, key, value, map_flags);
+}
+
const struct bpf_map_ops dev_map_ops = {
.map_alloc = dev_map_alloc,
.map_free = dev_map_free,
@@ -512,6 +696,16 @@ const struct bpf_map_ops dev_map_ops = {
.map_check_btf = map_check_no_btf,
};
+const struct bpf_map_ops dev_map_hash_ops = {
+ .map_alloc = dev_map_alloc,
+ .map_free = dev_map_free,
+ .map_get_next_key = dev_map_hash_get_next_key,
+ .map_lookup_elem = dev_map_hash_lookup_elem,
+ .map_update_elem = dev_map_hash_update_elem,
+ .map_delete_elem = dev_map_hash_delete_elem,
+ .map_check_btf = map_check_no_btf,
+};
+
static int dev_map_notification(struct notifier_block *notifier,
ulong event, void *ptr)
{
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index a2e763703c30..231b9e22827c 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3460,6 +3460,7 @@ static int check_map_func_compatibility(struct bpf_verifier_env *env,
goto error;
break;
case BPF_MAP_TYPE_DEVMAP:
+ case BPF_MAP_TYPE_DEVMAP_HASH:
if (func_id != BPF_FUNC_redirect_map &&
func_id != BPF_FUNC_map_lookup_elem)
goto error;
@@ -3542,6 +3543,7 @@ static int check_map_func_compatibility(struct bpf_verifier_env *env,
break;
case BPF_FUNC_redirect_map:
if (map->map_type != BPF_MAP_TYPE_DEVMAP &&
+ map->map_type != BPF_MAP_TYPE_DEVMAP_HASH &&
map->map_type != BPF_MAP_TYPE_CPUMAP &&
map->map_type != BPF_MAP_TYPE_XSKMAP)
goto error;
diff --git a/net/core/filter.c b/net/core/filter.c
index 47f6386fb17a..619130b346af 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -3517,7 +3517,8 @@ static int __bpf_tx_xdp_map(struct net_device *dev_rx, void *fwd,
int err;
switch (map->map_type) {
- case BPF_MAP_TYPE_DEVMAP: {
+ case BPF_MAP_TYPE_DEVMAP:
+ case BPF_MAP_TYPE_DEVMAP_HASH: {
struct bpf_dtab_netdev *dst = fwd;
err = dev_map_enqueue(dst, xdp, dev_rx);
@@ -3554,6 +3555,7 @@ void xdp_do_flush_map(void)
if (map) {
switch (map->map_type) {
case BPF_MAP_TYPE_DEVMAP:
+ case BPF_MAP_TYPE_DEVMAP_HASH:
__dev_map_flush(map);
break;
case BPF_MAP_TYPE_CPUMAP:
@@ -3574,6 +3576,8 @@ static inline void *__xdp_map_lookup_elem(struct bpf_map *map, u32 index)
switch (map->map_type) {
case BPF_MAP_TYPE_DEVMAP:
return __dev_map_lookup_elem(map, index);
+ case BPF_MAP_TYPE_DEVMAP_HASH:
+ return __dev_map_hash_lookup_elem(map, index);
case BPF_MAP_TYPE_CPUMAP:
return __cpu_map_lookup_elem(map, index);
case BPF_MAP_TYPE_XSKMAP:
@@ -3655,7 +3659,8 @@ static int xdp_do_generic_redirect_map(struct net_device *dev,
ri->tgt_value = NULL;
WRITE_ONCE(ri->map, NULL);
- if (map->map_type == BPF_MAP_TYPE_DEVMAP) {
+ if (map->map_type == BPF_MAP_TYPE_DEVMAP ||
+ map->map_type == BPF_MAP_TYPE_DEVMAP_HASH) {
struct bpf_dtab_netdev *dst = fwd;
err = dev_map_generic_redirect(dst, skb, xdp_prog);
^ permalink raw reply related
* [PATCH bpf-next v4 4/6] tools/include/uapi: Add devmap_hash BPF map type
From: Toke Høiland-Jørgensen @ 2019-07-22 11:52 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, David Miller, Jesper Dangaard Brouer,
Jakub Kicinski, Björn Töpel, Yonghong Song
In-Reply-To: <156379636786.12332.17776973951938230698.stgit@alrua-x1>
From: Toke Høiland-Jørgensen <toke@redhat.com>
This adds the devmap_hash BPF map type to the uapi headers in tools/.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
tools/include/uapi/linux/bpf.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index f506c68b2612..f7eaec10e82e 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -134,6 +134,7 @@ enum bpf_map_type {
BPF_MAP_TYPE_QUEUE,
BPF_MAP_TYPE_STACK,
BPF_MAP_TYPE_SK_STORAGE,
+ BPF_MAP_TYPE_DEVMAP_HASH,
};
/* Note that tracing related programs such as
^ permalink raw reply related
* [PATCH bpf-next v4 1/6] include/bpf.h: Remove map_insert_ctx() stubs
From: Toke Høiland-Jørgensen @ 2019-07-22 11:52 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, David Miller, Jesper Dangaard Brouer,
Jakub Kicinski, Björn Töpel, Yonghong Song
In-Reply-To: <156379636786.12332.17776973951938230698.stgit@alrua-x1>
From: Toke Høiland-Jørgensen <toke@redhat.com>
When we changed the device and CPU maps to use linked lists instead of
bitmaps, we also removed the need for the map_insert_ctx() helpers to keep
track of the bitmaps inside each map. However, it seems I forgot to remove
the function definitions stubs, so remove those here.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
include/linux/bpf.h | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 18f4cc2c6acd..bfdb54dd2ad1 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -713,7 +713,6 @@ struct xdp_buff;
struct sk_buff;
struct bpf_dtab_netdev *__dev_map_lookup_elem(struct bpf_map *map, u32 key);
-void __dev_map_insert_ctx(struct bpf_map *map, u32 index);
void __dev_map_flush(struct bpf_map *map);
int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp,
struct net_device *dev_rx);
@@ -721,7 +720,6 @@ int dev_map_generic_redirect(struct bpf_dtab_netdev *dst, struct sk_buff *skb,
struct bpf_prog *xdp_prog);
struct bpf_cpu_map_entry *__cpu_map_lookup_elem(struct bpf_map *map, u32 key);
-void __cpu_map_insert_ctx(struct bpf_map *map, u32 index);
void __cpu_map_flush(struct bpf_map *map);
int cpu_map_enqueue(struct bpf_cpu_map_entry *rcpu, struct xdp_buff *xdp,
struct net_device *dev_rx);
@@ -801,10 +799,6 @@ static inline struct net_device *__dev_map_lookup_elem(struct bpf_map *map,
return NULL;
}
-static inline void __dev_map_insert_ctx(struct bpf_map *map, u32 index)
-{
-}
-
static inline void __dev_map_flush(struct bpf_map *map)
{
}
@@ -834,10 +828,6 @@ struct bpf_cpu_map_entry *__cpu_map_lookup_elem(struct bpf_map *map, u32 key)
return NULL;
}
-static inline void __cpu_map_insert_ctx(struct bpf_map *map, u32 index)
-{
-}
-
static inline void __cpu_map_flush(struct bpf_map *map)
{
}
^ permalink raw reply related
* [PATCH bpf-next v4 0/6] xdp: Add devmap_hash map type
From: Toke Høiland-Jørgensen @ 2019-07-22 11:52 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, David Miller, Jesper Dangaard Brouer,
Jakub Kicinski, Björn Töpel, Yonghong Song
This series adds a new map type, devmap_hash, that works like the existing
devmap type, but using a hash-based indexing scheme. This is useful for the use
case where a devmap is indexed by ifindex (for instance for use with the routing
table lookup helper). For this use case, the regular devmap needs to be sized
after the maximum ifindex number, not the number of devices in it. A hash-based
indexing scheme makes it possible to size the map after the number of devices it
should contain instead.
This was previously part of my patch series that also turned the regular
bpf_redirect() helper into a map-based one; for this series I just pulled out
the patches that introduced the new map type.
Changelog:
v4:
- Remove check_memlock parameter that was left over from an earlier patch
series.
- Reorder struct members to avoid holes.
v3:
- Rework the split into different patches
- Use spin_lock_irqsave()
- Also add documentation and bash completion definitions for bpftool
v2:
- Split commit adding the new map type so uapi and tools changes are separate.
Changes to these patches since the previous series:
- Rebase on top of the other devmap changes (makes this one simpler!)
- Don't enforce key==val, but allow arbitrary indexes.
- Rename the type to devmap_hash to reflect the fact that it's just a hashmap now.
---
Toke Høiland-Jørgensen (6):
include/bpf.h: Remove map_insert_ctx() stubs
xdp: Refactor devmap allocation code for reuse
xdp: Add devmap_hash map type for looking up devices by hashed index
tools/include/uapi: Add devmap_hash BPF map type
tools/libbpf_probes: Add new devmap_hash type
tools: Add definitions for devmap_hash map type
include/linux/bpf.h | 11 -
include/linux/bpf_types.h | 1
include/trace/events/xdp.h | 3
include/uapi/linux/bpf.h | 1
kernel/bpf/devmap.c | 326 +++++++++++++++++++----
kernel/bpf/verifier.c | 2
net/core/filter.c | 9 -
tools/bpf/bpftool/Documentation/bpftool-map.rst | 2
tools/bpf/bpftool/bash-completion/bpftool | 4
tools/bpf/bpftool/map.c | 3
tools/include/uapi/linux/bpf.h | 1
tools/lib/bpf/libbpf_probes.c | 1
tools/testing/selftests/bpf/test_maps.c | 16 +
13 files changed, 315 insertions(+), 65 deletions(-)
^ permalink raw reply
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-22 11:39 UTC (permalink / raw)
To: Lars Persson, Ilias Apalodimas, Jon Hunter
Cc: Jose Abreu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai, linux-tegra
In-Reply-To: <CADnJP=thexf2sWcVVOLWw14rpteEj0RrfDdY8ER90MpbNN4-oA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]
From: Lars Persson <lists@bofh.nu>
Date: Jul/22/2019, 12:11:50 (UTC+00:00)
> On Mon, Jul 22, 2019 at 12:18 PM Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > On Thu, Jul 18, 2019 at 07:48:04AM +0000, Jose Abreu wrote:
> > > From: Jon Hunter <jonathanh@nvidia.com>
> > > Date: Jul/17/2019, 19:58:53 (UTC+00:00)
> > >
> > > > Let me know if you have any thoughts.
> > >
> > > Can you try attached patch ?
> > >
> >
> > The log says someone calls panic() right?
> > Can we trye and figure were that happens during the stmmac init phase?
> >
>
> The reason for the panic is hidden in this one line of the kernel logs:
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> The init process is killed by SIGSEGV (signal 11 = 0xb).
>
> I would suggest you look for data corruption bugs in the RX path. If
> the code is fetched from the NFS mount then a corrupt RX buffer can
> trigger a crash in userspace.
>
> /Lars
Jon, I'm not familiar with ARM. Are the buffer addresses being allocated
in a coherent region ? Can you try attached patch which adds full memory
barrier before the sync ?
---
Thanks,
Jose Miguel Abreu
[-- Attachment #2: 0001-net-stmmac-Add-memory-barrier.patch --]
[-- Type: application/octet-stream, Size: 1397 bytes --]
From 1fe4964e832e32e2c5706a0ed174c9f8e0419efd Mon Sep 17 00:00:00 2001
Message-Id: <1fe4964e832e32e2c5706a0ed174c9f8e0419efd.1563795486.git.joabreu@synopsys.com>
From: Jose Abreu <joabreu@synopsys.com>
Date: Mon, 22 Jul 2019 13:37:51 +0200
Subject: [PATCH net] net: stmmac: Add memory barrier
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7a6920098dd0..207c3755bcc5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3425,6 +3425,9 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
continue;
}
+ /* Full memory barrier */
+ mb();
+
dma_sync_single_for_cpu(priv->device, buf->addr,
frame_len, DMA_FROM_DEVICE);
skb_copy_to_linear_data(skb, page_address(buf->page),
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox