* Re: [PATCH][net-next] net: limit each hash list length to MAX_GRO_SKBS
From: David Miller @ 2018-07-05 1:04 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1530693768-26845-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Wed, 4 Jul 2018 16:42:48 +0800
> @@ -4989,10 +4988,11 @@ static int napi_gro_complete(struct sk_buff *skb)
> return netif_receive_skb_internal(skb);
> }
>
> -static void __napi_gro_flush_chain(struct napi_struct *napi, struct list_head *head,
> +static void __napi_gro_flush_chain(struct napi_struct *napi, int index,
> bool flush_old)
Hash is usually u32, so please lets make the type consistent. Make index here
a 'u32' and also make 'i' in napi_gro_flush() a 'u32' too.
> @@ -5138,6 +5122,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
> enum gro_result ret;
> int same_flow;
> int grow;
> + u32 hash = skb_get_hash_raw(skb) & (GRO_HASH_BUCKETS - 1);
Please preserve reverse christmas tree local variable ordering.
Otherwise this looks great.
Thank you.
^ permalink raw reply
* Re: [PATCH v2 00/14] ravb/sh_eth: fix sleep in atomic by reusing shared ethtool handlers
From: David Miller @ 2018-07-05 0:56 UTC (permalink / raw)
To: vladimir_zapolskiy
Cc: sergei.shtylyov, andrew, geert, netdev, linux-renesas-soc
In-Reply-To: <20180704081245.7395-1-vladimir_zapolskiy@mentor.com>
From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Date: Wed, 4 Jul 2018 11:12:38 +0300
> For ages trivial changes to RAVB and SuperH ethernet links by means of
> standard 'ethtool' trigger a 'sleeping function called from invalid
> context' bug, to visualize it on r8a7795 ULCB:
...
> The root cause is that an attempt to modify ECMR and GECMR registers
> only when RX/TX function is disabled was too overcomplicated in its
> original implementation, also processing of an optional Link Change
> interrupt added even more complexity, as a result the implementation
> was error prone.
>
> The new locking scheme is confirmed to be correct by dumping driver
> specific and generic PHY framework function calls with aid of ftrace
> while running more or less advanced tests.
>
> Please note that sh_eth patches from the series were built-tested only.
>
> On purpose I do not add Fixes tags, the reused PHY handlers were added
> way later than the fixed problems were firstly found in the drivers.
>
> Changes from v1 to v2:
> * the original patches are split to bugfixes and enhancements only,
> both v1 and v2 series are absolutely equal in total, thus I omit
> description of changes in individual patches,
> * the latter implies that there should be no strict need for retesting,
> but because formally two series are different, I have to drop the tags
> given by Geert and Andrew, please send your tags again.
These changes look fine to me but I want to see some reviews and/or
testing before I apply them.
Thanks.
^ permalink raw reply
* Re: [PATCH net] net: mv __dev_notify_flags from void to int
From: David Miller @ 2018-07-05 0:49 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, sbrivio, xiyou.wangcong
In-Reply-To: <1530685786-26449-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Wed, 4 Jul 2018 14:29:46 +0800
> @@ -7062,8 +7073,7 @@ int dev_change_flags(struct net_device *dev, unsigned int flags)
> return ret;
>
> changes = (old_flags ^ dev->flags) | (old_gflags ^ dev->gflags);
> - __dev_notify_flags(dev, old_flags, changes);
> - return ret;
> + return __dev_notify_flags(dev, old_flags, changes);
By doing this, you will lose any error code returned from dev_open().
That is why we return 'ret' instead of plain '0' here.
^ permalink raw reply
* Re: [PATCH net] net: phy: fix flag masking in __set_phy_supported
From: David Miller @ 2018-07-05 0:48 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <c0ca1da0-2b55-19c0-708a-ccab9a97ec5c@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue, 3 Jul 2018 22:34:54 +0200
> Currently also the pause flags are removed from phydev->supported because
> they're not included in PHY_DEFAULT_FEATURES. I don't think this is
> intended, especially when considering that this function can be called
> via phy_set_max_speed() anywhere in a driver. Change the masking to mask
> out only the values we're going to change. In addition remove the
> misleading comment, job of this small function is just to adjust the
> supported and advertised speeds.
>
> Fixes: f3a6bd393c2c ("phylib: Add phy_set_max_speed helper")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: general protection fault in rds_ib_get_mr
From: santosh.shilimkar @ 2018-07-05 0:32 UTC (permalink / raw)
To: Eric Biggers, linux-rdma, rds-devel
Cc: syzbot, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <20180704213506.GH725@sol.localdomain>
On 7/4/18 2:35 PM, Eric Biggers wrote:
> On Sun, May 13, 2018 at 10:46:37PM -0700, santosh.shilimkar@oracle.com wrote:
>> On 5/13/18 2:10 PM, Eric Biggers wrote:
>>> On Wed, Mar 21, 2018 at 09:00:01AM -0700, syzbot wrote:
>>
>> [...]
>>
>>
>>> Still reproducible on Linus' tree (commit 66e1c94db3cd4) and linux-next
>>> (next-20180511). Here's a simplified reproducer:
>>>
>> Thanks for the test case !!
>>
[...]
>
> Ping; this RDS bug is still unfixed. The same reproducer I gave earlier still
> works, even when run as a non-root user. I tested upstream commit
> fc36def997cfd6 (v4.18-rc3-113-gfc36def997cfd), and linux-next commit
> bce40927669338 (next-20180704).
>
Yeah I haven't sent a fix for this yet. Downstream we have refactored
MR code and I wanted to get that upstream. With that this bug will
also get addressed. I was hoping to get that series but since some
optimisation is still pending investigations its getting delayed.
Will find out if I can fix this panic in meantime with smaller change.
Thanks for reminder.
Regards,
Santosh
^ permalink raw reply
* [PATCH net-next 4/4] vxlan: fix default fdb entry netlink notify ordering during netdev create
From: Roopa Prabhu @ 2018-07-04 23:46 UTC (permalink / raw)
To: davem; +Cc: netdev, jbenc, mike.rapoport, stephen
In-Reply-To: <1530747992-15878-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Problem:
In vxlan_newlink, a default fdb entry is added before register_netdev.
The default fdb creation function also notifies user-space of the
fdb entry on the vxlan device which user-space does not know about yet.
(RTM_NEWNEIGH goes before RTM_NEWLINK for the same ifindex).
This patch fixes the user-space netlink notification ordering issue
with the following changes:
- decouple fdb notify from fdb create.
- Move fdb notify after register_netdev.
- Call rtnl_configure_link in vxlan newlink handler to notify
userspace about the newlink before fdb notify and
hence avoiding the user-space race.
Fixes: afbd8bae9c79 ("vxlan: add implicit fdb entry for default destination")
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/vxlan.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 794a9a7..ababba3 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -3197,6 +3197,7 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
{
struct vxlan_net *vn = net_generic(net, vxlan_net_id);
struct vxlan_dev *vxlan = netdev_priv(dev);
+ struct vxlan_fdb *f = NULL;
int err;
err = vxlan_dev_configure(net, dev, conf, false, extack);
@@ -3207,27 +3208,38 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
/* create an fdb entry for a valid default destination */
if (!vxlan_addr_any(&vxlan->default_dst.remote_ip)) {
- err = vxlan_fdb_update(vxlan, all_zeros_mac,
+ err = vxlan_fdb_create(vxlan, all_zeros_mac,
&vxlan->default_dst.remote_ip,
NUD_REACHABLE | NUD_PERMANENT,
- NLM_F_EXCL | NLM_F_CREATE,
vxlan->cfg.dst_port,
vxlan->default_dst.remote_vni,
vxlan->default_dst.remote_vni,
vxlan->default_dst.remote_ifindex,
- NTF_SELF);
+ NTF_SELF, &f);
if (err)
return err;
}
err = register_netdevice(dev);
+ if (err)
+ goto errout;
+
+ err = rtnl_configure_link(dev, NULL);
if (err) {
- vxlan_fdb_delete_default(vxlan, vxlan->default_dst.remote_vni);
- return err;
+ unregister_netdevice(dev);
+ goto errout;
}
+ /* notify default fdb entry */
+ if (f)
+ vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f), RTM_NEWNEIGH);
+
list_add(&vxlan->next, &vn->vxlan_list);
return 0;
+errout:
+ if (f)
+ vxlan_fdb_destroy(vxlan, f, false);
+ return err;
}
static int vxlan_nl2conf(struct nlattr *tb[], struct nlattr *data[],
@@ -3462,6 +3474,7 @@ static int vxlan_changelink(struct net_device *dev, struct nlattr *tb[],
struct vxlan_rdst *dst = &vxlan->default_dst;
struct vxlan_rdst old_dst;
struct vxlan_config conf;
+ struct vxlan_fdb *f = NULL;
int err;
err = vxlan_nl2conf(tb, data,
@@ -3487,19 +3500,19 @@ static int vxlan_changelink(struct net_device *dev, struct nlattr *tb[],
old_dst.remote_ifindex, 0);
if (!vxlan_addr_any(&dst->remote_ip)) {
- err = vxlan_fdb_update(vxlan, all_zeros_mac,
+ err = vxlan_fdb_create(vxlan, all_zeros_mac,
&dst->remote_ip,
NUD_REACHABLE | NUD_PERMANENT,
- NLM_F_CREATE | NLM_F_APPEND,
vxlan->cfg.dst_port,
dst->remote_vni,
dst->remote_vni,
dst->remote_ifindex,
- NTF_SELF);
+ NTF_SELF, &f);
if (err) {
spin_unlock_bh(&vxlan->hash_lock);
return err;
}
+ vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f), RTM_NEWNEIGH);
}
spin_unlock_bh(&vxlan->hash_lock);
}
--
2.1.4
^ permalink raw reply related
* [PATCH net-next 3/4] vxlan: make netlink notify in vxlan_fdb_destroy optional
From: Roopa Prabhu @ 2018-07-04 23:46 UTC (permalink / raw)
To: davem; +Cc: netdev, jbenc, mike.rapoport, stephen
In-Reply-To: <1530747992-15878-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Add a new option do_notify to vxlan_fdb_destroy to make
sending netlink notify optional. Used by a later patch.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/vxlan.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index aa88beb..794a9a7 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -775,13 +775,15 @@ static void vxlan_fdb_free(struct rcu_head *head)
kfree(f);
}
-static void vxlan_fdb_destroy(struct vxlan_dev *vxlan, struct vxlan_fdb *f)
+static void vxlan_fdb_destroy(struct vxlan_dev *vxlan, struct vxlan_fdb *f,
+ bool do_notify)
{
netdev_dbg(vxlan->dev,
"delete %pM\n", f->eth_addr);
--vxlan->addrcnt;
- vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f), RTM_DELNEIGH);
+ if (do_notify)
+ vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f), RTM_DELNEIGH);
hlist_del_rcu(&f->hlist);
call_rcu(&f->rcu, vxlan_fdb_free);
@@ -931,7 +933,7 @@ static int __vxlan_fdb_delete(struct vxlan_dev *vxlan,
goto out;
}
- vxlan_fdb_destroy(vxlan, f);
+ vxlan_fdb_destroy(vxlan, f, true);
out:
return 0;
@@ -2399,7 +2401,7 @@ static void vxlan_cleanup(struct timer_list *t)
"garbage collect %pM\n",
f->eth_addr);
f->state = NUD_STALE;
- vxlan_fdb_destroy(vxlan, f);
+ vxlan_fdb_destroy(vxlan, f, true);
} else if (time_before(timeout, next_timer))
next_timer = timeout;
}
@@ -2450,7 +2452,7 @@ static void vxlan_fdb_delete_default(struct vxlan_dev *vxlan, __be32 vni)
spin_lock_bh(&vxlan->hash_lock);
f = __vxlan_find_mac(vxlan, all_zeros_mac, vni);
if (f)
- vxlan_fdb_destroy(vxlan, f);
+ vxlan_fdb_destroy(vxlan, f, true);
spin_unlock_bh(&vxlan->hash_lock);
}
@@ -2504,7 +2506,7 @@ static void vxlan_flush(struct vxlan_dev *vxlan, bool do_all)
continue;
/* the all_zeros_mac entry is deleted at vxlan_uninit */
if (!is_zero_ether_addr(f->eth_addr))
- vxlan_fdb_destroy(vxlan, f);
+ vxlan_fdb_destroy(vxlan, f, true);
}
}
spin_unlock_bh(&vxlan->hash_lock);
--
2.1.4
^ permalink raw reply related
* [PATCH net-next 2/4] vxlan: add new fdb alloc and create helpers
From: Roopa Prabhu @ 2018-07-04 23:46 UTC (permalink / raw)
To: davem; +Cc: netdev, jbenc, mike.rapoport, stephen
In-Reply-To: <1530747992-15878-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
- Add new vxlan_fdb_alloc helper
- rename existing vxlan_fdb_create into vxlan_fdb_update:
because it really creates or updates an existing
fdb entry
- move new fdb creation into a separate vxlan_fdb_create
Main motivation for this change is to introduce the ability
to decouple vxlan fdb creation and notify, used in a later patch.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/vxlan.c | 91 ++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 62 insertions(+), 29 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 601ae17..aa88beb 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -637,9 +637,62 @@ static int vxlan_gro_complete(struct sock *sk, struct sk_buff *skb, int nhoff)
return eth_gro_complete(skb, nhoff + sizeof(struct vxlanhdr));
}
-/* Add new entry to forwarding table -- assumes lock held */
+static struct vxlan_fdb *vxlan_fdb_alloc(struct vxlan_dev *vxlan,
+ const u8 *mac, __u16 state,
+ __be32 src_vni, __u8 ndm_flags)
+{
+ struct vxlan_fdb *f;
+
+ f = kmalloc(sizeof(*f), GFP_ATOMIC);
+ if (!f)
+ return NULL;
+ f->state = state;
+ f->flags = ndm_flags;
+ f->updated = f->used = jiffies;
+ f->vni = src_vni;
+ INIT_LIST_HEAD(&f->remotes);
+ memcpy(f->eth_addr, mac, ETH_ALEN);
+
+ return f;
+}
+
static int vxlan_fdb_create(struct vxlan_dev *vxlan,
const u8 *mac, union vxlan_addr *ip,
+ __u16 state, __be16 port, __be32 src_vni,
+ __be32 vni, __u32 ifindex, __u8 ndm_flags,
+ struct vxlan_fdb **fdb)
+{
+ struct vxlan_rdst *rd = NULL;
+ struct vxlan_fdb *f;
+ int rc;
+
+ if (vxlan->cfg.addrmax &&
+ vxlan->addrcnt >= vxlan->cfg.addrmax)
+ return -ENOSPC;
+
+ netdev_dbg(vxlan->dev, "add %pM -> %pIS\n", mac, ip);
+ f = vxlan_fdb_alloc(vxlan, mac, state, src_vni, ndm_flags);
+ if (!f)
+ return -ENOMEM;
+
+ rc = vxlan_fdb_append(f, ip, port, vni, ifindex, &rd);
+ if (rc < 0) {
+ kfree(f);
+ return rc;
+ }
+
+ ++vxlan->addrcnt;
+ hlist_add_head_rcu(&f->hlist,
+ vxlan_fdb_head(vxlan, mac, src_vni));
+
+ *fdb = f;
+
+ return 0;
+}
+
+/* Add new entry to forwarding table -- assumes lock held */
+static int vxlan_fdb_update(struct vxlan_dev *vxlan,
+ const u8 *mac, union vxlan_addr *ip,
__u16 state, __u16 flags,
__be16 port, __be32 src_vni, __be32 vni,
__u32 ifindex, __u8 ndm_flags)
@@ -688,37 +741,17 @@ static int vxlan_fdb_create(struct vxlan_dev *vxlan,
if (!(flags & NLM_F_CREATE))
return -ENOENT;
- if (vxlan->cfg.addrmax &&
- vxlan->addrcnt >= vxlan->cfg.addrmax)
- return -ENOSPC;
-
/* Disallow replace to add a multicast entry */
if ((flags & NLM_F_REPLACE) &&
(is_multicast_ether_addr(mac) || is_zero_ether_addr(mac)))
return -EOPNOTSUPP;
netdev_dbg(vxlan->dev, "add %pM -> %pIS\n", mac, ip);
- f = kmalloc(sizeof(*f), GFP_ATOMIC);
- if (!f)
- return -ENOMEM;
-
- notify = 1;
- f->state = state;
- f->flags = ndm_flags;
- f->updated = f->used = jiffies;
- f->vni = src_vni;
- INIT_LIST_HEAD(&f->remotes);
- memcpy(f->eth_addr, mac, ETH_ALEN);
-
- rc = vxlan_fdb_append(f, ip, port, vni, ifindex, &rd);
- if (rc < 0) {
- kfree(f);
+ rc = vxlan_fdb_create(vxlan, mac, ip, state, port, src_vni,
+ vni, ifindex, ndm_flags, &f);
+ if (rc < 0)
return rc;
- }
-
- ++vxlan->addrcnt;
- hlist_add_head_rcu(&f->hlist,
- vxlan_fdb_head(vxlan, mac, src_vni));
+ notify = 1;
}
if (notify) {
@@ -864,7 +897,7 @@ static int vxlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
return -EAFNOSUPPORT;
spin_lock_bh(&vxlan->hash_lock);
- err = vxlan_fdb_create(vxlan, addr, &ip, ndm->ndm_state, flags,
+ err = vxlan_fdb_update(vxlan, addr, &ip, ndm->ndm_state, flags,
port, src_vni, vni, ifindex, ndm->ndm_flags);
spin_unlock_bh(&vxlan->hash_lock);
@@ -1007,7 +1040,7 @@ static bool vxlan_snoop(struct net_device *dev,
/* close off race between vxlan_flush and incoming packets */
if (netif_running(dev))
- vxlan_fdb_create(vxlan, src_mac, src_ip,
+ vxlan_fdb_update(vxlan, src_mac, src_ip,
NUD_REACHABLE,
NLM_F_EXCL|NLM_F_CREATE,
vxlan->cfg.dst_port,
@@ -3172,7 +3205,7 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
/* create an fdb entry for a valid default destination */
if (!vxlan_addr_any(&vxlan->default_dst.remote_ip)) {
- err = vxlan_fdb_create(vxlan, all_zeros_mac,
+ err = vxlan_fdb_update(vxlan, all_zeros_mac,
&vxlan->default_dst.remote_ip,
NUD_REACHABLE | NUD_PERMANENT,
NLM_F_EXCL | NLM_F_CREATE,
@@ -3452,7 +3485,7 @@ static int vxlan_changelink(struct net_device *dev, struct nlattr *tb[],
old_dst.remote_ifindex, 0);
if (!vxlan_addr_any(&dst->remote_ip)) {
- err = vxlan_fdb_create(vxlan, all_zeros_mac,
+ err = vxlan_fdb_update(vxlan, all_zeros_mac,
&dst->remote_ip,
NUD_REACHABLE | NUD_PERMANENT,
NLM_F_CREATE | NLM_F_APPEND,
--
2.1.4
^ permalink raw reply related
* [PATCH net-next 1/4] rtnetlink: add rtnl_link_state check in rtnl_configure_link
From: Roopa Prabhu @ 2018-07-04 23:46 UTC (permalink / raw)
To: davem; +Cc: netdev, jbenc, mike.rapoport, stephen
In-Reply-To: <1530747992-15878-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
rtnl_configure_link sets dev->rtnl_link_state to
RTNL_LINK_INITIALIZED and unconditionally calls
__dev_notify_flags to notify user-space of dev flags.
current call sequence for rtnl_configure_link
rtnetlink_newlink
rtnl_link_ops->newlink
rtnl_configure_link (unconditionally notifies userspace of
default and new dev flags)
If a newlink handler wants to call rtnl_configure_link
early, we will end up with duplicate notifications to
user-space.
This patch fixes rtnl_configure_link to check rtnl_link_state
and call __dev_notify_flags with gchanges = 0 if already
RTNL_LINK_INITIALIZED.
Later in the series, this patch will help the following sequence
where a driver implementing newlink can call rtnl_configure_link
to initialize the link early.
makes the following call sequence work:
rtnetlink_newlink
rtnl_link_ops->newlink (vxlan) -> rtnl_configure_link (initializes
link and notifies
user-space of default
dev flags)
rtnl_configure_link (updates dev flags if requested by user ifm
and notifies user-space of new dev flags)
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
net/core/rtnetlink.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 5ef6122..e3f743c 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2759,9 +2759,12 @@ int rtnl_configure_link(struct net_device *dev, const struct ifinfomsg *ifm)
return err;
}
- dev->rtnl_link_state = RTNL_LINK_INITIALIZED;
-
- __dev_notify_flags(dev, old_flags, ~0U);
+ if (dev->rtnl_link_state == RTNL_LINK_INITIALIZED) {
+ __dev_notify_flags(dev, old_flags, 0U);
+ } else {
+ dev->rtnl_link_state = RTNL_LINK_INITIALIZED;
+ __dev_notify_flags(dev, old_flags, ~0U);
+ }
return 0;
}
EXPORT_SYMBOL(rtnl_configure_link);
--
2.1.4
^ permalink raw reply related
* [PATCH net-next 0/4] vxlan: fix default fdb entry user-space notify ordering/race
From: Roopa Prabhu @ 2018-07-04 23:46 UTC (permalink / raw)
To: davem; +Cc: netdev, jbenc, mike.rapoport, stephen
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Problem:
In vxlan_newlink, a default fdb entry is added before register_netdev.
The default fdb creation function notifies user-space of the
fdb entry on the vxlan device which user-space does not know about yet.
(RTM_NEWNEIGH goes before RTM_NEWLINK for the same ifindex).
This series fixes the user-space netlink notification ordering issue
with the following changes:
- decouple fdb notify from fdb create.
- Move fdb notify after register_netdev.
- modify rtnl_configure_link to allow configuring a link early.
- Call rtnl_configure_link in vxlan newlink handler to notify
userspace about the newlink before fdb notify and
hence avoiding the user-space race.
Fixes: afbd8bae9c79 ("vxlan: add implicit fdb entry for default destination")
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Roopa Prabhu (4):
vxlan: add new fdb alloc and create helpers
vxlan: make netlink notify in vxlan_fdb_destroy optional
rtnetlink: add rtnl_link_state check in rtnl_configure_link
vxlan: fix default fdb netlink notify ordering during netdev create
drivers/net/vxlan.c | 130 ++++++++++++++++++++++++++++++++++-----------------
net/core/rtnetlink.c | 9 ++--
2 files changed, 94 insertions(+), 45 deletions(-)
--
2.1.4
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Russell King - ARM Linux @ 2018-07-04 23:41 UTC (permalink / raw)
To: Peter Robinson
Cc: Daniel Borkmann, netdev, labbott, linux-arm-kernel, Eric Dumazet
In-Reply-To: <CALeDE9OJomWstG+AcftR543WBi5Bo8ANQj3T-pOW3BfBNzB=uw@mail.gmail.com>
Subject says offlist, but this isn't...
On Wed, Jul 04, 2018 at 08:33:20AM +0100, Peter Robinson wrote:
> Sorry for the delay on this from my end. I noticed there was some bpf
> bits land in the last net fixes pull request landed Monday so I built
> a kernel with the JIT reenabled. It seems it's improved in that the
> completely dead no output boot has gone but the original problem that
> arrived in the merge window still persists:
>
> [ 17.564142] note: systemd-udevd[194] exited with preempt_count 1
> [ 17.592739] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000c
> [ 17.601002] pgd = (ptrval)
> [ 17.603819] [0000000c] *pgd=00000000
> [ 17.607487] Internal error: Oops: 805 [#10] SMP ARM
> [ 17.612396] Modules linked in:
> [ 17.615484] CPU: 0 PID: 195 Comm: systemd-udevd Tainted: G D
> 4.18.0-0.rc3.git1.1.bpf1.fc29.armv7hl #1
> [ 17.626056] Hardware name: Generic AM33XX (Flattened Device Tree)
> [ 17.632198] PC is at sk_filter_trim_cap+0x218/0x2fc
> [ 17.637102] LR is at (null)
> [ 17.640086] pc : [<c0ab03b4>] lr : [<00000000>] psr: 60000013
> [ 17.646384] sp : cfe1dd48 ip : 00000000 fp : 00000000
> [ 17.651635] r10: d837e000 r9 : d833be00 r8 : 00000000
> [ 17.656887] r7 : 00000001 r6 : e003d000 r5 : 00000000 r4 : 00000000
> [ 17.663447] r3 : 00000007 r2 : 00000000 r1 : 00000000 r0 : 00000000
> [ 17.670009] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [ 17.677180] Control: 10c5387d Table: 8fe20019 DAC: 00000051
> [ 17.682956] Process systemd-udevd (pid: 195, stack limit = 0x(ptrval))
> [ 17.689518] Stack: (0xcfe1dd48 to 0xcfe1e000)
Can you provide a full disassembly of sk_filter_trim_cap from vmlinux
(iow, annotated with its linked address) for the above dump please -
alternatively a new dump with matching disassembly. Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [net-next,v2] tcp: Improve setsockopt() TCP_USER_TIMEOUT accuracy
From: Jonathan Maxwell @ 2018-07-04 23:34 UTC (permalink / raw)
To: David Laight
Cc: Neal Cardwell, David Miller, Eric Dumazet, Alexey Kuznetsov,
Hideaki YOSHIFUJI, Netdev, LKML, jmaxwell@redhat.com
In-Reply-To: <2a78c5cbb53248289b54505aece15584@AcuMS.aculab.com>
Let's wait for Eric to review. Then I'll put together the next version.
Regards
Jon
On Thu, Jul 5, 2018 at 12:57 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Neal Cardwell
>> Sent: 04 July 2018 15:14
>>
>> On Tue, Jul 3, 2018 at 8:06 PM Jon Maxwell <jmaxwell37@gmail.com> wrote:
>> >
>> > Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
>> > ---
>> > net/ipv4/tcp_timer.c | 48 +++++++++++++++++++++++++++++++++++++++---------
>> > 1 file changed, 39 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
>> > index 3b3611729928..d129e670d02a 100644
>> > --- a/net/ipv4/tcp_timer.c
>> > +++ b/net/ipv4/tcp_timer.c
> ...
>> > +static __u32 tcp_clamp_rto_to_user_timeout(struct sock *sk)
>> > +{
>> > + struct inet_connection_sock *icsk = inet_csk(sk);
>> > + __u32 rto = icsk->icsk_rto;
>
> Why cache rto past all the function calls until it is needed?
>
>> > + __u32 elapsed, user_timeout;
>> > + unsigned int start_ts;
>>
>> I'd suggest u32 here for start_ts (per the rationale above).
>>
>> > +
>> > + start_ts = tcp_retransmit_stamp(sk);
>> > + if (!icsk->icsk_user_timeout || !start_ts)
>> > + return rto;
>> > + elapsed = tcp_time_stamp(tcp_sk(sk)) - start_ts;
>> > + user_timeout = jiffies_to_msecs(icsk->icsk_user_timeout);
>> > + if (elapsed >= user_timeout)
>> > + rto = 1; /* user timeout has passed; fire ASAP */
>> > + else
>> > + rto = min(rto, (__u32)msecs_to_jiffies(user_timeout - elapsed));
>>
>> My sense is that min_t would be preferred here, e.g:
>>
>> rto = min_t(__u32, rto, msecs_to_jiffies(user_timeout - elapsed));
>
> Think I'd just write the conditional...
>
>> > + return rto;
>> > +}
>
> Looks to me like it doesn't correctly allow for the conversions
> between millisecond and jiffies either.
> I suspect the msecs_to_jiffies() call can return zero (unless it rounds up).
> Coding with a signed 'time until user timeout' might make it simpler.
>
> David
>
>
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Daniel Borkmann @ 2018-07-04 23:10 UTC (permalink / raw)
To: Peter Robinson; +Cc: Eric Dumazet, netdev, linux-arm-kernel, labbott
In-Reply-To: <CALeDE9OJomWstG+AcftR543WBi5Bo8ANQj3T-pOW3BfBNzB=uw@mail.gmail.com>
On 07/04/2018 09:33 AM, Peter Robinson wrote:
> On Tue, Jun 26, 2018 at 1:52 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 06/26/2018 02:23 PM, Peter Robinson wrote:
>>>>>> On 06/24/2018 11:24 AM, Peter Robinson wrote:
>>>>>>>>> I'm seeing this netlink/sk_filter_trim_cap crash on ARMv7 across quite
>>>>>>>>> a few ARMv7 platforms on Fedora with 4.18rc1. I've tested RPi2/RPi3
>>>>>>>>> (doesn't happen on aarch64), AllWinner H3, BeagleBone and a few
>>>>>>>>> others, both LPAE/normal kernels.
>>>>>>
>>>>>> So this is arm32 right?
>>>>>
>>>>> Correct.
>>>>>
>>>>>>>>> I'm a bit out of my depth in this part of the kernel but I'm wondering
>>>>>>>>> if it's known, I couldn't find anything that looked obvious on a few
>>>>>>>>> mailing lists.
>>>>>>>>>
>>>>>>>>> Peter
>>>>>>>>
>>>>>>>> Hi Peter
>>>>>>>>
>>>>>>>> Could you provide symbolic information ?
>>>>>>>
>>>>>>> I passed in through scripts/decode_stacktrace.sh is that what you were after:
>>>>>>>
>>>>>>> [ 8.673880] Internal error: Oops: a06 [#10] SMP ARM
>>>>>>> [ 8.673949] ---[ end trace 049df4786ea3140a ]---
>>>>>>> [ 8.678754] Modules linked in:
>>>>>>> [ 8.678766] CPU: 1 PID: 206 Comm: systemd-udevd Tainted: G D
>>>>>>> 4.18.0-0.rc1.git0.1.fc29.armv7hl+lpae #1
>>>>>>> [ 8.678769] Hardware name: Allwinner sun8i Family
>>>>>>> [ 8.678781] PC is at sk_filter_trim_cap ()
>>>>>>> [ 8.678790] LR is at (null)
>>>>>>> [ 8.709463] pc : lr : psr: 60000013 ()
>>>>>>> [ 8.715722] sp : c996bd60 ip : 00000000 fp : 00000000
>>>>>>> [ 8.720939] r10: ee79dc00 r9 : c12c9f80 r8 : 00000000
>>>>>>> [ 8.726157] r7 : 00000000 r6 : 00000001 r5 : f1648000 r4 : 00000000
>>>>>>> [ 8.732674] r3 : 00000007 r2 : 00000000 r1 : 00000000 r0 : 00000000
>>>>>>> [ 8.739193] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
>>>>>>> [ 8.746318] Control: 30c5387d Table: 6e7bc880 DAC: ffe75ece
>>>>>>> [ 8.752055] Process systemd-udevd (pid: 206, stack limit = 0x(ptrval))
>>>>>>> [ 8.758574] Stack: (0xc996bd60 to 0xc996c000)
>>>>>>
>>>>>> Do you have BPF JIT enabled or disabled? Does it happen with disabled?
>>>>>
>>>>> Enabled, I can test with it disabled, BPF configs bits are:
>>>>> CONFIG_BPF_EVENTS=y
>>>>> # CONFIG_BPFILTER is not set
>>>>> CONFIG_BPF_JIT_ALWAYS_ON=y
>>>>> CONFIG_BPF_JIT=y
>>>>> CONFIG_BPF_STREAM_PARSER=y
>>>>> CONFIG_BPF_SYSCALL=y
>>>>> CONFIG_BPF=y
>>>>> CONFIG_CGROUP_BPF=y
>>>>> CONFIG_HAVE_EBPF_JIT=y
>>>>> CONFIG_IPV6_SEG6_BPF=y
>>>>> CONFIG_LWTUNNEL_BPF=y
>>>>> # CONFIG_NBPFAXI_DMA is not set
>>>>> CONFIG_NET_ACT_BPF=m
>>>>> CONFIG_NET_CLS_BPF=m
>>>>> CONFIG_NETFILTER_XT_MATCH_BPF=m
>>>>> # CONFIG_TEST_BPF is not set
>>>>>
>>>>>> I can see one bug, but your stack trace seems unrelated.
>>>>>>
>>>>>> Anyway, could you try with this?
>>>>>
>>>>> Build in process.
>>>>>
>>>>>> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
>>>>>> index 6e8b716..f6a62ae 100644
>>>>>> --- a/arch/arm/net/bpf_jit_32.c
>>>>>> +++ b/arch/arm/net/bpf_jit_32.c
>>>>>> @@ -1844,7 +1844,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
>>>>>> /* there are 2 passes here */
>>>>>> bpf_jit_dump(prog->len, image_size, 2, ctx.target);
>>>>>>
>>>>>> - set_memory_ro((unsigned long)header, header->pages);
>>>>>> + bpf_jit_binary_lock_ro(header);
>>>>>> prog->bpf_func = (void *)ctx.target;
>>>>>> prog->jited = 1;
>>>>>> prog->jited_len = image_size;
>>>>
>>>> So with that and the other fix there was no improvement, with those
>>>> and the BPF JIT disabled it works, I'm not sure if the two patches
>>>> have any effect with the JIT disabled though.
>>>>
>>>> Will look at the other patches shortly, there's been some other issue
>>>> introduced between rc1 and rc2 which I have to work out before I can
>>>> test those though.
>>>
>>> Quick update, with linus's head as of yesterday, basically rc2 plus
>>> davem's network fixes it works if the JIT is disabled IE:
>>> # CONFIG_BPF_JIT_ALWAYS_ON is not set
>>> # CONFIG_BPF_JIT is not set
>>>
>>> If I enable it the boot breaks even worse than the errors above in
>>> that I get no console output at all, even with earlycon, so we've gone
>>> backwards since rc1 somehow.
>>>
>>> I'll try the above two reverted unless you have any other suggestions.
>>
>> Ok, thanks, lets do that!
>>
>> I'm still working on fixes meanwhile, should have something by end of day.
>
> Sorry for the delay on this from my end. I noticed there was some bpf
> bits land in the last net fixes pull request landed Monday so I built
> a kernel with the JIT reenabled. It seems it's improved in that the
> completely dead no output boot has gone but the original problem that
> arrived in the merge window still persists:
Okay, thanks a lot! And on top of that tree could you try with the below
applied to check whether it fixes the issue?
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index f6a62ae..45e6b49 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -234,11 +234,11 @@ static void jit_fill_hole(void *area, unsigned int size)
#define SCRATCH_SIZE 80
/* total stack size used in JITed code */
-#define _STACK_SIZE (ctx->prog->aux->stack_depth + SCRATCH_SIZE)
+#define _STACK_SIZE (ctx->prog->aux->stack_depth + SCRATCH_SIZE + 4)
#define STACK_SIZE ALIGN(_STACK_SIZE, STACK_ALIGNMENT)
/* Get the offset of eBPF REGISTERs stored on scratch space. */
-#define STACK_VAR(off) (STACK_SIZE - off)
+#define STACK_VAR(off) (STACK_SIZE - 4 - off)
#if __LINUX_ARM_ARCH__ < 7
^ permalink raw reply related
* [PATCH] net: core: filter: mark expected switch fall-through
From: Gustavo A. R. Silva @ 2018-07-04 22:34 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, David S. Miller
Cc: netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Warning level 2 was used: -Wimplicit-fallthrough=2
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/core/filter.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index 547fd34..b9ec916 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -4660,6 +4660,7 @@ bpf_base_func_proto(enum bpf_func_id func_id)
case BPF_FUNC_trace_printk:
if (capable(CAP_SYS_ADMIN))
return bpf_get_trace_printk_proto();
+ /* else: fall through */
default:
return NULL;
}
--
2.7.4
^ permalink raw reply related
* [PATCH] net: decnet: dn_nsp_in: mark expected switch fall-through
From: Gustavo A. R. Silva @ 2018-07-04 22:05 UTC (permalink / raw)
To: David S. Miller
Cc: linux-decnet-user, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/decnet/dn_nsp_in.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/decnet/dn_nsp_in.c b/net/decnet/dn_nsp_in.c
index 1b212064..34aba55 100644
--- a/net/decnet/dn_nsp_in.c
+++ b/net/decnet/dn_nsp_in.c
@@ -491,6 +491,7 @@ static void dn_nsp_disc_conf(struct sock *sk, struct sk_buff *skb)
break;
case DN_RUN:
sk->sk_shutdown |= SHUTDOWN_MASK;
+ /* fall through */
case DN_CC:
scp->state = DN_CN;
}
--
2.7.4
^ permalink raw reply related
* linux-next: Signed-off-by missing for commit in the net tree
From: Stephen Rothwell @ 2018-07-04 21:49 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 187 bytes --]
Hi all,
Commit
33bd5ac54dc4 ("net/ipv6: Revert attempt to simplify route replace and append")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: general protection fault in rds_ib_get_mr
From: Eric Biggers @ 2018-07-04 21:35 UTC (permalink / raw)
To: santosh.shilimkar@oracle.com, linux-rdma, rds-devel
Cc: syzbot, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <27665604-6a26-36e2-3a58-9c8b3d9eab80@oracle.com>
On Sun, May 13, 2018 at 10:46:37PM -0700, santosh.shilimkar@oracle.com wrote:
> On 5/13/18 2:10 PM, Eric Biggers wrote:
> > On Wed, Mar 21, 2018 at 09:00:01AM -0700, syzbot wrote:
>
> [...]
>
>
> > Still reproducible on Linus' tree (commit 66e1c94db3cd4) and linux-next
> > (next-20180511). Here's a simplified reproducer:
> >
> Thanks for the test case !!
>
> Regards,
> Santosh
Ping; this RDS bug is still unfixed. The same reproducer I gave earlier still
works, even when run as a non-root user. I tested upstream commit
fc36def997cfd6 (v4.18-rc3-113-gfc36def997cfd), and linux-next commit
bce40927669338 (next-20180704).
- Eric
^ permalink raw reply
* Re: WARNING: ODEBUG bug in do_arpt_get_ctl
From: Eric Biggers @ 2018-07-04 21:24 UTC (permalink / raw)
To: syzbot
Cc: coreteam, davem, fw, kadlec, linux-kernel, netdev,
netfilter-devel, pablo, syzkaller-bugs
In-Reply-To: <94eb2c0efc1e7e42b20565bf3254@google.com>
On Wed, Feb 21, 2018 at 12:59:03PM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 91ab883eb21325ad80f3473633f794c78ac87f51 (Mon Feb 19 01:29:42 2018 +0000)
> Linux 4.16-rc2
>
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+9d1c0d941336dbc741a1@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> IPVS: ftp: loaded support on port[0] = 21
> IPVS: ftp: loaded support on port[0] = 21
> IPVS: ftp: loaded support on port[0] = 21
> ------------[ cut here ]------------
> ODEBUG: free active (active state 0) object type: work_struct hint:
> htable_gc+0x0/0xc0 net/netfilter/xt_hashlimit.c:376
> WARNING: CPU: 1 PID: 4165 at lib/debugobjects.c:291
> debug_print_object+0x166/0x220 lib/debugobjects.c:288
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 4165 Comm: syz-executor3 Not tainted 4.16.0-rc2+ #320
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> __warn+0x1dc/0x200 kernel/panic.c:547
> report_bug+0x211/0x2d0 lib/bug.c:184
> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
> fixup_bug arch/x86/kernel/traps.c:247 [inline]
> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x58/0x80 arch/x86/entry/entry_64.S:957
> RIP: 0010:debug_print_object+0x166/0x220 lib/debugobjects.c:288
> RSP: 0018:ffff8801b3d8f790 EFLAGS: 00010082
> RAX: dffffc0000000008 RBX: 0000000000000003 RCX: ffffffff815abdbe
> RDX: 0000000000000000 RSI: 1ffff100367b1ea2 RDI: 1ffff100367b1e77
> RBP: ffff8801b3d8f7d0 R08: 0000000000000000 R09: 1ffff100367b1e49
> R10: ffffed00367b1f21 R11: ffffffff86b394b8 R12: 0000000000000001
> R13: ffffffff86b14d80 R14: ffffffff86007de0 R15: ffffffff8147ac00
> __debug_check_no_obj_freed lib/debugobjects.c:745 [inline]
> debug_check_no_obj_freed+0x662/0xf1f lib/debugobjects.c:774
> __vunmap+0x112/0x380 mm/vmalloc.c:1530
> vfree+0x50/0xe0 mm/vmalloc.c:1606
> copy_entries_to_user net/ipv4/netfilter/arp_tables.c:714 [inline]
> get_entries net/ipv4/netfilter/arp_tables.c:867 [inline]
> do_arpt_get_ctl+0x7c4/0xa00 net/ipv4/netfilter/arp_tables.c:1485
> nf_sockopt net/netfilter/nf_sockopt.c:104 [inline]
> nf_getsockopt+0x6a/0xc0 net/netfilter/nf_sockopt.c:122
> ip_getsockopt+0x15c/0x220 net/ipv4/ip_sockglue.c:1571
> tcp_getsockopt+0x82/0xd0 net/ipv4/tcp.c:3359
> sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2934
> SYSC_getsockopt net/socket.c:1880 [inline]
> SyS_getsockopt+0x178/0x340 net/socket.c:1862
> do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x45687a
> RSP: 002b:0000000000a3eb48 EFLAGS: 00000212 ORIG_RAX: 0000000000000037
> RAX: ffffffffffffffda RBX: 0000000000000027 RCX: 000000000045687a
> RDX: 0000000000000061 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 0000000000a3f200 R08: 0000000000a3eb7c R09: 0000000000000001
> R10: 0000000000a3f200 R11: 0000000000000212 R12: 0000000000a3eb80
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000001380
>
Like the similar bug report "WARNING: ODEBUG bug in do_ipt_get_ctl" [1], this
report doesn't make sense as there is no work_struct in the array being freed.
And this last occurred 4 months ago. So I am invalidating this one too as it
probably was a weird bug elsewhere in the kernel that has since been fixed:
#syz invalid
[1] https://groups.google.com/forum/#!msg/syzkaller-bugs/A_gWpsvtxKc/5YSSVpImDQAJ
- Eric
^ permalink raw reply
* Re: recvmsg bug not clear
From: 積丹尼 Dan Jacobson @ 2018-07-04 21:22 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-kernel, netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <97b3d0e4-7920-4462-6bc6-8cca3e57c560@infradead.org>
>>>>> "RD" == Randy Dunlap <rdunlap@infradead.org> writes:
RD> That's a message from net/ipv4/tcp.c
OK, but there should be something telling the user one way or the other
that the following is an error / bug message from the Linux kernel, (and
thus not some random program that the user installed), from the
component net/ipv4/tcp.c, and represents some condition that was
unexpected and should be reported to ... or is the user's own fault ...
and if he wants to google about it he is best to use ...
^ permalink raw reply
* Re: WARNING: ODEBUG bug in do_ipt_get_ctl
From: Eric Biggers @ 2018-07-04 21:19 UTC (permalink / raw)
To: syzbot
Cc: coreteam, davem, fw, kadlec, kuznet, linux-kernel, netdev,
netfilter-devel, pablo, syzkaller-bugs, yoshfuji
In-Reply-To: <001a1144a42015356b05660bcb98@google.com>
On Sun, Feb 25, 2018 at 08:22:01AM -0800, syzbot wrote:
> syzbot has found reproducer for the following crash on net-next commit
> f74290fdb363665538743d14c4f00aeacdb68d87 (Sat Feb 24 05:04:20 2018 +0000)
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>
> So far this crash happened 3 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+d7deafa2c73b7a2b74ef@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed.
>
> ------------[ cut here ]------------
> ODEBUG: free active (active state 0) object type: timer_list hint:
> delayed_work_timer_fn+0x0/0x90 kernel/workqueue.c:1355
> WARNING: CPU: 1 PID: 4244 at lib/debugobjects.c:291
> debug_print_object+0x166/0x220 lib/debugobjects.c:288
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 4244 Comm: syzkaller150583 Not tainted 4.16.0-rc2+ #241
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x24d lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> __warn+0x1dc/0x200 kernel/panic.c:547
> report_bug+0x211/0x2d0 lib/bug.c:184
> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
> fixup_bug arch/x86/kernel/traps.c:247 [inline]
> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x58/0x80 arch/x86/entry/entry_64.S:957
> RIP: 0010:debug_print_object+0x166/0x220 lib/debugobjects.c:288
> RSP: 0018:ffff8801cc2c7778 EFLAGS: 00010082
> RAX: dffffc0000000008 RBX: 0000000000000003 RCX: ffffffff815abe7e
> RDX: 0000000000000000 RSI: 1ffff10039858e9f RDI: 1ffff10039858e74
> RBP: ffff8801cc2c77b8 R08: 0000000000000000 R09: 1ffff10039858e46
> R10: ffffed0039858f1e R11: ffffffff86f395b8 R12: 0000000000000001
> R13: ffffffff86f4ae20 R14: ffffffff86407fa0 R15: ffffffff815fe8e0
> __debug_check_no_obj_freed lib/debugobjects.c:745 [inline]
> debug_check_no_obj_freed+0x662/0xf1f lib/debugobjects.c:774
> __vunmap+0x112/0x380 mm/vmalloc.c:1530
> vfree+0x50/0xe0 mm/vmalloc.c:1606
> copy_entries_to_user net/ipv4/netfilter/ip_tables.c:880 [inline]
> get_entries net/ipv4/netfilter/ip_tables.c:1035 [inline]
> do_ipt_get_ctl+0x7f5/0xac0 net/ipv4/netfilter/ip_tables.c:1708
> nf_sockopt net/netfilter/nf_sockopt.c:104 [inline]
> nf_getsockopt+0x6a/0xc0 net/netfilter/nf_sockopt.c:122
> ip_getsockopt+0x152/0x200 net/ipv4/ip_sockglue.c:1572
> tcp_getsockopt+0x82/0xd0 net/ipv4/tcp.c:3332
> sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2938
> SYSC_getsockopt net/socket.c:1881 [inline]
> SyS_getsockopt+0x178/0x340 net/socket.c:1863
> do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x455faa
> RSP: 002b:000000000080e8c8 EFLAGS: 00000216 ORIG_RAX: 0000000000000037
> RAX: ffffffffffffffda RBX: 00000000006ea840 RCX: 0000000000455faa
> RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000004
> RBP: 00000000006ea840 R08: 000000000080e8ec R09: 0000000000004000
> R10: 000000000080e9f0 R11: 0000000000000216 R12: 0000000000000004
> R13: 000000000080e9f0 R14: 000000000080e8f0 R15: 0000000000000000
This last occurred 4 months ago, the report doesn't make sense, and I can't
reproduce it even with the same kernel commit, kernel config, and C repro syzbot
gave. The "debug objects" infrastructure is complaining that there was an
active timer freed by the 'vfree(counters);' in copy_entries_to_user(), via
IPT_SO_GET_ENTRIES. But, 'counters' is simply an array of
struct xt_counters {
__u64 pcnt, bcnt; /* Packet and byte counters */
};
There's no timer it can be freeing.
So I'm invalidating this report, as it probably was a weird bug elsewhere in the
kernel that has been fixed by now.
#syz invalid
- Eric
^ permalink raw reply
* [PATCH] tipc: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-07-04 21:13 UTC (permalink / raw)
To: Jon Maloy, Ying Xue, David S. Miller
Cc: netdev, tipc-discussion, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Warning level 2 was used: -Wimplicit-fallthrough=2
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/tipc/bearer.c | 1 +
net/tipc/link.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index 2dfb492..fd6d8f1 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -610,6 +610,7 @@ static int tipc_l2_device_event(struct notifier_block *nb, unsigned long evt,
case NETDEV_CHANGE:
if (netif_carrier_ok(dev))
break;
+ /* else: fall through */
case NETDEV_UP:
test_and_set_bit_lock(0, &b->up);
break;
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 695acb7..6386032 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1063,6 +1063,7 @@ static bool tipc_data_input(struct tipc_link *l, struct sk_buff *skb,
skb_queue_tail(mc_inputq, skb);
return true;
}
+ /* else: fall through */
case CONN_MANAGER:
skb_queue_tail(inputq, skb);
return true;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] net/ipv6: Revert attempt to simplify route replace and append
From: Ido Schimmel @ 2018-07-04 21:10 UTC (permalink / raw)
To: David Ahern; +Cc: dsahern, netdev, sharpd, Thomas.Winter, petrm
In-Reply-To: <e0f62775-a7e0-ad4e-5eaa-a6ecb3b2c8db@gmail.com>
On Tue, Jul 03, 2018 at 02:02:06PM -0600, David Ahern wrote:
> It is unfortunate that mlxsw has to replicate the node lookup code.
The kernel can store multiple routes with the same prefix/length, but
only one is used for forwarding. Thus when a route is deleted it should
be potentially overwritten by a different route in the device's tables.
This is why mlxsw stores these nodes.
We can have the IPv4/IPv6 code only generate a REPLACE / DELETE
notification for routes that are actually used for forwarding and
relieve listeners from the need to implement this logic themselves. I
think this should work.
?
^ permalink raw reply
* [PATCH] wireless: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-07-04 21:05 UTC (permalink / raw)
To: Johannes Berg, David S. Miller
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Warning level 2 was used: -Wimplicit-fallthrough=2
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/wireless/chan.c | 2 ++
net/wireless/nl80211.c | 9 +++++++++
net/wireless/wext-compat.c | 2 ++
3 files changed, 13 insertions(+)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 2db713d..145cb51 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -747,6 +747,7 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
case NL80211_CHAN_WIDTH_20:
if (!ht_cap->ht_supported)
return false;
+ /* else: fall through */
case NL80211_CHAN_WIDTH_20_NOHT:
prohibited_flags |= IEEE80211_CHAN_NO_20MHZ;
width = 20;
@@ -769,6 +770,7 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
cap = vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
if (cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ)
return false;
+ /* else: fall through */
case NL80211_CHAN_WIDTH_80:
if (!vht_cap->vht_supported)
return false;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e4e5f02..59b0ac5 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1676,6 +1676,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
state->split_start++;
if (state->split)
break;
+ /* else: fall through */
case 1:
if (nla_put(msg, NL80211_ATTR_CIPHER_SUITES,
sizeof(u32) * rdev->wiphy.n_cipher_suites,
@@ -1722,6 +1723,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
state->split_start++;
if (state->split)
break;
+ /* else: fall through */
case 2:
if (nl80211_put_iftypes(msg, NL80211_ATTR_SUPPORTED_IFTYPES,
rdev->wiphy.interface_modes))
@@ -1729,6 +1731,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
state->split_start++;
if (state->split)
break;
+ /* else: fall through */
case 3:
nl_bands = nla_nest_start(msg, NL80211_ATTR_WIPHY_BANDS);
if (!nl_bands)
@@ -1754,6 +1757,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
state->chan_start++;
if (state->split)
break;
+ /* else: fall through */
default:
/* add frequencies */
nl_freqs = nla_nest_start(
@@ -1807,6 +1811,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
state->split_start++;
if (state->split)
break;
+ /* else: fall through */
case 4:
nl_cmds = nla_nest_start(msg, NL80211_ATTR_SUPPORTED_COMMANDS);
if (!nl_cmds)
@@ -1833,6 +1838,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
state->split_start++;
if (state->split)
break;
+ /* else: fall through */
case 5:
if (rdev->ops->remain_on_channel &&
(rdev->wiphy.flags & WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL) &&
@@ -1850,6 +1856,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
state->split_start++;
if (state->split)
break;
+ /* else: fall through */
case 6:
#ifdef CONFIG_PM
if (nl80211_send_wowlan(msg, rdev, state->split))
@@ -1872,6 +1879,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
state->split_start++;
if (state->split)
break;
+ /* else: fall through */
case 8:
if ((rdev->wiphy.flags & WIPHY_FLAG_HAVE_AP_SME) &&
nla_put_u32(msg, NL80211_ATTR_DEVICE_AP_SME,
@@ -4466,6 +4474,7 @@ static int parse_station_flags(struct genl_info *info,
params->sta_flags_mask = BIT(NL80211_STA_FLAG_AUTHENTICATED) |
BIT(NL80211_STA_FLAG_MFP) |
BIT(NL80211_STA_FLAG_AUTHORIZED);
+ /* fall through */
default:
return -EINVAL;
}
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 167f702..9db3920 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -1333,6 +1333,7 @@ static struct iw_statistics *cfg80211_wireless_stats(struct net_device *dev)
wstats.qual.qual = sig + 110;
break;
}
+ /* else: fall through */
case CFG80211_SIGNAL_TYPE_UNSPEC:
if (sinfo.filled & BIT_ULL(NL80211_STA_INFO_SIGNAL)) {
wstats.qual.updated |= IW_QUAL_LEVEL_UPDATED;
@@ -1341,6 +1342,7 @@ static struct iw_statistics *cfg80211_wireless_stats(struct net_device *dev)
wstats.qual.qual = sinfo.signal;
break;
}
+ /* else: fall through */
default:
wstats.qual.updated |= IW_QUAL_LEVEL_INVALID;
wstats.qual.updated |= IW_QUAL_QUAL_INVALID;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 2/5 v2] net: gemini: Improve connection prints
From: Andrew Lunn @ 2018-07-04 20:40 UTC (permalink / raw)
To: Linus Walleij
Cc: netdev, David S . Miller, Michał Mirosław,
Florian Fainelli, Paulius Zaleckas, Hans Ulli Kroll, Janos Laube,
linux-arm-kernel
In-Reply-To: <20180704183324.10605-2-linus.walleij@linaro.org>
On Wed, Jul 04, 2018 at 08:33:21PM +0200, Linus Walleij wrote:
> Switch over to using a module parameter and debug prints
> that can be controlled by this or ethtool like everyone
> else. Depromote all other prints to debug messages.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Use a module parameter and the message levels like all
> other drivers and stop trying to be special.
> ---
> drivers/net/ethernet/cortina/gemini.c | 44 +++++++++++++++------------
> 1 file changed, 25 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
> index 8fc31723f700..f219208d2351 100644
> --- a/drivers/net/ethernet/cortina/gemini.c
> +++ b/drivers/net/ethernet/cortina/gemini.c
> @@ -46,6 +46,11 @@
> #define DRV_NAME "gmac-gemini"
> #define DRV_VERSION "1.0"
>
> +#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
> +static int debug = -1;
> +module_param(debug, int, 0);
> +MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
> +
> #define HSIZE_8 0x00
> #define HSIZE_16 0x01
> #define HSIZE_32 0x02
> @@ -300,23 +305,26 @@ static void gmac_speed_set(struct net_device *netdev)
> status.bits.speed = GMAC_SPEED_1000;
> if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
> status.bits.mii_rmii = GMAC_PHY_RGMII_1000;
> - netdev_info(netdev, "connect to RGMII @ 1Gbit\n");
> + netdev_dbg(netdev, "connect %s to RGMII @ 1Gbit\n",
> + phydev_name(phydev));
Hi Linus
Since these are netdev_dbg, they will generally never be seen. So
could you add a call to phy_print_status() at the end of this
function. That is what most MAC drivers do.
> - netdev_info(netdev, "connected to PHY \"%s\"\n",
> - phydev_name(phy));
> - phy_attached_print(phy, "phy_id=0x%.8lx, phy_mode=%s\n",
> - (unsigned long)phy->phy_id,
> - phy_modes(phy->interface));
> + netdev_dbg(netdev, "connected to PHY \"%s\"\n",
> + phydev_name(phy));
>
It would be nice to call phy_attached_info(), as most other MAC
drivers do.
Andrew
^ permalink raw reply
* Re: [PATCHv2 net-next 2/2] selftests: add a selftest for directed broadcast forwarding
From: Ido Schimmel @ 2018-07-04 20:39 UTC (permalink / raw)
To: Xin Long; +Cc: David Ahern, network dev, davem, Davide Caratti
In-Reply-To: <CADvbK_c6pdnHuKd_aDG3REWvGRx5AtGH2YO90tyRvcWesBDzPw@mail.gmail.com>
On Thu, Jul 05, 2018 at 01:56:23AM +0800, Xin Long wrote:
> On Wed, Jul 4, 2018 at 3:23 AM, David Ahern <dsahern@gmail.com> wrote:
> > your commands are not a proper test. The test should succeed and fail
> > based on the routing lookup, not iptables rules.
> A proper test can be done easily with netns, as vrf can't isolate much.
> I don't want to bother forwarding/ directory with netns, so I will probably
> just drop this selftest, and let the feature patch go first.
>
> What do you think?
You can add a tc rule on the ingress of h2 and make sure that in the
first case ping succeeds and the tc rule wasn't hit. In the second case
ping should also succeed, but the tc rule should be hit. This is similar
to your original netns test.
You can look at tc_flower.sh for reference and in particular at
tc_check_packets().
^ 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