* Re: [PATCH net] net: dsa: fix lockdep warning
From: Florian Fainelli @ 2019-02-17 17:03 UTC (permalink / raw)
To: Russell King, Andrew Lunn, Vivien Didelot
Cc: Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <E1gvPHw-0008OD-To@rmk-PC.armlinux.org.uk>
Hi Russell,
On 2/17/2019 8:27 AM, 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.
Since this is specific to mv88e6xxx, in case you resubmit, can you put
that in the commit subject as well? Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH net] net: dsa: fix lockdep warning
From: Russell King - ARM Linux admin @ 2019-02-17 17:03 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Vivien Didelot, Heiner Kallweit,
David S. Miller, netdev
In-Reply-To: <20190217170024.GG5968@lunn.ch>
On Sun, Feb 17, 2019 at 06:00:24PM +0100, Andrew Lunn wrote:
> On Sun, Feb 17, 2019 at 04:51:40PM +0000, Russell King - ARM Linux admin wrote:
> > On Sun, Feb 17, 2019 at 05:46:29PM +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
> > > > ------------------------------------------------------
> > >
> > > Hi Russell
> > >
> > > Thanks for turning this into a proper patch. I had just started to try
> > > to reproduce this and confirm your fix. I will add a tested-by once i
> > > do.
> >
> > Do you have a clearfog board? If so, just add:
> >
> > + interrupt-parent = <&gpio0>;
> > + interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
> >
> > to the DSA switch definitions in
> > arch/arm/boot/dts/armada-388-clearfog.dts
>
> Hi Russell
>
> I'm using a different board, but i have a similar interrupt
> configuration. I just expect that turning on LOCKDEP should be enough.
> I don't think EPROBE_DEFFER is playing a part here.
Yep, lockdep should be enough. In case it does matter, I have DSA
built as modules here.
--
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: No traffic with Marvell switch and latest linux-next
From: Heiner Kallweit @ 2019-02-17 17:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: Russell King - ARM Linux admin, Florian Fainelli,
netdev@vger.kernel.org
In-Reply-To: <20190217165730.GF5968@lunn.ch>
On 17.02.2019 17:57, Andrew Lunn wrote:
>> There haven't been that many changes to mv88e8xxx since 5.0-rc6.
>> I reverted 7c0db24cc431 ("dsa: mv88e6xxx: Ensure all pending interrupts
>> are handled prior to exit") who looked like a candidate and bingo:
>> network is working again. Obviously something is wrong with this patch.
>
> O.K. I tested it on an edge interrupt system, but not a level
> interrupt. I wounder if it is related to that somehow? DTU should be
> using level interrupts.
>
Sorry, I may have been too fast with this statement. With this patch
reverted it worked, but now I have a build with this patch still included,
and it works too. Need to dig deeper ..
> Andrew
>
Heiner
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Andrew Lunn @ 2019-02-17 17:10 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Russell King - ARM Linux admin, Florian Fainelli,
netdev@vger.kernel.org
In-Reply-To: <c7050314-8af4-b65f-778d-92b9d4a7cc27@gmail.com>
> Sorry, I may have been too fast with this statement. With this patch
> reverted it worked, but now I have a build with this patch still included,
> and it works too. Need to dig deeper ..
Hi Heiner
Watch out for boot vs reboot, and when rebooting if port 8 had link or
not before you reboot.
Andrew
^ permalink raw reply
* Re: [BUG] [FIX] net: dsa: oops in br_vlan_enabled
From: Florian Fainelli @ 2019-02-17 17:13 UTC (permalink / raw)
To: Frank Wunderlich, netdev, Andrew Lunn, Vivien Didelot
In-Reply-To: <trinity-782c45c1-ef94-4340-8def-f949a4a929a9-1550334156901@3c-app-gmx-bs35>
Hi Frank,
On 2/16/2019 8:22 AM, Frank Wunderlich wrote:
> Hi,
>
> i've found an oops in 4.19.23/10, seems to be fixed anyhow in 5.0 (also works in 4.14.101)
>
> root@bpi-r2:~# ip link add link lan0 name lan0.5 type vlan id 5
> root@bpi-r2:~# ip addr add 192.168.5.200/24 brd 192.168.5.255 dev lan0.5
> root@bpi-r2:~# ip link set dev lan0 up
> root@bpi-r2:~# ip link set dev lan0.5 up
So that these steps don't involve a bridge, and because we don't (yet)
implment ndo_vlan_rx_{add,kill}_vid() netdevice_ops, there is no VLAN
programming, it's all software
>
> 12: lan0.5@lan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
> link/ether 02:02:02:02:02:02 brd ff:ff:ff:ff:ff:ff
> inet 192.168.5.200/24 brd 192.168.5.255 scope global lan0.5
> valid_lft forever preferred_lft forever
>
> root@bpi-r2:~# brctl addbr bridge_name
> root@bpi-r2:~# brctl addif bridge_name lan0.5
Unless you changed the bridge to have VLAN filtering/awareness with:
echo 1 > /sys/class/net/bridge_name/bridge/vlan_filtering
There will be no VLAN configuration/objects pushed to DSA since commit
2ea7a679ca2abd251c1ec03f20508619707e1749 ("net: dsa: Don't add vlans
when vlan filtering is disabled") so I am not sure how you got into that
situation because prior to pushing a VLAN object, the port must be part
of a bridge, so the steps typically look like:
- port_bridge_join which assigns dp->bridge_dev
- port_vlan_add
Does your 4.19.23 kernel somehow change how VLAN objects are pushed down
the switch driver?
> [ 352.057128] bridge_name: port 1(lan0.5) entered blocking state
> [ 352.063065] bridge_name: port 1(lan0.5) entered disabled state
> [ 352.069181] device lan0.5 entered promiscuous mode
> [ 352.074018] device lan0 entered promiscuous mode
> [ 352.078906] Unable to handle kernel NULL pointer dereference at virtual address 00000558
> ...
> [ 352.493085] [<bf0fde88>] (br_vlan_enabled [bridge]) from [<bf12c234>] (dsa_port_vlan_add+0x60/0xbc [dsa_core])
> [ 352.503050] [<bf12c234>] (dsa_port_vlan_add [dsa_core]) from [<bf12cb64>] (dsa_slave_port_obj_add+0x4c/0x50 [dsa_core])
> [ 352.513776] [<bf12cb64>] (dsa_slave_port_obj_add [dsa_core]) from [<c0b4e2d4>] (__switchdev_port_obj_add+0x50/0xc4)
> [ 352.524138] [<c0b4e2d4>] (__switchdev_port_obj_add) from [<c0b4e324>] (__switchdev_port_obj_add+0xa0/0xc4)
> [ 352.533721] [<c0b4e324>] (__switchdev_port_obj_add) from [<c0b4e3a8>] (switchdev_port_obj_add_now+0x60/0x130)
> [ 352.543562] [<c0b4e3a8>] (switchdev_port_obj_add_now) from [<c0b4e7e4>] (switchdev_port_obj_add+0x44/0x190)
> [ 352.553284] [<c0b4e7e4>] (switchdev_port_obj_add) from [<bf1013d0>] (br_switchdev_port_vlan_add+0x60/0x7c [bridge])
> [ 352.563733] [<bf1013d0>] (br_switchdev_port_vlan_add [bridge]) from [<bf0ff250>] (__vlan_add+0xb0/0x620 [bridge])
> [ 352.574007] [<bf0ff250>] (__vlan_add [bridge]) from [<bf0ffd04>] (nbp_vlan_add+0xc4/0x150 [bridge])
> [ 352.583073] [<bf0ffd04>] (nbp_vlan_add [bridge]) from [<bf0ffec4>] (nbp_vlan_init+0x134/0x164 [bridge])
> [ 352.592482] [<bf0ffec4>] (nbp_vlan_init [bridge]) from [<bf0edd4c>] (br_add_if+0x40c/0x5fc [bridge])
> [ 352.601632] [<bf0edd4c>] (br_add_if [bridge]) from [<bf0eeb14>] (add_del_if+0x6c/0x80 [bridge])
> [ 352.610351] [<bf0eeb14>] (add_del_if [bridge]) from [<bf0ef5b0>] (br_dev_ioctl+0x7c/0x9c [bridge])
> [ 352.619290] [<bf0ef5b0>] (br_dev_ioctl [bridge]) from [<c09583d4>] (dev_ifsioc+0x184/0x324)
> [ 352.627582] [<c09583d4>] (dev_ifsioc) from [<c09589e8>] (dev_ioctl+0x32c/0x5cc)
> [ 352.634837] [<c09589e8>] (dev_ioctl) from [<c090913c>] (sock_ioctl+0x3bc/0x580)
>
>
> since my 4.19.23 kernel is modified a bit i tried with 4.19.10 without my net modifications and it is still reproducable with steps above (create a vlan on dsa-user-port and then use it in a bridge)
>
> i fixed it with these changes:
>
> diff --git a/net/dsa/port.c b/net/dsa/port.c
> index ed0595459df1..962887752ae8 100644
> --- a/net/dsa/port.c
> +++ b/net/dsa/port.c
> @@ -255,8 +255,9 @@ int dsa_port_vlan_add(struct dsa_port *dp,
> if (netif_is_bridge_master(vlan->obj.orig_dev))
> return -EOPNOTSUPP;
>
> - if (br_vlan_enabled(dp->bridge_dev))
> - return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
> + printk(KERN_ALERT "DEBUG: Passed %s %d 0x%x \n",__FUNCTION__,__LINE__,(unsigned int)dp->bridge_dev);
> + if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
> + return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
>
> return 0;
> }
> @@ -273,7 +274,7 @@ int dsa_port_vlan_del(struct dsa_port *dp,
> if (netif_is_bridge_master(vlan->obj.orig_dev))
> return -EOPNOTSUPP;
>
> - if (br_vlan_enabled(dp->bridge_dev))
> + if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
> return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
>
> return 0;
>
> i've found in a Patch from florian/vivien: https://www.mail-archive.com/netdev@vger.kernel.org/msg281415.html
>
> Strange that 5.0-rc1 does not crash,because these 2 code-sections are unchanged: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/dsa/port.c#n255 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_vlan.c#n788
>
> maybe you know why only 4.19 is affected...
>
> regards Frank
>
--
Florian
^ permalink raw reply
* Re: [PATCH net] net: dsa: fix lockdep warning
From: Andrew Lunn @ 2019-02-17 17:55 UTC (permalink / raw)
To: Russell King
Cc: Florian Fainelli, Vivien Didelot, Heiner Kallweit,
David S. Miller, netdev
In-Reply-To: <E1gvPHw-0008OD-To@rmk-PC.armlinux.org.uk>
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.
Andrew
^ permalink raw reply
* Re: [PATCH net] mlxsw: __mlxsw_sp_port_headroom_set(): Fix a use of local variable
From: David Miller @ 2019-02-17 18:14 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, mlxsw
In-Reply-To: <20190217071809.19295-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Sun, 17 Feb 2019 07:18:41 +0000
> From: Petr Machata <petrm@mellanox.com>
>
> The function-local variable "delay" enters the loop interpreted as delay
> in bits. However, inside the loop it gets overwritten by the result of
> mlxsw_sp_pg_buf_delay_get(), and thus leaves the loop as quantity in
> cells. Thus on second and further loop iterations, the headroom for a
> given priority is configured with a wrong size.
>
> Fix by introducing a loop-local variable, delay_cells. Rename thres to
> thres_cells for consistency.
>
> Fixes: f417f04da589 ("mlxsw: spectrum: Refactor port buffer configuration")
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied and queued up for -stable, thanks Ido.
^ permalink raw reply
* [PATCH] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat
From: Andrew Lunn @ 2019-02-17 18:11 UTC (permalink / raw)
To: Russell King; +Cc: netdev, Vivien Didelot, Andrew Lunn
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?
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
^ permalink raw reply related
* Re: [PATCH net-next v3 0/4] net: phy: add and use genphy_c45_an_config_an
From: David Miller @ 2019-02-17 18:28 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, linux, netdev
In-Reply-To: <46898fe1-8924-0da0-1bbd-b54c220ff8d1@gmail.com>
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? :-)
^ permalink raw reply
* Re: [PATCH net-next 0/2] tracepoints in neighbor subsystem
From: David Miller @ 2019-02-17 18:34 UTC (permalink / raw)
To: roopa; +Cc: netdev, dsa
In-Reply-To: <1550164511-21195-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Thu, 14 Feb 2019 09:15:09 -0800
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Roopa Prabhu (2):
> trace: events: add a few neigh tracepoints
> neigh: hook tracepoints in neigh update code
Series applied, thanks.
Maybe put some actual text in this intro posting next time, explaining
what the series is doing, how it is doing it, and why?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v5] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: David Miller @ 2019-02-17 18:37 UTC (permalink / raw)
To: callum.sinclair
Cc: kuznet, yoshfuji, nikolay, netdev, linux-kernel, nicolas.dichtel
In-Reply-To: <20190214024418.21490-2-callum.sinclair@alliedtelesis.co.nz>
From: Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
Date: Thu, 14 Feb 2019 15:44:18 +1300
> +#define MRT_FLUSH_VIFS 4 /* Flush multicast vifs */
> +#define MRT_FLUSH_VIFS_STATIC 8 /* Flush static multicast vifs */
Please rename to MRT_FLUSH_MIFS* as suggested by Nicolas and respin.
Thanks.
^ permalink raw reply
* 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
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