* Re: ax25: fix possible use-after-free
From: Eric Dumazet @ 2019-02-17 18:39 UTC (permalink / raw)
To: f6bvp, netdev
In-Reply-To: <20190216233349.7977096b@draws-f6bvp>
On 02/16/2019 02:33 PM, f6bvp wrote:
>
> Patch applied successfully on Linux draws-f6bvp 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
>
> However ax25_route_lock_use and ax25_route_lock_unuse() are not declared and compile failed.
>
> make : on entre dans le répertoire « /usr/src/linux-headers-4.14.79-v7+ »
> CC [M] /usr/src/linux-4.14.y/net/ax25/ax25_ip.o
> /usr/src/linux-4.14.y/net/ax25/ax25_ip.c: In function ‘ax25_ip_xmit’:
> /usr/src/linux-4.14.y/net/ax25/ax25_ip.c:117:2: error: implicit declaration of function ‘ax25_route_lock_use’ [-Werror=implicit-function-declaration]
> ax25_route_lock_use();
> ^~~~~~~~~~~~~~~~~~~
> /usr/src/linux-4.14.y/net/ax25/ax25_ip.c:211:2: error: implicit declaration of function ‘ax25_route_lock_unuse’ [-Werror=implicit-function-declaration]
> ax25_route_lock_unuse();
> ^~~~~~~~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
> scripts/Makefile.build:328 : la recette pour la cible « /usr/src/linux-4.14.y/net/ax25/ax25_ip.o » a echouee
> make[1]: *** [/usr/src/linux-4.14.y/net/ax25/ax25_ip.o] Erreur 1
> Makefile:1527 : la recette pour la cible « _module_/usr/src/linux-4.14.y/net/ax25 » a echouee
> make: *** [_module_/usr/src/linux-4.14.y/net/ax25] Erreur 2
> make : on quitte le repertoire « /usr/src/linux-headers-4.14.79-v7+ »
>
>
> Bernard, f6bvp
>
Hi Bernard
Are you sure you applied the patch correctly/completely ?
git cherry-pick worked without conflicts on top of 4.14.100
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: phy: add and use genphy_c45_an_config_an
From: Heiner Kallweit @ 2019-02-17 18:45 UTC (permalink / raw)
To: David Miller; +Cc: andrew, f.fainelli, linux, netdev
In-Reply-To: <20190217.102851.1246921765512051517.davem@davemloft.net>
On 17.02.2019 19:28, David Miller wrote:
> From: Heiner Kallweit <hkallweit1@gmail.com>
> Date: Sun, 17 Feb 2019 10:27:43 +0100
>
>> This series adds genphy_c45_an_config_an() and uses it in the
>> marvell10g diver. In addition patch 4 aligns the aneg configuration
>> with what is done in genphy_config_aneg().
>>
>> v2:
>> - in patch 2 changed function name to genphy_c45_an_config_aneg
>> - in patch 3 add a comment regarding 1000BaseT vendor registers
>>
>> v3:
>> - rebase patch 3
>
> Series applied.
>
> For patches #1 and #4 there was some fuzz which I resolved.
>
> Did you really rebase this series? :-)
>
I swear .. I think reason is that there are further patches under review
dealing with the same file(s).
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: core: Extend thermal module with per QSFP module thermal zones
From: David Miller @ 2019-02-17 18:58 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, andrew, mlxsw, vadimp
In-Reply-To: <20190214202146.1544-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Thu, 14 Feb 2019 20:22:55 +0000
> From: Vadim Pasternak <vadimp@mellanox.com>
>
> Add a dedicated thermal zone for each QSFP/SFP module. The current
> temperature is obtained from the module's temperature sensor and the
> trip points are set based on the warning and critical thresholds
> read from the module.
>
> A cooling device (fan) is bound to all the thermal zones. The
> thermal zone governor is set to user space in order to avoid
> collisions between thermal zones.
> For example, one thermal zone might want to increase the speed of
> the fan, whereas another one would like to decrease it.
>
> Deferring this decision to user space allows the user to the take
> the most suitable decision.
>
> Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: caif: use skb helpers instead of open-coding them
From: David Miller @ 2019-02-17 19:02 UTC (permalink / raw)
To: jannh; +Cc: dmitry.tarnyagin, netdev
In-Reply-To: <20190214213547.41783-1-jannh@google.com>
From: Jann Horn <jannh@google.com>
Date: Thu, 14 Feb 2019 22:35:47 +0100
> Use existing skb_put_data() and skb_trim() instead of open-coding them,
> with the skb_put_data() first so that logically, `skb` still contains the
> data to be copied in its data..tail area when skb_put_data() reads it.
> This change on its own is a cleanup, and it is also necessary for potential
> future integration of skbuffs with things like KASAN.
>
> Signed-off-by: Jann Horn <jannh@google.com>
Applied, thanks.
Feel free to send me a MAINTAINERS patch that either updates the
bouncing email or removes it altogether. If the listed maintainer
bounces and won't reply when you ask them if they are still
maintaining things it is valid to just remove them.
Thanks.
^ permalink raw reply
* Re: Re: [BUG] [FIX] net: dsa: oops in br_vlan_enabled
From: Frank Wunderlich @ 2019-02-17 19:05 UTC (permalink / raw)
To: Florian Fainelli, netdev
Hi Florian
a user from Bananapi-forum has reported the oops and i had reproduced this and patched out this oops.
That means not that vlan in bridge works, only no crash.
my kernel only conatins the second gmac dsa-patches for mt7530/bpi-r2 i've posted at the end of last year, but the oops also occur without them.
have not changed bridge vlan-configuration by
echo 1 > /sys/class/net/bridge_name/bridge/vlan_filtering
maybe that vlan-objects/configuration is not passed through, but there should happen no oops.
kernel-source is here: https://github.com/frank-w/BPI-R2-4.14/tree/4.19-main
ps: please take me in CC so i can answer directly
regards Frank
^ permalink raw reply
* Re: stmmac / meson8b-dwmac
From: Simon Huelck @ 2019-02-17 19:13 UTC (permalink / raw)
To: Martin Blumenstingl, Jose Abreu
Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue,
linux-amlogic, netdev
In-Reply-To: <CAFBinCAJwk5Go4ZEt2cqVKyfeeOxsa-+3pfLpzQo=XNr5u4Shw@mail.gmail.com>
Hi Martin,
i repeated your commands , nothing changed the problematic result ....
regards,
Simon
Am 17.02.2019 um 15:48 schrieb Martin Blumenstingl:
> Hello Jose,
>
> On Mon, Feb 11, 2019 at 2:45 PM Jose Abreu <jose.abreu@synopsys.com> wrote:
>> Hello,
>>
>> On 2/9/2019 1:09 AM, Martin Blumenstingl wrote:
>>> (it's interesting that the sending direction has 445 retries)
>> I saw this before and I think it was related with COE. Can you
>> please disable all offloading and try again?
> OK, details are:
>
> (before doing anything)
> # ethtool -k eth0
> Features for eth0:
> rx-checksumming: on
> tx-checksumming: on
> tx-checksum-ipv4: on
> tx-checksum-ip-generic: off [fixed]
> tx-checksum-ipv6: on
> tx-checksum-fcoe-crc: off [fixed]
> tx-checksum-sctp: off [fixed]
> scatter-gather: on
> tx-scatter-gather: on
> tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: off
> tx-tcp-segmentation: off [fixed]
> tx-tcp-ecn-segmentation: off [fixed]
> tx-tcp-mangleid-segmentation: off [fixed]
> tx-tcp6-segmentation: off [fixed]
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off [fixed]
> rx-vlan-offload: off [fixed]
> tx-vlan-offload: off [fixed]
> ntuple-filters: off [fixed]
> receive-hashing: off [fixed]
> highdma: on [fixed]
> rx-vlan-filter: off [fixed]
> vlan-challenged: off [fixed]
> tx-lockless: off [fixed]
> netns-local: off [fixed]
> tx-gso-robust: off [fixed]
> tx-fcoe-segmentation: off [fixed]
> tx-gre-segmentation: off [fixed]
> tx-gre-csum-segmentation: off [fixed]
> tx-ipxip4-segmentation: off [fixed]
> tx-ipxip6-segmentation: off [fixed]
> tx-udp_tnl-segmentation: off [fixed]
> tx-udp_tnl-csum-segmentation: off [fixed]
> tx-gso-partial: off [fixed]
> tx-sctp-segmentation: off [fixed]
> tx-esp-segmentation: off [fixed]
> tx-udp-segmentation: off [fixed]
> fcoe-mtu: off [fixed]
> tx-nocache-copy: off
> loopback: off [fixed]
> rx-fcs: off [fixed]
> rx-all: off [fixed]
> tx-vlan-stag-hw-insert: off [fixed]
> rx-vlan-stag-hw-parse: off [fixed]
> rx-vlan-stag-filter: off [fixed]
> l2-fwd-offload: off [fixed]
> hw-tc-offload: off [fixed]
> esp-hw-offload: off [fixed]
> esp-tx-csum-hw-offload: off [fixed]
> rx-udp_tunnel-port-offload: off [fixed]
> tls-hw-tx-offload: off [fixed]
> tls-hw-rx-offload: off [fixed]
> rx-gro-hw: off [fixed]
> tls-hw-record: off [fixed]
>
> this causes retries when running iperf3 in transmit mode.
>
> with offloading disabled:
>
> # ethtool -K eth0 rx off tx off
> # ethtool -k eth0
> Features for eth0:
> rx-checksumming: off
> tx-checksumming: off
> tx-checksum-ipv4: off
> tx-checksum-ip-generic: off [fixed]
> tx-checksum-ipv6: off
> tx-checksum-fcoe-crc: off [fixed]
> tx-checksum-sctp: off [fixed]
> scatter-gather: on
> tx-scatter-gather: on
> tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: off
> tx-tcp-segmentation: off [fixed]
> tx-tcp-ecn-segmentation: off [fixed]
> tx-tcp-mangleid-segmentation: off [fixed]
> tx-tcp6-segmentation: off [fixed]
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off [fixed]
> rx-vlan-offload: off [fixed]
> tx-vlan-offload: off [fixed]
> ntuple-filters: off [fixed]
> receive-hashing: off [fixed]
> highdma: on [fixed]
> rx-vlan-filter: off [fixed]
> vlan-challenged: off [fixed]
> tx-lockless: off [fixed]
> netns-local: off [fixed]
> tx-gso-robust: off [fixed]
> tx-fcoe-segmentation: off [fixed]
> tx-gre-segmentation: off [fixed]
> tx-gre-csum-segmentation: off [fixed]
> tx-ipxip4-segmentation: off [fixed]
> tx-ipxip6-segmentation: off [fixed]
> tx-udp_tnl-segmentation: off [fixed]
> tx-udp_tnl-csum-segmentation: off [fixed]
> tx-gso-partial: off [fixed]
> tx-sctp-segmentation: off [fixed]
> tx-esp-segmentation: off [fixed]
> tx-udp-segmentation: off [fixed]
> fcoe-mtu: off [fixed]
> tx-nocache-copy: off
> loopback: off [fixed]
> rx-fcs: off [fixed]
> rx-all: off [fixed]
> tx-vlan-stag-hw-insert: off [fixed]
> rx-vlan-stag-hw-parse: off [fixed]
> rx-vlan-stag-filter: off [fixed]
> l2-fwd-offload: off [fixed]
> hw-tc-offload: off [fixed]
> esp-hw-offload: off [fixed]
> esp-tx-csum-hw-offload: off [fixed]
> rx-udp_tunnel-port-offload: off [fixed]
> tls-hw-tx-offload: off [fixed]
> tls-hw-rx-offload: off [fixed]
> rx-gro-hw: off [fixed]
> tls-hw-record: off [fixed]
> # iperf3 -c 192.168.1.100
> Connecting to host 192.168.1.100, port 5201
> [ 5] local 192.168.1.131 port 58412 connected to 192.168.1.100 port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 112 MBytes 937 Mbits/sec 32 59.4 KBytes
> [ 5] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 25 290 KBytes
> [ 5] 2.00-3.00 sec 109 MBytes 915 Mbits/sec 150 279 KBytes
> [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 334 KBytes
> [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 342 KBytes
> [ 5] 5.00-6.00 sec 111 MBytes 934 Mbits/sec 98 320 KBytes
> [ 5] 6.00-7.00 sec 111 MBytes 929 Mbits/sec 123 76.4 KBytes
> [ 5] 7.00-8.00 sec 109 MBytes 917 Mbits/sec 119 277 KBytes
> [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 314 KBytes
> [ 5] 9.00-10.00 sec 112 MBytes 940 Mbits/sec 0 318 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec 547 sender
> [ 5] 0.00-10.04 sec 1.09 GBytes 929 Mbits/sec receiver
>
> iperf Done.
>
> so for me disabling offloading didn't change anything.
>
> Jose, is my command for disabling offloading correct?
> Simon, does disabling offloading improve anything in your iperf2 or
> real-world scenario on a kernel where you previously had performance
> issues?
>
>
> Regards
> Martin
^ permalink raw reply
* Re: [PATCH] tcp: Namespace-ify sysctl_tcp_rmem and sysctl_tcp_wmem
From: Sasha Levin @ 2019-02-17 19:21 UTC (permalink / raw)
To: Alakesh Haloi
Cc: stable, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Eric Dumazet, netdev, linux-kernel
In-Reply-To: <20190214011159.GA35034@dev-dsk-alakeshh-2c-f8a3e6e0.us-west-2.amazon.com>
On Thu, Feb 14, 2019 at 01:12:08AM +0000, Alakesh Haloi wrote:
>[ Upstream commit 356d1833b638bd465672aefeb71def3ab93fc17d ]
>
>Note that when a new netns is created, it inherits its
>sysctl_tcp_rmem and sysctl_tcp_wmem from initial netns.
>
>This change is needed so that we can refine TCP rcvbuf autotuning,
>to take RTT into consideration.
>
>Signed-off-by: Eric Dumazet <edumazet@google.com>
>Cc: Wei Wang <weiwan@google.com>
>Signed-off-by: David S. Miller <davem@davemloft.net>
>[alakeshh: backport to v4.14: The patch does not apply to v4.14
>directly and hence needed manual backport. Function signature for
>the function tcp_select_initial_window had to be changed to be able
>to pass pointer to struct sock.]
>Signed-off-by: Alakesh Haloi <alakeshh@amazon.com>
>Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
>Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
>Cc: Eric Dumazet <edumazet@google.com>
>Cc: <stable@vger.kernel.org> # 4.14.x
What does this fix? This is a new interface...
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH net] net: dsa: fix lockdep warning
From: Russell King - ARM Linux admin @ 2019-02-17 19:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Vivien Didelot, Heiner Kallweit,
David S. Miller, netdev
In-Reply-To: <20190217175539.GI5968@lunn.ch>
On Sun, Feb 17, 2019 at 06:55:39PM +0100, Andrew Lunn wrote:
> On Sun, Feb 17, 2019 at 04:27:32PM +0000, Russell King wrote:
> > ======================================================
> > WARNING: possible circular locking dependency detected
> > 4.20.0+ #302 Not tainted
> > ------------------------------------------------------
> > systemd-udevd/160 is trying to acquire lock:
> > edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704
> >
> > but task is already holding lock:
> > edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704
> >
> > which lock already depends on the new lock.
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #1 (&desc->request_mutex){+.+.}:
> > mutex_lock_nested+0x1c/0x24
> > __setup_irq+0xa0/0x704
> > request_threaded_irq+0xd0/0x150
> > mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx]
>
> > -> #0 (&chip->reg_lock){+.+.}:
> > __mutex_lock+0x50/0x8b8
> > mutex_lock_nested+0x1c/0x24
> > __setup_irq+0x640/0x704
> > request_threaded_irq+0xd0/0x150
> > mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx]
> > mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx]
> > mdio_probe+0x2c/0x54
> >
> > other info that might help us debug this:
> >
> > Possible unsafe locking scenario:
> >
> > CPU0 CPU1
> > ---- ----
> > lock(&desc->request_mutex);
> > lock(&chip->reg_lock);
> > lock(&desc->request_mutex);
> > lock(&chip->reg_lock);
>
> Hi Russell
>
> I failed to reproduce it on a Freescale system. Which made me take a
> closer look at the above. This is a false positive.
>
> In #1 we are requesting the GPIO interrupt. In #2 we are requesting
> the chained interrupt from the mv88e6xxx global 1 interrupt handler.
> So these are different desc->request_mutex. The Freescale VF610 GPIO
> driver uses gpiochip_irqchip_add(), which creates a lock class for the
> GPIO. The marvell gpio-mvebu driver does not create a lock class. So
> when i test on Freescale, lockdep can tell they are different mutex,
> but on clearfog it cannot.
>
> So i think the real fix is probably two fold, although just doing one
> is sufficient:
>
> 1) Add lock classes to gpio-mvebu, by call irq_set_lockdep_class()
> 2) Add lock classes to chip.c global 1, by calling irq_set_lockdep_class()
>
> There is probably more value in 1) since the mvebu gpio driver is much
> more widely used than the mv88e6xxx driver.
I'd ask one question: is there any reason to hold chip->reg_lock while
calling request_threaded_irq()? If not, then surely it would be best
not to do so?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat
From: Russell King - ARM Linux admin @ 2019-02-17 19:55 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Vivien Didelot
In-Reply-To: <20190217181143.14817-1-andrew@lunn.ch>
On Sun, Feb 17, 2019 at 07:11:43PM +0100, Andrew Lunn wrote:
> The following false positive lockdep splat has been observed.
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 4.20.0+ #302 Not tainted
> ------------------------------------------------------
> systemd-udevd/160 is trying to acquire lock:
> edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704
>
> but task is already holding lock:
> edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&desc->request_mutex){+.+.}:
> mutex_lock_nested+0x1c/0x24
> __setup_irq+0xa0/0x704
> request_threaded_irq+0xd0/0x150
> mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx]
> mdio_probe+0x2c/0x54
> really_probe+0x200/0x2c4
> driver_probe_device+0x5c/0x174
> __driver_attach+0xd8/0xdc
> bus_for_each_dev+0x58/0x7c
> bus_add_driver+0xe4/0x1f0
> driver_register+0x7c/0x110
> mdio_driver_register+0x24/0x58
> do_one_initcall+0x74/0x2e8
> do_init_module+0x60/0x1d0
> load_module+0x1968/0x1ff4
> sys_finit_module+0x8c/0x98
> ret_fast_syscall+0x0/0x28
> 0xbedf2ae8
>
> -> #0 (&chip->reg_lock){+.+.}:
> __mutex_lock+0x50/0x8b8
> mutex_lock_nested+0x1c/0x24
> __setup_irq+0x640/0x704
> request_threaded_irq+0xd0/0x150
> mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx]
> mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx]
> mdio_probe+0x2c/0x54
> really_probe+0x200/0x2c4
> driver_probe_device+0x5c/0x174
> __driver_attach+0xd8/0xdc
> bus_for_each_dev+0x58/0x7c
> bus_add_driver+0xe4/0x1f0
> driver_register+0x7c/0x110
> mdio_driver_register+0x24/0x58
> do_one_initcall+0x74/0x2e8
> do_init_module+0x60/0x1d0
> load_module+0x1968/0x1ff4
> sys_finit_module+0x8c/0x98
> ret_fast_syscall+0x0/0x28
> 0xbedf2ae8
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&desc->request_mutex);
> lock(&chip->reg_lock);
> lock(&desc->request_mutex);
> lock(&chip->reg_lock);
>
> &desc->request_mutex refer to two different mutex. #1 is the GPIO for
> the chip interrupt. #2 is the chained interrupt between global 1 and
> global 2.
>
> Add lockdep classes to the GPIO interrupt to avoid this.
>
> Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>
> Hi Russell
>
> Does this fix it for you on Clearfog?
Yes, that also fixes the problem, but I do think this is just papering
over mv88e6xxx needlessly holding locks when it doesn't need to do so.
>
> drivers/net/dsa/mv88e6xxx/chip.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 32e7af5caa69..936d53a92144 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -442,12 +442,20 @@ static int mv88e6xxx_g1_irq_setup_common(struct mv88e6xxx_chip *chip)
>
> static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
> {
> + static struct lock_class_key lock_key;
> + static struct lock_class_key request_key;
> int err;
>
> err = mv88e6xxx_g1_irq_setup_common(chip);
> if (err)
> return err;
>
> + /* These lock classes tells lockdep that global 1 irqs are in
> + * a different category than their parent GPIO, so it won't
> + * report false recursion.
> + */
> + irq_set_lockdep_class(chip->irq, &lock_key, &request_key);
> +
> err = request_threaded_irq(chip->irq, NULL,
> mv88e6xxx_g1_irq_thread_fn,
> IRQF_ONESHOT | IRQF_SHARED,
> --
> 2.20.1
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [PATCH net-next v6] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: Callum Sinclair @ 2019-02-17 21:07 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, nikolay, netdev, linux-kernel
Cc: nicolas.dichtel, Callum Sinclair
Created a way to clear the multicast forwarding cache on a socket
without having to either remove the entries manually using the delete
entry socket option or destroy and recreate the multicast socket.
Calling the socket option MRT_FLUSH will allow any combination of the
four flag options to be cleared.
MRT_FLUSH_MFC will clear all non static mfc entries and clear the unresolved cache
MRT_FLUSH_MFC_STATIC will clear all static mfc entries
MRT_FLUSH_VIFS will clear all non static interfaces
MRT_FLUSH_VIFS_STATIC will clear all static interfaces.
Callum Sinclair (1):
ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
include/uapi/linux/mroute.h | 9 ++++-
include/uapi/linux/mroute6.h | 9 ++++-
net/ipv4/ipmr.c | 75 +++++++++++++++++++++-------------
net/ipv6/ip6mr.c | 78 +++++++++++++++++++++++-------------
4 files changed, 115 insertions(+), 56 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net-next v6] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: Callum Sinclair @ 2019-02-17 21:07 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, nikolay, netdev, linux-kernel
Cc: nicolas.dichtel, Callum Sinclair
In-Reply-To: <20190217210752.20914-1-callum.sinclair@alliedtelesis.co.nz>
Currently the only way to clear the forwarding cache was to delete the
entries one by one using the MRT_DEL_MFC socket option or to destroy and
recreate the socket.
Create a new socket option which with the use of optional flags can
clear any combination of multicast entries (static or not static) and
multicast vifs (static or not static).
Calling the new socket option MRT_FLUSH with the flags MRT_FLUSH_MFC and
MRT_FLUSH_VIFS will clear all entries and vifs on the socket except for
static entries.
Signed-off-by: Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
---
v1 -> v2:
Implemented additional flags for static entries
v2 -> v3:
Cleaned up flag logic so any combination of routes can be cleared.
Fixed style errors
Fixed incorrect flag values
v3 -> v4:
Fixed style errors
Fixed incorrect flag (MRT_FLUSH was used instead of MRT_FLUSH_VIFS)
v4 -> v5:
Only clear the unresolved queue when MRT_FLUSH_MFC flag is set.
v5 -> v6:
Renamed MRT6_FLUSH_VIFS to MRT6_FLUSH_MIFS
include/uapi/linux/mroute.h | 9 ++++-
include/uapi/linux/mroute6.h | 9 ++++-
net/ipv4/ipmr.c | 75 +++++++++++++++++++++-------------
net/ipv6/ip6mr.c | 78 +++++++++++++++++++++++-------------
4 files changed, 115 insertions(+), 56 deletions(-)
diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
index 5d37a9ccce63..11c8c1fc1124 100644
--- a/include/uapi/linux/mroute.h
+++ b/include/uapi/linux/mroute.h
@@ -28,12 +28,19 @@
#define MRT_TABLE (MRT_BASE+9) /* Specify mroute table ID */
#define MRT_ADD_MFC_PROXY (MRT_BASE+10) /* Add a (*,*|G) mfc entry */
#define MRT_DEL_MFC_PROXY (MRT_BASE+11) /* Del a (*,*|G) mfc entry */
-#define MRT_MAX (MRT_BASE+11)
+#define MRT_FLUSH (MRT_BASE+12) /* Flush all mfc entries and/or vifs */
+#define MRT_MAX (MRT_BASE+12)
#define SIOCGETVIFCNT SIOCPROTOPRIVATE /* IP protocol privates */
#define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
#define SIOCGETRPF (SIOCPROTOPRIVATE+2)
+/* MRT_FLUSH optional flags */
+#define MRT_FLUSH_MFC 1 /* Flush multicast entries */
+#define MRT_FLUSH_MFC_STATIC 2 /* Flush static multicast entries */
+#define MRT_FLUSH_VIFS 4 /* Flush multicast vifs */
+#define MRT_FLUSH_VIFS_STATIC 8 /* Flush static multicast vifs */
+
#define MAXVIFS 32
typedef unsigned long vifbitmap_t; /* User mode code depends on this lot */
typedef unsigned short vifi_t;
diff --git a/include/uapi/linux/mroute6.h b/include/uapi/linux/mroute6.h
index 9999cc006390..c36177a86516 100644
--- a/include/uapi/linux/mroute6.h
+++ b/include/uapi/linux/mroute6.h
@@ -31,12 +31,19 @@
#define MRT6_TABLE (MRT6_BASE+9) /* Specify mroute table ID */
#define MRT6_ADD_MFC_PROXY (MRT6_BASE+10) /* Add a (*,*|G) mfc entry */
#define MRT6_DEL_MFC_PROXY (MRT6_BASE+11) /* Del a (*,*|G) mfc entry */
-#define MRT6_MAX (MRT6_BASE+11)
+#define MRT6_FLUSH (MRT6_BASE+12) /* Flush all mfc entries and/or vifs */
+#define MRT6_MAX (MRT6_BASE+12)
#define SIOCGETMIFCNT_IN6 SIOCPROTOPRIVATE /* IP protocol privates */
#define SIOCGETSGCNT_IN6 (SIOCPROTOPRIVATE+1)
#define SIOCGETRPF (SIOCPROTOPRIVATE+2)
+/* MRT6_FLUSH optional flags */
+#define MRT6_FLUSH_MFC 1 /* Flush multicast entries */
+#define MRT6_FLUSH_MFC_STATIC 2 /* Flush static multicast entries */
+#define MRT6_FLUSH_MIFS 4 /* Flushing multicast vifs */
+#define MRT6_FLUSH_MIFS_STATIC 8 /* Flush static multicast vifs */
+
#define MAXMIFS 32
typedef unsigned long mifbitmap_t; /* User mode code depends on this lot */
typedef unsigned short mifi_t;
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index e536970557dd..2c931120c494 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -110,7 +110,7 @@ static int ipmr_cache_report(struct mr_table *mrt,
static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
int cmd);
static void igmpmsg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
-static void mroute_clean_tables(struct mr_table *mrt, bool all);
+static void mroute_clean_tables(struct mr_table *mrt, int flags);
static void ipmr_expire_process(struct timer_list *t);
#ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
@@ -415,7 +415,8 @@ static struct mr_table *ipmr_new_table(struct net *net, u32 id)
static void ipmr_free_table(struct mr_table *mrt)
{
del_timer_sync(&mrt->ipmr_expire_timer);
- mroute_clean_tables(mrt, true);
+ mroute_clean_tables(mrt, MRT_FLUSH_VIFS | MRT_FLUSH_VIFS_STATIC |
+ MRT_FLUSH_MFC | MRT_FLUSH_MFC_STATIC);
rhltable_destroy(&mrt->mfc_hash);
kfree(mrt);
}
@@ -1296,7 +1297,7 @@ static int ipmr_mfc_add(struct net *net, struct mr_table *mrt,
}
/* Close the multicast socket, and clear the vif tables etc */
-static void mroute_clean_tables(struct mr_table *mrt, bool all)
+static void mroute_clean_tables(struct mr_table *mrt, int flags)
{
struct net *net = read_pnet(&mrt->net);
struct mr_mfc *c, *tmp;
@@ -1305,35 +1306,44 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
int i;
/* Shut down all active vif entries */
- for (i = 0; i < mrt->maxvif; i++) {
- if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
- continue;
- vif_delete(mrt, i, 0, &list);
+ if (flags & (MRT_FLUSH_VIFS | MRT_FLUSH_VIFS_STATIC)) {
+ for (i = 0; i < mrt->maxvif; i++) {
+ if (((mrt->vif_table[i].flags & VIFF_STATIC) &&
+ !(flags & MRT_FLUSH_VIFS_STATIC)) ||
+ (!(mrt->vif_table[i].flags & VIFF_STATIC) && !(flags & MRT_FLUSH_VIFS)))
+ continue;
+ vif_delete(mrt, i, 0, &list);
+ }
+ unregister_netdevice_many(&list);
}
- unregister_netdevice_many(&list);
/* Wipe the cache */
- list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
- if (!all && (c->mfc_flags & MFC_STATIC))
- continue;
- rhltable_remove(&mrt->mfc_hash, &c->mnode, ipmr_rht_params);
- list_del_rcu(&c->list);
- cache = (struct mfc_cache *)c;
- call_ipmr_mfc_entry_notifiers(net, FIB_EVENT_ENTRY_DEL, cache,
- mrt->id);
- mroute_netlink_event(mrt, cache, RTM_DELROUTE);
- mr_cache_put(c);
- }
-
- if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
- spin_lock_bh(&mfc_unres_lock);
- list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
- list_del(&c->list);
+ if (flags & (MRT_FLUSH_MFC | MRT_FLUSH_MFC_STATIC)) {
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
+ if (((c->mfc_flags & MFC_STATIC) && !(flags & MRT_FLUSH_MFC_STATIC)) ||
+ (!(c->mfc_flags & MFC_STATIC) && !(flags & MRT_FLUSH_MFC)))
+ continue;
+ rhltable_remove(&mrt->mfc_hash, &c->mnode, ipmr_rht_params);
+ list_del_rcu(&c->list);
cache = (struct mfc_cache *)c;
+ call_ipmr_mfc_entry_notifiers(net, FIB_EVENT_ENTRY_DEL, cache,
+ mrt->id);
mroute_netlink_event(mrt, cache, RTM_DELROUTE);
- ipmr_destroy_unres(mrt, cache);
+ mr_cache_put(c);
+ }
+ }
+
+ if (flags & MRT_FLUSH_MFC) {
+ if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
+ spin_lock_bh(&mfc_unres_lock);
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
+ list_del(&c->list);
+ cache = (struct mfc_cache *)c;
+ mroute_netlink_event(mrt, cache, RTM_DELROUTE);
+ ipmr_destroy_unres(mrt, cache);
+ }
+ spin_unlock_bh(&mfc_unres_lock);
}
- spin_unlock_bh(&mfc_unres_lock);
}
}
@@ -1354,7 +1364,7 @@ static void mrtsock_destruct(struct sock *sk)
NETCONFA_IFINDEX_ALL,
net->ipv4.devconf_all);
RCU_INIT_POINTER(mrt->mroute_sk, NULL);
- mroute_clean_tables(mrt, false);
+ mroute_clean_tables(mrt, MRT_FLUSH_VIFS | MRT_FLUSH_MFC);
}
}
rtnl_unlock();
@@ -1479,6 +1489,17 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval,
sk == rtnl_dereference(mrt->mroute_sk),
parent);
break;
+ case MRT_FLUSH:
+ if (optlen != sizeof(val)) {
+ ret = -EINVAL;
+ break;
+ }
+ if (get_user(val, (int __user *)optval)) {
+ ret = -EFAULT;
+ break;
+ }
+ mroute_clean_tables(mrt, val);
+ break;
/* Control PIM assert. */
case MRT_ASSERT:
if (optlen != sizeof(val)) {
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index cc01aa3f2b5e..3594f1d9c68c 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -97,7 +97,7 @@ static void mr6_netlink_event(struct mr_table *mrt, struct mfc6_cache *mfc,
static void mrt6msg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
static int ip6mr_rtm_dumproute(struct sk_buff *skb,
struct netlink_callback *cb);
-static void mroute_clean_tables(struct mr_table *mrt, bool all);
+static void mroute_clean_tables(struct mr_table *mrt, int flags);
static void ipmr_expire_process(struct timer_list *t);
#ifdef CONFIG_IPV6_MROUTE_MULTIPLE_TABLES
@@ -393,7 +393,8 @@ static struct mr_table *ip6mr_new_table(struct net *net, u32 id)
static void ip6mr_free_table(struct mr_table *mrt)
{
del_timer_sync(&mrt->ipmr_expire_timer);
- mroute_clean_tables(mrt, true);
+ mroute_clean_tables(mrt, MRT6_FLUSH_MIFS | MRT6_FLUSH_MIFS_STATIC |
+ MRT6_FLUSH_MFC | MRT6_FLUSH_MFC_STATIC);
rhltable_destroy(&mrt->mfc_hash);
kfree(mrt);
}
@@ -1496,42 +1497,51 @@ static int ip6mr_mfc_add(struct net *net, struct mr_table *mrt,
* Close the multicast socket, and clear the vif tables etc
*/
-static void mroute_clean_tables(struct mr_table *mrt, bool all)
+static void mroute_clean_tables(struct mr_table *mrt, int flags)
{
struct mr_mfc *c, *tmp;
LIST_HEAD(list);
int i;
/* Shut down all active vif entries */
- for (i = 0; i < mrt->maxvif; i++) {
- if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
- continue;
- mif6_delete(mrt, i, 0, &list);
+ if (flags & (MRT6_FLUSH_MIFS | MRT6_FLUSH_MIFS_STATIC)) {
+ for (i = 0; i < mrt->maxvif; i++) {
+ if (((mrt->vif_table[i].flags & VIFF_STATIC) &&
+ !(flags & MRT6_FLUSH_MIFS_STATIC)) ||
+ (!(mrt->vif_table[i].flags & VIFF_STATIC) && !(flags & MRT6_FLUSH_MIFS)))
+ continue;
+ mif6_delete(mrt, i, 0, &list);
+ }
+ unregister_netdevice_many(&list);
}
- unregister_netdevice_many(&list);
/* Wipe the cache */
- list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
- if (!all && (c->mfc_flags & MFC_STATIC))
- continue;
- rhltable_remove(&mrt->mfc_hash, &c->mnode, ip6mr_rht_params);
- list_del_rcu(&c->list);
- call_ip6mr_mfc_entry_notifiers(read_pnet(&mrt->net),
- FIB_EVENT_ENTRY_DEL,
- (struct mfc6_cache *)c, mrt->id);
- mr6_netlink_event(mrt, (struct mfc6_cache *)c, RTM_DELROUTE);
- mr_cache_put(c);
+ if (flags & (MRT6_FLUSH_MFC | MRT6_FLUSH_MFC_STATIC)) {
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
+ if (((c->mfc_flags & MFC_STATIC) && !(flags & MRT6_FLUSH_MFC_STATIC)) ||
+ (!(c->mfc_flags & MFC_STATIC) && !(flags & MRT6_FLUSH_MFC)))
+ continue;
+ rhltable_remove(&mrt->mfc_hash, &c->mnode, ip6mr_rht_params);
+ list_del_rcu(&c->list);
+ call_ip6mr_mfc_entry_notifiers(read_pnet(&mrt->net),
+ FIB_EVENT_ENTRY_DEL,
+ (struct mfc6_cache *)c, mrt->id);
+ mr6_netlink_event(mrt, (struct mfc6_cache *)c, RTM_DELROUTE);
+ mr_cache_put(c);
+ }
}
- if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
- spin_lock_bh(&mfc_unres_lock);
- list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
- list_del(&c->list);
- mr6_netlink_event(mrt, (struct mfc6_cache *)c,
- RTM_DELROUTE);
- ip6mr_destroy_unres(mrt, (struct mfc6_cache *)c);
+ if (flags & MRT6_FLUSH_MFC) {
+ if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
+ spin_lock_bh(&mfc_unres_lock);
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
+ list_del(&c->list);
+ mr6_netlink_event(mrt, (struct mfc6_cache *)c,
+ RTM_DELROUTE);
+ ip6mr_destroy_unres(mrt, (struct mfc6_cache *)c);
+ }
+ spin_unlock_bh(&mfc_unres_lock);
}
- spin_unlock_bh(&mfc_unres_lock);
}
}
@@ -1587,7 +1597,7 @@ int ip6mr_sk_done(struct sock *sk)
NETCONFA_IFINDEX_ALL,
net->ipv6.devconf_all);
- mroute_clean_tables(mrt, false);
+ mroute_clean_tables(mrt, MRT6_FLUSH_MIFS | MRT6_FLUSH_MFC);
err = 0;
break;
}
@@ -1703,6 +1713,20 @@ int ip6_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, uns
rtnl_unlock();
return ret;
+ case MRT6_FLUSH:
+ {
+ int flags;
+
+ if (optlen != sizeof(flags))
+ return -EINVAL;
+ if (get_user(flags, (int __user *)optval))
+ return -EFAULT;
+ rtnl_lock();
+ mroute_clean_tables(mrt, flags);
+ rtnl_unlock();
+ return 0;
+ }
+
/*
* Control PIM assert (to activate pim will activate assert)
*/
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next 00/13] net: mvpp2: various fixes
From: David Miller @ 2019-02-17 21:23 UTC (permalink / raw)
To: antoine.tenart
Cc: linux, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20190215153241.6857-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Fri, 15 Feb 2019 16:32:28 +0100
> This series contains various fixes on bugs reported to us, or bugs I
> stumbled upon while testing the various interface configurations I have
> access to.
>
> While this series contain fixes, it's sent to net-next as it is based
> on top of Russell's rework and fixes he sent during the last 2 weeks
> (such as his PPv2 phylink rework) that were applied to net-next. It'll
> also allow the users to have more time to test those changes.
Please respond to the feedback you've received.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: sched: matchall: verify that filter is not NULL in mall_walk()
From: David Miller @ 2019-02-17 21:25 UTC (permalink / raw)
To: vladbu; +Cc: netdev, idosch, jhs, xiyou.wangcong, jiri
In-Reply-To: <20190215151756.8719-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Fri, 15 Feb 2019 17:17:56 +0200
> Check that filter is not NULL before passing it to tcf_walker->fn()
> callback. This can happen when mall_change() failed to offload filter to
> hardware.
>
> Fixes: ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex")
> Reported-by: Ido Schimmel <idosch@mellanox.com>
> Tested-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: sched: fw: don't set arg->stop in fw_walk() when empty
From: David Miller @ 2019-02-17 21:25 UTC (permalink / raw)
To: vladbu; +Cc: netdev, idosch, jhs, xiyou.wangcong, jiri
In-Reply-To: <20190215152007.8854-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Fri, 15 Feb 2019 17:20:07 +0200
> Some classifiers set arg->stop in their implementation of tp->walk() API
> when empty. Most of classifiers do not adhere to that convention. Do not
> set arg->stop in fw_walk() to unify tp->walk() behavior among classifier
> implementations.
>
> Fixes: ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex")
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Applied.
^ permalink raw reply
* [PATCH] orinoco : Replace function name in string with __func__
From: Keyur Patel @ 2019-02-17 16:25 UTC (permalink / raw)
Cc: iamkeyur96, Kalle Valo, David S. Miller, Eric Biggers, Herbert Xu,
linux-wireless, netdev, linux-kernel
From: Keyur Patel <iamkeyur96@gmail.com>
Replace hard coded function name with __func__, to
improve robustness and to conform to the Linux kernel coding
style. Issue found using checkpatch.
Signed-off-by: Keyur Patel <iamkeyur96@gmail.com>
---
drivers/net/wireless/intersil/orinoco/mic.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/intersil/orinoco/mic.c b/drivers/net/wireless/intersil/orinoco/mic.c
index 709d9ab3e7bc..67b0c05afbdb 100644
--- a/drivers/net/wireless/intersil/orinoco/mic.c
+++ b/drivers/net/wireless/intersil/orinoco/mic.c
@@ -18,16 +18,16 @@ int orinoco_mic_init(struct orinoco_private *priv)
{
priv->tx_tfm_mic = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_mic)) {
- printk(KERN_DEBUG "orinoco_mic_init: could not allocate "
- "crypto API michael_mic\n");
+ printk(KERN_DEBUG "%s: could not allocate "
+ "crypto API michael_mic\n", __func__);
priv->tx_tfm_mic = NULL;
return -ENOMEM;
}
priv->rx_tfm_mic = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_mic)) {
- printk(KERN_DEBUG "orinoco_mic_init: could not allocate "
- "crypto API michael_mic\n");
+ printk(KERN_DEBUG "%s: could not allocate "
+ "crypto API michael_mic\n", __func__);
priv->rx_tfm_mic = NULL;
return -ENOMEM;
}
@@ -52,7 +52,7 @@ int orinoco_mic(struct crypto_shash *tfm_michael, u8 *key,
int err;
if (tfm_michael == NULL) {
- printk(KERN_WARNING "orinoco_mic: tfm_michael == NULL\n");
+ printk(KERN_WARNING "%s: tfm_michael == NULL\n", __func__);
return -1;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] net: sched: matchall: verify that filter is not NULL in mall_walk()
From: David Miller @ 2019-02-17 21:27 UTC (permalink / raw)
To: vladbu; +Cc: idosch, netdev, jhs, xiyou.wangcong, jiri
In-Reply-To: <20190215121120.4971-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Fri, 15 Feb 2019 14:11:20 +0200
> Check that filter is not NULL before passing it to tcf_walker->fn()
> callback. This can happen when mall_change() failed to offload filter to
> hardware.
>
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: add support for bridge flags
From: Florian Fainelli @ 2019-02-17 21:37 UTC (permalink / raw)
To: Russell King, Andrew Lunn, Vivien Didelot; +Cc: David S. Miller, netdev
In-Reply-To: <E1gvNNT-0006Xr-JA@rmk-PC.armlinux.org.uk>
On 2/17/2019 6:25 AM, Russell King wrote:
> The Linux bridge implementation allows various properties of the bridge
> to be controlled, such as flooding unknown unicast and multicast frames.
> This patch adds the necessary DSA infrastructure to allow the Linux
> bridge support to control these properties for DSA switches.
>
> We implement this by providing two new methods: one to get the switch-
> wide support bitmask, and another to set the properties.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
[snip]
>
> +int dsa_port_bridge_flags(const struct dsa_port *dp, unsigned long flags,
> + struct switchdev_trans *trans)
> +{
> + struct dsa_switch *ds = dp->ds;
> + int port = dp->index;
> +
> + if (switchdev_trans_ph_prepare(trans))
> + return ds->ops->port_bridge_flags ? 0 : -EOPNOTSUPP;
> +
> + if (ds->ops->port_bridge_flags)
> + ds->ops->port_bridge_flags(ds, port, flags);
If you have a switch fabric with multiple switches, it seems to me that
you also need to make sure that the DSA and CPU ports will have
compatible flooding attribute, so just like the port_vlan_add()
callback, you probably need to make this a switch fabric-wide event and
use a notifier here. At least the DSA ports need to have MC flooding
turned on for an user port to also have MC flooding working.
Other than that LGTM.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: mv88e6xxx: add support for bridge flags
From: Florian Fainelli @ 2019-02-17 21:38 UTC (permalink / raw)
To: Russell King, Andrew Lunn, Vivien Didelot; +Cc: David S. Miller, netdev
In-Reply-To: <E1gvNNY-0006Y7-NF@rmk-PC.armlinux.org.uk>
On 2/17/2019 6:25 AM, Russell King wrote:
> Add support for the bridge flags to Marvell 88e6xxx bridges, allowing
> the multicast and unicast flood properties to be controlled. These
> can be controlled on a per-port basis via commands such as:
>
> bridge link set dev lan1 flood on|off
> bridge link set dev lan1 mcast_flood on|off
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: defautl to multicast and unicast flooding
From: Florian Fainelli @ 2019-02-17 21:45 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Andrew Lunn, Vivien Didelot
Cc: David S. Miller, netdev
In-Reply-To: <20190217163434.xo3ojbny4dnfqqwq@shell.armlinux.org.uk>
On 2/17/2019 8:34 AM, Russell King - ARM Linux admin wrote:
> On Sun, Feb 17, 2019 at 02:27:16PM +0000, Russell King - ARM Linux admin wrote:
>> On Sun, Feb 17, 2019 at 02:25:17PM +0000, Russell King wrote:
>>> Switches work by learning the MAC address for each attached station by
>>> monitoring traffic from each station. When a station sends a packet,
>>> the switch records which port the MAC address is connected to.
>>>
>>> With IPv4 networking, before communication commences with a neighbour,
>>> an ARP packet is broadcasted to all stations asking for the MAC address
>>> corresponding with the IPv4. The desired station responds with an ARP
>>> reply, and the ARP reply causes the switch to learn which port the
>>> station is connected to.
>>>
>>> With IPv6 networking, the situation is rather different. Rather than
>>> broadcasting ARP packets, a "neighbour solicitation" is multicasted
>>> rather than broadcasted. This multicast needs to reach the intended
>>> station in order for the neighbour to be discovered.
>>>
>>> Once a neighbour has been discovered, and entered into the sending
>>> stations neighbour cache, communication can restart at a point later
>>> without sending a new neighbour solicitation, even if the entry in
>>> the neighbour cache is marked as stale. This can be after the MAC
>>> address has expired from the forwarding cache of the DSA switch -
>>> when that occurs, there is a long pause in communication.
>>>
>>> Our DSA implementation for mv88e6xxx switches has defaulted to having
>>> multicast and unicast flooding disabled. As per the above description,
>>> this is fine for IPv4 networking, since the broadcasted ARP queries
>>> will be sent to and received by all stations on the same network.
>>> However, this breaks IPv6 very badly - blocking neighbour solicitations
>>> and later causing connections to stall.
>>>
>>> The defaults that the Linux bridge code expect from bridges are that
>>> unknown unicast frames and unknown multicast frames are flooded to
>>> all stations, which is at odds to the defaults adopted by our DSA
>>> implementation for mv88e6xxx switches.
>>>
>>> This commit enables by default flooding of both unknown unicast and
>>> unknown multicast frames. This means that mv88e6xxx DSA switches now
>>> behave as per the bridge(8) man page, and IPv6 works flawlessly through
>>> such a switch.
>>
>> Note that there is the open question whether this affects the case where
>> each port is used as a separate network interface: that case has not yet
>> been tested.
>
> I've checked with a mv88e6131 on the clearfog gt8k board. lan1
> connected to my lan with plenty of traffic on, and configured as
> part of a bridge. lan2 connected to the zii board, but not part
> of the bridge. Monitoring lan2 from the zii board shows no traffic
> that was received from lan1.
>
> So it looks fine.
With the current state whereby we do not have the necessary hooks to
perform filtering on non-bridged/standalone ports, this is entirely fine
indeed.
In the future this is part of something I want to address because it is
IMHO highly undesirable to have non-bridged ports be flooded with
unknown multicast or unknown unicast for that matter because that makes
them deviate from a standard NIC interface. Unknown unicast is not
necessarily a low hanging fruit, but still, if we have switches capable
of filtering, we might as well make use of that. Of course, one
difficulty is that we must not break running tcpdump on those DSA slave
network interfaces.
>
>>
>>>
>>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>>> ---
>>> drivers/net/dsa/mv88e6xxx/chip.c | 9 +++++----
>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
>>> index b75a865a293d..eb5e3d88374f 100644
>>> --- a/drivers/net/dsa/mv88e6xxx/chip.c
>>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
>>> @@ -2144,13 +2144,14 @@ static int mv88e6xxx_setup_message_port(struct mv88e6xxx_chip *chip, int port)
>>> static int mv88e6xxx_setup_egress_floods(struct mv88e6xxx_chip *chip, int port)
>>> {
>>> struct dsa_switch *ds = chip->ds;
>>> - bool flood;
>>>
>>> - /* Upstream ports flood frames with unknown unicast or multicast DA */
>>> - flood = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port);
>>> + /* Linux bridges are expected to flood unknown multicast and
>>> + * unicast frames to all ports - as per the defaults specified
>>> + * in the iproute2 bridge(8) man page. Not doing this causes
>>> + * stalls and failures with IPv6 over Marvell bridges. */
>>> if (chip->info->ops->port_set_egress_floods)
>>> return chip->info->ops->port_set_egress_floods(chip, port,
>>> - flood, flood);
>>> + true, true);
>>>
>>> return 0;
>>> }
>>> --
>>> 2.7.4
>>>
>>>
>>
>> --
>> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
>> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
>> According to speedtest.net: 11.9Mbps down 500kbps up
>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 perf,bpf 00/11] perf annotation of BPF programs
From: Jiri Olsa @ 2019-02-17 21:57 UTC (permalink / raw)
To: Song Liu
Cc: netdev, linux-kernel, ast, daniel, kernel-team, peterz, acme,
jolsa, namhyung
In-Reply-To: <20190215215354.3114006-1-songliubraving@fb.com>
On Fri, Feb 15, 2019 at 01:53:43PM -0800, Song Liu wrote:
> Changes v2 to v3:
> 1. Remove unnecessary include in header files;
> 2. Improved error handling;
> 3. Better naming of functions, variables, etc.;
> 4. Enable bpf events by default for perf-top.
>
> Changes v1 to v2:
> 1. Fix compilation error with different feature-disassembler-four-args;
> 2. Fix a segfault in perf-record;
> 3. Split patches 5/9 and 6/9 so that perf_env changes and perf.data changes
> are in separate patches.
>
> This series enables annotation of BPF programs in perf.
>
> perf tool gathers information via sys_bpf and (optionally) stores them in
> perf.data as headers.
>
> Patch 1/11 fixes a minor issue in kernel;
> Patch 2/11 to 4/11 introduce new helper functions and use them in perf and
> bpftool;
> Patch 5/11 to 8/11 saves information of bpf program in perf_env;
> Patch 9/11 adds --bpf-event options to perf-top;
> Patch 10/11 enables annotation of bpf programs based on information
> gathered in 5/11 to 8/11;
> Patch 11/11 handles information of short living BPF program that are loaded
> during perf-record or perf-top.
>
> Commands tested during developments are perf-top, perf-record, perf-report,
> and perf-annotate.
>
> ===================== Note on patch dependency ========================
> This set has dependency in both bpf-next tree and tip/perf/core. Current
> version is developed on bpf-next tree with the following commits
> cherry-picked from tip/perf/core:
>
> (from 1/10 to 10/10)
> commit 76193a94522f ("perf, bpf: Introduce PERF_RECORD_KSYMBOL")
> commit d764ac646491 ("tools headers uapi: Sync tools/include/uapi/linux/perf_event.h")
> commit 6ee52e2a3fe4 ("perf, bpf: Introduce PERF_RECORD_BPF_EVENT")
> commit df063c83aa2c ("tools headers uapi: Sync tools/include/uapi/linux/perf_event.h")
> commit 9aa0bfa370b2 ("perf tools: Handle PERF_RECORD_KSYMBOL")
> commit 45178a928a4b ("perf tools: Handle PERF_RECORD_BPF_EVENT")
> commit 7b612e291a5a ("perf tools: Synthesize PERF_RECORD_* for loaded BPF programs")
> commit a40b95bcd30c ("perf top: Synthesize BPF events for pre-existing loaded BPF programs")
> commit 6934058d9fb6 ("bpf: Add module name [bpf] to ksymbols for bpf programs")
> commit 811184fb6977 ("perf bpf: Fix synthesized PERF_RECORD_KSYMBOL/BPF_EVENT")
> ========================================================================
>
> This set is also available at:
>
> https://github.com/liu-song-6/linux/tree/bpf-annotation
I'm getting same compilation error as last time,
maybe it wasnt updated?
thanks,
jirka
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: defautl to multicast and unicast flooding
From: Russell King - ARM Linux admin @ 2019-02-17 21:58 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, Vivien Didelot, David S. Miller, netdev
In-Reply-To: <1a956aeb-f195-90ca-a5a5-fabac450feac@gmail.com>
On Sun, Feb 17, 2019 at 01:45:24PM -0800, Florian Fainelli wrote:
>
>
> On 2/17/2019 8:34 AM, Russell King - ARM Linux admin wrote:
> > On Sun, Feb 17, 2019 at 02:27:16PM +0000, Russell King - ARM Linux admin wrote:
> >> On Sun, Feb 17, 2019 at 02:25:17PM +0000, Russell King wrote:
> >>> Switches work by learning the MAC address for each attached station by
> >>> monitoring traffic from each station. When a station sends a packet,
> >>> the switch records which port the MAC address is connected to.
> >>>
> >>> With IPv4 networking, before communication commences with a neighbour,
> >>> an ARP packet is broadcasted to all stations asking for the MAC address
> >>> corresponding with the IPv4. The desired station responds with an ARP
> >>> reply, and the ARP reply causes the switch to learn which port the
> >>> station is connected to.
> >>>
> >>> With IPv6 networking, the situation is rather different. Rather than
> >>> broadcasting ARP packets, a "neighbour solicitation" is multicasted
> >>> rather than broadcasted. This multicast needs to reach the intended
> >>> station in order for the neighbour to be discovered.
> >>>
> >>> Once a neighbour has been discovered, and entered into the sending
> >>> stations neighbour cache, communication can restart at a point later
> >>> without sending a new neighbour solicitation, even if the entry in
> >>> the neighbour cache is marked as stale. This can be after the MAC
> >>> address has expired from the forwarding cache of the DSA switch -
> >>> when that occurs, there is a long pause in communication.
> >>>
> >>> Our DSA implementation for mv88e6xxx switches has defaulted to having
> >>> multicast and unicast flooding disabled. As per the above description,
> >>> this is fine for IPv4 networking, since the broadcasted ARP queries
> >>> will be sent to and received by all stations on the same network.
> >>> However, this breaks IPv6 very badly - blocking neighbour solicitations
> >>> and later causing connections to stall.
> >>>
> >>> The defaults that the Linux bridge code expect from bridges are that
> >>> unknown unicast frames and unknown multicast frames are flooded to
> >>> all stations, which is at odds to the defaults adopted by our DSA
> >>> implementation for mv88e6xxx switches.
> >>>
> >>> This commit enables by default flooding of both unknown unicast and
> >>> unknown multicast frames. This means that mv88e6xxx DSA switches now
> >>> behave as per the bridge(8) man page, and IPv6 works flawlessly through
> >>> such a switch.
> >>
> >> Note that there is the open question whether this affects the case where
> >> each port is used as a separate network interface: that case has not yet
> >> been tested.
> >
> > I've checked with a mv88e6131 on the clearfog gt8k board. lan1
> > connected to my lan with plenty of traffic on, and configured as
> > part of a bridge. lan2 connected to the zii board, but not part
> > of the bridge. Monitoring lan2 from the zii board shows no traffic
> > that was received from lan1.
> >
> > So it looks fine.
>
> With the current state whereby we do not have the necessary hooks to
> perform filtering on non-bridged/standalone ports, this is entirely fine
> indeed.
>
> In the future this is part of something I want to address because it is
> IMHO highly undesirable to have non-bridged ports be flooded with
> unknown multicast or unknown unicast for that matter because that makes
> them deviate from a standard NIC interface. Unknown unicast is not
> necessarily a low hanging fruit, but still, if we have switches capable
> of filtering, we might as well make use of that. Of course, one
> difficulty is that we must not break running tcpdump on those DSA slave
> network interfaces.
Sorry, I think you have the wrong end of the stick.
For a non-bridged port, I am seeing _no_ traffic apart from that
explicitly sent out through that port. In other words, there are
_no_ flooded frames coming out of the non-bridged port.
This patch appears to have no material effect on non-bridged ports.
>
> >
> >>
> >>>
> >>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> >>> ---
> >>> drivers/net/dsa/mv88e6xxx/chip.c | 9 +++++----
> >>> 1 file changed, 5 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> >>> index b75a865a293d..eb5e3d88374f 100644
> >>> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> >>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> >>> @@ -2144,13 +2144,14 @@ static int mv88e6xxx_setup_message_port(struct mv88e6xxx_chip *chip, int port)
> >>> static int mv88e6xxx_setup_egress_floods(struct mv88e6xxx_chip *chip, int port)
> >>> {
> >>> struct dsa_switch *ds = chip->ds;
> >>> - bool flood;
> >>>
> >>> - /* Upstream ports flood frames with unknown unicast or multicast DA */
> >>> - flood = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port);
> >>> + /* Linux bridges are expected to flood unknown multicast and
> >>> + * unicast frames to all ports - as per the defaults specified
> >>> + * in the iproute2 bridge(8) man page. Not doing this causes
> >>> + * stalls and failures with IPv6 over Marvell bridges. */
> >>> if (chip->info->ops->port_set_egress_floods)
> >>> return chip->info->ops->port_set_egress_floods(chip, port,
> >>> - flood, flood);
> >>> + true, true);
> >>>
> >>> return 0;
> >>> }
> >>> --
> >>> 2.7.4
> >>>
> >>>
> >>
> >> --
> >> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> >> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> >> According to speedtest.net: 11.9Mbps down 500kbps up
> >
>
> --
> Florian
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: defautl to multicast and unicast flooding
From: Florian Fainelli @ 2019-02-17 22:03 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Vivien Didelot, David S. Miller, netdev
In-Reply-To: <20190217215827.2iavpy4xyh3viqup@shell.armlinux.org.uk>
On 2/17/2019 1:58 PM, Russell King - ARM Linux admin wrote:
> On Sun, Feb 17, 2019 at 01:45:24PM -0800, Florian Fainelli wrote:
>>
>>
>> On 2/17/2019 8:34 AM, Russell King - ARM Linux admin wrote:
>>> On Sun, Feb 17, 2019 at 02:27:16PM +0000, Russell King - ARM Linux admin wrote:
>>>> On Sun, Feb 17, 2019 at 02:25:17PM +0000, Russell King wrote:
>>>>> Switches work by learning the MAC address for each attached station by
>>>>> monitoring traffic from each station. When a station sends a packet,
>>>>> the switch records which port the MAC address is connected to.
>>>>>
>>>>> With IPv4 networking, before communication commences with a neighbour,
>>>>> an ARP packet is broadcasted to all stations asking for the MAC address
>>>>> corresponding with the IPv4. The desired station responds with an ARP
>>>>> reply, and the ARP reply causes the switch to learn which port the
>>>>> station is connected to.
>>>>>
>>>>> With IPv6 networking, the situation is rather different. Rather than
>>>>> broadcasting ARP packets, a "neighbour solicitation" is multicasted
>>>>> rather than broadcasted. This multicast needs to reach the intended
>>>>> station in order for the neighbour to be discovered.
>>>>>
>>>>> Once a neighbour has been discovered, and entered into the sending
>>>>> stations neighbour cache, communication can restart at a point later
>>>>> without sending a new neighbour solicitation, even if the entry in
>>>>> the neighbour cache is marked as stale. This can be after the MAC
>>>>> address has expired from the forwarding cache of the DSA switch -
>>>>> when that occurs, there is a long pause in communication.
>>>>>
>>>>> Our DSA implementation for mv88e6xxx switches has defaulted to having
>>>>> multicast and unicast flooding disabled. As per the above description,
>>>>> this is fine for IPv4 networking, since the broadcasted ARP queries
>>>>> will be sent to and received by all stations on the same network.
>>>>> However, this breaks IPv6 very badly - blocking neighbour solicitations
>>>>> and later causing connections to stall.
>>>>>
>>>>> The defaults that the Linux bridge code expect from bridges are that
>>>>> unknown unicast frames and unknown multicast frames are flooded to
>>>>> all stations, which is at odds to the defaults adopted by our DSA
>>>>> implementation for mv88e6xxx switches.
>>>>>
>>>>> This commit enables by default flooding of both unknown unicast and
>>>>> unknown multicast frames. This means that mv88e6xxx DSA switches now
>>>>> behave as per the bridge(8) man page, and IPv6 works flawlessly through
>>>>> such a switch.
>>>>
>>>> Note that there is the open question whether this affects the case where
>>>> each port is used as a separate network interface: that case has not yet
>>>> been tested.
>>>
>>> I've checked with a mv88e6131 on the clearfog gt8k board. lan1
>>> connected to my lan with plenty of traffic on, and configured as
>>> part of a bridge. lan2 connected to the zii board, but not part
>>> of the bridge. Monitoring lan2 from the zii board shows no traffic
>>> that was received from lan1.
>>>
>>> So it looks fine.
>>
>> With the current state whereby we do not have the necessary hooks to
>> perform filtering on non-bridged/standalone ports, this is entirely fine
>> indeed.
>>
>> In the future this is part of something I want to address because it is
>> IMHO highly undesirable to have non-bridged ports be flooded with
>> unknown multicast or unknown unicast for that matter because that makes
>> them deviate from a standard NIC interface. Unknown unicast is not
>> necessarily a low hanging fruit, but still, if we have switches capable
>> of filtering, we might as well make use of that. Of course, one
>> difficulty is that we must not break running tcpdump on those DSA slave
>> network interfaces.
>
> Sorry, I think you have the wrong end of the stick.
>
> For a non-bridged port, I am seeing _no_ traffic apart from that
> explicitly sent out through that port. In other words, there are
> _no_ flooded frames coming out of the non-bridged port.
>
> This patch appears to have no material effect on non-bridged ports.
Presumably because that non-bridged port and the CPU port are part of
the same domain with only those 2 ports and that is what we want.
Now what happens if say you have a station that sends multicast traffic
through that port to e.g.: 226.94.1.1, I bet that port happily sends
that multicast traffic to the CPU port with no filtering what so ever
and this ends-up being dropped in the network stack because there is a
socket look up failure there. IMHO unless you have a receiver/server on
that network interface on the DSA network interface and a matching
socket you should not be receiving that multicast traffic and the switch
should be filtering it. Since the network stack will call into
ndo_set_rx_mode() for those cases, we really just need to make that
multicast traffic known, instead of unknown to the switch.
--
Florian
^ permalink raw reply
* Re: [PATCH v3 perf,bpf 00/11] perf annotation of BPF programs
From: Jiri Olsa @ 2019-02-17 22:04 UTC (permalink / raw)
To: Song Liu
Cc: netdev, linux-kernel, ast, daniel, kernel-team, peterz, acme,
jolsa, namhyung
In-Reply-To: <20190217215744.GA797@krava>
On Sun, Feb 17, 2019 at 10:57:44PM +0100, Jiri Olsa wrote:
> On Fri, Feb 15, 2019 at 01:53:43PM -0800, Song Liu wrote:
> > Changes v2 to v3:
> > 1. Remove unnecessary include in header files;
> > 2. Improved error handling;
> > 3. Better naming of functions, variables, etc.;
> > 4. Enable bpf events by default for perf-top.
> >
> > Changes v1 to v2:
> > 1. Fix compilation error with different feature-disassembler-four-args;
> > 2. Fix a segfault in perf-record;
> > 3. Split patches 5/9 and 6/9 so that perf_env changes and perf.data changes
> > are in separate patches.
> >
> > This series enables annotation of BPF programs in perf.
> >
> > perf tool gathers information via sys_bpf and (optionally) stores them in
> > perf.data as headers.
> >
> > Patch 1/11 fixes a minor issue in kernel;
> > Patch 2/11 to 4/11 introduce new helper functions and use them in perf and
> > bpftool;
> > Patch 5/11 to 8/11 saves information of bpf program in perf_env;
> > Patch 9/11 adds --bpf-event options to perf-top;
> > Patch 10/11 enables annotation of bpf programs based on information
> > gathered in 5/11 to 8/11;
> > Patch 11/11 handles information of short living BPF program that are loaded
> > during perf-record or perf-top.
> >
> > Commands tested during developments are perf-top, perf-record, perf-report,
> > and perf-annotate.
> >
> > ===================== Note on patch dependency ========================
> > This set has dependency in both bpf-next tree and tip/perf/core. Current
> > version is developed on bpf-next tree with the following commits
> > cherry-picked from tip/perf/core:
> >
> > (from 1/10 to 10/10)
> > commit 76193a94522f ("perf, bpf: Introduce PERF_RECORD_KSYMBOL")
> > commit d764ac646491 ("tools headers uapi: Sync tools/include/uapi/linux/perf_event.h")
> > commit 6ee52e2a3fe4 ("perf, bpf: Introduce PERF_RECORD_BPF_EVENT")
> > commit df063c83aa2c ("tools headers uapi: Sync tools/include/uapi/linux/perf_event.h")
> > commit 9aa0bfa370b2 ("perf tools: Handle PERF_RECORD_KSYMBOL")
> > commit 45178a928a4b ("perf tools: Handle PERF_RECORD_BPF_EVENT")
> > commit 7b612e291a5a ("perf tools: Synthesize PERF_RECORD_* for loaded BPF programs")
> > commit a40b95bcd30c ("perf top: Synthesize BPF events for pre-existing loaded BPF programs")
> > commit 6934058d9fb6 ("bpf: Add module name [bpf] to ksymbols for bpf programs")
> > commit 811184fb6977 ("perf bpf: Fix synthesized PERF_RECORD_KSYMBOL/BPF_EVENT")
> > ========================================================================
> >
> > This set is also available at:
> >
> > https://github.com/liu-song-6/linux/tree/bpf-annotation
>
> I'm getting same compilation error as last time,
> maybe it wasnt updated?
I also applied manualy (with some conflicts) your patches
from emails on bpf/next/master with merged tip/perf/core
and got following compilation error:
CC util/find_bit.o
util/annotate.c: In function ‘symbol__disassemble_bpf’:
util/annotate.c:1771:29: error: incompatible type for argument 1 of ‘disassembler’
disassemble = disassembler(bfdf);
^~~~
In file included from util/annotate.c:36:
/usr/include/dis-asm.h:276:63: note: expected ‘enum bfd_architecture’ but argument is of type ‘bfd *’ {aka ‘struct bfd *’}
extern disassembler_ftype disassembler (enum bfd_architecture arc,
~~~~~~~~~~~~~~~~~~~~~~^~~
util/annotate.c:1771:16: error: too few arguments to function ‘disassembler’
disassemble = disassembler(bfdf);
^~~~~~~~~~~~
In file included from util/annotate.c:36:
/usr/include/dis-asm.h:276:27: note: declared here
extern disassembler_ftype disassembler (enum bfd_architecture arc,
^~~~~~~~~~~~
thanks,
jirka
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: add support for bridge flags
From: Russell King - ARM Linux admin @ 2019-02-17 22:04 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, Vivien Didelot, David S. Miller, netdev
In-Reply-To: <a3c3a343-a49d-a93a-929a-9a1b1304129e@gmail.com>
On Sun, Feb 17, 2019 at 01:37:19PM -0800, Florian Fainelli wrote:
>
>
> On 2/17/2019 6:25 AM, Russell King wrote:
> > The Linux bridge implementation allows various properties of the bridge
> > to be controlled, such as flooding unknown unicast and multicast frames.
> > This patch adds the necessary DSA infrastructure to allow the Linux
> > bridge support to control these properties for DSA switches.
> >
> > We implement this by providing two new methods: one to get the switch-
> > wide support bitmask, and another to set the properties.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
>
> [snip]
>
> >
> > +int dsa_port_bridge_flags(const struct dsa_port *dp, unsigned long flags,
> > + struct switchdev_trans *trans)
> > +{
> > + struct dsa_switch *ds = dp->ds;
> > + int port = dp->index;
> > +
> > + if (switchdev_trans_ph_prepare(trans))
> > + return ds->ops->port_bridge_flags ? 0 : -EOPNOTSUPP;
> > +
> > + if (ds->ops->port_bridge_flags)
> > + ds->ops->port_bridge_flags(ds, port, flags);
>
> If you have a switch fabric with multiple switches, it seems to me that
> you also need to make sure that the DSA and CPU ports will have
> compatible flooding attribute, so just like the port_vlan_add()
> callback, you probably need to make this a switch fabric-wide event and
> use a notifier here. At least the DSA ports need to have MC flooding
> turned on for an user port to also have MC flooding working.
mv88e6xxx already today detects CPU and DSA ports and sets unicast
and multicast flooding for these ports - see
mv88e6xxx_setup_egress_floods():
/* Upstream ports flood frames with unknown unicast or multicast DA */
flood = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port);
if (chip->info->ops->port_set_egress_floods)
return chip->info->ops->port_set_egress_floods(chip, port,
flood, flood);
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: add support for bridge flags
From: Florian Fainelli @ 2019-02-17 22:07 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Vivien Didelot, David S. Miller, netdev
In-Reply-To: <20190217220439.zqu7dz7kfukssrlz@shell.armlinux.org.uk>
On 2/17/2019 2:04 PM, Russell King - ARM Linux admin wrote:
> On Sun, Feb 17, 2019 at 01:37:19PM -0800, Florian Fainelli wrote:
>>
>>
>> On 2/17/2019 6:25 AM, Russell King wrote:
>>> The Linux bridge implementation allows various properties of the bridge
>>> to be controlled, such as flooding unknown unicast and multicast frames.
>>> This patch adds the necessary DSA infrastructure to allow the Linux
>>> bridge support to control these properties for DSA switches.
>>>
>>> We implement this by providing two new methods: one to get the switch-
>>> wide support bitmask, and another to set the properties.
>>>
>>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>>> ---
>>
>> [snip]
>>
>>>
>>> +int dsa_port_bridge_flags(const struct dsa_port *dp, unsigned long flags,
>>> + struct switchdev_trans *trans)
>>> +{
>>> + struct dsa_switch *ds = dp->ds;
>>> + int port = dp->index;
>>> +
>>> + if (switchdev_trans_ph_prepare(trans))
>>> + return ds->ops->port_bridge_flags ? 0 : -EOPNOTSUPP;
>>> +
>>> + if (ds->ops->port_bridge_flags)
>>> + ds->ops->port_bridge_flags(ds, port, flags);
>>
>> If you have a switch fabric with multiple switches, it seems to me that
>> you also need to make sure that the DSA and CPU ports will have
>> compatible flooding attribute, so just like the port_vlan_add()
>> callback, you probably need to make this a switch fabric-wide event and
>> use a notifier here. At least the DSA ports need to have MC flooding
>> turned on for an user port to also have MC flooding working.
>
> mv88e6xxx already today detects CPU and DSA ports and sets unicast
> and multicast flooding for these ports - see
> mv88e6xxx_setup_egress_floods():
Indeed, probably for historical reasons, since that type of logic should
ideally be migrated to the core DSA layer, this is fine for now though.
>
> /* Upstream ports flood frames with unknown unicast or multicast DA */
> flood = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port);
> if (chip->info->ops->port_set_egress_floods)
> return chip->info->ops->port_set_egress_floods(chip, port,
> flood, flood);
>
--
Florian
^ permalink raw reply
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