* Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: Song Liu @ 2018-09-24 19:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, michael.chan@broadcom.com, Ariel Elior,
Eric Dumazet, Tariq Toukan, Saeed Mahameed, Jeff Kirsher,
jakub.kicinski@netronome.com, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek
In-Reply-To: <CANn89i+8mngtTLs8gzmEFjreW9ie64MPmZWaUDV+KRR7wgNfMA@mail.gmail.com>
> On Sep 24, 2018, at 8:30 AM, Eric Dumazet <edumazet@google.com> wrote:
>
> On Sun, Sep 23, 2018 at 10:04 PM David Miller <davem@davemloft.net> wrote:
>>
>> Series applied, thanks Eric.
>
> Thanks David.
>
> Song, would you please this additional patch ?
>
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index 3219a2932463096566ce8ff336ecdf699422dd65..2ad45babe621b2c979ad5496b7df4342e4efbaa6
> 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -150,13 +150,6 @@ static void poll_one_napi(struct napi_struct *napi)
> {
> int work = 0;
>
> - /* net_rx_action's ->poll() invocations and our's are
> - * synchronized by this test which is only made while
> - * holding the napi->poll_lock.
> - */
> - if (!test_bit(NAPI_STATE_SCHED, &napi->state))
> - return;
> -
> /* If we set this bit but see that it has already been set,
> * that indicates that napi has been disabled and we need
> * to abort this operation
This triggers dev_watchdog() on a simple netperf TCP_RR on bnxt (I haven't
tested other drivers yet).
I guess this is because NAPI_STATE_SCHED is set when poll_one_napi() calls
napi->poll(). And then cleared by napi->poll(). So a packet is missed by
napi (set NAPI_STATE_SCHED, but didn't got handled).
Song
^ permalink raw reply
* Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: Eric Dumazet @ 2018-09-24 19:41 UTC (permalink / raw)
To: songliubraving
Cc: David Miller, netdev, michael.chan, Ariel Elior, Eric Dumazet,
Tariq Toukan, Saeed Mahameed, Jeff Kirsher, jakub.kicinski,
Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <B352B219-D053-432C-AEB7-C0A74D2F6613@fb.com>
On Mon, Sep 24, 2018 at 12:31 PM Song Liu <songliubraving@fb.com> wrote:
> This triggers dev_watchdog() on a simple netperf TCP_RR on bnxt (I haven't
> tested other drivers yet).
>
> I guess this is because NAPI_STATE_SCHED is set when poll_one_napi() calls
> napi->poll(). And then cleared by napi->poll().
Which part of napi->poll() could possibly clear NAPI_STATE_SCHED when
called by netpoll ?
AFAIK, napi_complete_done() should exit early (before having a chance
to clear NAPI_STATE_SCHED)
because of :
if (unlikely(n->state & (NAPIF_STATE_NPSVC | NAPIF_STATE_IN_BUSY_POLL)))
return false;
Thanks !
^ permalink raw reply
* Re: [PATCH net 2/2] net: phy: fix WoL handling when suspending the PHY
From: Heiner Kallweit @ 2018-09-24 19:56 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, David Miller,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <6b5a93d4-46c8-7928-eea5-76740071b5a7@gmail.com>
On 24.09.2018 20:21, Florian Fainelli wrote:
> On 09/24/2018 11:11 AM, Heiner Kallweit wrote:
>> Core of the problem is that phy_suspend() suspends the PHY when it
>> should not because of WoL. phy_suspend() checks for WoL already, but
>> this works only if the PHY driver handles WoL (what is rarely the case).
>> Typically WoL is handled by the MAC driver.
>>
>> This patch uses new member wol_enabled of struct net_device as
>> additional criteria in the check when not to suspend the PHY because
>> of WoL.
>>
>> Last but not least change phy_detach() to call phy_suspend() before
>> attached_dev is set to NULL. phy_suspend() accesses attached_dev
>> when checking whether the MAC driver activated WoL.
>
> Looks fine to me, just a few nits/questions down below:
>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>
>>
>> Fixes: f1e911d5d0df ("r8169: add basic phylib support")
>> Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> drivers/net/phy/phy_device.c | 12 +++++++++---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index af64a9320..6c0195e53 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -93,7 +93,12 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
>> if (!netdev)
>> return !phydev->suspended;
>>
>> - /* Don't suspend PHY if the attached netdev parent may wakeup.
>> + if (netdev->wol_enabled)
>> + return false;
>> +
>> + /* As lang as not all affected network drivers support the
>> + * wol_enabled flag, let's check for hints that WoL is enabled.
>
> Typo: as long (sorry for being that nitpicky).
>
>> + * Don't suspend PHY if the attached netdev parent may wakeup.
>> * The parent may point to a PCI device, as in tg3 driver.
>> */
>> if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
>> @@ -1132,9 +1137,9 @@ void phy_detach(struct phy_device *phydev)
>> sysfs_remove_link(&dev->dev.kobj, "phydev");
>> sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
>> }
>> + phy_suspend(phydev);
>> phydev->attached_dev->phydev = NULL;
>> phydev->attached_dev = NULL;
>> - phy_suspend(phydev);
>> phydev->phylink = NULL;
>>
>> phy_led_triggers_unregister(phydev);
>> @@ -1168,12 +1173,13 @@ EXPORT_SYMBOL(phy_detach);
>> int phy_suspend(struct phy_device *phydev)
>> {
>> struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
>> + struct net_device *netdev = phydev->attached_dev;
>> struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
>> int ret = 0;
>>
>> /* If the device has WOL enabled, we cannot suspend the PHY */
>> phy_ethtool_get_wol(phydev, &wol);
>> - if (wol.wolopts)
>> + if (wol.wolopts || (netdev && netdev->wol_enabled))
>
> Since you moved the phydev->attached_dev assignment to be after
> phy_suspend(), do you really need to check for netdev here? Is there
> another code path you found that might be running phy_suspend() with a
> disconnected PHY? Not a problem per-se, just wondering.
>
There's a call to phy_suspend() in the phylib state machine and I'm
not sure we can guarantee that a netdevice is attached.
Because phy_suspend() is exported anybody can use it, correct or
incorrect. Therefore I'd say core functions better should play safe.
^ permalink raw reply
* [PATCH net v2 0/2] net: phy: fix WoL handling when suspending the PHY
From: Heiner Kallweit @ 2018-09-24 19:58 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
phy_suspend doesn't always recognize that WoL is enabled and therefore
suspends the PHY when it should not. First idea to address the issue
was to reuse checks used in mdio_bus_phy_may_suspend which check
whether relevant devices are wakeup-enabled.
Florian raised some concerns because drivers may enable wakeup even if
WoL isn't enabled (e.g. certain USB network drivers).
The new approach focuses on reducing the risk to break existing stuff.
We add a flag wol_enabled to struct net_device which is set in
ethtool_set_wol(). Then this flag is checked in phy_suspend().
This doesn't cover 100% of the cases yet (e.g. if WoL is enabled w/o
explicit configuration), but it covers the most relevant cases with
very little risk of regressions.
v2:
- Fix a typo
Heiner Kallweit (2):
net: core: add member wol_enabled to struct net_device
net: phy: fix WoL handling when suspending the PHY
drivers/net/phy/phy_device.c | 12 +++++++++---
include/linux/netdevice.h | 3 +++
net/core/ethtool.c | 9 ++++++++-
3 files changed, 20 insertions(+), 4 deletions(-)
--
2.19.0
^ permalink raw reply
* Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: Song Liu @ 2018-09-24 20:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, michael.chan@broadcom.com, Ariel Elior,
Eric Dumazet, Tariq Toukan, Saeed Mahameed, Jeff Kirsher,
jakub.kicinski@netronome.com, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek
In-Reply-To: <CANn89iLdMaW6rcK3+JT3J56M3xT2pgPPEpQRhngBL4DocMNChw@mail.gmail.com>
> On Sep 24, 2018, at 12:41 PM, Eric Dumazet <edumazet@google.com> wrote:
>
> On Mon, Sep 24, 2018 at 12:31 PM Song Liu <songliubraving@fb.com> wrote:
>
>> This triggers dev_watchdog() on a simple netperf TCP_RR on bnxt (I haven't
>> tested other drivers yet).
>>
>> I guess this is because NAPI_STATE_SCHED is set when poll_one_napi() calls
>> napi->poll(). And then cleared by napi->poll().
>
> Which part of napi->poll() could possibly clear NAPI_STATE_SCHED when
> called by netpoll ?
>
> AFAIK, napi_complete_done() should exit early (before having a chance
> to clear NAPI_STATE_SCHED)
> because of :
>
> if (unlikely(n->state & (NAPIF_STATE_NPSVC | NAPIF_STATE_IN_BUSY_POLL)))
> return false;
>
> Thanks !
You are right on this condition. But this does trigger dev_watchdog() for
some reason.
Thanks,
Song
^ permalink raw reply
* [PATCH net v2 1/2] net: core: add member wol_enabled to struct net_device
From: Heiner Kallweit @ 2018-09-24 19:58 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <43386295-806b-ff32-4c7c-56aaeb87b4db@gmail.com>
Add flag wol_enabled to struct net_device indicating whether
Wake-on-LAN is enabled. As first user phy_suspend() will use it to
decide whether PHY can be suspended or not.
Fixes: f1e911d5d0df ("r8169: add basic phylib support")
Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
include/linux/netdevice.h | 3 +++
net/core/ethtool.c | 9 ++++++++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 1cbbf77a6..f5f1f1450 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1756,6 +1756,8 @@ enum netdev_priv_flags {
* switch driver and used to set the phys state of the
* switch port.
*
+ * @wol_enabled: Wake-on-LAN is enabled
+ *
* FIXME: cleanup struct net_device such that network protocol info
* moves out.
*/
@@ -2039,6 +2041,7 @@ struct net_device {
struct lock_class_key *qdisc_tx_busylock;
struct lock_class_key *qdisc_running_key;
bool proto_down;
+ unsigned wol_enabled:1;
};
#define to_net_dev(d) container_of(d, struct net_device, dev)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 9d4e56d97..86f765d42 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1395,6 +1395,7 @@ static int ethtool_get_wol(struct net_device *dev, char __user *useraddr)
static int ethtool_set_wol(struct net_device *dev, char __user *useraddr)
{
struct ethtool_wolinfo wol;
+ int ret;
if (!dev->ethtool_ops->set_wol)
return -EOPNOTSUPP;
@@ -1402,7 +1403,13 @@ static int ethtool_set_wol(struct net_device *dev, char __user *useraddr)
if (copy_from_user(&wol, useraddr, sizeof(wol)))
return -EFAULT;
- return dev->ethtool_ops->set_wol(dev, &wol);
+ ret = dev->ethtool_ops->set_wol(dev, &wol);
+ if (ret)
+ return ret;
+
+ dev->wol_enabled = !!wol.wolopts;
+
+ return 0;
}
static int ethtool_get_eee(struct net_device *dev, char __user *useraddr)
--
2.19.0
^ permalink raw reply related
* [PATCH net v2 2/2] net: phy: fix WoL handling when suspending the PHY
From: Heiner Kallweit @ 2018-09-24 20:01 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <a32b98eb-3071-2269-ab95-a44f90866912@gmail.com>
Core of the problem is that phy_suspend() suspends the PHY when it
should not because of WoL. phy_suspend() checks for WoL already, but
this works only if the PHY driver handles WoL (what is rarely the case).
Typically WoL is handled by the MAC driver.
This patch uses new member wol_enabled of struct net_device as
additional criteria in the check when not to suspend the PHY because
of WoL.
Last but not least change phy_detach() to call phy_suspend() before
attached_dev is set to NULL. phy_suspend() accesses attached_dev
when checking whether the MAC driver activated WoL.
Fixes: f1e911d5d0df ("r8169: add basic phylib support")
Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
v2:
- fix typo in comment
---
drivers/net/phy/phy_device.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index af64a9320..6c0195e53 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -93,7 +93,12 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
if (!netdev)
return !phydev->suspended;
- /* Don't suspend PHY if the attached netdev parent may wakeup.
+ if (netdev->wol_enabled)
+ return false;
+
+ /* As long as not all affected network drivers support the
+ * wol_enabled flag, let's check for hints that WoL is enabled.
+ * Don't suspend PHY if the attached netdev parent may wake up.
* The parent may point to a PCI device, as in tg3 driver.
*/
if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
@@ -1132,9 +1137,9 @@ void phy_detach(struct phy_device *phydev)
sysfs_remove_link(&dev->dev.kobj, "phydev");
sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
}
+ phy_suspend(phydev);
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
- phy_suspend(phydev);
phydev->phylink = NULL;
phy_led_triggers_unregister(phydev);
@@ -1168,12 +1173,13 @@ EXPORT_SYMBOL(phy_detach);
int phy_suspend(struct phy_device *phydev)
{
struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
+ struct net_device *netdev = phydev->attached_dev;
struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
int ret = 0;
/* If the device has WOL enabled, we cannot suspend the PHY */
phy_ethtool_get_wol(phydev, &wol);
- if (wol.wolopts)
+ if (wol.wolopts || (netdev && netdev->wol_enabled))
return -EBUSY;
if (phydev->drv && phydrv->suspend)
--
2.19.0
^ permalink raw reply related
* bond: take rcu lock in bond_poll_controller
From: Dave Jones @ 2018-09-24 19:23 UTC (permalink / raw)
To: netdev
Callers of bond_for_each_slave_rcu are expected to hold the rcu lock,
otherwise a trace like below is shown
WARNING: CPU: 2 PID: 179 at net/core/dev.c:6567 netdev_lower_get_next_private_rcu+0x34/0x40
CPU: 2 PID: 179 Comm: kworker/u16:15 Not tainted 4.19.0-rc5-backup+ #1
Workqueue: bond0 bond_mii_monitor
RIP: 0010:netdev_lower_get_next_private_rcu+0x34/0x40
Code: 48 89 fb e8 fe 29 63 ff 85 c0 74 1e 48 8b 45 00 48 81 c3 c0 00 00 00 48 8b 00 48 39 d8 74 0f 48 89 45 00 48 8b 40 f8 5b 5d c3 <0f> 0b eb de 31 c0 eb f5 0f 1f 40 00 0f 1f 44 00 00 48 8>
RSP: 0018:ffffc9000087fa68 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff880429614560 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 00000000ffffffff RDI: ffffffffa184ada0
RBP: ffffc9000087fa80 R08: 0000000000000001 R09: 0000000000000000
R10: ffffc9000087f9f0 R11: ffff880429798040 R12: ffff8804289d5980
R13: ffffffffa1511f60 R14: 00000000000000c8 R15: 00000000ffffffff
FS: 0000000000000000(0000) GS:ffff88042f880000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4b78fce180 CR3: 000000018180f006 CR4: 00000000001606e0
Call Trace:
bond_poll_controller+0x52/0x170
netpoll_poll_dev+0x79/0x290
netpoll_send_skb_on_dev+0x158/0x2c0
netpoll_send_udp+0x2d5/0x430
write_ext_msg+0x1e0/0x210
console_unlock+0x3c4/0x630
vprintk_emit+0xfa/0x2f0
printk+0x52/0x6e
? __netdev_printk+0x12b/0x220
netdev_info+0x64/0x80
? bond_3ad_set_carrier+0xe9/0x180
bond_select_active_slave+0x1fc/0x310
bond_mii_monitor+0x709/0x9b0
process_one_work+0x221/0x5e0
worker_thread+0x4f/0x3b0
kthread+0x100/0x140
? process_one_work+0x5e0/0x5e0
? kthread_delayed_work_timer_fn+0x90/0x90
ret_from_fork+0x24/0x30
Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a764a83f99da..519968d4513b 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -978,6 +978,7 @@ static void bond_poll_controller(struct net_device *bond_dev)
if (bond_3ad_get_active_agg_info(bond, &ad_info))
return;
+ rcu_read_lock();
bond_for_each_slave_rcu(bond, slave, iter) {
ops = slave->dev->netdev_ops;
if (!bond_slave_is_up(slave) || !ops->ndo_poll_controller)
@@ -998,6 +999,7 @@ static void bond_poll_controller(struct net_device *bond_dev)
ops->ndo_poll_controller(slave->dev);
up(&ni->dev_lock);
}
+ rcu_read_unlock();
}
static void bond_netpoll_cleanup(struct net_device *bond_dev)
^ permalink raw reply related
* Re: [PATCH net-next v1 5/5] ipv6: add vrf table handling code for ipv6 mcast
From: David Ahern @ 2018-09-24 20:13 UTC (permalink / raw)
To: Mike Manning, netdev; +Cc: Patrick Ruddy
In-Reply-To: <20180924161326.17167-6-mmanning@vyatta.att-mail.com>
just started looking at this set. Compiler notes one problem:
On 9/24/18 10:13 AM, Mike Manning wrote:
> @@ -2146,6 +2157,7 @@ static void ip6_mr_forward(struct net *net, struct mr_table *mrt,
>
> int ip6_mr_input(struct sk_buff *skb)
> {
> + struct rtable *rt = skb_rtable(skb);
The above change is not needed.
$ make -j 24 -s
/home/dsa/kernel-2.git/net/ipv6/ip6mr.c: In function ‘ip6_mr_input’:
/home/dsa/kernel-2.git/net/ipv6/ip6mr.c:2160:17: warning: unused
variable ‘rt’ [-Wunused-variable]
struct rtable *rt = skb_rtable(skb);
> struct mfc6_cache *cache;
> struct net *net = dev_net(skb->dev);
> struct mr_table *mrt;
> @@ -2154,6 +2166,19 @@ int ip6_mr_input(struct sk_buff *skb)
> .flowi6_mark = skb->mark,
> };
> int err;
> + struct net_device *dev;
> +
> + /* skb->dev passed in is the master dev for vrfs.
> + * Get the proper interface that does have a vif associated with it.
> + */
> + dev = skb->dev;
> + if (netif_is_l3_master(skb->dev)) {
> + dev = dev_get_by_index_rcu(net, IPCB(skb)->iif);
> + if (!dev) {
> + kfree_skb(skb);
> + return -ENODEV;
> + }
> + }
>
> err = ip6mr_fib_lookup(net, &fl6, &mrt);
> if (err < 0) {
> @@ -2165,7 +2190,7 @@ int ip6_mr_input(struct sk_buff *skb)
> cache = ip6mr_cache_find(mrt,
> &ipv6_hdr(skb)->saddr, &ipv6_hdr(skb)->daddr);
> if (!cache) {
> - int vif = ip6mr_find_vif(mrt, skb->dev);
> + int vif = ip6mr_find_vif(mrt, dev);
>
> if (vif >= 0)
> cache = ip6mr_cache_find_any(mrt,
> @@ -2179,9 +2204,9 @@ int ip6_mr_input(struct sk_buff *skb)
> if (!cache) {
> int vif;
>
> - vif = ip6mr_find_vif(mrt, skb->dev);
> + vif = ip6mr_find_vif(mrt, dev);
> if (vif >= 0) {
> - int err = ip6mr_cache_unresolved(mrt, vif, skb);
> + int err = ip6mr_cache_unresolved(mrt, vif, skb, dev);
> read_unlock(&mrt_lock);
>
> return err;
> @@ -2191,7 +2216,7 @@ int ip6_mr_input(struct sk_buff *skb)
> return -ENODEV;
> }
>
> - ip6_mr_forward(net, mrt, skb, cache);
> + ip6_mr_forward(net, mrt, dev, skb, cache);
>
> read_unlock(&mrt_lock);
>
^ permalink raw reply
* Re: r8169 hang on 4.18
From: Heiner Kallweit @ 2018-09-24 20:21 UTC (permalink / raw)
To: Ortwin Glück, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <332fecce-3fab-1c92-1558-67a1d90d6372@odi.ch>
On 24.09.2018 14:00, Ortwin Glück wrote:
> Hi,
>
> Stable kernel has stability problems on r8169 that were not present in 4.17.3:
>
> [ 0.000000] Linux version 4.18.8 (kbuild@lofw) (gcc version 7.3.0 (Gentoo 7.3.0-r3 p1.4)) #70 SMP PREEMPT Mon Sep 17 17:56:57 CEST 2018
> [ 0.000000] Command line: BOOT_IMAGE=/boot/linux-4.18.8 root=LABEL=ROOT ro rootfstype=ext4 net.ifnames=0 pci=nomsi
>
> [ 1.772849] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [ 1.772852] r8169 0000:07:00.0: can't disable ASPM; OS doesn't have ASPM control
> [ 1.784948] r8169 0000:07:00.0 eth4: RTL8168h/8111h, 50:9a:4c:2e:92:be, XID 54100800, IRQ 16
> [ 1.784949] r8169 0000:07:00.0 eth4: jumbo features [frames: 9200 bytes, tx checksumming: ko]
>
> We saw the interface unresponsive twice during the last 3 days with:
>
> [Mon Sep 24 11:35:56 2018] ------------[ cut here ]------------
> [Mon Sep 24 11:35:56 2018] NETDEV WATCHDOG: wan (r8169): transmit queue 0 timed out
> [Mon Sep 24 11:35:56 2018] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x215/0x220
> [Mon Sep 24 11:35:56 2018] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.18.8 #70
> [Mon Sep 24 11:35:56 2018] Hardware name: Dell Inc. OptiPlex 3050/0W0CHX, BIOS 1.6.5 09/09/2017
> [Mon Sep 24 11:35:56 2018] RIP: 0010:dev_watchdog+0x215/0x220
> [Mon Sep 24 11:35:56 2018] Code: 49 63 4c 24 e8 eb 8c 4c 89 ef c6 05 1a 19 ca 00 01 e8 5f 52 fd ff 89 d9 4c 89 ee 48 c7 c7 78 ab 67 89 48 89 c2 e8 1b 2b 49 ff <0f> 0b eb be 0f 1f 80 00 00 00 00 41 57 45 89 cf 41 56 49 89 d6 41
> [Mon Sep 24 11:35:56 2018] RSP: 0018:ffff96f05dd03e98 EFLAGS: 00010282
> [Mon Sep 24 11:35:56 2018] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
> [Mon Sep 24 11:35:56 2018] RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff96f05dd15350
> [Mon Sep 24 11:35:56 2018] RBP: ffff96f0462ee41c R08: 0000000000000001 R09: 000000000000133d
> [Mon Sep 24 11:35:56 2018] R10: 0000000000000202 R11: 0000000000000000 R12: ffff96f0462ee438
> [Mon Sep 24 11:35:56 2018] R13: ffff96f0462ee000 R14: 0000000000000001 R15: ffff96f0455eaa80
> [Mon Sep 24 11:35:56 2018] FS: 0000000000000000(0000) GS:ffff96f05dd00000(0000) knlGS:0000000000000000
> [Mon Sep 24 11:35:56 2018] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [Mon Sep 24 11:35:56 2018] CR2: 000055c9498766e0 CR3: 00000000bb80a006 CR4: 00000000003606e0
> [Mon Sep 24 11:35:56 2018] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [Mon Sep 24 11:35:56 2018] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [Mon Sep 24 11:35:56 2018] Call Trace:
> [Mon Sep 24 11:35:56 2018] <IRQ>
> [Mon Sep 24 11:35:56 2018] ? pfifo_fast_reset+0x130/0x130
> [Mon Sep 24 11:35:56 2018] ? pfifo_fast_reset+0x130/0x130
> [Mon Sep 24 11:35:56 2018] call_timer_fn+0x11/0x70
> [Mon Sep 24 11:35:56 2018] expire_timers+0x8e/0xa0
> [Mon Sep 24 11:35:56 2018] run_timer_softirq+0xb9/0x160
> [Mon Sep 24 11:35:56 2018] ? __hrtimer_run_queues+0x135/0x1a0
> [Mon Sep 24 11:35:56 2018] ? hw_breakpoint_pmu_read+0x10/0x10
> [Mon Sep 24 11:35:56 2018] ? ktime_get+0x39/0x90
> [Mon Sep 24 11:35:56 2018] ? lapic_next_event+0x20/0x20
> [Mon Sep 24 11:35:56 2018] __do_softirq+0xcb/0x1f8
> [Mon Sep 24 11:35:56 2018] irq_exit+0xa9/0xb0
> [Mon Sep 24 11:35:56 2018] smp_apic_timer_interrupt+0x59/0x90
> [Mon Sep 24 11:35:56 2018] apic_timer_interrupt+0xf/0x20
> [Mon Sep 24 11:35:56 2018] </IRQ>
> [Mon Sep 24 11:35:56 2018] RIP: 0010:cpuidle_enter_state+0x129/0x200
> [Mon Sep 24 11:35:56 2018] Code: 45 00 89 c3 e8 d8 3b 55 ff 65 8b 3d b1 eb 45 77 e8 8c 3a 55 ff 31 ff 49 89 c4 e8 72 43 55 ff fb 48 ba cf f7 53 e3 a5 9b c4 20 <4c> 89 e1 4c 29 e9 48 89 c8 48 c1 f9 3f 48 f7 ea b8 ff ff ff 7f 48
> [Mon Sep 24 11:35:56 2018] RSP: 0018:ffff9a93c06e7ea8 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> [Mon Sep 24 11:35:56 2018] RAX: ffff96f05dd1f800 RBX: 0000000000000003 RCX: 000000000000001f
> [Mon Sep 24 11:35:56 2018] RDX: 20c49ba5e353f7cf RSI: 00000000258f0602 RDI: 0000000000000000
> [Mon Sep 24 11:35:56 2018] RBP: ffff96f05dd25ee0 R08: 00000000000002b4 R09: 00000000ffffffff
> [Mon Sep 24 11:35:56 2018] R10: ffff9a93c06e7e90 R11: 0000000000000142 R12: 00012ec849a182b9
> [Mon Sep 24 11:35:56 2018] R13: 00012ec8499ddf88 R14: 0000000000000003 R15: 0000000000000000
> [Mon Sep 24 11:35:56 2018] ? cpuidle_enter_state+0x11e/0x200
> [Mon Sep 24 11:35:56 2018] do_idle+0x1c0/0x200
> [Mon Sep 24 11:35:56 2018] cpu_startup_entry+0x6a/0x70
> [Mon Sep 24 11:35:56 2018] start_secondary+0x18a/0x1c0
> [Mon Sep 24 11:35:56 2018] secondary_startup_64+0xa5/0xb0
> [Mon Sep 24 11:35:56 2018] ---[ end trace 327bd9c035abe307 ]---
>
> This is the built-in ethernet port on a Dell main board:
> 07:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
> Subsystem: Dell RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [1028:07a3]
> Flags: bus master, fast devsel, latency 0, IRQ 16
> I/O ports at e000 [size=256]
> Memory at f7404000 (64-bit, non-prefetchable) [size=4K]
> Memory at f7400000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [70] Express Endpoint, MSI 01
> Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
> Capabilities: [170] Latency Tolerance Reporting
> Capabilities: [178] L1 PM Substates
> Kernel driver in use: r8169
>
> The box has an extra 4-way ethernet card that uses the same driver. We had to set pci=nomsi because the card frequently behaved erratic with msi on.
>
> Thanks,
>
> Ortwin
>
Thanks for the report. Here come a few inquiries:
You say the box has one on-board network port and four network ports on
an extension card, all five driven by r8169. The on-board chip is a
RTL8168h, what's the type of the chips on the extension card?
I'm asking because r8169 supports ~ 50 chip variants of the RTL8169/8
family.
Are the problems the same on all five ports?
Can you reproduce the problem (how)? Any specific network usage
triggering the problem?
The root cause of the problem not necessarily is in r8169, some other
change could have broken it too. Can you test using r8169 from 4.18
on top of 4.17?
When stating "behaves erratic" you refer to the network hangs
mentioned before? Or to some other issue?
A similar report is here:
https://bugzilla.kernel.org/show_bug.cgi?id=201109
There the problem seems to start with the upgrade from 4.18.4 to 4.18.5.
Can you try with 4.18.4 ?
The diff between 4.18.4 and 4.18.5 shows nothing related to r8169.
Rgds, Heiner
^ permalink raw reply
* Re: [PATCH v2] rtlwifi: btcoex: Use proper enumerated types for Wi-Fi only interface
From: Pkshih @ 2018-09-25 2:43 UTC (permalink / raw)
To: kvalo@codeaurora.org, natechancellor@gmail.com
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180923063114.11446-1-natechancellor@gmail.com>
On Sat, 2018-09-22 at 23:31 -0700, Nathan Chancellor wrote:
> Clang warns when one enumerated type is implicitly converted to another.
>
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1327:34:
> warning: implicit conversion from enumeration type 'enum
> btc_chip_interface' to different enumeration type 'enum
> wifionly_chip_interface' [-Wenum-conversion]
> wifionly_cfg->chip_interface = BTC_INTF_PCI;
> ~ ^~~~~~~~~~~~
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1330:34:
> warning: implicit conversion from enumeration type 'enum
> btc_chip_interface' to different enumeration type 'enum
> wifionly_chip_interface' [-Wenum-conversion]
> wifionly_cfg->chip_interface = BTC_INTF_USB;
> ~ ^~~~~~~~~~~~
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1333:34:
> warning: implicit conversion from enumeration type 'enum
> btc_chip_interface' to different enumeration type 'enum
> wifionly_chip_interface' [-Wenum-conversion]
> wifionly_cfg->chip_interface = BTC_INTF_UNKNOWN;
> ~ ^~~~~~~~~~~~~~~~
> 3 warnings generated.
>
> Use the values from the correct enumerated type, wifionly_chip_interface.
>
> BTC_INTF_UNKNOWN = WIFIONLY_INTF_UNKNOWN = 0
> BTC_INTF_PCI = WIFIONLY_INTF_PCI = 1
> BTC_INTF_USB = WIFIONLY_INTF_USB = 2
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/135
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
^ permalink raw reply
* [PATCH bpf-next] flow_dissector: lookup netns by skb->sk if skb->dev is NULL
From: Willem de Bruijn @ 2018-09-24 20:49 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
BPF flow dissectors are configured per network namespace.
__skb_flow_dissect looks up the netns through dev_net(skb->dev).
In some dissector paths skb->dev is NULL, such as for Unix sockets.
In these cases fall back to looking up the netns by socket.
Analyzing the codepaths leading to __skb_flow_dissect I did not find
a case where both skb->dev and skb->sk are NULL. Warn and fall back to
standard flow dissector if one is found.
Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/core/flow_dissector.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 5c5dd74b5b3b..738c7562e1e0 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -714,7 +714,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
struct flow_dissector_key_vlan *key_vlan;
enum flow_dissect_ret fdret;
enum flow_dissector_key_id dissector_vlan = FLOW_DISSECTOR_KEY_MAX;
- struct bpf_prog *attached;
+ struct bpf_prog *attached = NULL;
int num_hdrs = 0;
u8 ip_proto = 0;
bool ret;
@@ -755,8 +755,14 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
target_container);
rcu_read_lock();
- attached = skb ? rcu_dereference(dev_net(skb->dev)->flow_dissector_prog)
- : NULL;
+ if (skb) {
+ if (skb->dev)
+ attached = rcu_dereference(dev_net(skb->dev)->flow_dissector_prog);
+ else if (skb->sk)
+ attached = rcu_dereference(sock_net(skb->sk)->flow_dissector_prog);
+ else
+ WARN_ON_ONCE(1);
+ }
if (attached) {
/* Note that even though the const qualifier is discarded
* throughout the execution of the BPF program, all changes(the
--
2.19.0.444.g18242da7ef-goog
^ permalink raw reply related
* Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: Eric Dumazet @ 2018-09-24 20:56 UTC (permalink / raw)
To: songliubraving
Cc: David Miller, netdev, michael.chan, Ariel Elior, Eric Dumazet,
Tariq Toukan, Saeed Mahameed, Jeff Kirsher, jakub.kicinski,
Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <ED77932E-558E-4422-AA7C-2DEED4F2954C@fb.com>
On Mon, Sep 24, 2018 at 1:00 PM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Sep 24, 2018, at 12:41 PM, Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Mon, Sep 24, 2018 at 12:31 PM Song Liu <songliubraving@fb.com> wrote:
> >
> >> This triggers dev_watchdog() on a simple netperf TCP_RR on bnxt (I haven't
> >> tested other drivers yet).
> >>
> >> I guess this is because NAPI_STATE_SCHED is set when poll_one_napi() calls
> >> napi->poll(). And then cleared by napi->poll().
> >
> > Which part of napi->poll() could possibly clear NAPI_STATE_SCHED when
> > called by netpoll ?
> >
> > AFAIK, napi_complete_done() should exit early (before having a chance
> > to clear NAPI_STATE_SCHED)
> > because of :
> >
> > if (unlikely(n->state & (NAPIF_STATE_NPSVC | NAPIF_STATE_IN_BUSY_POLL)))
> > return false;
> >
> > Thanks !
>
> You are right on this condition. But this does trigger dev_watchdog() for
> some reason.
Interesting, maybe a bnxt specific issue.
It seems their model is to process TX/RX notification in the same queue,
they throw away RX events if budget == 0
It means commit e7b9569102995ebc26821789628eef45bd9840d8 is wrong and
must be reverted.
Otherwise, we have a possibility of blocking a queue under netpoll pressure.
^ permalink raw reply
* Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: Eric Dumazet @ 2018-09-24 21:05 UTC (permalink / raw)
To: songliubraving
Cc: David Miller, netdev, michael.chan, Ariel Elior, Eric Dumazet,
Tariq Toukan, Saeed Mahameed, Jeff Kirsher, jakub.kicinski,
Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <CANn89iL46aONnTP6+Mb=tSq2-ywntAMwasLEuCs8VNBd5jqitg@mail.gmail.com>
>
> Interesting, maybe a bnxt specific issue.
>
> It seems their model is to process TX/RX notification in the same queue,
> they throw away RX events if budget == 0
>
> It means commit e7b9569102995ebc26821789628eef45bd9840d8 is wrong and
> must be reverted.
>
> Otherwise, we have a possibility of blocking a queue under netpoll pressure.
Hmm, actually a revert might not be enough, since code at lines 2030-2031
would fire and we might not call napi_complete_done() anyway.
Unfortunately this driver logic is quite complex.
Could you test on other NIC eventually ?
Thanks.
^ permalink raw reply
* Re: [bpf-next, v4 0/5] Introduce eBPF flow dissector
From: Willem de Bruijn @ 2018-09-24 21:14 UTC (permalink / raw)
To: Petar Penkov
Cc: ys114321, Alexei Starovoitov, Petar Penkov, Network Development,
David Miller, Alexei Starovoitov, Daniel Borkmann, simon.horman,
ecree, songliubraving, Tom Herbert
In-Reply-To: <CAG4SDVVib24cyjvzzKBYbvhY8fgMZwcfq5jwCNuX3iipO_+P0w@mail.gmail.com>
On Fri, Sep 14, 2018 at 5:51 PM Petar Penkov <ppenkov@google.com> wrote:
>
> On Fri, Sep 14, 2018 at 2:47 PM, Y Song <ys114321@gmail.com> wrote:
> > On Fri, Sep 14, 2018 at 12:24 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> >>
> >> On Fri, Sep 14, 2018 at 07:46:17AM -0700, Petar Penkov wrote:
> >> > From: Petar Penkov <ppenkov@google.com>
> >> >
> >> > This patch series hardens the RX stack by allowing flow dissection in BPF,
> >> > as previously discussed [1]. Because of the rigorous checks of the BPF
> >> > verifier, this provides significant security guarantees. In particular, the
> >> > BPF flow dissector cannot get inside of an infinite loop, as with
> >> > CVE-2013-4348, because BPF programs are guaranteed to terminate. It cannot
> >> > read outside of packet bounds, because all memory accesses are checked.
> >> > Also, with BPF the administrator can decide which protocols to support,
> >> > reducing potential attack surface. Rarely encountered protocols can be
> >> > excluded from dissection and the program can be updated without kernel
> >> > recompile or reboot if a bug is discovered.
> >> >
> >> > Patch 1 adds infrastructure to execute a BPF program in __skb_flow_dissect.
> >> > This includes a new BPF program and attach type.
> >> >
> >> > Patch 2 adds the new BPF flow dissector definitions to tools/uapi.
> >> >
> >> > Patch 3 adds support for the new BPF program type to libbpf and bpftool.
> >> >
> >> > Patch 4 adds a flow dissector program in BPF. This parses most protocols in
> >> > __skb_flow_dissect in BPF for a subset of flow keys (basic, control, ports,
> >> > and address types).
> >> >
> >> > Patch 5 adds a selftest that attaches the BPF program to the flow dissector
> >> > and sends traffic with different levels of encapsulation.
> >> >
> >> > Performance Evaluation:
> >> > The in-kernel implementation was compared against the demo program from
> >> > patch 4 using the test in patch 5 with IPv4/UDP traffic over 10 seconds.
> >> > $perf record -a -C 4 taskset -c 4 ./test_flow_dissector -i 4 -f 8 \
> >> > -t 10
> >>
> >> Looks great. Applied to bpf-next with one extra patch:
> >> SEC("dissect")
> >> -int dissect(struct __sk_buff *skb)
> >> +int _dissect(struct __sk_buff *skb)
> >>
> >> otherwise the test doesn't build.
> >> I'm not sure how it builds for you. Which llvm did you use?
> >
> > This is a known issue. IIRC, llvm <= 4 should be okay and llvm >= 5 would fail.
> >
> I was running a much older version of llvm so I imagine this was the
> issue. Thanks for the fix!
> >>
> >> Also above command works and ipv4 test in ./test_flow_dissector.sh
> >> is passing as well, but it still fails at the end for me:
> >> ./test_flow_dissector.sh
> >> bpffs not mounted. Mounting...
> >> 0: IP
> >> 1: IPV6
> >> 2: IPV6OP
> >> 3: IPV6FR
> >> 4: MPLS
> >> 5: VLAN
> >> Testing IPv4...
> >> inner.dest4: 127.0.0.1
> >> inner.source4: 127.0.0.3
> >> pkts: tx=10 rx=10
> >> inner.dest4: 127.0.0.1
> >> inner.source4: 127.0.0.3
> >> pkts: tx=10 rx=0
> >> inner.dest4: 127.0.0.1
> >> inner.source4: 127.0.0.3
> >> pkts: tx=10 rx=10
> >> Testing IPIP...
> >> tunnels before test:
> >> tunl0: any/ip remote any local any ttl inherit nopmtudisc
> >> sit_test_LV5N: any/ip remote 127.0.0.2 local 127.0.0.1 dev lo ttl inherit
> >> ipip_test_LV5N: any/ip remote 127.0.0.2 local 127.0.0.1 dev lo ttl inherit
> >> sit0: ipv6/ip remote any local any ttl 64 nopmtudisc
> >> gre_test_LV5N: gre/ip remote 127.0.0.2 local 127.0.0.1 dev lo ttl inherit
> >> gre0: gre/ip remote any local any ttl inherit nopmtudisc
> >> inner.dest4: 192.168.0.1
> >> inner.source4: 1.1.1.1
> >> encap proto: 4
> >> outer.dest4: 127.0.0.1
> >> outer.source4: 127.0.0.2
> >> pkts: tx=10 rx=0
> >> tunnels after test:
> >> tunl0: any/ip remote any local any ttl inherit nopmtudisc
> >> sit0: ipv6/ip remote any local any ttl 64 nopmtudisc
> >> gre0: gre/ip remote any local any ttl inherit nopmtudisc
> >> selftests: test_flow_dissector [FAILED]
> >>
> >> is it something in my setup or test is broken?
> >>
> I just reran the test and it is passing. We will investigate what
> could be causing the issue.
I've tried, but I am still not able to reproduce this exact issue.
This may be due to how we split the compilation and execution
With
make defconfig &&
make kvmconfig &&
make kselftest-merge &&
make -j $N bzImage
and starting the result in qemu -kernel I miss a few built-ins. The test
complains loudly if sch_ingress or ipip are missing. After updating to
=y, the tests all pass for me.
The confounding part is that in the above output the test shows no
error output and all tunnels are setup correctly.
For debugging purposes, I can update the script to run all tests instead
of existing on the first failure and to output more state, including the
address on the device and the state of the netns.
^ permalink raw reply
* Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: Song Liu @ 2018-09-24 21:18 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Michael Chan, Ariel Elior, Eric Dumazet,
Tariq Toukan, Saeed Mahameed, Jeff Kirsher, Jakub Kicinski,
Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <CANn89i+dri9_d8XMcUd=+-ncFYmgDQRd4TWB93QwtoAk+ooX6g@mail.gmail.com>
> On Sep 24, 2018, at 2:05 PM, Eric Dumazet <edumazet@google.com> wrote:
>
>>
>> Interesting, maybe a bnxt specific issue.
>>
>> It seems their model is to process TX/RX notification in the same queue,
>> they throw away RX events if budget == 0
>>
>> It means commit e7b9569102995ebc26821789628eef45bd9840d8 is wrong and
>> must be reverted.
>>
>> Otherwise, we have a possibility of blocking a queue under netpoll pressure.
>
> Hmm, actually a revert might not be enough, since code at lines 2030-2031
> would fire and we might not call napi_complete_done() anyway.
>
> Unfortunately this driver logic is quite complex.
>
> Could you test on other NIC eventually ?
>
It actually runs OK on ixgbe.
@Michael, could you please help us with this?
Thanks,
Song
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-09-25 3:32 UTC (permalink / raw)
To: gregkh; +Cc: netdev, linux-kernel
1) Fix multiqueue handling of coalesce timer in stmmac, from Jose
Abreu.
2) Fix memory corruption in NFC, from Suren Baghdasaryan.
3) Don't write reserved bits in ravb driver, from Kazuya Mizuguchi.
4) SMC bug fixes from Karsten Graul, YueHaibing, and Ursula Braun.
5) Fix TX done race in mvpp2, from Antoine Tenart.
6) ipv6 metrics leak, from Wei Wang.
7) Adjust firmware version requirements in mlxsw, from Petr Machata.
8) Fix autonegotiation on resume in r8169, from Heiner Kallweit.
9) Fixed missing entries when dumping /proc/net/if_inet6, from Jeff
Barnhill.
10) Fix double free in devlink, from Dan Carpenter.
11) Fix ethtool regression from UFO feature removal, from Maciej
Żenczykowski.
12) Fix drivers that have a ndo_poll_controller() that captures the
cpu entirely on loaded hosts by trying to drain all rx and tx
queues, from Eric Dumazet.
13) Fix memory corruption with jumbo frames in aquantia driver, from
Friedemann Gerold.
Please pull, thanks a lot!
The following changes since commit 5211da9ca526a5adddee1ccd078e6e33a583ab36:
Merge gitolite.kernel.org:/pub/scm/linux/kernel/git/davem/net (2018-09-18 09:31:53 +0200)
are available in the Git repository at:
gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to f4a518797b40e956b6e6220b42657e045dc24470:
net: mvneta: fix the remaining Rx descriptor unmapping issues (2018-09-24 12:27:28 -0700)
----------------------------------------------------------------
Alaa Hleihel (1):
net/mlx5: Check for SQ and not RQ state when modifying hairpin SQ
Antoine Tenart (4):
net: mvpp2: fix a txq_done race condition
net: mvneta: fix the Rx desc buffer DMA unmapping
net: mscc: fix the frame extraction into the skb
net: mvneta: fix the remaining Rx descriptor unmapping issues
Christian Lamparter (1):
net: emac: fix fixed-link setup for the RTL8363SB switch
Dan Carpenter (1):
devlink: double free in devlink_resource_fill()
Daniel Borkmann (1):
Merge branch 'bpf-sockmap-estab-fixes'
David S. Miller (9):
Merge branch 'stmmac-Coalesce-and-tail-addr-fixes'
Merge tag 'mlx5-fixes-2018-09-17' of git://git.kernel.org/.../saeed/linux
Merge branch 'net-smc-fixes'
Merge branch 'ipv6-fix-issues-on-accessing-fib6_metrics'
Merge tag 'batadv-net-for-davem-20180919' of git://git.open-mesh.org/linux-merge
Merge branch 'qed-fixes'
rds: Fix build regression.
Merge branch 'netpoll-avoid-capture-effects-for-NAPI-drivers'
Merge git://git.kernel.org/.../bpf/bpf
Davide Caratti (1):
bnxt_en: don't try to offload VLAN 'modify' action
Eli Cohen (1):
net/mlx5: Fix read from coherent memory
Eric Dumazet (15):
netpoll: make ndo_poll_controller() optional
bonding: use netpoll_poll_dev() helper
ixgbe: remove ndo_poll_controller
ixgbevf: remove ndo_poll_controller
fm10k: remove ndo_poll_controller
ixgb: remove ndo_poll_controller
igb: remove ndo_poll_controller
ice: remove ndo_poll_controller
i40evf: remove ndo_poll_controller
mlx4: remove ndo_poll_controller
mlx5: remove ndo_poll_controller
bnx2x: remove ndo_poll_controller
bnxt: remove ndo_poll_controller
nfp: remove ndo_poll_controller
tun: remove ndo_poll_controller
Friedemann Gerold (1):
net: aquantia: memory corruption on jumbo frames
Heiner Kallweit (1):
r8169: fix autoneg issue on resume with RTL8168E
Jakub Kicinski (1):
tools: bpf: fix license for a compat header file
Jeff Barnhill (1):
net/ipv6: Display all addresses in output of /proc/net/if_inet6
Johannes Berg (1):
smc: generic netlink family should be __ro_after_init
John Fastabend (3):
bpf: sockmap only allow ESTABLISHED sock state
bpf: sockmap, fix transition through disconnect without close
bpf: test_maps, only support ESTABLISHED socks
Jose Abreu (2):
net: stmmac: Rework coalesce timer and fix multi-queue races
net: stmmac: Fixup the tail addr setting in xmit path
Karsten Graul (1):
net/smc: no urgent data check for listen sockets
Kazuya Mizuguchi (1):
ravb: do not write 1 to reserved bits
Maciej Żenczykowski (1):
net-ethtool: ETHTOOL_GUFO did not and should not require CAP_NET_ADMIN
Marek Lindner (2):
batman-adv: fix backbone_gw refcount on queue_work() failure
batman-adv: fix hardif_neigh refcount on queue_work() failure
Nathan Chancellor (2):
net/mlx4: Use cpumask_available for eq->affinity_mask
RDS: IB: Use DEFINE_PER_CPU_SHARED_ALIGNED for rds_ib_stats
Paolo Abeni (2):
ip6_tunnel: be careful when accessing the inner header
ip_tunnel: be careful when accessing the inner header
Petr Machata (1):
mlxsw: spectrum: Bump required firmware version
Russell King (1):
sfp: fix oops with ethtool -m
Sabrina Dubroca (1):
selftests: pmtu: properly redirect stderr to /dev/null
Saeed Mahameed (1):
net/mlx5e: TLS, Read capabilities only when it is safe
Saif Hasan (1):
mpls: allow routes on ip6gre devices
Sean Tranchetti (1):
netlabel: check for IPV4MASK in addrinfo_get
Sudarsana Reddy Kalluru (3):
qed: Fix populating the invalid stag value in multi function mode.
qed: Do not add VLAN 0 tag to untagged frames in multi-function mode.
qed: Add missing device config for RoCE EDPM in UFP mode.
Suren Baghdasaryan (2):
NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
NFC: Fix the number of pipes
Sven Eckelmann (9):
batman-adv: Avoid probe ELP information leak
batman-adv: Fix segfault when writing to throughput_override
batman-adv: Fix segfault when writing to sysfs elp_interval
batman-adv: Prevent duplicated gateway_node entry
batman-adv: Prevent duplicated nc_node entry
batman-adv: Prevent duplicated softif_vlan entry
batman-adv: Prevent duplicated global TT entry
batman-adv: Prevent duplicated tvlv handler
batman-adv: Increase version number to 2018.3
Ursula Braun (3):
net/smc: fix non-blocking connect problem
net/smc: remove duplicate mutex_unlock
net/smc: enable fallback for connection abort in state INIT
Wei Wang (2):
Revert "ipv6: fix double refcount of fib6_metrics"
ipv6: fix memory leak on dst->_metrics
Wei Yongjun (1):
PCI: hv: Fix return value check in hv_pci_assign_slots()
Xin Long (1):
sctp: update dst pmtu with the correct daddr
YueHaibing (7):
net/smc: fix sizeof to int comparison
net: seeq: fix return type of ndo_start_xmit function
net: cirrus: fix return type of ndo_start_xmit function
net: sgi: fix return type of ndo_start_xmit function
net: wiznet: fix return type of ndo_start_xmit function
net: i825xx: fix return type of ndo_start_xmit function
net: apple: fix return type of ndo_start_xmit function
zhong jiang (1):
net: bnxt: Fix a uninitialized variable warning.
drivers/net/bonding/bond_main.c | 11 +---
drivers/net/ethernet/apple/bmac.c | 4 +-
drivers/net/ethernet/apple/mace.c | 4 +-
drivers/net/ethernet/apple/macmace.c | 4 +-
drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 32 ++++++-----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 16 ------
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 18 -------
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 3 ++
drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 20 ++++---
drivers/net/ethernet/cirrus/ep93xx_eth.c | 2 +-
drivers/net/ethernet/cirrus/mac89x0.c | 4 +-
drivers/net/ethernet/i825xx/ether1.c | 5 +-
drivers/net/ethernet/i825xx/lib82596.c | 4 +-
drivers/net/ethernet/i825xx/sun3_82586.c | 6 ++-
drivers/net/ethernet/ibm/emac/core.c | 15 ++++--
drivers/net/ethernet/intel/fm10k/fm10k.h | 3 --
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 3 --
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 22 --------
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 26 ---------
drivers/net/ethernet/intel/ice/ice_main.c | 27 ----------
drivers/net/ethernet/intel/igb/igb_main.c | 30 -----------
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 25 ---------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 25 ---------
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 21 --------
drivers/net/ethernet/marvell/mvneta.c | 13 +++--
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 10 ++--
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 20 -------
drivers/net/ethernet/mellanox/mlx4/eq.c | 3 +-
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c | 3 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 19 -------
drivers/net/ethernet/mellanox/mlx5/core/transobj.c | 2 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 +-
drivers/net/ethernet/mscc/ocelot_board.c | 12 +++--
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 18 -------
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 45 ++++++++++------
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 1 +
drivers/net/ethernet/qlogic/qed/qed_dev.c | 15 +++++-
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 4 ++
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 24 +++++++--
drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 6 +++
drivers/net/ethernet/realtek/r8169.c | 9 ++++
drivers/net/ethernet/renesas/ravb.h | 5 ++
drivers/net/ethernet/renesas/ravb_main.c | 11 ++--
drivers/net/ethernet/renesas/ravb_ptp.c | 2 +-
drivers/net/ethernet/seeq/ether3.c | 5 +-
drivers/net/ethernet/seeq/sgiseeq.c | 3 +-
drivers/net/ethernet/sgi/ioc3-eth.c | 4 +-
drivers/net/ethernet/sgi/meth.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/common.h | 4 +-
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 14 ++++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 238 ++++++++++++++++++++++++++++++++++++++++++++++-----------------------------------
drivers/net/ethernet/wiznet/w5100.c | 2 +-
drivers/net/ethernet/wiznet/w5300.c | 2 +-
drivers/net/phy/sfp-bus.c | 4 +-
drivers/net/tun.c | 43 ---------------
drivers/pci/controller/pci-hyperv.c | 4 +-
include/linux/netpoll.h | 5 +-
include/linux/stmmac.h | 1 +
include/net/nfc/hci.h | 2 +-
kernel/bpf/sockmap.c | 91 ++++++++++++++++++++++++-------
net/batman-adv/bat_v_elp.c | 10 ++--
net/batman-adv/bridge_loop_avoidance.c | 10 +++-
net/batman-adv/gateway_client.c | 11 +++-
net/batman-adv/main.h | 2 +-
net/batman-adv/network-coding.c | 27 +++++-----
net/batman-adv/soft-interface.c | 25 ++++++---
net/batman-adv/sysfs.c | 30 +++++++----
net/batman-adv/translation-table.c | 6 ++-
net/batman-adv/tvlv.c | 8 ++-
net/core/devlink.c | 3 +-
net/core/ethtool.c | 1 +
net/core/netpoll.c | 19 +++----
net/ipv4/ip_tunnel.c | 9 ++++
net/ipv6/addrconf.c | 4 +-
net/ipv6/ip6_tunnel.c | 13 ++++-
net/ipv6/route.c | 9 +++-
net/mpls/af_mpls.c | 6 ++-
net/netlabel/netlabel_unlabeled.c | 3 +-
net/nfc/hci/core.c | 10 ++++
net/rds/ib.h | 2 +-
net/sctp/transport.c | 12 ++++-
net/smc/af_smc.c | 26 +++++----
net/smc/smc_clc.c | 14 +++--
net/smc/smc_close.c | 14 ++---
net/smc/smc_pnet.c | 2 +-
tools/include/tools/libc_compat.h | 2 +-
tools/testing/selftests/bpf/test_maps.c | 10 ++--
tools/testing/selftests/net/pmtu.sh | 4 +-
89 files changed, 621 insertions(+), 653 deletions(-)
^ permalink raw reply
* [PATCH net-next] net: phy: improve handling delayed work
From: Heiner Kallweit @ 2018-09-24 21:36 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
Using mod_delayed_work() allows to simplify handling delayed work and
removes the need for the sync parameter in phy_trigger_machine().
Also introduce a helper phy_queue_state_machine() to encapsulate the
low-level delayed work calls. No functional change intended.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy.c | 29 +++++++++++++++--------------
include/linux/phy.h | 2 +-
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index a1f8e4816..40a7dc101 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -537,7 +537,7 @@ static int phy_start_aneg_priv(struct phy_device *phydev, bool sync)
mutex_unlock(&phydev->lock);
if (trigger)
- phy_trigger_machine(phydev, sync);
+ phy_trigger_machine(phydev);
return err;
}
@@ -635,6 +635,13 @@ int phy_speed_up(struct phy_device *phydev)
}
EXPORT_SYMBOL_GPL(phy_speed_up);
+static inline void phy_queue_state_machine(struct phy_device *phydev,
+ unsigned int secs)
+{
+ mod_delayed_work(system_power_efficient_wq, &phydev->state_queue,
+ secs * HZ);
+}
+
/**
* phy_start_machine - start PHY state machine tracking
* @phydev: the phy_device struct
@@ -647,7 +654,7 @@ EXPORT_SYMBOL_GPL(phy_speed_up);
*/
void phy_start_machine(struct phy_device *phydev)
{
- queue_delayed_work(system_power_efficient_wq, &phydev->state_queue, HZ);
+ phy_queue_state_machine(phydev, 1);
}
EXPORT_SYMBOL_GPL(phy_start_machine);
@@ -655,19 +662,14 @@ EXPORT_SYMBOL_GPL(phy_start_machine);
* phy_trigger_machine - trigger the state machine to run
*
* @phydev: the phy_device struct
- * @sync: indicate whether we should wait for the workqueue cancelation
*
* Description: There has been a change in state which requires that the
* state machine runs.
*/
-void phy_trigger_machine(struct phy_device *phydev, bool sync)
+void phy_trigger_machine(struct phy_device *phydev)
{
- if (sync)
- cancel_delayed_work_sync(&phydev->state_queue);
- else
- cancel_delayed_work(&phydev->state_queue);
- queue_delayed_work(system_power_efficient_wq, &phydev->state_queue, 0);
+ phy_queue_state_machine(phydev, 0);
}
/**
@@ -703,7 +705,7 @@ static void phy_error(struct phy_device *phydev)
phydev->state = PHY_HALTED;
mutex_unlock(&phydev->lock);
- phy_trigger_machine(phydev, false);
+ phy_trigger_machine(phydev);
}
/**
@@ -745,7 +747,7 @@ static irqreturn_t phy_change(struct phy_device *phydev)
mutex_unlock(&phydev->lock);
/* reschedule state queue work to run as soon as possible */
- phy_trigger_machine(phydev, true);
+ phy_trigger_machine(phydev);
if (phy_interrupt_is_valid(phydev) && phy_clear_interrupt(phydev))
goto phy_err;
@@ -911,7 +913,7 @@ void phy_start(struct phy_device *phydev)
}
mutex_unlock(&phydev->lock);
- phy_trigger_machine(phydev, true);
+ phy_trigger_machine(phydev);
}
EXPORT_SYMBOL(phy_start);
@@ -1130,8 +1132,7 @@ void phy_state_machine(struct work_struct *work)
* called from phy_disconnect() synchronously.
*/
if (phy_polling_mode(phydev) && old_state != PHY_HALTED)
- queue_delayed_work(system_power_efficient_wq, &phydev->state_queue,
- PHY_STATE_TIME * HZ);
+ phy_queue_state_machine(phydev, PHY_STATE_TIME);
}
/**
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 192a1fa0c..15bd074ef 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1039,7 +1039,7 @@ void phy_change_work(struct work_struct *work);
void phy_mac_interrupt(struct phy_device *phydev);
void phy_start_machine(struct phy_device *phydev);
void phy_stop_machine(struct phy_device *phydev);
-void phy_trigger_machine(struct phy_device *phydev, bool sync);
+void phy_trigger_machine(struct phy_device *phydev);
int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);
void phy_ethtool_ksettings_get(struct phy_device *phydev,
struct ethtool_link_ksettings *cmd);
--
2.19.0
^ permalink raw reply related
* Re: [PATCH net v2 1/2] net: core: add member wol_enabled to struct net_device
From: Florian Fainelli @ 2018-09-24 21:39 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <6a574380-06f6-4bce-9705-e2b554359337@gmail.com>
On 09/24/2018 12:58 PM, Heiner Kallweit wrote:
> Add flag wol_enabled to struct net_device indicating whether
> Wake-on-LAN is enabled. As first user phy_suspend() will use it to
> decide whether PHY can be suspended or not.
>
> Fixes: f1e911d5d0df ("r8169: add basic phylib support")
> Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks Heiner!
--
Florian
^ permalink raw reply
* Re: [PATCH net 2/2] net: phy: fix WoL handling when suspending the PHY
From: Florian Fainelli @ 2018-09-24 21:39 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <4b3089bc-cd91-7a1f-b1bc-6d87fcb9fc1f@gmail.com>
On 09/24/2018 12:56 PM, Heiner Kallweit wrote:
> On 24.09.2018 20:21, Florian Fainelli wrote:
>> On 09/24/2018 11:11 AM, Heiner Kallweit wrote:
>>> Core of the problem is that phy_suspend() suspends the PHY when it
>>> should not because of WoL. phy_suspend() checks for WoL already, but
>>> this works only if the PHY driver handles WoL (what is rarely the case).
>>> Typically WoL is handled by the MAC driver.
>>>
>>> This patch uses new member wol_enabled of struct net_device as
>>> additional criteria in the check when not to suspend the PHY because
>>> of WoL.
>>>
>>> Last but not least change phy_detach() to call phy_suspend() before
>>> attached_dev is set to NULL. phy_suspend() accesses attached_dev
>>> when checking whether the MAC driver activated WoL.
>>
>> Looks fine to me, just a few nits/questions down below:
>>
>> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>>
>>>
>>> Fixes: f1e911d5d0df ("r8169: add basic phylib support")
>>> Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>> ---
>>> drivers/net/phy/phy_device.c | 12 +++++++++---
>>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>>> index af64a9320..6c0195e53 100644
>>> --- a/drivers/net/phy/phy_device.c
>>> +++ b/drivers/net/phy/phy_device.c
>>> @@ -93,7 +93,12 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
>>> if (!netdev)
>>> return !phydev->suspended;
>>>
>>> - /* Don't suspend PHY if the attached netdev parent may wakeup.
>>> + if (netdev->wol_enabled)
>>> + return false;
>>> +
>>> + /* As lang as not all affected network drivers support the
>>> + * wol_enabled flag, let's check for hints that WoL is enabled.
>>
>> Typo: as long (sorry for being that nitpicky).
>>
>>> + * Don't suspend PHY if the attached netdev parent may wakeup.
>>> * The parent may point to a PCI device, as in tg3 driver.
>>> */
>>> if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
>>> @@ -1132,9 +1137,9 @@ void phy_detach(struct phy_device *phydev)
>>> sysfs_remove_link(&dev->dev.kobj, "phydev");
>>> sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
>>> }
>>> + phy_suspend(phydev);
>>> phydev->attached_dev->phydev = NULL;
>>> phydev->attached_dev = NULL;
>>> - phy_suspend(phydev);
>>> phydev->phylink = NULL;
>>>
>>> phy_led_triggers_unregister(phydev);
>>> @@ -1168,12 +1173,13 @@ EXPORT_SYMBOL(phy_detach);
>>> int phy_suspend(struct phy_device *phydev)
>>> {
>>> struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
>>> + struct net_device *netdev = phydev->attached_dev;
>>> struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
>>> int ret = 0;
>>>
>>> /* If the device has WOL enabled, we cannot suspend the PHY */
>>> phy_ethtool_get_wol(phydev, &wol);
>>> - if (wol.wolopts)
>>> + if (wol.wolopts || (netdev && netdev->wol_enabled))
>>
>> Since you moved the phydev->attached_dev assignment to be after
>> phy_suspend(), do you really need to check for netdev here? Is there
>> another code path you found that might be running phy_suspend() with a
>> disconnected PHY? Not a problem per-se, just wondering.
>>
> There's a call to phy_suspend() in the phylib state machine and I'm
> not sure we can guarantee that a netdevice is attached.
> Because phy_suspend() is exported anybody can use it, correct or
> incorrect. Therefore I'd say core functions better should play safe.
Sounds good to me, better safe than sorry.
--
Florian
^ permalink raw reply
* [PATCH net] bonding: pass link-local packets to bonding master also.
From: Mahesh Bandewar @ 2018-09-24 21:39 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, Veaceslav Falico, David Miller
Cc: Mahesh Bandewar, Netdev, Eric Dumazet, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
Commit b89f04c61efe ("bonding: deliver link-local packets with
skb->dev set to link that packets arrived on") changed the behavior
of how link-local-multicast packets are processed. The change in
the behavior broke some legacy use cases where these packets are
expected to arrive on bonding master device also.
This patch passes the packet to the stack with the link it arrived
on as well as passes to the bonding-master device to preserve the
legacy use case.
Fixes: b89f04c61efe ("bonding: deliver link-local packets with skb->dev set to link that packets arrived on")
Reported-by: Michal Soltys <soltys@ziu.info>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/bonding/bond_main.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 9866fa959a19..e3157aed656a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1178,9 +1178,26 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
}
}
- /* don't change skb->dev for link-local packets */
- if (is_link_local_ether_addr(eth_hdr(skb)->h_dest))
+ /* Link-local multicast packets should be passed to the
+ * stack on the link they arrive as well as pass them to the
+ * bond-master device. These packets are mostly usable when
+ * stack receives it with the link on which they arrive
+ * (e.g. LLDP) they also must be available on master. Some of
+ * the use cases include (but are not limited to): LLDP agents
+ * that must be able to operate both on enslaved interfaces as
+ * well as on bonds themselves; linux bridges that must be able
+ * to process/pass BPDUs from attached bonds when any kind of
+ * STP version is enabled on the network.
+ */
+ if (is_link_local_ether_addr(eth_hdr(skb)->h_dest)) {
+ struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
+
+ if (nskb) {
+ nskb->dev = bond->dev;
+ netif_rx(nskb);
+ }
return RX_HANDLER_PASS;
+ }
if (bond_should_deliver_exact_match(skb, slave, bond))
return RX_HANDLER_EXACT;
--
2.19.0.444.g18242da7ef-goog
^ permalink raw reply related
* [PATCH net] bonding: avoid possible dead-lock
From: Mahesh Bandewar @ 2018-09-24 21:40 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, Veaceslav Falico, David Miller
Cc: Mahesh Bandewar, Netdev, Eric Dumazet, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
Syzkaller reported this on a slightly older kernel but it's still
applicable to the current kernel -
======================================================
WARNING: possible circular locking dependency detected
4.18.0-next-20180823+ #46 Not tainted
------------------------------------------------------
syz-executor4/26841 is trying to acquire lock:
00000000dd41ef48 ((wq_completion)bond_dev->name){+.+.}, at: flush_workqueue+0x2db/0x1e10 kernel/workqueue.c:2652
but task is already holding lock:
00000000768ab431 (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline]
00000000768ab431 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4708
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (rtnl_mutex){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
bond_netdev_notify drivers/net/bonding/bond_main.c:1310 [inline]
bond_netdev_notify_work+0x44/0xd0 drivers/net/bonding/bond_main.c:1320
process_one_work+0xc73/0x1aa0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x35a/0x420 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
-> #1 ((work_completion)(&(&nnw->work)->work)){+.+.}:
process_one_work+0xc0b/0x1aa0 kernel/workqueue.c:2129
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x35a/0x420 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
-> #0 ((wq_completion)bond_dev->name){+.+.}:
lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901
flush_workqueue+0x30a/0x1e10 kernel/workqueue.c:2655
drain_workqueue+0x2a9/0x640 kernel/workqueue.c:2820
destroy_workqueue+0xc6/0x9d0 kernel/workqueue.c:4155
__alloc_workqueue_key+0xef9/0x1190 kernel/workqueue.c:4138
bond_init+0x269/0x940 drivers/net/bonding/bond_main.c:4734
register_netdevice+0x337/0x1100 net/core/dev.c:8410
bond_newlink+0x49/0xa0 drivers/net/bonding/bond_netlink.c:453
rtnl_newlink+0xef4/0x1d50 net/core/rtnetlink.c:3099
rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4711
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4729
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:622 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:632
___sys_sendmsg+0x7fd/0x930 net/socket.c:2115
__sys_sendmsg+0x11d/0x290 net/socket.c:2153
__do_sys_sendmsg net/socket.c:2162 [inline]
__se_sys_sendmsg net/socket.c:2160 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2160
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
(wq_completion)bond_dev->name --> (work_completion)(&(&nnw->work)->work) --> rtnl_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(rtnl_mutex);
lock((work_completion)(&(&nnw->work)->work));
lock(rtnl_mutex);
lock((wq_completion)bond_dev->name);
*** DEADLOCK ***
1 lock held by syz-executor4/26841:
stack backtrace:
CPU: 1 PID: 26841 Comm: syz-executor4 Not tainted 4.18.0-next-20180823+ #46
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_circular_bug.isra.34.cold.55+0x1bd/0x27d kernel/locking/lockdep.c:1222
check_prev_add kernel/locking/lockdep.c:1862 [inline]
check_prevs_add kernel/locking/lockdep.c:1975 [inline]
validate_chain kernel/locking/lockdep.c:2416 [inline]
__lock_acquire+0x3449/0x5020 kernel/locking/lockdep.c:3412
lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901
flush_workqueue+0x30a/0x1e10 kernel/workqueue.c:2655
drain_workqueue+0x2a9/0x640 kernel/workqueue.c:2820
destroy_workqueue+0xc6/0x9d0 kernel/workqueue.c:4155
__alloc_workqueue_key+0xef9/0x1190 kernel/workqueue.c:4138
bond_init+0x269/0x940 drivers/net/bonding/bond_main.c:4734
register_netdevice+0x337/0x1100 net/core/dev.c:8410
bond_newlink+0x49/0xa0 drivers/net/bonding/bond_netlink.c:453
rtnl_newlink+0xef4/0x1d50 net/core/rtnetlink.c:3099
rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4711
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4729
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:622 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:632
___sys_sendmsg+0x7fd/0x930 net/socket.c:2115
__sys_sendmsg+0x11d/0x290 net/socket.c:2153
__do_sys_sendmsg net/socket.c:2162 [inline]
__se_sys_sendmsg net/socket.c:2160 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2160
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2df20a5c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f2df20a66d4 RCX: 0000000000457089
RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003
RBP: 0000000000930140 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004d40b8 R14: 00000000004c8ad8 R15: 0000000000000001
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/bonding/bond_main.c | 43 +++++++++++++--------------------
include/net/bonding.h | 7 +-----
2 files changed, 18 insertions(+), 32 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a764a83f99da..9866fa959a19 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -210,6 +210,7 @@ static void bond_get_stats(struct net_device *bond_dev,
static void bond_slave_arr_handler(struct work_struct *work);
static bool bond_time_in_interval(struct bonding *bond, unsigned long last_act,
int mod);
+static void bond_netdev_notify_work(struct work_struct *work);
/*---------------------------- General routines -----------------------------*/
@@ -1276,6 +1277,8 @@ static struct slave *bond_alloc_slave(struct bonding *bond)
return NULL;
}
}
+ INIT_DELAYED_WORK(&slave->notify_work, bond_netdev_notify_work);
+
return slave;
}
@@ -1283,6 +1286,7 @@ static void bond_free_slave(struct slave *slave)
{
struct bonding *bond = bond_get_bond_by_slave(slave);
+ cancel_delayed_work_sync(&slave->notify_work);
if (BOND_MODE(bond) == BOND_MODE_8023AD)
kfree(SLAVE_AD_INFO(slave));
@@ -1304,39 +1308,26 @@ static void bond_fill_ifslave(struct slave *slave, struct ifslave *info)
info->link_failure_count = slave->link_failure_count;
}
-static void bond_netdev_notify(struct net_device *dev,
- struct netdev_bonding_info *info)
-{
- rtnl_lock();
- netdev_bonding_info_change(dev, info);
- rtnl_unlock();
-}
-
static void bond_netdev_notify_work(struct work_struct *_work)
{
- struct netdev_notify_work *w =
- container_of(_work, struct netdev_notify_work, work.work);
+ struct slave *slave = container_of(_work, struct slave,
+ notify_work.work);
+
+ if (rtnl_trylock()) {
+ struct netdev_bonding_info binfo;
- bond_netdev_notify(w->dev, &w->bonding_info);
- dev_put(w->dev);
- kfree(w);
+ bond_fill_ifslave(slave, &binfo.slave);
+ bond_fill_ifbond(slave->bond, &binfo.master);
+ netdev_bonding_info_change(slave->dev, &binfo);
+ rtnl_unlock();
+ } else {
+ queue_delayed_work(slave->bond->wq, &slave->notify_work, 1);
+ }
}
void bond_queue_slave_event(struct slave *slave)
{
- struct bonding *bond = slave->bond;
- struct netdev_notify_work *nnw = kzalloc(sizeof(*nnw), GFP_ATOMIC);
-
- if (!nnw)
- return;
-
- dev_hold(slave->dev);
- nnw->dev = slave->dev;
- bond_fill_ifslave(slave, &nnw->bonding_info.slave);
- bond_fill_ifbond(bond, &nnw->bonding_info.master);
- INIT_DELAYED_WORK(&nnw->work, bond_netdev_notify_work);
-
- queue_delayed_work(slave->bond->wq, &nnw->work, 0);
+ queue_delayed_work(slave->bond->wq, &slave->notify_work, 0);
}
void bond_lower_state_changed(struct slave *slave)
diff --git a/include/net/bonding.h b/include/net/bonding.h
index a2d058170ea3..b46d68acf701 100644
--- a/include/net/bonding.h
+++ b/include/net/bonding.h
@@ -139,12 +139,6 @@ struct bond_parm_tbl {
int mode;
};
-struct netdev_notify_work {
- struct delayed_work work;
- struct net_device *dev;
- struct netdev_bonding_info bonding_info;
-};
-
struct slave {
struct net_device *dev; /* first - useful for panic debug */
struct bonding *bond; /* our master */
@@ -172,6 +166,7 @@ struct slave {
#ifdef CONFIG_NET_POLL_CONTROLLER
struct netpoll *np;
#endif
+ struct delayed_work notify_work;
struct kobject kobj;
struct rtnl_link_stats64 slave_stats;
};
--
2.19.0.444.g18242da7ef-goog
^ permalink raw reply related
* [PATCH 2/4] ARM: socfpga_defconfig: Enable CONFIG_MTD_ALTERA_SYSMGR
From: thor.thayer @ 2018-09-24 22:09 UTC (permalink / raw)
To: lee.jones, peppe.cavallaro, dinguyen, linux, alexandre.torgue,
joabreu
Cc: thor.thayer, davem, mchehab+samsung, catalin.marinas, akpm, arnd,
aisheng.dong, linux-kernel, netdev, linux-arm-kernel
In-Reply-To: <1537826946-18942-1-git-send-email-thor.thayer@linux.intel.com>
From: Thor Thayer <thor.thayer@linux.intel.com>
Add System Manager driver by default for SOCFPGA ARM32 platforms.
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
arch/arm/configs/socfpga_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
index 371fca4e1ab7..c510a32f9f0d 100644
--- a/arch/arm/configs/socfpga_defconfig
+++ b/arch/arm/configs/socfpga_defconfig
@@ -109,6 +109,7 @@ CONFIG_SENSORS_LTC2978_REGULATOR=y
CONFIG_WATCHDOG=y
CONFIG_DW_WATCHDOG=y
CONFIG_MFD_ALTERA_A10SR=y
+CONFIG_MFD_ALTERA_SYSMGR=y
CONFIG_MFD_STMPE=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] net: stmmac: socfpga: Use shared System Manager driver
From: thor.thayer @ 2018-09-24 22:09 UTC (permalink / raw)
To: lee.jones, peppe.cavallaro, dinguyen, linux, alexandre.torgue,
joabreu
Cc: thor.thayer, davem, mchehab+samsung, catalin.marinas, akpm, arnd,
aisheng.dong, linux-kernel, netdev, linux-arm-kernel
In-Reply-To: <1537826946-18942-1-git-send-email-thor.thayer@linux.intel.com>
From: Thor Thayer <thor.thayer@linux.intel.com>
The ARM64 System Manager requires a different method of reading
the System Manager than ARM32. A new System Manager driver was
created to steer ARM32 System Manager calls to syscon and ARM64
System Manager calls to the new access method.
Convert from syscon to the shared System Manager driver so that
both ARM64 and ARM32 are supported.
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 5b3b06a0a3bf..743c7f471edb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -15,6 +15,7 @@
* Adopted from dwmac-sti.c
*/
+#include <linux/mfd/altera-sysmgr.h>
#include <linux/mfd/syscon.h>
#include <linux/of.h>
#include <linux/of_address.h>
@@ -114,7 +115,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
dwmac->interface = of_get_phy_mode(np);
- sys_mgr_base_addr = syscon_regmap_lookup_by_phandle(np, "altr,sysmgr-syscon");
+ sys_mgr_base_addr =
+ altr_sysmgr_regmap_lookup_by_phandle(np, "altr,sysmgr-syscon");
if (IS_ERR(sys_mgr_base_addr)) {
dev_info(dev, "No sysmgr-syscon node found\n");
return PTR_ERR(sys_mgr_base_addr);
--
2.7.4
^ permalink raw reply related
* [PATCH net] net: phy: sfp: Fix unregistering of HWMON SFP device
From: Andrew Lunn @ 2018-09-24 22:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Florian Fainelli, Russell King, Andrew Lunn
A HWMON device is only registered is the SFP module supports the
diagnostic page and is complient to SFF8472. Don't unconditionally
unregister the hwmon device when the SFP module is remove, otherwise
we access data structures which don't exist.
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/sfp.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 52fffb98fde9..23705ffae6bb 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1098,8 +1098,11 @@ static int sfp_hwmon_insert(struct sfp *sfp)
static void sfp_hwmon_remove(struct sfp *sfp)
{
- hwmon_device_unregister(sfp->hwmon_dev);
- kfree(sfp->hwmon_name);
+ if (!PTR_ERR_OR_NULL(sfp->hwmon_dev)) {
+ hwmon_device_unregister(sfp->hwmon_dev);
+ sfp->hwmon_dev = NULL;
+ kfree(sfp->hwmon_name);
+ }
}
#else
static int sfp_hwmon_insert(struct sfp *sfp)
--
2.19.0.rc1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox