* [PATCH net] net, sched: respect rcu grace period on cls destruction
From: Daniel Borkmann @ 2016-11-27 0:18 UTC (permalink / raw)
To: davem
Cc: xiyou.wangcong, john.fastabend, roid, ast, hannes, jiri, netdev,
Daniel Borkmann
Roi reported a crash in flower where tp->root was NULL in ->classify()
callbacks. Reason is that in ->destroy() tp->root is set to NULL via
RCU_INIT_POINTER(). It's problematic for some of the classifiers, because
this doesn't respect RCU grace period for them, and as a result, still
outstanding readers from tc_classify() will try to blindly dereference
a NULL tp->root.
The tp->root object is strictly private to the classifier implementation
and holds internal data the core such as tc_ctl_tfilter() doesn't know
about. Within some classifiers, such as cls_bpf, cls_basic, etc, tp->root
is only checked for NULL in ->get() callback, but nowhere else. This is
misleading and seemed to be copied from old classifier code that was not
cleaned up properly. For example, d3fa76ee6b4a ("[NET_SCHED]: cls_basic:
fix NULL pointer dereference") moved tp->root initialization into ->init()
routine, where before it was part of ->change(), so ->get() had to deal
with tp->root being NULL back then, so that was indeed a valid case, after
d3fa76ee6b4a, not really anymore. We used to set tp->root to NULL long
ago in ->destroy(), see 47a1a1d4be29 ("pkt_sched: remove unnecessary xchg()
in packet classifiers"); but the NULLifying was reintroduced with the
RCUification, but it's not correct for every classifier implementation.
In the cases that are fixed here with one exception of cls_cgroup, tp->root
object is allocated and initialized inside ->init() callback, which is always
performed at a point in time after we allocate a new tp, which means tp and
thus tp->root was not globally visible in the tp chain yet (see tc_ctl_tfilter()).
Also, on destruction tp->root is strictly kfree_rcu()'ed in ->destroy()
handler, same for the tp which is kfree_rcu()'ed right when we return
from ->destroy() in tcf_destroy(). This means, the head object's lifetime
for such classifiers is always tied to the tp lifetime. The RCU callback
invocation for the two kfree_rcu() could be out of order, but that's fine
since both are independent.
Dropping the RCU_INIT_POINTER(tp->root, NULL) for these classifiers here
means that 1) we don't need a useless NULL check in fast-path and, 2) that
outstanding readers of that tp in tc_classify() can still execute under
respect with RCU grace period as it is actually expected.
Things that haven't been touched here: cls_fw and cls_route. They each
handle tp->root being NULL in ->classify() path for historic reasons, so
their ->destroy() implementation can stay as is. If someone actually
cares, they could get cleaned up at some point to avoid the test in fast
path. cls_u32 doesn't set tp->root to NULL. For cls_rsvp, I just added a
!head should anyone actually be using/testing it, so it at least aligns with
cls_fw and cls_route. For cls_flower we additionally need to defer rhashtable
destruction (to a sleepable context) after RCU grace period as concurrent
readers might still access it. (Note that in this case we need to hold module
reference to keep work callback address intact, since we only wait on module
unload for all call_rcu()s to finish.)
This fixes one race to bring RCU grace period guarantees back. Next step
as worked on by Cong however is to fix 1e052be69d04 ("net_sched: destroy
proto tp when all filters are gone") to get the order of unlinking the tp
in tc_ctl_tfilter() for the RTM_DELTFILTER case right by moving
RCU_INIT_POINTER() before tcf_destroy() and let the notification for
removal be done through the prior ->delete() callback. Both are independant
issues. Once we have that right, we can then clean tp->root up for a number
of classifiers by not making them RCU pointers, which requires a new callback
(->uninit) that is triggered from tp's RCU callback, where we just kfree()
tp->root from there.
Fixes: 1f947bf151e9 ("net: sched: rcu'ify cls_bpf")
Fixes: 9888faefe132 ("net: sched: cls_basic use RCU")
Fixes: 70da9f0bf999 ("net: sched: cls_flow use RCU")
Fixes: 77b9900ef53a ("tc: introduce Flower classifier")
Fixes: bf3994d2ed31 ("net/sched: introduce Match-all classifier")
Fixes: 952313bd6258 ("net: sched: cls_cgroup use RCU")
Reported-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: Roi Dayan <roid@mellanox.com>
Cc: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_basic.c | 4 ----
net/sched/cls_bpf.c | 4 ----
net/sched/cls_cgroup.c | 7 +++----
net/sched/cls_flow.c | 1 -
net/sched/cls_flower.c | 31 ++++++++++++++++++++++++++-----
net/sched/cls_matchall.c | 1 -
net/sched/cls_rsvp.h | 3 ++-
net/sched/cls_tcindex.c | 1 -
8 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/net/sched/cls_basic.c b/net/sched/cls_basic.c
index eb219b7..5877f60 100644
--- a/net/sched/cls_basic.c
+++ b/net/sched/cls_basic.c
@@ -62,9 +62,6 @@ static unsigned long basic_get(struct tcf_proto *tp, u32 handle)
struct basic_head *head = rtnl_dereference(tp->root);
struct basic_filter *f;
- if (head == NULL)
- return 0UL;
-
list_for_each_entry(f, &head->flist, link) {
if (f->handle == handle) {
l = (unsigned long) f;
@@ -109,7 +106,6 @@ static bool basic_destroy(struct tcf_proto *tp, bool force)
tcf_unbind_filter(tp, &f->res);
call_rcu(&f->rcu, basic_delete_filter);
}
- RCU_INIT_POINTER(tp->root, NULL);
kfree_rcu(head, rcu);
return true;
}
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index bb1d5a4..0a47ba5 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -292,7 +292,6 @@ static bool cls_bpf_destroy(struct tcf_proto *tp, bool force)
call_rcu(&prog->rcu, __cls_bpf_delete_prog);
}
- RCU_INIT_POINTER(tp->root, NULL);
kfree_rcu(head, rcu);
return true;
}
@@ -303,9 +302,6 @@ static unsigned long cls_bpf_get(struct tcf_proto *tp, u32 handle)
struct cls_bpf_prog *prog;
unsigned long ret = 0UL;
- if (head == NULL)
- return 0UL;
-
list_for_each_entry(prog, &head->plist, link) {
if (prog->handle == handle) {
ret = (unsigned long) prog;
diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
index 85233c47..c1f2007 100644
--- a/net/sched/cls_cgroup.c
+++ b/net/sched/cls_cgroup.c
@@ -137,11 +137,10 @@ static bool cls_cgroup_destroy(struct tcf_proto *tp, bool force)
if (!force)
return false;
-
- if (head) {
- RCU_INIT_POINTER(tp->root, NULL);
+ /* Head can still be NULL due to cls_cgroup_init(). */
+ if (head)
call_rcu(&head->rcu, cls_cgroup_destroy_rcu);
- }
+
return true;
}
diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index e396723..6575aba 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -596,7 +596,6 @@ static bool flow_destroy(struct tcf_proto *tp, bool force)
list_del_rcu(&f->list);
call_rcu(&f->rcu, flow_destroy_filter);
}
- RCU_INIT_POINTER(tp->root, NULL);
kfree_rcu(head, rcu);
return true;
}
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index f6f40fb..b296f39 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -13,6 +13,7 @@
#include <linux/init.h>
#include <linux/module.h>
#include <linux/rhashtable.h>
+#include <linux/workqueue.h>
#include <linux/if_ether.h>
#include <linux/in6.h>
@@ -64,7 +65,10 @@ struct cls_fl_head {
bool mask_assigned;
struct list_head filters;
struct rhashtable_params ht_params;
- struct rcu_head rcu;
+ union {
+ struct work_struct work;
+ struct rcu_head rcu;
+ };
};
struct cls_fl_filter {
@@ -269,6 +273,24 @@ static void fl_hw_update_stats(struct tcf_proto *tp, struct cls_fl_filter *f)
dev->netdev_ops->ndo_setup_tc(dev, tp->q->handle, tp->protocol, &tc);
}
+static void fl_destroy_sleepable(struct work_struct *work)
+{
+ struct cls_fl_head *head = container_of(work, struct cls_fl_head,
+ work);
+ if (head->mask_assigned)
+ rhashtable_destroy(&head->ht);
+ kfree(head);
+ module_put(THIS_MODULE);
+}
+
+static void fl_destroy_rcu(struct rcu_head *rcu)
+{
+ struct cls_fl_head *head = container_of(rcu, struct cls_fl_head, rcu);
+
+ INIT_WORK(&head->work, fl_destroy_sleepable);
+ schedule_work(&head->work);
+}
+
static bool fl_destroy(struct tcf_proto *tp, bool force)
{
struct cls_fl_head *head = rtnl_dereference(tp->root);
@@ -282,10 +304,9 @@ static bool fl_destroy(struct tcf_proto *tp, bool force)
list_del_rcu(&f->list);
call_rcu(&f->rcu, fl_destroy_filter);
}
- RCU_INIT_POINTER(tp->root, NULL);
- if (head->mask_assigned)
- rhashtable_destroy(&head->ht);
- kfree_rcu(head, rcu);
+
+ __module_get(THIS_MODULE);
+ call_rcu(&head->rcu, fl_destroy_rcu);
return true;
}
diff --git a/net/sched/cls_matchall.c b/net/sched/cls_matchall.c
index 25927b6..f935429 100644
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@ -114,7 +114,6 @@ static bool mall_destroy(struct tcf_proto *tp, bool force)
call_rcu(&f->rcu, mall_destroy_filter);
}
- RCU_INIT_POINTER(tp->root, NULL);
kfree_rcu(head, rcu);
return true;
}
diff --git a/net/sched/cls_rsvp.h b/net/sched/cls_rsvp.h
index 4f05a19..322438f 100644
--- a/net/sched/cls_rsvp.h
+++ b/net/sched/cls_rsvp.h
@@ -152,7 +152,8 @@ static int rsvp_classify(struct sk_buff *skb, const struct tcf_proto *tp,
return -1;
nhptr = ip_hdr(skb);
#endif
-
+ if (unlikely(!head))
+ return -1;
restart:
#if RSVP_DST_LEN == 4
diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
index 96144bd..0751245 100644
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -543,7 +543,6 @@ static bool tcindex_destroy(struct tcf_proto *tp, bool force)
walker.fn = tcindex_destroy_element;
tcindex_walk(tp, &walker);
- RCU_INIT_POINTER(tp->root, NULL);
call_rcu(&p->rcu, __tcindex_destroy);
return true;
}
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] mlx4: give precise rx/tx bytes/packets counters
From: Saeed Mahameed @ 2016-11-26 22:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Tariq Toukan
In-Reply-To: <1480088780.8455.543.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Nov 25, 2016 at 5:46 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> mlx4 stats are chaotic because a deferred work queue is responsible
> to update them every 250 ms.
>
Hello Eric,
Well the only historical reason for this deferred work is that we
query FW for some counters which might sleep.
and there is one place in the kernel where dev_get_stats(dev, &temp)
is called under a rw lock "read_lock(&dev_base_lock);"
in http://lxr.free-electrons.com/source/net/core/net-sysfs.c#L552, i
am not sure why is it this way ? Maybe it is time fix this and get rid
of the deferred work, which will give you the same precision even for
when reading ehttool stats, which this patch didn't take care off.
this will also improve other drivers who might sleep while reading
stats.
> Even sampling stats every one second with "sar -n DEV 1" gives
> variations like the following :
>
> lpaa23:~# sar -n DEV 1 10 | grep eth0 | cut -c1-65
> 07:39:22 eth0 146877.00 3265554.00 9467.15 4828168.50
> 07:39:23 eth0 146587.00 3260329.00 9448.15 4820445.98
> 07:39:24 eth0 146894.00 3259989.00 9468.55 4819943.26
> 07:39:25 eth0 110368.00 2454497.00 7113.95 3629012.17 <<>>
> 07:39:26 eth0 146563.00 3257502.00 9447.25 4816266.23
> 07:39:27 eth0 145678.00 3258292.00 9389.79 4817414.39
> 07:39:28 eth0 145268.00 3253171.00 9363.85 4809852.46
> 07:39:29 eth0 146439.00 3262185.00 9438.97 4823172.48
> 07:39:30 eth0 146758.00 3264175.00 9459.94 4826124.13
> 07:39:31 eth0 146843.00 3256903.00 9465.44 4815381.97
> Average: eth0 142827.50 3179259.70 9206.30 4700578.16
>
> This patch allows rx/tx bytes/packets counters being folded at the
> time we need stats.
>
> We now can fetch stats every 1 ms if we want to check NIC behavior
> on a small time window. It is also easier to detect anomalies.
>
> lpaa23:~# sar -n DEV 1 10 | grep eth0 | cut -c1-65
> 07:42:50 eth0 142915.00 3177696.00 9212.06 4698270.42
> 07:42:51 eth0 143741.00 3200232.00 9265.15 4731593.02
> 07:42:52 eth0 142781.00 3171600.00 9202.92 4689260.16
> 07:42:53 eth0 143835.00 3192932.00 9271.80 4720761.39
> 07:42:54 eth0 141922.00 3165174.00 9147.64 4679759.21
> 07:42:55 eth0 142993.00 3207038.00 9216.78 4741653.05
> 07:42:56 eth0 141394.06 3154335.64 9113.85 4663731.73
> 07:42:57 eth0 141850.00 3161202.00 9144.48 4673866.07
> 07:42:58 eth0 143439.00 3180736.00 9246.05 4702755.35
> 07:42:59 eth0 143501.00 3210992.00 9249.99 4747501.84
> Average: eth0 142835.66 3182165.93 9206.98 4704874.08
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Tariq Toukan <tariqt@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1
> drivers/net/ethernet/mellanox/mlx4/en_port.c | 77 +++++++++-----
> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1
> 4 files changed, 58 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> index 487a58f9c192896852fef271b6cce9bde132deb7..d9c9f86a30df953fa555934c5406057dcaf28960 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> @@ -367,6 +367,8 @@ static void mlx4_en_get_ethtool_stats(struct net_device *dev,
>
> spin_lock_bh(&priv->stats_lock);
>
> + mlx4_en_fold_software_stats(dev);
> +
> for (i = 0; i < NUM_MAIN_STATS; i++, bitmap_iterator_inc(&it))
> if (bitmap_iterator_test(&it))
> data[index++] = ((unsigned long *)&dev->stats)[i];
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 9018bb1b2e12142e048281a9d28ddf95e0023a61..d28d841db23ce885d2011877a156bacf23f65afe 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -1321,6 +1321,7 @@ mlx4_en_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *stats)
> struct mlx4_en_priv *priv = netdev_priv(dev);
>
> spin_lock_bh(&priv->stats_lock);
> + mlx4_en_fold_software_stats(dev);
> netdev_stats_to_stats64(stats, &dev->stats);
> spin_unlock_bh(&priv->stats_lock);
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_port.c b/drivers/net/ethernet/mellanox/mlx4/en_port.c
> index 1eb4c1e10bad1dad26049876acf107a2073a6ab1..c6c4f1238923e09eced547454b86c68720292859 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_port.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_port.c
> @@ -147,6 +147,39 @@ static unsigned long en_stats_adder(__be64 *start, __be64 *next, int num)
> return ret;
> }
>
> +void mlx4_en_fold_software_stats(struct net_device *dev)
> +{
> + struct mlx4_en_priv *priv = netdev_priv(dev);
> + struct mlx4_en_dev *mdev = priv->mdev;
> + unsigned long packets, bytes;
> + int i;
> +
> + if (mlx4_is_master(mdev->dev))
> + return;
hmm, I think here you are just dragging a wrong discussion made in
mlx4 driver that the PF (only in SRIOV mode) netdev stats should
report the whole port stats from MLX4_CMD_DUMP_ETH_STATS FW command.
IMHO mlx4_en_get_stats64 should always report SW stats.
regardless, this function "mlx4_en_fold_software_stats" should always
fold the SW stats unconditionally, and W/A it somewhere else if SW
stats should be reported from FW. otherwise we will keep dragging this
confusion.
> +
> + packets = 0;
> + bytes = 0;
> + for (i = 0; i < priv->rx_ring_num; i++) {
> + const struct mlx4_en_rx_ring *ring = priv->rx_ring[i];
> +
> + packets += READ_ONCE(ring->packets);
> + bytes += READ_ONCE(ring->bytes);
> + }
> + dev->stats.rx_packets = packets;
> + dev->stats.rx_bytes = bytes;
> +
> + packets = 0;
> + bytes = 0;
> + for (i = 0; i < priv->tx_ring_num[TX]; i++) {
> + const struct mlx4_en_tx_ring *ring = priv->tx_ring[TX][i];
> +
> + packets += READ_ONCE(ring->packets);
> + bytes += READ_ONCE(ring->bytes);
> + }
> + dev->stats.tx_packets = packets;
> + dev->stats.tx_bytes = bytes;
> +}
> +
> int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8 port, u8 reset)
> {
> struct mlx4_counter tmp_counter_stats;
> @@ -159,6 +192,7 @@ int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8 port, u8 reset)
> u64 in_mod = reset << 8 | port;
> int err;
> int i, counter_index;
> + unsigned long sw_tx_dropped = 0;
> unsigned long sw_rx_dropped = 0;
>
> mailbox = mlx4_alloc_cmd_mailbox(mdev->dev);
> @@ -174,8 +208,8 @@ int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8 port, u8 reset)
>
> spin_lock_bh(&priv->stats_lock);
>
> - stats->rx_packets = 0;
> - stats->rx_bytes = 0;
> + mlx4_en_fold_software_stats(dev);
> +
> priv->port_stats.rx_chksum_good = 0;
> priv->port_stats.rx_chksum_none = 0;
> priv->port_stats.rx_chksum_complete = 0;
> @@ -183,19 +217,16 @@ int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8 port, u8 reset)
> priv->xdp_stats.rx_xdp_tx = 0;
> priv->xdp_stats.rx_xdp_tx_full = 0;
> for (i = 0; i < priv->rx_ring_num; i++) {
> - stats->rx_packets += priv->rx_ring[i]->packets;
> - stats->rx_bytes += priv->rx_ring[i]->bytes;
> - sw_rx_dropped += priv->rx_ring[i]->dropped;
> - priv->port_stats.rx_chksum_good += priv->rx_ring[i]->csum_ok;
> - priv->port_stats.rx_chksum_none += priv->rx_ring[i]->csum_none;
> - priv->port_stats.rx_chksum_complete += priv->rx_ring[i]->csum_complete;
> - priv->xdp_stats.rx_xdp_drop += priv->rx_ring[i]->xdp_drop;
> - priv->xdp_stats.rx_xdp_tx += priv->rx_ring[i]->xdp_tx;
> - priv->xdp_stats.rx_xdp_tx_full += priv->rx_ring[i]->xdp_tx_full;
> + const struct mlx4_en_rx_ring *ring = priv->rx_ring[i];
> +
> + sw_rx_dropped += READ_ONCE(ring->dropped);
> + priv->port_stats.rx_chksum_good += READ_ONCE(ring->csum_ok);
> + priv->port_stats.rx_chksum_none += READ_ONCE(ring->csum_none);
> + priv->port_stats.rx_chksum_complete += READ_ONCE(ring->csum_complete);
> + priv->xdp_stats.rx_xdp_drop += READ_ONCE(ring->xdp_drop);
> + priv->xdp_stats.rx_xdp_tx += READ_ONCE(ring->xdp_tx);
> + priv->xdp_stats.rx_xdp_tx_full += READ_ONCE(ring->xdp_tx_full);
> }
> - stats->tx_packets = 0;
> - stats->tx_bytes = 0;
> - stats->tx_dropped = 0;
> priv->port_stats.tx_chksum_offload = 0;
> priv->port_stats.queue_stopped = 0;
> priv->port_stats.wake_queue = 0;
> @@ -205,15 +236,14 @@ int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8 port, u8 reset)
> for (i = 0; i < priv->tx_ring_num[TX]; i++) {
> const struct mlx4_en_tx_ring *ring = priv->tx_ring[TX][i];
>
> - stats->tx_packets += ring->packets;
> - stats->tx_bytes += ring->bytes;
> - stats->tx_dropped += ring->tx_dropped;
> - priv->port_stats.tx_chksum_offload += ring->tx_csum;
> - priv->port_stats.queue_stopped += ring->queue_stopped;
> - priv->port_stats.wake_queue += ring->wake_queue;
> - priv->port_stats.tso_packets += ring->tso_packets;
> - priv->port_stats.xmit_more += ring->xmit_more;
> + sw_tx_dropped += READ_ONCE(ring->tx_dropped);
> + priv->port_stats.tx_chksum_offload += READ_ONCE(ring->tx_csum);
> + priv->port_stats.queue_stopped += READ_ONCE(ring->queue_stopped);
> + priv->port_stats.wake_queue += READ_ONCE(ring->wake_queue);
> + priv->port_stats.tso_packets += READ_ONCE(ring->tso_packets);
> + priv->port_stats.xmit_more += READ_ONCE(ring->xmit_more);
> }
> +
> if (mlx4_is_master(mdev->dev)) {
> stats->rx_packets = en_stats_adder(&mlx4_en_stats->RTOT_prio_0,
> &mlx4_en_stats->RTOT_prio_1,
As you see here in SRIOV mode (PF only) reads sw stats from FW.
Tariq, I think we need to fix this.
> @@ -251,7 +281,8 @@ int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8 port, u8 reset)
> stats->rx_length_errors = be32_to_cpu(mlx4_en_stats->RdropLength);
> stats->rx_crc_errors = be32_to_cpu(mlx4_en_stats->RCRC);
> stats->rx_fifo_errors = be32_to_cpu(mlx4_en_stats->RdropOvflw);
> - stats->tx_dropped += be32_to_cpu(mlx4_en_stats->TDROP);
> + stats->tx_dropped = be32_to_cpu(mlx4_en_stats->TDROP) +
> + sw_tx_dropped;
>
> /* RX stats */
> priv->pkstats.rx_multicast_packets = stats->multicast;
> diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> index 574bcbb1b38fc4758511d8f7bd17a87b0a507a73..20a936428f4a44c8ca0a7161855da310f9166b50 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> @@ -755,6 +755,7 @@ void mlx4_en_rx_irq(struct mlx4_cq *mcq);
> int mlx4_SET_MCAST_FLTR(struct mlx4_dev *dev, u8 port, u64 mac, u64 clear, u8 mode);
> int mlx4_SET_VLAN_FLTR(struct mlx4_dev *dev, struct mlx4_en_priv *priv);
>
> +void mlx4_en_fold_software_stats(struct net_device *dev);
> int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8 port, u8 reset);
> int mlx4_en_QUERY_PORT(struct mlx4_en_dev *mdev, u8 port);
>
>
>
^ permalink raw reply
* Re: [PATCH 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code
From: Bjørn Mork @ 2016-11-26 21:17 UTC (permalink / raw)
To: Daniele Palmas
Cc: Oliver Neukum, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87k2bq7zn8.fsf-3F4PFWf5pNjpjLOzFPqGjWGXanvQGlWp@public.gmane.org>
Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> writes:
> Finally, I found my modems (or at least a number of them) again today.
> But I'm sorry to say, that the troublesome Huawei E3372h-153 is still
> giving us a hard time. It does not work with your patch. The symptom is
> the same as earlier: The modem returns MBIM frames with 32bit headers.
>
> So for now, I have to NAK this patch.
>
> I am sure we can find a good solution that makes all of these modems
> work, but I cannot support a patch that breaks previously working
> configurations. Sorry. I'll do a few experiments and see if there is a
> simple fix for this. Otherwise we'll probably have to do the quirk
> game.
This is a proof-of-concept only, but it appears to be working. Please
test with your device(s) too. It's still mostly your code, as you can
see.
If this turns out to work, then I believe we should refactor
cdc_ncm_init() and cdc_ncm_bind_common() to make the whole
initialisation sequence a bit cleaner. And maybe also include
cdc_mbim_bind(). Ideally, the MBIM specific RESET should happen there
instead of "polluting" the NCM driver with MBIM specific code.
But anyway: The sequence that seems to work for both the E3372h-153
and the EM7455 is
USB_CDC_GET_NTB_PARAMETERS
USB_CDC_RESET_FUNCTION
usb_set_interface(dev->udev, 'data interface no', 0);
remaining parts of cdc_ncm_init(), excluding USB_CDC_GET_NTB_PARAMETERS
usb_set_interface(dev->udev, 'data interface no', 'data alt setting');
without any additional delay between the two usb_set_interface() calls.
So the major difference from your patch is that I moved the two control
requests out of cdc_ncm_init() to allow running them _before_ setting
the data interface to altsetting 0.
But maybe I was just lucky. This was barely proof tested. Needs a lot
more testing and cleanups as suggested. I'd appreciate it if you
continued that, as I don't really have any time for it...
FWIW, I also ran a quick test with a D-Link DWM-156A7 (Mediatek MBIM
firmware) and a Huawei E367 (Qualcomm device with early Huawei MBIM
firmware, distinctly different from the E3372h-153 and most other
MBIM devices I've seen)
Bjørn
---
drivers/net/usb/cdc_ncm.c | 48 ++++++++++++++++++++++++++++----------------
include/uapi/linux/usb/cdc.h | 1 +
2 files changed, 32 insertions(+), 17 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 877c9516e781..be019cbf1719 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -488,16 +488,6 @@ static int cdc_ncm_init(struct usbnet *dev)
u8 iface_no = ctx->control->cur_altsetting->desc.bInterfaceNumber;
int err;
- err = usbnet_read_cmd(dev, USB_CDC_GET_NTB_PARAMETERS,
- USB_TYPE_CLASS | USB_DIR_IN
- |USB_RECIP_INTERFACE,
- 0, iface_no, &ctx->ncm_parm,
- sizeof(ctx->ncm_parm));
- if (err < 0) {
- dev_err(&dev->intf->dev, "failed GET_NTB_PARAMETERS\n");
- return err; /* GET_NTB_PARAMETERS is required */
- }
-
/* set CRC Mode */
if (cdc_ncm_flags(dev) & USB_CDC_NCM_NCAP_CRC_MODE) {
dev_dbg(&dev->intf->dev, "Setting CRC mode off\n");
@@ -837,12 +827,43 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_
}
}
+ iface_no = ctx->control->cur_altsetting->desc.bInterfaceNumber;
+ temp = usbnet_read_cmd(dev, USB_CDC_GET_NTB_PARAMETERS,
+ USB_TYPE_CLASS | USB_DIR_IN
+ | USB_RECIP_INTERFACE,
+ 0, iface_no, &ctx->ncm_parm,
+ sizeof(ctx->ncm_parm));
+ if (temp < 0) {
+ dev_err(&dev->intf->dev, "failed GET_NTB_PARAMETERS\n");
+ goto error; /* GET_NTB_PARAMETERS is required */
+ }
+
+ /* Some modems (e.g. Telit LE922A6) need to reset the MBIM function
+ * or they will fail to work properly.
+ * For details on RESET_FUNCTION request see document
+ * "USB Communication Class Subclass Specification for MBIM"
+ * RESET_FUNCTION should be harmless for all the other MBIM modems
+ */
+ if (cdc_ncm_comm_intf_is_mbim(ctx->control->cur_altsetting)) {
+ temp = usbnet_write_cmd(dev, USB_CDC_RESET_FUNCTION,
+ USB_TYPE_CLASS | USB_DIR_OUT
+ | USB_RECIP_INTERFACE,
+ 0, iface_no, NULL, 0);
+ if (temp < 0)
+ dev_err(&dev->intf->dev, "failed RESET_FUNCTION\n");
+ }
+
iface_no = ctx->data->cur_altsetting->desc.bInterfaceNumber;
/* Reset data interface. Some devices will not reset properly
* unless they are configured first. Toggle the altsetting to
* force a reset
+ * This is applied only to ncm devices, since it has been verified
+ * to cause issues with some MBIM modems (e.g. Telit LE922A6).
+ * MBIM devices reset is achieved using MBIM request RESET_FUNCTION
+ * in cdc_ncm_init
*/
+
usb_set_interface(dev->udev, iface_no, data_altsetting);
temp = usb_set_interface(dev->udev, iface_no, 0);
if (temp) {
@@ -854,13 +875,6 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_
if (cdc_ncm_init(dev))
goto error2;
- /* Some firmwares need a pause here or they will silently fail
- * to set up the interface properly. This value was decided
- * empirically on a Sierra Wireless MC7455 running 02.08.02.00
- * firmware.
- */
- usleep_range(10000, 20000);
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2016-11-26 21:04 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix leak in fsl/fman driver, from Dan Carpenter.
2) Call flow dissector initcall earlier than any networking driver can
register and start to use it, from Eric Dumazet.
3) Some dup header fixes from Geliang Tang.
4) TIPC link monitoring compat fix from Jon Paul Maloy.
5) Link changes require EEE re-negotiation in bcm_sf2 driver, from
Florian Fainelli.
6) Fix bogus handle ID passed into tfilter_notify_chain(), from
Roman Mashak.
7) Fix dump size calculation in rtnl_calcit(), from Zhang Shengju.
Please pull, thanks a lot!
The following changes since commit 3b404a519815b9820f73f1ecf404e5546c9270ba:
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security (2016-11-21 15:27:41 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 6998cc6ec23740347670da13186d2979c5401903:
tipc: resolve connection flow control compatibility problem (2016-11-25 21:38:16 -0500)
----------------------------------------------------------------
Andrew Lunn (1):
net: ethernet: mvneta: Remove IFF_UNICAST_FLT which is not implemented
Andy Gospodarek (1):
bnxt: do not busy-poll when link is down
Arnd Bergmann (1):
mvpp2: use correct size for memset
Christophe Jaillet (1):
bnxt_en: Fix a VXLAN vs GENEVE issue
Dan Carpenter (1):
fsl/fman: fix a leak in tgec_free()
David S. Miller (2):
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth
Merge tag 'linux-can-fixes-for-4.9-20161123' of git://git.kernel.org/.../mkl/linux-can
Eric Dumazet (2):
flow_dissect: call init_default_flow_dissectors() earlier
udplite: call proper backlog handlers
Florian Fainelli (1):
net: dsa: bcm_sf2: Ensure we re-negotiate EEE during after link change
Gao Feng (1):
driver: macvlan: Check if need rollback multicast setting in macvlan_open
Geliang Tang (4):
dwc_eth_qos: drop duplicate headers
ibmvnic: drop duplicate header seq_file.h
net: ieee802154: drop duplicate header delay.h
net/mlx5: drop duplicate header delay.h
Johan Hedberg (1):
Bluetooth: Fix using the correct source address type
Jon Paul Maloy (3):
tipc: fix compatibility bug in link monitoring
tipc: improve sanity check for received domain records
tipc: resolve connection flow control compatibility problem
Kirill Esipov (1):
net: phy: micrel: fix KSZ8041FTL supported value
Miroslav Lichvar (1):
net: ethtool: don't require CAP_NET_ADMIN for ETHTOOL_GLINKSETTINGS
Oliver Hartkopp (1):
can: bcm: fix support for CAN FD frames
Paolo Abeni (1):
ipv6: bump genid when the IFA_F_TENTATIVE flag is clear
Randy Dunlap (1):
netdevice.h: fix kernel-doc warning
Roman Mashak (1):
net sched filters: fix filter handle ID in tfilter_notify_chain()
Tariq Toukan (1):
net/mlx4_en: Free netdev resources under state lock
WANG Cong (1):
net: revert "net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit"
Zhang Shengju (1):
rtnetlink: fix the wrong minimal dump size getting from rtnl_calcit()
drivers/net/dsa/bcm_sf2.c | 4 ++++
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 15 ++++++++++++---
drivers/net/ethernet/freescale/fman/fman_tgec.c | 3 ---
drivers/net/ethernet/ibm/ibmvnic.c | 1 -
drivers/net/ethernet/marvell/mvneta.c | 2 +-
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 ++++-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 1 -
drivers/net/ethernet/synopsys/dwc_eth_qos.c | 2 --
drivers/net/ieee802154/adf7242.c | 1 -
drivers/net/macvlan.c | 3 ++-
drivers/net/phy/micrel.c | 8 ++++----
include/linux/netdevice.h | 2 +-
include/net/bluetooth/hci_core.h | 2 +-
net/bluetooth/6lowpan.c | 4 ++--
net/bluetooth/hci_conn.c | 26 ++++++++++++++++++++++++--
net/bluetooth/l2cap_core.c | 2 +-
net/bluetooth/rfcomm/tty.c | 2 +-
net/bluetooth/sco.c | 2 +-
net/can/bcm.c | 18 ++++++++++--------
net/core/ethtool.c | 1 +
net/core/flow_dissector.c | 2 +-
net/core/rtnetlink.c | 2 +-
net/ipv4/udp.c | 2 +-
net/ipv4/udp_impl.h | 2 +-
net/ipv4/udplite.c | 2 +-
net/ipv6/addrconf.c | 18 ++++++++++++------
net/ipv6/udp.c | 2 +-
net/ipv6/udp_impl.h | 2 +-
net/ipv6/udplite.c | 2 +-
net/l2tp/l2tp_eth.c | 2 +-
net/sched/cls_api.c | 2 +-
net/tipc/link.c | 5 +++--
net/tipc/monitor.c | 10 +++++-----
net/tipc/socket.c | 2 +-
35 files changed, 101 insertions(+), 60 deletions(-)
^ permalink raw reply
* [PATCH] amd-xgbe: Fix unused suspend handlers build warning
From: Borislav Petkov @ 2016-11-26 20:53 UTC (permalink / raw)
To: LKML; +Cc: Tom Lendacky, netdev
From: Borislav Petkov <bp@suse.de>
Fix:
drivers/net/ethernet/amd/xgbe/xgbe-main.c:835:12: warning: ‘xgbe_suspend’ defined
but not used [-Wunused-function]
drivers/net/ethernet/amd/xgbe/xgbe-main.c:855:12: warning: ‘xgbe_resume’ defined
but not used [-Wunused-function]
I see it during randconfig builds here.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
index e10e569c0d5f..2e8451b0a74a 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
@@ -831,7 +831,7 @@ static int xgbe_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int xgbe_suspend(struct device *dev)
{
struct net_device *netdev = dev_get_drvdata(dev);
@@ -876,7 +876,7 @@ static int xgbe_resume(struct device *dev)
return ret;
}
-#endif /* CONFIG_PM */
+#endif /* CONFIG_PM_SLEEP */
#ifdef CONFIG_ACPI
static const struct acpi_device_id xgbe_acpi_match[] = {
--
2.10.0
^ permalink raw reply related
* Re: net: GPF in eth_header
From: Eric Dumazet @ 2016-11-26 20:34 UTC (permalink / raw)
To: Andrey Konovalov
Cc: syzkaller, Dmitry Vyukov, David Miller, Tom Herbert,
Alexander Duyck, Hannes Frederic Sowa, Jiri Benc, Sabrina Dubroca,
netdev, LKML
In-Reply-To: <CACPEyM-4dwvmEvq3uTN_8Y-YosP8qA3cYV+oxkufFOn8M+=hew@mail.gmail.com>
2016-11-26 12:05 GMT-08:00 Eric Dumazet <erdlkml@gmail.com>:
>> Hi Eric,
>>
>> The crash happens when the kernel tries to access shadow for nonmapped memory.
>>
>> The issue here is an integer overflow which happens in neigh_resolve_output().
>> skb_network_offset(skb) can return negative number, but __skb_pull()
>> accepts unsigned int as len.
>> As a result, the least significat bit in higher 32 bits of skb->data
>> gets set and we get an out-of-bounds with offset of 4 GB.
>>
>> I've attached a short reproducer, but you either need KASAN or to add
>> a BUG_ON to see the crash.
>> In this reproducer skb_network_offset() becomes negative after merging
>> two ipv6 fragments.
>>
>> I actually see multiple places where skb_network_offset() is used as
>> an argument to skb_pull().
>> So I guess every place can potentially be buggy.
>
> Well, I think the intent is to accept a negative number.
>
> This definitely was assumed by commit e1f165032c8bade authors !
>
> I guess they were using a 32bit kernel for their tests.
Correct fix would be to use
skb_push(skb, -skb_network_offset(skb));
As done in other locations...
^ permalink raw reply
* Re: [PATCH 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code
From: Bjørn Mork @ 2016-11-26 20:30 UTC (permalink / raw)
To: Daniele Palmas; +Cc: Oliver Neukum, linux-usb, netdev
In-Reply-To: <1479904606-30647-2-git-send-email-dnlplm@gmail.com>
Finally, I found my modems (or at least a number of them) again today.
But I'm sorry to say, that the troublesome Huawei E3372h-153 is still
giving us a hard time. It does not work with your patch. The symptom is
the same as earlier: The modem returns MBIM frames with 32bit headers.
So for now, I have to NAK this patch.
I am sure we can find a good solution that makes all of these modems
work, but I cannot support a patch that breaks previously working
configurations. Sorry. I'll do a few experiments and see if there is a
simple fix for this. Otherwise we'll probably have to do the quirk
game.
Bjørn
^ permalink raw reply
* [PATCH net-next 6/6] tcp: SOF_TIMESTAMPING_OPT_STATS option for SO_TIMESTAMPING
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch exports the sender chronograph stats via the socket
SO_TIMESTAMPING channel. Currently we can instrument how long a
particular application unit of data was queued in TCP by tracking
SOF_TIMESTAMPING_TX_SOFTWARE and SOF_TIMESTAMPING_TX_SCHED. Having
these sender chronograph stats exported simultaneously along with
these timestamps allow further breaking down the various sender
limitation. For example, a video server can tell if a particular
chunk of video on a connection takes a long time to deliver because
TCP was experiencing small receive window. It is not possible to
tell before this patch without packet traces.
To prepare these stats, the user needs to set
SOF_TIMESTAMPING_OPT_STATS and SOF_TIMESTAMPING_OPT_TSONLY flags
while requesting other SOF_TIMESTAMPING TX timestamps. When the
timestamps are available in the error queue, the stats are returned
in a separate control message of type SCM_TIMESTAMPING_OPT_STATS,
in a list of TLVs (struct nlattr) of types: TCP_NLA_BUSY_TIME,
TCP_NLA_RWND_LIMITED, TCP_NLA_SNDBUF_LIMITED. Unit is microsecond.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
Documentation/networking/timestamping.txt | 10 ++++++++++
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
include/linux/tcp.h | 2 ++
include/uapi/asm-generic/socket.h | 2 ++
include/uapi/linux/net_tstamp.h | 3 ++-
include/uapi/linux/tcp.h | 8 ++++++++
net/core/skbuff.c | 12 +++++++++---
net/core/sock.c | 7 +++++++
net/ipv4/tcp.c | 20 ++++++++++++++++++++
net/socket.c | 7 ++++++-
20 files changed, 88 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index 671cccf..96f5069 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -182,6 +182,16 @@ SOF_TIMESTAMPING_OPT_TSONLY:
the timestamp even if sysctl net.core.tstamp_allow_data is 0.
This option disables SOF_TIMESTAMPING_OPT_CMSG.
+SOF_TIMESTAMPING_OPT_STATS:
+
+ Optional stats that are obtained along with the transmit timestamps.
+ It must be used together with SOF_TIMESTAMPING_OPT_TSONLY. When the
+ transmit timestamp is available, the stats are available in a
+ separate control message of type SCM_TIMESTAMPING_OPT_STATS, as a
+ list of TLVs (struct nlattr) of types. These stats allow the
+ application to associate various transport layer stats with
+ the transmit timestamps, such as how long a certain block of
+ data was limited by peer's receiver window.
New applications are encouraged to pass SOF_TIMESTAMPING_OPT_ID to
disambiguate timestamps and SOF_TIMESTAMPING_OPT_TSONLY to operate
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 9e46d6e..afc901b 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index afbc98f0..81e0353 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -90,5 +90,7 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index 0018fad..57feb0c 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -99,4 +99,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index 5fe42fc..5853f8e9 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -90,4 +90,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 2027240a..566ecdc 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -108,4 +108,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index 5129f23..0e12527 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -90,4 +90,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index 9c935d7..7a109b7 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -89,4 +89,6 @@
#define SO_CNX_ADVICE 0x402E
+#define SCM_TIMESTAMPING_OPT_STATS 0x402F
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index 1672e33..44583a5 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index 41b51c2..b24a64c 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -96,4 +96,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 31aede3..a25dc32 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -86,6 +86,8 @@
#define SO_CNX_ADVICE 0x0037
+#define SCM_TIMESTAMPING_OPT_STATS 0x0038
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 81435d9..9fdbe1f 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -101,4 +101,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* _XTENSA_SOCKET_H */
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index d5d3bd8..00e0ee8 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -428,4 +428,6 @@ static inline void tcp_saved_syn_free(struct tcp_sock *tp)
tp->saved_syn = NULL;
}
+struct sk_buff *tcp_get_timestamping_opt_stats(const struct sock *sk);
+
#endif /* _LINUX_TCP_H */
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index 67d632f..2c748dd 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -92,4 +92,6 @@
#define SO_CNX_ADVICE 53
+#define SCM_TIMESTAMPING_OPT_STATS 54
+
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index 264e515..464dcca 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -25,8 +25,9 @@ enum {
SOF_TIMESTAMPING_TX_ACK = (1<<9),
SOF_TIMESTAMPING_OPT_CMSG = (1<<10),
SOF_TIMESTAMPING_OPT_TSONLY = (1<<11),
+ SOF_TIMESTAMPING_OPT_STATS = (1<<12),
- SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_TSONLY,
+ SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_STATS,
SOF_TIMESTAMPING_MASK = (SOF_TIMESTAMPING_LAST - 1) |
SOF_TIMESTAMPING_LAST
};
diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
index 2863b66..c53de26 100644
--- a/include/uapi/linux/tcp.h
+++ b/include/uapi/linux/tcp.h
@@ -220,6 +220,14 @@ struct tcp_info {
__u64 tcpi_sndbuf_limited; /* Time (usec) limited by send buffer */
};
+/* netlink attributes types for SCM_TIMESTAMPING_OPT_STATS */
+enum {
+ TCP_NLA_PAD,
+ TCP_NLA_BUSY, /* Time (usec) busy sending data */
+ TCP_NLA_RWND_LIMITED, /* Time (usec) limited by receive window */
+ TCP_NLA_SNDBUF_LIMITED, /* Time (usec) limited by send buffer */
+};
+
/* for TCP_MD5SIG socket option */
#define TCP_MD5SIG_MAXKEYLEN 80
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d1d1a5a..b7986c9 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3839,10 +3839,16 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb,
if (!skb_may_tx_timestamp(sk, tsonly))
return;
- if (tsonly)
- skb = alloc_skb(0, GFP_ATOMIC);
- else
+ if (tsonly) {
+ if ((sk->sk_tsflags & SOF_TIMESTAMPING_OPT_STATS) &&
+ sk->sk_protocol == IPPROTO_TCP &&
+ sk->sk_type == SOCK_STREAM)
+ skb = tcp_get_timestamping_opt_stats(sk);
+ else
+ skb = alloc_skb(0, GFP_ATOMIC);
+ } else {
skb = skb_clone(orig_skb, GFP_ATOMIC);
+ }
if (!skb)
return;
diff --git a/net/core/sock.c b/net/core/sock.c
index 14e6145..d8c7f8c 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -854,6 +854,13 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
sk->sk_tskey = 0;
}
}
+
+ if (val & SOF_TIMESTAMPING_OPT_STATS &&
+ !(val & SOF_TIMESTAMPING_OPT_TSONLY)) {
+ ret = -EINVAL;
+ break;
+ }
+
sk->sk_tsflags = val;
if (val & SOF_TIMESTAMPING_RX_SOFTWARE)
sock_enable_timestamp(sk,
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index cdde20f..1149b48 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2841,6 +2841,26 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
}
EXPORT_SYMBOL_GPL(tcp_get_info);
+struct sk_buff *tcp_get_timestamping_opt_stats(const struct sock *sk)
+{
+ const struct tcp_sock *tp = tcp_sk(sk);
+ struct sk_buff *stats;
+ struct tcp_info info;
+
+ stats = alloc_skb(3 * nla_total_size_64bit(sizeof(u64)), GFP_ATOMIC);
+ if (!stats)
+ return NULL;
+
+ tcp_get_info_chrono_stats(tp, &info);
+ nla_put_u64_64bit(stats, TCP_NLA_BUSY,
+ info.tcpi_busy_time, TCP_NLA_PAD);
+ nla_put_u64_64bit(stats, TCP_NLA_RWND_LIMITED,
+ info.tcpi_rwnd_limited, TCP_NLA_PAD);
+ nla_put_u64_64bit(stats, TCP_NLA_SNDBUF_LIMITED,
+ info.tcpi_sndbuf_limited, TCP_NLA_PAD);
+ return stats;
+}
+
static int do_tcp_getsockopt(struct sock *sk, int level,
int optname, char __user *optval, int __user *optlen)
{
diff --git a/net/socket.c b/net/socket.c
index e2584c5..e631894 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -693,9 +693,14 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
(sk->sk_tsflags & SOF_TIMESTAMPING_RAW_HARDWARE) &&
ktime_to_timespec_cond(shhwtstamps->hwtstamp, tss.ts + 2))
empty = 0;
- if (!empty)
+ if (!empty) {
put_cmsg(msg, SOL_SOCKET,
SCM_TIMESTAMPING, sizeof(tss), &tss);
+
+ if (skb->len && (sk->sk_tsflags & SOF_TIMESTAMPING_OPT_STATS))
+ put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_OPT_STATS,
+ skb->len, skb->data);
+ }
}
EXPORT_SYMBOL_GPL(__sock_recv_timestamp);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 4/6] tcp: instrument how long TCP is limited by insufficient send buffer
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch measures the amount of time when TCP runs out of new data
to send to the network due to insufficient send buffer, while TCP
is still busy delivering (i.e. write queue is not empty). The goal
is to indicate either the send buffer autotuning or user SO_SNDBUF
setting has resulted network under-utilization.
The measurement starts conservatively by checking various conditions
to minimize false claims (i.e. under-estimation is more likely).
The measurement stops when the SOCK_NOSPACE flag is cleared. But it
does not account the time elapsed till the next application write.
Also the measurement only starts if the sender is still busy sending
data, s.t. the limit accounted is part of the total busy time.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp.c | 10 ++++++++--
net/ipv4/tcp_input.c | 5 ++++-
net/ipv4/tcp_output.c | 12 ++++++++++++
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 913f9bb..259ffb5 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -996,8 +996,11 @@ static ssize_t do_tcp_sendpages(struct sock *sk, struct page *page, int offset,
goto out;
out_err:
/* make sure we wake any epoll edge trigger waiter */
- if (unlikely(skb_queue_len(&sk->sk_write_queue) == 0 && err == -EAGAIN))
+ if (unlikely(skb_queue_len(&sk->sk_write_queue) == 0 &&
+ err == -EAGAIN)) {
sk->sk_write_space(sk);
+ tcp_chrono_stop(sk, TCP_CHRONO_SNDBUF_LIMITED);
+ }
return sk_stream_error(sk, flags, err);
}
@@ -1331,8 +1334,11 @@ int tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
out_err:
err = sk_stream_error(sk, flags, err);
/* make sure we wake any epoll edge trigger waiter */
- if (unlikely(skb_queue_len(&sk->sk_write_queue) == 0 && err == -EAGAIN))
+ if (unlikely(skb_queue_len(&sk->sk_write_queue) == 0 &&
+ err == -EAGAIN)) {
sk->sk_write_space(sk);
+ tcp_chrono_stop(sk, TCP_CHRONO_SNDBUF_LIMITED);
+ }
release_sock(sk);
return err;
}
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index a5d1727..56fe736 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5059,8 +5059,11 @@ static void tcp_check_space(struct sock *sk)
/* pairs with tcp_poll() */
smp_mb__after_atomic();
if (sk->sk_socket &&
- test_bit(SOCK_NOSPACE, &sk->sk_socket->flags))
+ test_bit(SOCK_NOSPACE, &sk->sk_socket->flags)) {
tcp_new_space(sk);
+ if (!test_bit(SOCK_NOSPACE, &sk->sk_socket->flags))
+ tcp_chrono_stop(sk, TCP_CHRONO_SNDBUF_LIMITED);
+ }
}
}
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index b74444c..d3545d0 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1514,6 +1514,18 @@ static void tcp_cwnd_validate(struct sock *sk, bool is_cwnd_limited)
if (sysctl_tcp_slow_start_after_idle &&
(s32)(tcp_time_stamp - tp->snd_cwnd_stamp) >= inet_csk(sk)->icsk_rto)
tcp_cwnd_application_limited(sk);
+
+ /* The following conditions together indicate the starvation
+ * is caused by insufficient sender buffer:
+ * 1) just sent some data (see tcp_write_xmit)
+ * 2) not cwnd limited (this else condition)
+ * 3) no more data to send (null tcp_send_head )
+ * 4) application is hitting buffer limit (SOCK_NOSPACE)
+ */
+ if (!tcp_send_head(sk) && sk->sk_socket &&
+ test_bit(SOCK_NOSPACE, &sk->sk_socket->flags) &&
+ (1 << sk->sk_state) & (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT))
+ tcp_chrono_start(sk, TCP_CHRONO_SNDBUF_LIMITED);
}
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 5/6] tcp: export sender limits chronographs to TCP_INFO
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch exports all the sender chronograph measurements collected
in the previous patches to TCP_INFO interface. Note that busy time
exported includes all the other sending limits (rwnd-limited,
sndbuf-limited). Internally the time unit is jiffy but externally
the measurements are in microseconds for future extensions.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
include/uapi/linux/tcp.h | 4 ++++
net/ipv4/tcp.c | 20 ++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
index 73ac0db..2863b66 100644
--- a/include/uapi/linux/tcp.h
+++ b/include/uapi/linux/tcp.h
@@ -214,6 +214,10 @@ struct tcp_info {
__u32 tcpi_data_segs_out; /* RFC4898 tcpEStatsDataSegsOut */
__u64 tcpi_delivery_rate;
+
+ __u64 tcpi_busy_time; /* Time (usec) busy sending data */
+ __u64 tcpi_rwnd_limited; /* Time (usec) limited by receive window */
+ __u64 tcpi_sndbuf_limited; /* Time (usec) limited by send buffer */
};
/* for TCP_MD5SIG socket option */
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 259ffb5..cdde20f 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2708,6 +2708,25 @@ int compat_tcp_setsockopt(struct sock *sk, int level, int optname,
EXPORT_SYMBOL(compat_tcp_setsockopt);
#endif
+static void tcp_get_info_chrono_stats(const struct tcp_sock *tp,
+ struct tcp_info *info)
+{
+ u64 stats[__TCP_CHRONO_MAX], total = 0;
+ enum tcp_chrono i;
+
+ for (i = TCP_CHRONO_BUSY; i < __TCP_CHRONO_MAX; ++i) {
+ stats[i] = tp->chrono_stat[i - 1];
+ if (i == tp->chrono_type)
+ stats[i] += tcp_time_stamp - tp->chrono_start;
+ stats[i] *= USEC_PER_SEC / HZ;
+ total += stats[i];
+ }
+
+ info->tcpi_busy_time = total;
+ info->tcpi_rwnd_limited = stats[TCP_CHRONO_RWND_LIMITED];
+ info->tcpi_sndbuf_limited = stats[TCP_CHRONO_SNDBUF_LIMITED];
+}
+
/* Return information about state of tcp endpoint in API format. */
void tcp_get_info(struct sock *sk, struct tcp_info *info)
{
@@ -2800,6 +2819,7 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
info->tcpi_bytes_acked = tp->bytes_acked;
info->tcpi_bytes_received = tp->bytes_received;
info->tcpi_notsent_bytes = max_t(int, 0, tp->write_seq - tp->snd_nxt);
+ tcp_get_info_chrono_stats(tp, info);
unlock_sock_fast(sk, slow);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 2/6] tcp: instrument how long TCP is busy sending
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch measures TCP busy time, which is defined as the period
of time when sender has data (or FIN) to send. The time starts when
data is buffered and stops when the write queue is flushed by ACKs
or error events.
Note the busy time does not include SYN time, unless data is
included in SYN (i.e. Fast Open). It does include FIN time even
if the FIN carries no payload. Excluding pure FIN is possible but
would incur one additional test in the fast path, which may not
be worth it.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
include/net/tcp.h | 6 +++++-
net/ipv4/tcp_input.c | 3 +++
net/ipv4/tcp_output.c | 19 ++++++++++++++++---
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index e5ff408..3e097e3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1535,6 +1535,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
{
struct sk_buff *skb;
+ tcp_chrono_stop(sk, TCP_CHRONO_BUSY);
while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
sk_wmem_free_skb(sk, skb);
sk_mem_reclaim(sk);
@@ -1593,8 +1594,10 @@ static inline void tcp_advance_send_head(struct sock *sk, const struct sk_buff *
static inline void tcp_check_send_head(struct sock *sk, struct sk_buff *skb_unlinked)
{
- if (sk->sk_send_head == skb_unlinked)
+ if (sk->sk_send_head == skb_unlinked) {
sk->sk_send_head = NULL;
+ tcp_chrono_stop(sk, TCP_CHRONO_BUSY);
+ }
if (tcp_sk(sk)->highest_sack == skb_unlinked)
tcp_sk(sk)->highest_sack = NULL;
}
@@ -1616,6 +1619,7 @@ static inline void tcp_add_write_queue_tail(struct sock *sk, struct sk_buff *skb
/* Queue it, remembering where we must start sending. */
if (sk->sk_send_head == NULL) {
sk->sk_send_head = skb;
+ tcp_chrono_start(sk, TCP_CHRONO_BUSY);
if (tcp_sk(sk)->highest_sack == NULL)
tcp_sk(sk)->highest_sack = skb;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 22e6a20..a5d1727 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3178,6 +3178,9 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
tp->lost_skb_hint = NULL;
}
+ if (!skb)
+ tcp_chrono_stop(sk, TCP_CHRONO_BUSY);
+
if (likely(between(tp->snd_up, prior_snd_una, tp->snd_una)))
tp->snd_up = tp->snd_una;
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 34f7517..e8ea584 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2096,8 +2096,8 @@ void tcp_chrono_start(struct sock *sk, const enum tcp_chrono type)
struct tcp_sock *tp = tcp_sk(sk);
/* If there are multiple conditions worthy of tracking in a
- * chronograph then the highest priority enum takes precedence over
- * the other conditions. So that if something "more interesting"
+ * chronograph then the highest priority enum takes precedence
+ * over the other conditions. So that if something "more interesting"
* starts happening, stop the previous chrono and start a new one.
*/
if (type > tp->chrono_type)
@@ -2108,7 +2108,18 @@ void tcp_chrono_stop(struct sock *sk, const enum tcp_chrono type)
{
struct tcp_sock *tp = tcp_sk(sk);
- tcp_chrono_set(tp, TCP_CHRONO_UNSPEC);
+
+ /* There are multiple conditions worthy of tracking in a
+ * chronograph, so that the highest priority enum takes
+ * precedence over the other conditions (see tcp_chrono_start).
+ * If a condition stops, we only stop chrono tracking if
+ * it's the "most interesting" or current chrono we are
+ * tracking and starts busy chrono if we have pending data.
+ */
+ if (tcp_write_queue_empty(sk))
+ tcp_chrono_set(tp, TCP_CHRONO_UNSPEC);
+ else if (type == tp->chrono_type)
+ tcp_chrono_set(tp, TCP_CHRONO_BUSY);
}
/* This routine writes packets to the network. It advances the
@@ -3328,6 +3339,8 @@ static int tcp_send_syn_data(struct sock *sk, struct sk_buff *syn)
fo->copied = space;
tcp_connect_queue_skb(sk, syn_data);
+ if (syn_data->len)
+ tcp_chrono_start(sk, TCP_CHRONO_BUSY);
err = tcp_transmit_skb(sk, syn_data, 1, sk->sk_allocation);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 3/6] tcp: instrument how long TCP is limited by receive window
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch measures the total time when the TCP stops sending because
the receiver's advertised window is not large enough. Note that
once the limit is lifted we are likely in the busy status if we
have data pending.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index e8ea584..b74444c 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2144,7 +2144,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
unsigned int tso_segs, sent_pkts;
int cwnd_quota;
int result;
- bool is_cwnd_limited = false;
+ bool is_cwnd_limited = false, is_rwnd_limited = false;
u32 max_segs;
sent_pkts = 0;
@@ -2181,8 +2181,10 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
break;
}
- if (unlikely(!tcp_snd_wnd_test(tp, skb, mss_now)))
+ if (unlikely(!tcp_snd_wnd_test(tp, skb, mss_now))) {
+ is_rwnd_limited = true;
break;
+ }
if (tso_segs == 1) {
if (unlikely(!tcp_nagle_test(tp, skb, mss_now,
@@ -2227,6 +2229,11 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
break;
}
+ if (is_rwnd_limited)
+ tcp_chrono_start(sk, TCP_CHRONO_RWND_LIMITED);
+ else
+ tcp_chrono_stop(sk, TCP_CHRONO_RWND_LIMITED);
+
if (likely(sent_pkts)) {
if (tcp_in_cwnd_reduction(sk))
tp->prr_out += sent_pkts;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 1/6] tcp: instrument tcp sender limits chronographs
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
In-Reply-To: <1480191016-73210-1-git-send-email-ycheng@google.com>
From: Francis Yan <francisyyan@gmail.com>
This patch implements the skeleton of the TCP chronograph
instrumentation on sender side limits:
1) idle (unspec)
2) busy sending data other than 3-4 below
3) rwnd-limited
4) sndbuf-limited
The limits are enumerated 'tcp_chrono'. Since a connection in
theory can idle forever, we do not track the actual length of this
uninteresting idle period. For the rest we track how long the sender
spends in each limit. At any point during the life time of a
connection, the sender must be in one of the four states.
If there are multiple conditions worthy of tracking in a chronograph
then the highest priority enum takes precedence over
the other conditions. So that if something "more interesting"
starts happening, stop the previous chrono and start a new one.
The time unit is jiffy(u32) in order to save space in tcp_sock.
This implies application must sample the stats no longer than every
49 days of 1ms jiffy.
Signed-off-by: Francis Yan <francisyyan@gmail.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
include/linux/tcp.h | 7 +++++--
include/net/tcp.h | 14 ++++++++++++++
net/ipv4/tcp_output.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 32a7c7e..d5d3bd8 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -211,8 +211,11 @@ struct tcp_sock {
u8 reord; /* reordering detected */
} rack;
u16 advmss; /* Advertised MSS */
- u8 rate_app_limited:1, /* rate_{delivered,interval_us} limited? */
- unused:7;
+ u32 chrono_start; /* Start time in jiffies of a TCP chrono */
+ u32 chrono_stat[3]; /* Time in jiffies for chrono_stat stats */
+ u8 chrono_type:2, /* current chronograph type */
+ rate_app_limited:1, /* rate_{delivered,interval_us} limited? */
+ unused:5;
u8 nonagle : 4,/* Disable Nagle algorithm? */
thin_lto : 1,/* Use linear timeouts for thin streams */
thin_dupack : 1,/* Fast retransmit on first dupack */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 7de8073..e5ff408 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1516,6 +1516,20 @@ struct tcp_fastopen_context {
struct rcu_head rcu;
};
+/* Latencies incurred by various limits for a sender. They are
+ * chronograph-like stats that are mutually exclusive.
+ */
+enum tcp_chrono {
+ TCP_CHRONO_UNSPEC,
+ TCP_CHRONO_BUSY, /* Actively sending data (non-empty write queue) */
+ TCP_CHRONO_RWND_LIMITED, /* Stalled by insufficient receive window */
+ TCP_CHRONO_SNDBUF_LIMITED, /* Stalled by insufficient send buffer */
+ __TCP_CHRONO_MAX,
+};
+
+void tcp_chrono_start(struct sock *sk, const enum tcp_chrono type);
+void tcp_chrono_stop(struct sock *sk, const enum tcp_chrono type);
+
/* write queue abstraction */
static inline void tcp_write_queue_purge(struct sock *sk)
{
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 19105b4..34f7517 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2081,6 +2081,36 @@ static bool tcp_small_queue_check(struct sock *sk, const struct sk_buff *skb,
return false;
}
+static void tcp_chrono_set(struct tcp_sock *tp, const enum tcp_chrono new)
+{
+ const u32 now = tcp_time_stamp;
+
+ if (tp->chrono_type > TCP_CHRONO_UNSPEC)
+ tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;
+ tp->chrono_start = now;
+ tp->chrono_type = new;
+}
+
+void tcp_chrono_start(struct sock *sk, const enum tcp_chrono type)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ /* If there are multiple conditions worthy of tracking in a
+ * chronograph then the highest priority enum takes precedence over
+ * the other conditions. So that if something "more interesting"
+ * starts happening, stop the previous chrono and start a new one.
+ */
+ if (type > tp->chrono_type)
+ tcp_chrono_set(tp, type);
+}
+
+void tcp_chrono_stop(struct sock *sk, const enum tcp_chrono type)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ tcp_chrono_set(tp, TCP_CHRONO_UNSPEC);
+}
+
/* This routine writes packets to the network. It advances the
* send_head. This happens as incoming acks open up the remote
* window for us.
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 0/6] tcp: sender chronographs instrumentation
From: Yuchung Cheng @ 2016-11-26 20:10 UTC (permalink / raw)
To: davem, soheil, francisyyan; +Cc: netdev, ncardwell, edumazet, Yuchung Cheng
This patch set provides instrumentation on TCP sender limitations.
While developing the BBR congestion control, we noticed that TCP
sending process is often limited by factors unrelated to congestion
control: insufficient sender buffer and/or insufficient receive
window/buffer to saturate the network bandwidth. Unfortunately these
limits are not visible to the users and often the poor performance
is attributed to the congestion control of choice.
Thie patch aims to help users get the high level understanding of
where sending process is limited by, similar to the TCP_INFO design.
It is not to replace detailed kernel tracing and instrumentation
facilities.
In addition this patch set provides a new option to the timestamping
work to instrument these limits on application data unit. For exampe,
one can use SO_TIMESTAMPING and this patch set to measure the how
long a particular HTTP response is limited by small receive window.
Patch set was initially written by Francis Yan then polished
by Yuchung Cheng, with lots of help from Eric Dumazet and Soheil
Hassas Yeganeh.
Francis Yan (6):
tcp: instrument tcp sender limits chronographs
tcp: instrument how long TCP is busy sending
tcp: instrument how long TCP is limited by receive window
tcp: instrument how long TCP is limited by insufficient send buffer
tcp: export sender limits chronographs to TCP_INFO
tcp: SOF_TIMESTAMPING_OPT_STATS option for SO_TIMESTAMPING
Documentation/networking/timestamping.txt | 10 +++++
arch/alpha/include/uapi/asm/socket.h | 2 +
arch/frv/include/uapi/asm/socket.h | 2 +
arch/ia64/include/uapi/asm/socket.h | 2 +
arch/m32r/include/uapi/asm/socket.h | 2 +
arch/mips/include/uapi/asm/socket.h | 2 +
arch/mn10300/include/uapi/asm/socket.h | 2 +
arch/parisc/include/uapi/asm/socket.h | 2 +
arch/powerpc/include/uapi/asm/socket.h | 2 +
arch/s390/include/uapi/asm/socket.h | 2 +
arch/sparc/include/uapi/asm/socket.h | 2 +
arch/xtensa/include/uapi/asm/socket.h | 2 +
include/linux/tcp.h | 9 ++++-
include/net/tcp.h | 20 +++++++++-
include/uapi/asm-generic/socket.h | 2 +
include/uapi/linux/net_tstamp.h | 3 +-
include/uapi/linux/tcp.h | 12 ++++++
net/core/skbuff.c | 12 ++++--
net/core/sock.c | 7 ++++
net/ipv4/tcp.c | 50 ++++++++++++++++++++++-
net/ipv4/tcp_input.c | 8 +++-
net/ipv4/tcp_output.c | 66 ++++++++++++++++++++++++++++++-
net/socket.c | 7 +++-
23 files changed, 215 insertions(+), 13 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* Re: net: GPF in eth_header
From: Eric Dumazet @ 2016-11-26 20:05 UTC (permalink / raw)
To: Andrey Konovalov
Cc: syzkaller, Dmitry Vyukov, David Miller, Tom Herbert,
Alexander Duyck, Hannes Frederic Sowa, Jiri Benc, Sabrina Dubroca,
netdev, LKML
In-Reply-To: <CAAeHK+x48aKLcKfN2aYA1pBPr4Y4ESUvjCTu0xGPoYZuiRbaaw@mail.gmail.com>
> Hi Eric,
>
> The crash happens when the kernel tries to access shadow for nonmapped memory.
>
> The issue here is an integer overflow which happens in neigh_resolve_output().
> skb_network_offset(skb) can return negative number, but __skb_pull()
> accepts unsigned int as len.
> As a result, the least significat bit in higher 32 bits of skb->data
> gets set and we get an out-of-bounds with offset of 4 GB.
>
> I've attached a short reproducer, but you either need KASAN or to add
> a BUG_ON to see the crash.
> In this reproducer skb_network_offset() becomes negative after merging
> two ipv6 fragments.
>
> I actually see multiple places where skb_network_offset() is used as
> an argument to skb_pull().
> So I guess every place can potentially be buggy.
Well, I think the intent is to accept a negative number.
This definitely was assumed by commit e1f165032c8bade authors !
I guess they were using a 32bit kernel for their tests.
^ permalink raw reply
* unsuscribe
From: seba @ 2016-11-26 19:55 UTC (permalink / raw)
To: netdev
unsuscribe
^ permalink raw reply
* Re: net: GPF in eth_header
From: Andrey Konovalov @ 2016-11-26 19:07 UTC (permalink / raw)
To: syzkaller
Cc: Dmitry Vyukov, David Miller, Tom Herbert, Alexander Duyck,
Hannes Frederic Sowa, Jiri Benc, Sabrina Dubroca, netdev, LKML
In-Reply-To: <CANn89iJeWV9YnOzy4eXL4Sbcyw_kj_CA8JrfGaFxMse_MUFL6Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5343 bytes --]
On Sat, Nov 26, 2016 at 7:28 PM, 'Eric Dumazet' via syzkaller
<syzkaller@googlegroups.com> wrote:
> On Sat, Nov 26, 2016 at 9:30 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> Hello,
>>
>> The following program triggers GPF in eth_header:
>>
>> https://gist.githubusercontent.com/dvyukov/613cadf05543b55a419f237e419cd495/raw/5471231523d1a07c3de55f11f87472c2816ee06c/gistfile1.txt
>>
>> On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>>
>> BUG: unable to handle kernel paging request at ffffed002d14d74a
>> IP: [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
>> PGD 7fff6067 [ 50.787819] PUD 7fff5067
>> PMD 0 [ 50.787819]
>> Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>> Modules linked in:
>> CPU: 2 PID: 6712 Comm: a.out Not tainted 4.9.0-rc6+ #55
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: ffff88003a1841c0 task.stack: ffff880034d08000
>> RIP: 0010:[<ffffffff86be3295>] [<ffffffff86be3295>]
>> eth_header+0x75/0x260 net/ethernet/eth.c:88
>> RSP: 0018:ffff880034d0eb68 EFLAGS: 00010a03
>> RAX: 1ffff1002d14d74a RBX: ffff880168a6ba4a RCX: ffff88006a9c7858
>> RDX: 000000000000dd86 RSI: dffffc0000000000 RDI: ffff880168a6ba56
>> RBP: ffff880034d0eb98 R08: 0000000000000000 R09: 0000000000000031
>> R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000
>> R13: ffff88006c208d80 R14: 00000000000086dd R15: ffff88006a9c7858
>> FS: 0000000001a02940(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: ffffed002d14d74a CR3: 0000000037373000 CR4: 00000000000006e0
>> Stack:
>> 000000316881ab40 ffff88006a9c76c0 ffff88006881ab40 ffff88006a9c77f8
>> 0000000000000000 dffffc0000000000 ffff880034d0ee98 ffffffff86b31af9
>> ffffffff8719605c ffff880034d0f0f8 ffffffff000086dd ffffffff86be3220
>> Call Trace:
>> [< inline >] dev_hard_header ./include/linux/netdevice.h:2762
>> [<ffffffff86b31af9>] neigh_resolve_output+0x659/0xb20 net/core/neighbour.c:1302
>> [< inline >] dst_neigh_output ./include/net/dst.h:464
>> [<ffffffff8719605c>] ip6_finish_output2+0xb3c/0x2500 net/ipv6/ip6_output.c:121
>> [<ffffffff871a0b0b>] ip6_finish_output+0x2eb/0x760 net/ipv6/ip6_output.c:139
>> [< inline >] NF_HOOK_COND ./include/linux/netfilter.h:246
>> [<ffffffff871a1157>] ip6_output+0x1d7/0x9a0 net/ipv6/ip6_output.c:153
>> [< inline >] dst_output ./include/net/dst.h:501
>> [<ffffffff873312ea>] ip6_local_out+0x9a/0x180 net/ipv6/output_core.c:170
>> [<ffffffff871a3886>] ip6_send_skb+0xa6/0x340 net/ipv6/ip6_output.c:1712
>> [<ffffffff871a3bd8>] ip6_push_pending_frames+0xb8/0xe0
>> net/ipv6/ip6_output.c:1732
>> [< inline >] rawv6_push_pending_frames net/ipv6/raw.c:607
>> [<ffffffff8722acfb>] rawv6_sendmsg+0x250b/0x2c20 net/ipv6/raw.c:920
>> [<ffffffff8701c4f5>] inet_sendmsg+0x385/0x590 net/ipv4/af_inet.c:734
>> [< inline >] sock_sendmsg_nosec net/socket.c:621
>> [<ffffffff86a6ea9f>] sock_sendmsg+0xcf/0x110 net/socket.c:631
>> [<ffffffff86a6ee0b>] sock_write_iter+0x32b/0x620 net/socket.c:829
>> [<ffffffff81a6f153>] do_iter_readv_writev+0x363/0x670 fs/read_write.c:695
>> [<ffffffff81a71ba1>] do_readv_writev+0x431/0x9b0 fs/read_write.c:872
>> [<ffffffff81a726dc>] vfs_writev+0x8c/0xc0 fs/read_write.c:911
>> [<ffffffff81a72825>] do_writev+0x115/0x2d0 fs/read_write.c:944
>> [< inline >] SYSC_writev fs/read_write.c:1017
>> [<ffffffff81a75fdc>] SyS_writev+0x2c/0x40 fs/read_write.c:1014
>> [<ffffffff8814cf85>] entry_SYSCALL_64_fastpath+0x23/0xc6
>> arch/x86/entry/entry_64.S:209
>> Code: 41 83 fe 04 0f 84 aa 00 00 00 e8 17 4e b0 fa 48 8d 7b 0c 48 be
>> 00 00 00 00 00 fc ff df 44 89 f2 66 c1 c2 08 48 89 f8 48 c1 e8 03 <0f>
>> b6 0c 30 48 8d 43 0d 49 89 c0 49 c1 e8 03 41 0f b6 34 30 49
>> RIP [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
>> RSP <ffff880034d0eb68>
>> CR2: ffffed002d14d74a
>> ---[ end trace a73fedfdc11bd60c ]---
>
>
> Hi Dmitry
>
> I could not reproduce the issue. Might need some specific configuration...
>
> loopback device has proper ethernet header (all 0)
>
> Fault happens in :
>
> 0f b6 0c 30 movzbl (%rax,%rsi,1),%ecx
>
> RAX=1ffff1002d14d74a which is RDI>>3, and RSI=dffffc0000000000
>
> Could this be a KASAN problem ?
Hi Eric,
The crash happens when the kernel tries to access shadow for nonmapped memory.
The issue here is an integer overflow which happens in neigh_resolve_output().
skb_network_offset(skb) can return negative number, but __skb_pull()
accepts unsigned int as len.
As a result, the least significat bit in higher 32 bits of skb->data
gets set and we get an out-of-bounds with offset of 4 GB.
I've attached a short reproducer, but you either need KASAN or to add
a BUG_ON to see the crash.
In this reproducer skb_network_offset() becomes negative after merging
two ipv6 fragments.
I actually see multiple places where skb_network_offset() is used as
an argument to skb_pull().
So I guess every place can potentially be buggy.
Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: ipv6-poc1.c --]
[-- Type: application/octet-stream, Size: 1020 bytes --]
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>
int main()
{
mmap(0x20000000ul, 0x28000ul, 0x3ul, 0x32ul, 0xfffffffffffffffful, 0x0ul);
long sock = socket(0xaul, 0x3ul, 0x2cul);
struct sockaddr_in6 addr;
memset(&addr, 0, sizeof(addr));
addr.sin6_family = AF_INET6;
addr.sin6_port = htons(0x4242);
addr.sin6_addr = in6addr_loopback;
// addr.sin6_addr.s6_addr[1] = 42;
connect(sock, (const struct sockaddr *)&addr, sizeof(addr));
memcpy((void*)0x20025000,
"\x06\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
72);
sendto(sock, (const void *)0x20025000ul, 0x48ul, 0x4ul, 0x0ul, 0x0ul);
sendto(sock, (const void *)0x20025000ul, 0x48ul, 0x4ul, 0x0ul, 0x0ul);
return 0;
}
^ permalink raw reply
* Re: net: stmmac: Meson GXBB: attempting to execute userspace memory
From: Ben Dooks @ 2016-11-26 18:57 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Alexandre Torgue, Kevin Hilman, Giuseppe Cavallaro, lkml, netdev,
Carlo Caione, linux-amlogic, linux-arm-kernel
In-Reply-To: <c8280798-453e-bd1d-bd4d-bf0956a169cc@gmx.de>
On 2016-11-26 07:53, Heinrich Schuchardt wrote:
> For Odroid C2 I have compiled kernel
> 4.9.0-rc6-next-20161124-00001-gbf7e142
> with one additional patch
> https://github.com/xypron/kernel-odroid-c2/blob/master/patch/0001-stmmac-RTL8211F-Meson-GXBB-TX-throughput-problems.patch
>
> I repeatedly see faults like the one below:
>
> [ 2557.400796] Unhandled fault: synchronous external abort (0x92000010)
> at 0x000040001e8ee4b0
> [ 2557.952413] CPU: 0 PID: 22837 Comm: cc1 Tainted: G D
> 4.9.0-rc6-next-20161124-00001-gbf7e142 #1
> [ 2557.962062] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2557.966980] task: ffff80006ddb7080 task.stack: ffff80006dd9c000
> [ 2557.972846] PC is at 0x6a0d98
> [ 2557.975776] LR is at 0x6a0e54
> [ 2557.978709] pc : [<00000000006a0d98>] lr : [<00000000006a0e54>]
> pstate: 80000000
> [ 2557.986040] sp : 0000fffff3ee5f80
> [ 2557.989318] x29: 0000fffff3ee5f80 x28: 000040000b3f1240
> [ 2557.994578] x27: 00000000012a7000 x26: 000040000b3f1288
> [ 2557.999840] x25: 0000000000f58f88 x24: 000040000b3f1240
> [ 2558.005101] x23: 0000000000000000 x22: 0000000000000001
> [ 2558.010362] x21: 0000000000000001 x20: 000040000b3f1250
> [ 2558.015623] x19: 0000000000000054 x18: 0000000000000001
> [ 2558.020885] x17: 0000400008acaa10 x16: 0000000001285050
> [ 2558.026146] x15: 000040000ad96dc8 x14: 000000000000001f
> [ 2558.031407] x13: 000040000b3f1270 x12: 000040000b3f1258
> [ 2558.036668] x11: 0000000001347000 x10: 0000000000000661
> [ 2558.041930] x9 : 0000000000000005 x8 : 0000000000000003
> [ 2558.047191] x7 : 000040000b3f1240 x6 : 0000000020020033
> [ 2558.052452] x5 : 000040000b402020 x4 : 000040000b3e1aa0
> [ 2558.057713] x3 : 000000000000000c x2 : 0000000000000020
> [ 2558.062974] x1 : 0000000000f45000 x0 : 0000000000000065
> [ 2558.068235]
> [ 2558.069712] Internal error: Attempting to execute userspace memory:
> 8600000f [#7] PREEMPT SMP
> [ 2558.078155] Modules linked in: meson_rng rng_core meson_gxbb_wdt
> ip_tables x_tables ipv6 dwmac_generic realtek dwmac_meson8b
> stmmac_platform stmmac
> [ 2558.091267] CPU: 0 PID: 22837 Comm: cc1 Tainted: G D
> 4.9.0-rc6-next-20161124-00001-gbf7e142 #1
> [ 2558.100925] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2558.105841] task: ffff80006ddb7080 task.stack: ffff80006dd9c000
> [ 2558.111706] PC is at 0x6a0e54
> [ 2558.114638] LR is at 0x6a0e54
> [ 2558.117571] pc : [<00000000006a0e54>] lr : [<00000000006a0e54>]
> pstate: 600003c5
> [ 2558.124902] sp : ffff80006dd9fec0
> [ 2558.128179] x29: 0000000000000000 x28: ffff80006ddb7080
> [ 2558.133441] x27: 00000000012a7000 x26: 000040000b3f1288
> [ 2558.138702] x25: 0000000000f58f88 x24: 000040000b3f1240
> [ 2558.143963] x23: 0000000080000000 x22: 00000000006a0d98
> [ 2558.149225] x21: ffffffffffffffff x20: 000080006e223000
> [ 2558.154486] x19: 0000000000000000 x18: 0000000000000010
> [ 2558.159747] x17: 0000400008acaa10 x16: 0000000001285050
> [ 2558.165008] x15: ffff000088e91f07 x14: 0000000000000006
> [ 2558.170270] x13: ffff000008e91f15 x12: 000000000000000f
> [ 2558.175531] x11: 0000000000000002 x10: 00000000000002ea
> [ 2558.180792] x9 : ffff80006dd9fb40 x8 : 0000000000010a8b
> [ 2558.186053] x7 : 0000000000000000 x6 : 000000000000020e
> [ 2558.191315] x5 : 00000000020f020e x4 : 0000000000000000
> [ 2558.196576] x3 : 0000000000000000 x2 : 000000000000020f
> [ 2558.201837] x1 : ffff80006ddb7080 x0 : 0000000000000000
> [ 2558.207098]
> [ 2558.208565] Process cc1 (pid: 22837, stack limit =
> 0xffff80006dd9c000)
> [ 2558.215035] Stack: (0xffff80006dd9fec0 to 0xffff80006dda0000)
> [ 2558.220728] fec0: 0000000000000065 0000000000f45000 0000000000000020
> 000000000000000c
> [ 2558.228490] fee0: 000040000b3e1aa0 000040000b402020 0000000020020033
> 000040000b3f1240
> [ 2558.236253] ff00: 0000000000000003 0000000000000005 0000000000000661
> 0000000001347000
> [ 2558.244015] ff20: 000040000b3f1258 000040000b3f1270 000000000000001f
> 000040000ad96dc8
> [ 2558.251778] ff40: 0000000001285050 0000400008acaa10 0000000000000001
> 0000000000000054
> [ 2558.259540] ff60: 000040000b3f1250 0000000000000001 0000000000000001
> 0000000000000000
> [ 2558.267303] ff80: 000040000b3f1240 0000000000f58f88 000040000b3f1288
> 00000000012a7000
> [ 2558.275065] ffa0: 000040000b3f1240 0000fffff3ee5f80 00000000006a0e54
> 0000fffff3ee5f80
> [ 2558.282828] ffc0: 00000000006a0d98 0000000080000000 0000000000000003
> ffffffffffffffff
> [ 2558.290590] ffe0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2558.298351] Call trace:
> [ 2558.300769] Exception stack(0xffff80006dd9fcf0 to
> 0xffff80006dd9fe20)
> [ 2558.307149] fce0: 0000000000000000
> 0001000000000000
> [ 2558.314913] fd00: ffff80006dd9fec0 00000000006a0e54 ffff800073acf500
> 0000000000000004
> [ 2558.322675] fd20: 0000000000000000 ffff000008dbbc18 ffff80006ddb7080
> 000000006dd9fdd0
> [ 2558.330438] fd40: ffff80006dd9fd90 ffff0000080ca878 ffff80006dd9fe40
> ffff80006ddb7080
> [ 2558.338200] fd60: 0000000000000004 00000000000003c0 ffff80006dd9fe40
> 000040000b3f1240
> [ 2558.345963] fd80: 0000000000f58f88 000040000b3f1288 0000000000000000
> ffff80006ddb7080
> [ 2558.353725] fda0: 000000000000020f 0000000000000000 0000000000000000
> 00000000020f020e
> [ 2558.361487] fdc0: 000000000000020e 0000000000000000 0000000000010a8b
> ffff80006dd9fb40
> [ 2558.369250] fde0: 00000000000002ea 0000000000000002 000000000000000f
> ffff000008e91f15
> [ 2558.377012] fe00: 0000000000000006 ffff000088e91f07 0000000001285050
> 0000400008acaa10
> [ 2558.384775] [<00000000006a0e54>] 0x6a0e54
> [ 2558.388743] Code: d503201f f9400280 2a1703e1 97ffff0a (aa0003f3)
> [ 2558.395241] ---[ end trace 7d280955c14d4ff1 ]---
> [ 2558.584022] Bad mode in Error handler detected on CPU0, code
> 0xbf000000 -- SError
> [ 2558.585871] CPU: 0 PID: 22867 Comm: cc1 Tainted: G D
> 4.9.0-rc6-next-20161124-00001-gbf7e142 #1
> [ 2558.595527] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2558.600444] task: ffff80007454d780 task.stack: ffff8000660bc000
> [ 2558.606310] PC is at 0x631928
> [ 2558.609240] LR is at 0xb59ce0
> [ 2558.612172] pc : [<0000000000631928>] lr : [<0000000000b59ce0>]
> pstate: 80000000
> [ 2558.619503] sp : 0000ffffed764d90
> [ 2558.622782] x29: 0000ffffed764d90 x28: 0000000000000028
> [ 2558.628042] x27: 000000001a1062f0 x26: 0000000001299198
> [ 2558.633303] x25: 0000000000000001 x24: 0000000000000000
> [ 2558.638564] x23: 0000000000000004 x22: 00000000013513c8
> [ 2558.643825] x21: 0000400039d43488 x20: 0000000000000000
> [ 2558.649086] x19: 0000400039d2d730 x18: 0000000000000000
> [ 2558.654348] x17: 0000400039a7c378 x16: 0000000001285138
> [ 2558.659609] x15: 0000000000000001 x14: 0000000000000000
> [ 2558.664870] x13: ffffff0000000000 x12: 0000000000000000
> [ 2558.670131] x11: 0000000000000028 x10: 000000000129b2b8
> [ 2558.675393] x9 : 0000000000000041 x8 : 0000000000000003
> [ 2558.680654] x7 : 0000000000000050 x6 : 000000000003d2c8
> [ 2558.685915] x5 : 0000000000000002 x4 : 0000000000000004
> [ 2558.691176] x3 : 0000000000000003 x2 : 0000000001349000
> [ 2558.696438] x1 : 000000000003cb90 x0 : 0000400039d45050
> [ 2558.701699]
> [ 2558.703177] Internal error: Attempting to execute userspace memory:
> 8600000f [#8] PREEMPT SMP
> [ 2558.711618] Modules linked in: meson_rng rng_core meson_gxbb_wdt
> ip_tables x_tables ipv6 dwmac_generic realtek dwmac_meson8b
> stmmac_platform stmmac
> [ 2558.724731] CPU: 0 PID: 22867 Comm: cc1 Tainted: G D
> 4.9.0-rc6-next-20161124-00001-gbf7e142 #1
> [ 2558.734388] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2558.739304] task: ffff80007454d780 task.stack: ffff8000660bc000
> [ 2558.745169] PC is at 0xb59ce0
> [ 2558.748102] LR is at 0xb59ce0
> [ 2558.751035] pc : [<0000000000b59ce0>] lr : [<0000000000b59ce0>]
> pstate: 600003c5
> [ 2558.758365] sp : ffff8000660bfec0
> [ 2558.761643] x29: 0000000000000000 x28: ffff80007454d780
> [ 2558.766904] x27: 000000001a1062f0 x26: 0000000001299198
> [ 2558.772165] x25: 0000000000000001 x24: 0000000000000000
> [ 2558.777426] x23: 0000000080000000 x22: 0000000000631928
> [ 2558.782688] x21: ffffffffffffffff x20: 000080006e223000
> [ 2558.787949] x19: 0000000000000000 x18: 0000000000000010
> [ 2558.793210] x17: 0000400039a7c378 x16: 0000000001285138
> [ 2558.798471] x15: ffff000088e91f07 x14: 0000000000000006
> [ 2558.803733] x13: ffff000008e91f15 x12: 000000000000000f
> [ 2558.808994] x11: 0000000000000002 x10: 0000000000000336
> [ 2558.814255] x9 : ffff8000660bfb40 x8 : 00000000000ab503
> [ 2558.819516] x7 : 0000000000000000 x6 : 00000000000000dd
> [ 2558.824778] x5 : 0000000000de00dd x4 : 0000000000000000
> [ 2558.830039] x3 : 0000000000000000 x2 : 00000000000000de
> [ 2558.835300] x1 : ffff80007454d780 x0 : 0000000000000000
> [ 2558.840561]
> [ 2558.842029] Process cc1 (pid: 22867, stack limit =
> 0xffff8000660bc000)
> [ 2558.848498] Stack: (0xffff8000660bfec0 to 0xffff8000660c0000)
> [ 2558.854191] fec0: 0000400039d45050 000000000003cb90 0000000001349000
> 0000000000000003
> [ 2558.861953] fee0: 0000000000000004 0000000000000002 000000000003d2c8
> 0000000000000050
> [ 2558.869716] ff00: 0000000000000003 0000000000000041 000000000129b2b8
> 0000000000000028
> [ 2558.877478] ff20: 0000000000000000 ffffff0000000000 0000000000000000
> 0000000000000001
> [ 2558.885241] ff40: 0000000001285138 0000400039a7c378 0000000000000000
> 0000400039d2d730
> [ 2558.893003] ff60: 0000000000000000 0000400039d43488 00000000013513c8
> 0000000000000004
> [ 2558.900766] ff80: 0000000000000000 0000000000000001 0000000001299198
> 000000001a1062f0
> [ 2558.908529] ffa0: 0000000000000028 0000ffffed764d90 0000000000b59ce0
> 0000ffffed764d90
> [ 2558.916291] ffc0: 0000000000631928 0000000080000000 000000001a18c000
> ffffffffffffffff
> [ 2558.924053] ffe0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2558.931814] Call trace:
> [ 2558.934232] Exception stack(0xffff8000660bfcf0 to
> 0xffff8000660bfe20)
> [ 2558.940613] fce0: 0000000000000000
> 0001000000000000
> [ 2558.948376] fd00: ffff8000660bfec0 0000000000b59ce0 ffff800073acf640
> 0000000000000004
> [ 2558.956138] fd20: 0000000000000000 ffff000008dbbc18 ffff80007454d780
> 00000000660bfdd0
> [ 2558.963901] fd40: ffff8000660bfd90 ffff0000080ca878 ffff8000660bfe40
> ffff80007454d780
> [ 2558.971663] fd60: 0000000000000004 00000000000003c0 ffff8000660bfe40
> 0000000000000000
> [ 2558.979426] fd80: 0000000000000001 0000000001299198 0000000000000000
> ffff80007454d780
> [ 2558.987188] fda0: 00000000000000de 0000000000000000 0000000000000000
> 0000000000de00dd
> [ 2558.994951] fdc0: 00000000000000dd 0000000000000000 00000000000ab503
> ffff8000660bfb40
> [ 2559.002713] fde0: 0000000000000336 0000000000000002 000000000000000f
> ffff000008e91f15
> [ 2559.010476] fe00: 0000000000000006 ffff000088e91f07 0000000001285138
> 0000400039a7c378
> [ 2559.018238] [<0000000000b59ce0>] 0xb59ce0
> [ 2559.022207] Code: d2800001 d2800002 d2800500 97eb5e9d (a9007c1f)
> [ 2559.028376] ---[ end trace 7d280955c14d4ff2 ]---
> [ 2559.034397] Bad mode in Error handler detected on CPU2, code
> 0xbf000000 -- SError
> [ 2559.040235] CPU: 2 PID: 22866 Comm: gcc Tainted: G D
> 4.9.0-rc6-next-20161124-00001-gbf7e142 #1
> [ 2559.049892] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2559.054808] task: ffff80007454e400 task.stack: ffff80006de9c000
> [ 2559.060674] PC is at 0x40003c0400d8
> [ 2559.064122] LR is at 0x46d4e0
> [ 2559.067055] pc : [<000040003c0400d8>] lr : [<000000000046d4e0>]
> pstate: 80000000
> [ 2559.074385] sp : 0000ffffe6387270
> [ 2559.077664] x29: 0000ffffe6387270 x28: 0000000016c0ff90
> [ 2559.082924] x27: 0000000000000002 x26: 0000000000000001
> [ 2559.088185] x25: 0000ffffe63873f4 x24: 0000ffffe63873f8
> [ 2559.093447] x23: 0000ffffe63873f4 x22: 0000ffffe63873f8
> [ 2559.098708] x21: 0000000016c104e0 x20: 0000000000005953
> [ 2559.103969] x19: 0000000000000000 [ 2559.107102] Unhandled fault:
> synchronous external abort (0x96000010) at 0xffff800000c1e000
> [ 2559.107108] Internal error: : 96000010 [#9] PREEMPT SMP
> [ 2559.107110] Modules linked in:
> [ 2559.107113] meson_rng rng_core meson_gxbb_wdt ip_tables x_tables
> ipv6 dwmac_generic realtek dwmac_meson8b stmmac_platform stmmac[
> 2559.107131] CPU: 0 PID: 1124 Comm: mmcqd/1 Tainted: G D 1
> [ 2559.107132] Hardware name: Hardkernel ODROID-C2 (DT)
> [ 2559.107135] task: ffff8000704abe80 task.stack: ffff8000734d0000
> [ 2559.107147] PC is at __memcpy+0x100/0x180
> [ 2559.107152] LR is at sg_copy_buffer+0xb0/0x110
> [ 2559.107155] pc : [<ffff00000837ee00>] lr : [<ffff00000838e928>]
> pstate: 200001c5
> [ 2559.107155] sp : ffff8000734d3bb0
> [ 2559.107157] x29: ffff8000734d3bb0
> [ 2559.107158] x28: ffff800073a14800 x27: ffff800073a14b68
> [ 2559.107162] x26: 0000000000000000 x25: 0000000000000140
> [ 2559.107165] x24: 0000000000000001 x23: 0000000000001000
> [ 2559.107168] x22: ffff8000746a2000 x21: 0000000000001000
> [ 2559.107170] x20: 0000000000000000 x19: 0000000000001000
> [ 2559.107172] x18: 0000000000000000 x17: ffffffffffffffff
> [ 2559.107175] x16: 00000000000006be x15: ffff000008c34000
> [ 2559.107178] x14: 747962342e090a34 x13: 3278302038323162
> [ 2559.107181] x12: 656c752e090a3864 x11: ffff800073866800
> [ 2559.107183] x10: ffff80006bf68eb0 x9 : 0000000000000000
> [ 2559.107186] x8 : ffff800073a94920 x7 : 0000000000000000
> [ 2559.107188] x6 : ffff8000746a2000 x5 : 0000820000000000
> [ 2559.107191] x4 : 0000000000000000 x3 : 0000000000000000
> [ 2559.107193] x2 : 0000000000000f80 x1 : ffff800000c1e000
> [ 2559.107196] x0 : ffff8000746a2000
> [ 2559.107199] Process mmcqd/1 (pid: 1124, stack limit =
> 0xffff8000734d0000)
> [ 2559.107202] Stack: (0xffff8000734d3bb0 to 0xffff8000734d4000)
> [ 2559.107205] 3ba0: ffff8000734d3c50
> ffff00000838e9bc
> [ 2559.107208] 3bc0: ffff800073a14000 ffff800073a14a30 ffff80006bf68eb0
> ffff800073a14a28
> [ 2559.107212] 3be0: ffff800073a14818 ffff800073a14800 0000000000000000
> ffff00000838e1c4
> [ 2559.107215] 3c00: ffff800073a94900 ffff7e0000030780 ffff800000c1e000
> 0000000000001000
> [ 2559.107218] 3c20: 0000000000001000 ffff800073ad0a00 0000000100000000
> 0000000000000001
> [ 2559.107221] 3c40: 0000100000000000 0000000000000005 ffff8000734d3c60
> ffff00000874c1bc
> [ 2559.107224] 3c60: ffff8000734d3c70 ffff000008748010 ffff8000734d3cd0
> ffff000008749908
> [ 2559.107228] 3c80: ffff80006bf68eb0 ffff800073a14000 ffff8000734c8000
> ffff800073a14818
> [ 2559.107231] 3ca0: ffff800073a14800 ffff800073a14800 ffff80006bf68eb0
> ffff800073a14a28
> [ 2559.107234] 3cc0: ffff80006bf68eb0 ffff000008749bc8 ffff8000734d3d70
> ffff00000874b298
> [ 2559.107237] 3ce0: ffff800073a14000 ffff800073a14818 ffff8000734c8000
> 0000000000000000
> [ 2559.107240] 3d00: ffff800073a14800 ffff800073a14800 ffff800073a13800
> 0000000000000000
> [ 2559.107243] 3d20: ffff80006bf68eb0 0000000000000000 00000000012853f0
> ffff000008c0fcb8
> [ 2559.107246] 3d40: 0000000000000000 000000000835bf14 ffff000008a05f58
> ffff800000000000
> [ 2559.107249] 3d60: ffff8000734c8000 0000000000000001 ffff8000734d3de0
> ffff00000874b6f4
> [ 2559.107252] 3d80: ffff800073a14818 ffff80006bf68eb0 ffff8000734c8000
> 0000000000000001
> [ 2559.107255] 3da0: ffff800073a14828 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107258] 3dc0: 0000000000000000 0000000000000000 ffff800073a14818
> ffff00000874b6c4
> [ 2559.107261] 3de0: ffff8000734d3e20 ffff0000080daa84 ffff800073a94980
> ffff000008e8eb08
> [ 2559.107264] 3e00: ffff000008b75b50 ffff800073a14818 ffff00000874b658
> 0000000000000000
> [ 2559.107267] 3e20: 0000000000000000 ffff000008082ec0 ffff0000080da9b8
> ffff800073a94980
> [ 2559.107270] 3e40: 0000000000000000 0000000000000000 0000000000000000
> 000003ff01893600
> [ 2559.107273] 3e60: ffff8000734d3ea0 0000000000000000 ffff0000080da9b8
> ffff800073a14818
> [ 2559.107276] 3e80: 0000000000000000 0000000000000000 ffff8000734d3e90
> ffff8000734d3e90
> [ 2559.107279] 3ea0: 0000000000000000 ffff000000000000 ffff8000734d3eb0
> ffff8000734d3eb0
> [ 2559.107281] 3ec0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107284] 3ee0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107287] 3f00: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107290] 3f20: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107293] 3f40: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107295] 3f60: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107298] 3f80: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107300] 3fa0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 2559.107303] 3fc0: 0000000000000000 0000000000000005 0000000000000000
> 0000000000000000
> [ 2559.107306] 3fe0: 0000000000000000 0000000000000000 0000001800002cba
> 26000000a01b3800
> [ 2559.107308] Call trace:
> [ 2559.107312] Exception stack(0xffff8000734d39e0 to
> 0xffff8000734d3b10)
> [ 2559.107315] 39e0: 0000000000001000 0001000000000000 ffff8000734d3bb0
> ffff00000837ee00
> [ 2559.107318] 3a00: 0000000000000007 ffff800000000000 ffff800000c1e000
> 0000000100100010
> [ 2559.107321] 3a20: ffff8000734d3ac0 ffff000008748d88 ffff8000734d3b8c
> 0000000000000001
> [ 2559.107324] 3a40: ffff8000734d3b40 ffff0000081c9dac ffff800074401d00
> ffff0000081745d8
> [ 2559.107327] 3a60: ffff7e0001b72f80 ffff80006dcbe300 00000000031fda40
> 0000000000000000
> [ 2559.107330] 3a80: ffff8000746a2000 ffff800000c1e000 0000000000000f80
> 0000000000000000
> [ 2559.107333] 3aa0: 0000000000000000 0000820000000000 ffff8000746a2000
> 0000000000000000
> [ 2559.107336] 3ac0: ffff800073a94920 0000000000000000 ffff80006bf68eb0
> ffff800073866800
> [ 2559.107339] 3ae0: 656c752e090a3864 3278302038323162 747962342e090a34
> ffff000008c34000
> [ 2559.107341] 3b00: 00000000000006be ffffffffffffffff
> [ 2559.107346] [<ffff00000837ee00>] __memcpy+0x100/0x180
> [ 2559.107349] [<ffff00000838e9bc>] sg_copy_to_buffer+0x14/0x20
> [ 2559.107357] [<ffff00000874c1bc>] mmc_queue_bounce_pre+0x34/0x40
> [ 2559.107362] [<ffff000008748010>] mmc_blk_rw_rq_prep+0x288/0x3a0
> [ 2559.107365] [<ffff000008749908>] mmc_blk_issue_rw_rq+0x3c0/0x998
> [ 2559.107368] [<ffff00000874b298>] mmc_blk_issue_rq+0x150/0x510
> [ 2559.107371] [<ffff00000874b6f4>] mmc_queue_thread+0x9c/0x140
> [ 2559.107377] [<ffff0000080daa84>] kthread+0xcc/0xe0
> [ 2559.107383] [<ffff000008082ec0>] ret_from_fork+0x10/0x50
Looks like it died whilst processing an mmc request.
^ permalink raw reply
* Re: [PATCH net-next] cgroup, bpf: remove unnecessary #include
From: Rami Rosen @ 2016-11-26 18:40 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S . Miller, Daniel Borkmann, Daniel Mack, Tejun Heo, Netdev
In-Reply-To: <1480145027-3524392-1-git-send-email-ast@fb.com>
Acked-by: Rami Rosen <roszenrami@gmail.com>
On 26 November 2016 at 09:23, Alexei Starovoitov <ast@fb.com> wrote:
> this #include is unnecessary and brings whole set of
> other headers into cgroup-defs.h. Remove it.
>
> Fixes: 3007098494be ("cgroup: add support for eBPF programs")
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> include/linux/bpf-cgroup.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
> index ec80d0c0953e..0cf1adfadd2d 100644
> --- a/include/linux/bpf-cgroup.h
> +++ b/include/linux/bpf-cgroup.h
> @@ -1,7 +1,6 @@
> #ifndef _BPF_CGROUP_H
> #define _BPF_CGROUP_H
>
> -#include <linux/bpf.h>
> #include <linux/jump_label.h>
> #include <uapi/linux/bpf.h>
>
> --
> 2.8.0
>
^ permalink raw reply
* Re: net: GPF in eth_header
From: Eric Dumazet @ 2016-11-26 18:28 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Miller, Tom Herbert, Alexander Duyck, Hannes Frederic Sowa,
Jiri Benc, Sabrina Dubroca, netdev, LKML, syzkaller
In-Reply-To: <CACT4Y+at4Fp6i7WRggYq7M1+z1aHo=Bff63p+1DzC2SnTjuWdA@mail.gmail.com>
On Sat, Nov 26, 2016 at 9:30 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> The following program triggers GPF in eth_header:
>
> https://gist.githubusercontent.com/dvyukov/613cadf05543b55a419f237e419cd495/raw/5471231523d1a07c3de55f11f87472c2816ee06c/gistfile1.txt
>
> On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>
> BUG: unable to handle kernel paging request at ffffed002d14d74a
> IP: [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
> PGD 7fff6067 [ 50.787819] PUD 7fff5067
> PMD 0 [ 50.787819]
> Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
> Modules linked in:
> CPU: 2 PID: 6712 Comm: a.out Not tainted 4.9.0-rc6+ #55
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff88003a1841c0 task.stack: ffff880034d08000
> RIP: 0010:[<ffffffff86be3295>] [<ffffffff86be3295>]
> eth_header+0x75/0x260 net/ethernet/eth.c:88
> RSP: 0018:ffff880034d0eb68 EFLAGS: 00010a03
> RAX: 1ffff1002d14d74a RBX: ffff880168a6ba4a RCX: ffff88006a9c7858
> RDX: 000000000000dd86 RSI: dffffc0000000000 RDI: ffff880168a6ba56
> RBP: ffff880034d0eb98 R08: 0000000000000000 R09: 0000000000000031
> R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff88006c208d80 R14: 00000000000086dd R15: ffff88006a9c7858
> FS: 0000000001a02940(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffed002d14d74a CR3: 0000000037373000 CR4: 00000000000006e0
> Stack:
> 000000316881ab40 ffff88006a9c76c0 ffff88006881ab40 ffff88006a9c77f8
> 0000000000000000 dffffc0000000000 ffff880034d0ee98 ffffffff86b31af9
> ffffffff8719605c ffff880034d0f0f8 ffffffff000086dd ffffffff86be3220
> Call Trace:
> [< inline >] dev_hard_header ./include/linux/netdevice.h:2762
> [<ffffffff86b31af9>] neigh_resolve_output+0x659/0xb20 net/core/neighbour.c:1302
> [< inline >] dst_neigh_output ./include/net/dst.h:464
> [<ffffffff8719605c>] ip6_finish_output2+0xb3c/0x2500 net/ipv6/ip6_output.c:121
> [<ffffffff871a0b0b>] ip6_finish_output+0x2eb/0x760 net/ipv6/ip6_output.c:139
> [< inline >] NF_HOOK_COND ./include/linux/netfilter.h:246
> [<ffffffff871a1157>] ip6_output+0x1d7/0x9a0 net/ipv6/ip6_output.c:153
> [< inline >] dst_output ./include/net/dst.h:501
> [<ffffffff873312ea>] ip6_local_out+0x9a/0x180 net/ipv6/output_core.c:170
> [<ffffffff871a3886>] ip6_send_skb+0xa6/0x340 net/ipv6/ip6_output.c:1712
> [<ffffffff871a3bd8>] ip6_push_pending_frames+0xb8/0xe0
> net/ipv6/ip6_output.c:1732
> [< inline >] rawv6_push_pending_frames net/ipv6/raw.c:607
> [<ffffffff8722acfb>] rawv6_sendmsg+0x250b/0x2c20 net/ipv6/raw.c:920
> [<ffffffff8701c4f5>] inet_sendmsg+0x385/0x590 net/ipv4/af_inet.c:734
> [< inline >] sock_sendmsg_nosec net/socket.c:621
> [<ffffffff86a6ea9f>] sock_sendmsg+0xcf/0x110 net/socket.c:631
> [<ffffffff86a6ee0b>] sock_write_iter+0x32b/0x620 net/socket.c:829
> [<ffffffff81a6f153>] do_iter_readv_writev+0x363/0x670 fs/read_write.c:695
> [<ffffffff81a71ba1>] do_readv_writev+0x431/0x9b0 fs/read_write.c:872
> [<ffffffff81a726dc>] vfs_writev+0x8c/0xc0 fs/read_write.c:911
> [<ffffffff81a72825>] do_writev+0x115/0x2d0 fs/read_write.c:944
> [< inline >] SYSC_writev fs/read_write.c:1017
> [<ffffffff81a75fdc>] SyS_writev+0x2c/0x40 fs/read_write.c:1014
> [<ffffffff8814cf85>] entry_SYSCALL_64_fastpath+0x23/0xc6
> arch/x86/entry/entry_64.S:209
> Code: 41 83 fe 04 0f 84 aa 00 00 00 e8 17 4e b0 fa 48 8d 7b 0c 48 be
> 00 00 00 00 00 fc ff df 44 89 f2 66 c1 c2 08 48 89 f8 48 c1 e8 03 <0f>
> b6 0c 30 48 8d 43 0d 49 89 c0 49 c1 e8 03 41 0f b6 34 30 49
> RIP [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
> RSP <ffff880034d0eb68>
> CR2: ffffed002d14d74a
> ---[ end trace a73fedfdc11bd60c ]---
Hi Dmitry
I could not reproduce the issue. Might need some specific configuration...
loopback device has proper ethernet header (all 0)
Fault happens in :
0f b6 0c 30 movzbl (%rax,%rsi,1),%ecx
RAX=1ffff1002d14d74a which is RDI>>3, and RSI=dffffc0000000000
Could this be a KASAN problem ?
^ permalink raw reply
* net: BUG in unix_notinflight
From: Dmitry Vyukov @ 2016-11-26 18:05 UTC (permalink / raw)
To: David Miller, Hannes Frederic Sowa, Willy Tarreau, netdev, LKML,
Eric Dumazet
Cc: syzkaller
Hello,
I am hitting the following BUG while running syzkaller fuzzer:
kernel BUG at net/unix/garbage.c:149!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 23491 Comm: syz-executor Not tainted 4.9.0-rc5+ #41
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
task: ffff8801c16b06c0 task.stack: ffff8801c2928000
RIP: 0010:[<ffffffff8717ebf4>] [<ffffffff8717ebf4>]
unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
RSP: 0018:ffff8801c292ea40 EFLAGS: 00010297
RAX: ffff8801c16b06c0 RBX: 1ffff10038525d4a RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 1ffff10038525d4e RDI: ffffffff8a6e9d84
RBP: ffff8801c292eb18 R08: 0000000000000000 R09: 0000000000000000
R10: cdca594876e035a1 R11: 0000000000000005 R12: 1ffff10038525d4e
R13: ffffffff899156e0 R14: ffff8801c292eaf0 R15: ffff88018b7cd780
FS: 00007f10420fa700(0000) GS:ffff8801d9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000002000a000 CR3: 00000001c2ecc000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000400 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Stack:
dffffc0000000000 ffff88019f036970 0000000041b58ab3 ffffffff894c5120
ffffffff8717e840 ffff8801c16b06c0 ffff88018b7cdcf0 ffffffff894c51e2
ffffffff81576d50 0000000000000000 ffffffff00000000 1ffff10000000000
Call Trace:
[<ffffffff8716cfbf>] unix_detach_fds.isra.19+0xff/0x170 net/unix/af_unix.c:1487
[<ffffffff8716f6a9>] unix_destruct_scm+0xf9/0x210 net/unix/af_unix.c:1496
[<ffffffff86a90a01>] skb_release_head_state+0x101/0x200 net/core/skbuff.c:655
[<ffffffff86a9808a>] skb_release_all+0x1a/0x60 net/core/skbuff.c:668
[<ffffffff86a980ea>] __kfree_skb+0x1a/0x30 net/core/skbuff.c:684
[<ffffffff86a98284>] kfree_skb+0x184/0x570 net/core/skbuff.c:705
[<ffffffff871789d5>] unix_release_sock+0x5b5/0xbd0 net/unix/af_unix.c:559
[<ffffffff87179039>] unix_release+0x49/0x90 net/unix/af_unix.c:836
[<ffffffff86a694b2>] sock_release+0x92/0x1f0 net/socket.c:570
[<ffffffff86a6962b>] sock_close+0x1b/0x20 net/socket.c:1017
[<ffffffff81a76b8e>] __fput+0x34e/0x910 fs/file_table.c:208
[<ffffffff81a771da>] ____fput+0x1a/0x20 fs/file_table.c:244
[<ffffffff81483ab0>] task_work_run+0x1a0/0x280 kernel/task_work.c:116
[< inline >] exit_task_work include/linux/task_work.h:21
[<ffffffff8141287a>] do_exit+0x183a/0x2640 kernel/exit.c:828
[<ffffffff8141383e>] do_group_exit+0x14e/0x420 kernel/exit.c:931
[<ffffffff814429d3>] get_signal+0x663/0x1880 kernel/signal.c:2307
[<ffffffff81239b45>] do_signal+0xc5/0x2190 arch/x86/kernel/signal.c:807
[<ffffffff8100666a>] exit_to_usermode_loop+0x1ea/0x2d0
arch/x86/entry/common.c:156
[< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
[<ffffffff81009693>] syscall_return_slowpath+0x4d3/0x570
arch/x86/entry/common.c:259
[<ffffffff881478e6>] entry_SYSCALL_64_fastpath+0xc4/0xc6
Code: df 49 89 87 70 05 00 00 41 c6 04 14 f8 48 89 f9 48 c1 e9 03 80
3c 11 00 75 64 49 89 87 78 05 00 00 e9 65 ff ff ff e8 ac 94 56 fa <0f>
0b 48 89 d7 48 89 95 30 ff ff ff e8 bb 22 87 fa 48 8b 95 30
RIP [<ffffffff8717ebf4>] unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
RSP <ffff8801c292ea40>
---[ end trace 4cbbd52674b68dab ]---
On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
Unfortunately this is not reproducible outside of syzkaller.
But easily reproducible with syzkaller. If you need to reproduce it,
follow instructions described here:
https://github.com/google/syzkaller/wiki/How-to-execute-syzkaller-programs
With the following as the program:
mmap(&(0x7f0000000000/0xdd5000)=nil, (0xdd5000), 0x3, 0x32,
0xffffffffffffffff, 0x0)
socketpair$unix(0x1, 0x5, 0x0, &(0x7f0000dc7000-0x8)={<r0=>0x0, <r1=>0x0})
sendmmsg$unix(r1,
&(0x7f0000dbf000-0xa8)=[{&(0x7f0000dbe000)=@file={0x1, ""}, 0x2,
&(0x7f0000dbe000)=[], 0x0, &(0x7f0000dc4000)=[@rights={0x20, 0x1, 0x1,
[r0, r0, r0, r1]}, @rights={0x14, 0x1, 0x1, [0xffffffffffffffff]},
@cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0}, @cred={0x20, 0x1, 0x2, 0x0,
0x0, 0x0}, @cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0}], 0x5, 0x800},
{&(0x7f0000dbf000-0x7d)=@file={0x1, ""}, 0x2, &(0x7f0000dbe000)=[],
0x0, &(0x7f0000dbf000-0x80)=[@rights={0x20, 0x1, 0x1,
[0xffffffffffffffff, r1, 0xffffffffffffffff, r0]}, @cred={0x20, 0x1,
0x2, 0x0, 0x0, 0x0}, @cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0},
@cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0}], 0x4, 0x4},
{&(0x7f0000dbf000-0x8)=@abs={0x0, 0x0, 0x8}, 0x8,
&(0x7f0000dbe000)=[{&(0x7f0000dc0000-0x27)="", 0x0},
{&(0x7f0000dc1000-0xb0)="", 0x0}, {&(0x7f0000dc2000-0xc4)="", 0x0},
{&(0x7f0000dc2000)="", 0x0}, {&(0x7f0000dc3000)="", 0x0}], 0x5,
&(0x7f0000dbe000)=[@cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0},
@rights={0x14, 0x1, 0x1, [r1]}, @cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0},
@cred={0x20, 0x1, 0x2, 0x0, 0x0, 0x0}], 0x4, 0x4}], 0x3, 0x800)
dup3(r1, r0, 0x80000)
close(r1)
^ permalink raw reply
* net: GPF in eth_header
From: Dmitry Vyukov @ 2016-11-26 17:30 UTC (permalink / raw)
To: David Miller, Tom Herbert, aduyck, Hannes Frederic Sowa, jbenc,
Sabrina Dubroca, netdev, LKML, Eric Dumazet
Cc: syzkaller
Hello,
The following program triggers GPF in eth_header:
https://gist.githubusercontent.com/dvyukov/613cadf05543b55a419f237e419cd495/raw/5471231523d1a07c3de55f11f87472c2816ee06c/gistfile1.txt
On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
BUG: unable to handle kernel paging request at ffffed002d14d74a
IP: [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
PGD 7fff6067 [ 50.787819] PUD 7fff5067
PMD 0 [ 50.787819]
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 2 PID: 6712 Comm: a.out Not tainted 4.9.0-rc6+ #55
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88003a1841c0 task.stack: ffff880034d08000
RIP: 0010:[<ffffffff86be3295>] [<ffffffff86be3295>]
eth_header+0x75/0x260 net/ethernet/eth.c:88
RSP: 0018:ffff880034d0eb68 EFLAGS: 00010a03
RAX: 1ffff1002d14d74a RBX: ffff880168a6ba4a RCX: ffff88006a9c7858
RDX: 000000000000dd86 RSI: dffffc0000000000 RDI: ffff880168a6ba56
RBP: ffff880034d0eb98 R08: 0000000000000000 R09: 0000000000000031
R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88006c208d80 R14: 00000000000086dd R15: ffff88006a9c7858
FS: 0000000001a02940(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffed002d14d74a CR3: 0000000037373000 CR4: 00000000000006e0
Stack:
000000316881ab40 ffff88006a9c76c0 ffff88006881ab40 ffff88006a9c77f8
0000000000000000 dffffc0000000000 ffff880034d0ee98 ffffffff86b31af9
ffffffff8719605c ffff880034d0f0f8 ffffffff000086dd ffffffff86be3220
Call Trace:
[< inline >] dev_hard_header ./include/linux/netdevice.h:2762
[<ffffffff86b31af9>] neigh_resolve_output+0x659/0xb20 net/core/neighbour.c:1302
[< inline >] dst_neigh_output ./include/net/dst.h:464
[<ffffffff8719605c>] ip6_finish_output2+0xb3c/0x2500 net/ipv6/ip6_output.c:121
[<ffffffff871a0b0b>] ip6_finish_output+0x2eb/0x760 net/ipv6/ip6_output.c:139
[< inline >] NF_HOOK_COND ./include/linux/netfilter.h:246
[<ffffffff871a1157>] ip6_output+0x1d7/0x9a0 net/ipv6/ip6_output.c:153
[< inline >] dst_output ./include/net/dst.h:501
[<ffffffff873312ea>] ip6_local_out+0x9a/0x180 net/ipv6/output_core.c:170
[<ffffffff871a3886>] ip6_send_skb+0xa6/0x340 net/ipv6/ip6_output.c:1712
[<ffffffff871a3bd8>] ip6_push_pending_frames+0xb8/0xe0
net/ipv6/ip6_output.c:1732
[< inline >] rawv6_push_pending_frames net/ipv6/raw.c:607
[<ffffffff8722acfb>] rawv6_sendmsg+0x250b/0x2c20 net/ipv6/raw.c:920
[<ffffffff8701c4f5>] inet_sendmsg+0x385/0x590 net/ipv4/af_inet.c:734
[< inline >] sock_sendmsg_nosec net/socket.c:621
[<ffffffff86a6ea9f>] sock_sendmsg+0xcf/0x110 net/socket.c:631
[<ffffffff86a6ee0b>] sock_write_iter+0x32b/0x620 net/socket.c:829
[<ffffffff81a6f153>] do_iter_readv_writev+0x363/0x670 fs/read_write.c:695
[<ffffffff81a71ba1>] do_readv_writev+0x431/0x9b0 fs/read_write.c:872
[<ffffffff81a726dc>] vfs_writev+0x8c/0xc0 fs/read_write.c:911
[<ffffffff81a72825>] do_writev+0x115/0x2d0 fs/read_write.c:944
[< inline >] SYSC_writev fs/read_write.c:1017
[<ffffffff81a75fdc>] SyS_writev+0x2c/0x40 fs/read_write.c:1014
[<ffffffff8814cf85>] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:209
Code: 41 83 fe 04 0f 84 aa 00 00 00 e8 17 4e b0 fa 48 8d 7b 0c 48 be
00 00 00 00 00 fc ff df 44 89 f2 66 c1 c2 08 48 89 f8 48 c1 e8 03 <0f>
b6 0c 30 48 8d 43 0d 49 89 c0 49 c1 e8 03 41 0f b6 34 30 49
RIP [<ffffffff86be3295>] eth_header+0x75/0x260 net/ethernet/eth.c:88
RSP <ffff880034d0eb68>
CR2: ffffed002d14d74a
---[ end trace a73fedfdc11bd60c ]---
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-26 17:20 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Sebastian Reichel, Pavel Machek, Michal Kazior, Kalle Valo,
Ivaylo Dimitrov, Tony Lindgren, linux-wireless,
Network Development, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161124184601.wo4al6nyzb6rmiqs-FnsA7b+Nu9XLHDo1XOr0g3XdqJI7FyRRX3B1VOXEql0@public.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 671 bytes --]
On Thursday 24 November 2016 19:46:01 Aaro Koskinen wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > Proprietary, signed and closed bootloader NOLO does not support DT.
> > So for booting you need to append DTS file to kernel image.
> >
> > U-Boot is optional and can be used as intermediate bootloader
> > between NOLO and kernel. But still it has problems with reading
> > from nand, so cannot read NVS data nor MAC address.
>
> You could use kexec to pass the fixed DT.
>
> A.
IIRC it was broken for N900/omap3, no idea if somebody fixed it.
--
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pavel Machek @ 2016-11-26 17:17 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Pali Rohár, Sebastian Reichel, Michal Kazior, Kalle Valo,
Ivaylo Dimitrov, Tony Lindgren, linux-wireless,
Network Development, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161124184601.wo4al6nyzb6rmiqs-FnsA7b+Nu9XLHDo1XOr0g3XdqJI7FyRRX3B1VOXEql0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On Thu 2016-11-24 20:46:01, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > Proprietary, signed and closed bootloader NOLO does not support DT. So
> > for booting you need to append DTS file to kernel image.
> >
> > U-Boot is optional and can be used as intermediate bootloader between
> > NOLO and kernel. But still it has problems with reading from nand, so
> > cannot read NVS data nor MAC address.
>
> You could use kexec to pass the fixed DT.
Yeah. You could also strap desktop PC to a USB GPRS card, and call it
phone. You could also make a pig fly.
But because you could does not mean you should. No, sorry, kexec is
not acceptable. Too hard to set up, slows boot too much.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: net: deadlock on genl_mutex
From: Eric Dumazet @ 2016-11-26 17:12 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Miller, Matti Vaittinen, Tycho Andersen, Cong Wang,
Florian Westphal, stephen hemminger, Tom Herbert, netdev, LKML,
Richard Guy Briggs, syzkaller
In-Reply-To: <CACT4Y+ZdSNVhF2MH0=t=kBUrgNSSnCSO5uwnnc5c0KNLG+VNFQ@mail.gmail.com>
On Sat, Nov 26, 2016 at 9:04 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> The following program triggers deadlock warnings on genl_mutex:
>
> https://gist.githubusercontent.com/dvyukov/65e33d053e507d2ab0bf6ae83d989585/raw/b3c640ec58e894b50bcbf255c471406466cfa5d0/gistfile1.txt
>
> On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>
> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
> in_atomic(): 1, irqs_disabled(): 0, pid: 32289, name: syz-executor
> CPU: 0 PID: 32289 Comm: syz-executor Not tainted 4.9.0-rc5+ #54
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff88003ec06420 ffffffff834c2e39 ffffffff00000000 1ffff10007d80c17
> ffffed0007d80c0f 0000000041b58ab3 ffffffff89575550 ffffffff834c2b4b
> ffffffff8baab1a0 dffffc0000000000 0000000000000000 ffff880068f794e0
> Call Trace:
> <IRQ> [ 287.394552] [< inline >] __dump_stack lib/dump_stack.c:15
> <IRQ> [ 287.394552] [<ffffffff834c2e39>] dump_stack+0x2ee/0x3f5
> lib/dump_stack.c:51
> [<ffffffff814b6ac3>] ___might_sleep+0x483/0x660 kernel/sched/core.c:7761
> [<ffffffff814b6d3a>] __might_sleep+0x9a/0x1a0 kernel/sched/core.c:7720
> [<ffffffff88139aaa>] mutex_lock_nested+0x1ea/0xf20 kernel/locking/mutex.c:620
> [< inline >] genl_lock net/netlink/genetlink.c:31
> [<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0 net/netlink/genetlink.c:531
> [<ffffffff86ca5458>] netlink_sock_destruct+0xf8/0x400
> net/netlink/af_netlink.c:331
> [<ffffffff86a7b234>] __sk_destruct+0xf4/0x7f0 net/core/sock.c:1423
> [<ffffffff86a87d6c>] sk_destruct+0x4c/0x80 net/core/sock.c:1453
> [<ffffffff86a87dfc>] __sk_free+0x5c/0x230 net/core/sock.c:1461
> [<ffffffff86a87ff8>] sk_free+0x28/0x30 net/core/sock.c:1472
> [< inline >] sock_put include/net/sock.h:1591
> [<ffffffff86ca6cd1>] deferred_put_nlk_sk+0x31/0x40 net/netlink/af_netlink.c:652
> [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
> [<ffffffff815cbc9d>] rcu_do_batch.isra.70+0x9ed/0xe20 kernel/rcu/tree.c:2776
> [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
> [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
> [<ffffffff815cc55c>] rcu_process_callbacks+0x48c/0xd70 kernel/rcu/tree.c:3024
> [<ffffffff8814d53b>] __do_softirq+0x32b/0xca8 kernel/softirq.c:284
> [< inline >] invoke_softirq kernel/softirq.c:364
> [<ffffffff8141a941>] irq_exit+0x1d1/0x210 kernel/softirq.c:405
> [< inline >] exiting_irq arch/x86/include/asm/apic.h:659
> [<ffffffff8814ca30>] smp_apic_timer_interrupt+0x80/0xa0
> arch/x86/kernel/apic/apic.c:960
> [<ffffffff8814badc>] apic_timer_interrupt+0x8c/0xa0
> arch/x86/entry/entry_64.S:489
> <EOI> [ 287.403717] [<ffffffff8155c987>] ? lock_is_held+0x247/0x310
> [<ffffffff814b6bde>] ___might_sleep+0x59e/0x660 kernel/sched/core.c:7729
> [<ffffffff814b6d3a>] __might_sleep+0x9a/0x1a0 kernel/sched/core.c:7720
> [<ffffffff88142d08>] down_read+0x78/0x160 kernel/locking/rwsem.c:21
> [< inline >] anon_vma_lock_read include/linux/rmap.h:127
> [<ffffffff81968295>] validate_mm+0xe5/0x880 mm/mmap.c:347
> [<ffffffff8196bf0b>] vma_link+0x11b/0x180 mm/mmap.c:605
> [<ffffffff81977f46>] mmap_region+0x1076/0x1880 mm/mmap.c:1692
> [<ffffffff81978e4f>] do_mmap+0x6ff/0xe80 mm/mmap.c:1450
> [< inline >] do_mmap_pgoff include/linux/mm.h:2039
> [<ffffffff818fd527>] vm_mmap_pgoff+0x1b7/0x210 mm/util.c:305
> [< inline >] SYSC_mmap_pgoff mm/mmap.c:1500
> [<ffffffff8196f961>] SyS_mmap_pgoff+0x231/0x5e0 mm/mmap.c:1458
> [< inline >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
> [<ffffffff8124bf4b>] SyS_mmap+0x1b/0x30 arch/x86/kernel/sys_x86_64.c:86
> [<ffffffff88149dc5>] entry_SYSCALL_64_fastpath+0x23/0xc6
>
> =================================
> [ INFO: inconsistent lock state ]
> 4.9.0-rc5+ #54 Tainted: G W
> ---------------------------------
> inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
> syz-executor/32289 [HC0[0]:SC1[1]:HE1:SE0] takes:
> ([ 287.580014] genl_mutex
> [< inline >] genl_lock net/netlink/genetlink.c:31
> [<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0 net/netlink/genetlink.c:531
> {SOFTIRQ-ON-W} state was registered at:
> [ 287.580014] [< inline >] mark_irqflags
> kernel/locking/lockdep.c:2938
> [ 287.580014] [<ffffffff81567ad7>] __lock_acquire+0x6e7/0x3380
> kernel/locking/lockdep.c:3292
> [ 287.580014] [<ffffffff8156b642>] lock_acquire+0x2a2/0x790
> kernel/locking/lockdep.c:3746
> [ 287.580014] [< inline >] __mutex_lock_common
> kernel/locking/mutex.c:521
> [ 287.580014] [<ffffffff88139aff>] mutex_lock_nested+0x23f/0xf20
> kernel/locking/mutex.c:621
> [ 287.580014] [< inline >] genl_lock net/netlink/genetlink.c:31
> [ 287.580014] [< inline >] genl_lock_all net/netlink/genetlink.c:52
> [ 287.580014] [<ffffffff86cba52e>]
> __genl_register_family+0x2ce/0x1870 net/netlink/genetlink.c:374
> [ 287.580014] [< inline >]
> _genl_register_family_with_ops_grps include/net/genetlink.h:173
> [ 287.580014] [<ffffffff8ab90c02>] genl_init+0x11d/0x185
> net/netlink/genetlink.c:1084
> [ 287.580014] [<ffffffff8100244b>] do_one_initcall+0xfb/0x3f0 init/main.c:778
> [ 287.580014] [< inline >] do_initcall_level init/main.c:844
> [ 287.580014] [< inline >] do_initcalls init/main.c:852
> [ 287.580014] [< inline >] do_basic_setup init/main.c:870
> [ 287.580014] [<ffffffff8aa3d03d>] kernel_init_freeable+0x5c4/0x69e
> init/main.c:1017
> [ 287.580014] [<ffffffff88129c88>] kernel_init+0x18/0x180 init/main.c:943
> [ 287.580014] [<ffffffff8814a05a>] ret_from_fork+0x2a/0x40
> arch/x86/entry/entry_64.S:433
>
> [ 78.258919] [ INFO: inconsistent lock state ]
> [ 78.258919] 4.9.0-rc5+ #54 Tainted: G W
> [ 78.258919] ---------------------------------
> [ 78.258919] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
> [ 78.258919] syz-fuzzer/5211 [HC0[0]:SC1[1]:HE1:SE0] takes:
> [ 78.258919] ([ 78.258919] genl_mutex
> ){+.?.+.}[ 78.258919] , at:
> [ 78.258919] [<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0
> [ 78.258919] {SOFTIRQ-ON-W} state was registered at:
> [ 78.258919] [ 78.258919] [<ffffffff81567ad7>] __lock_acquire+0x6e7/0x3380
> [ 78.258919] [ 78.258919] [<ffffffff8156b642>] lock_acquire+0x2a2/0x790
> [ 78.258919] [ 78.258919] [<ffffffff88139aff>]
> mutex_lock_nested+0x23f/0xf20
> [ 78.258919] [ 78.258919] [<ffffffff86cba52e>]
> __genl_register_family+0x2ce/0x1870
> [ 78.258919] [ 78.258919] [<ffffffff8ab90c02>] genl_init+0x11d/0x185
> [ 78.258919] [ 78.258919] [<ffffffff8100244b>] do_one_initcall+0xfb/0x3f0
> [ 78.258919] [ 78.258919] [<ffffffff8aa3d03d>]
> kernel_init_freeable+0x5c4/0x69e
> [ 78.258919] [ 78.258919] [<ffffffff88129c88>] kernel_init+0x18/0x180
> [ 78.258919] [ 78.258919] [<ffffffff8814a05a>] ret_from_fork+0x2a/0x40
> [ 78.258919] irq event stamp: 149484
> [ 78.258919] hardirqs last enabled at (149484): [ 78.258919]
> [<ffffffff8814a7df>] restore_regs_and_iret+0x0/0x1d
> [ 78.258919] hardirqs last disabled at (149483): [ 78.258919]
> [<ffffffff8814bad7>] apic_timer_interrupt+0x87/0xa0
> [ 78.258919] softirqs last enabled at (149302): [ 78.258919]
> [<ffffffff8814da39>] __do_softirq+0x829/0xca8
> [ 78.258919] softirqs last disabled at (149437): [ 78.258919]
> [<ffffffff8141a941>] irq_exit+0x1d1/0x210
>
> [ 78.258919]
> [ 78.258919] other info that might help us debug this:
> [ 78.258919] Possible unsafe locking scenario:
> [ 78.258919]
> [ 78.258919] CPU0
> [ 78.258919] ----
> [ 78.258919] lock([ 78.258919] genl_mutex
> [ 78.258919] );
> [ 78.258919] <Interrupt>
> [ 78.258919] lock([ 78.258919] genl_mutex
> [ 78.258919] );
> [ 78.258919]
> [ 78.258919] *** DEADLOCK ***
> [ 78.258919]
> [ 78.258919] 1 lock held by syz-fuzzer/5211:
> [ 78.258919] #0: [ 78.258919] (
> rcu_callback[ 78.258919] ){......}
> , at: [ 78.258919] [<ffffffff815cbc43>] rcu_do_batch.isra.70+0x993/0xe20
> [ 78.258919]
> [ 78.258919] stack backtrace:
>
> CPU: 0 PID: 32289 Comm: syz-executor Tainted: G W 4.9.0-rc5+ #54
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff88003ec05db8 ffffffff834c2e39 ffffffff00000000 1ffff10007d80b4a
> ffffed0007d80b42 0000000041b58ab3 ffffffff89575550 ffffffff834c2b4b
> ffff88003948a340 ffff88003ec22cc0 ffff8800384dd280 0000000041b58ab3
> Call Trace:
> <IRQ> [ 287.580014] [< inline >] __dump_stack lib/dump_stack.c:15
> <IRQ> [ 287.580014] [<ffffffff834c2e39>] dump_stack+0x2ee/0x3f5
> lib/dump_stack.c:51
> [<ffffffff815648df>] print_usage_bug+0x3ef/0x450 kernel/locking/lockdep.c:2388
> [< inline >] valid_state kernel/locking/lockdep.c:2401
> [< inline >] mark_lock_irq kernel/locking/lockdep.c:2599
> [<ffffffff81565870>] mark_lock+0xf30/0x1410 kernel/locking/lockdep.c:3062
> [< inline >] mark_irqflags kernel/locking/lockdep.c:2920
> [<ffffffff8156811e>] __lock_acquire+0xd2e/0x3380 kernel/locking/lockdep.c:3292
> [<ffffffff8156b642>] lock_acquire+0x2a2/0x790 kernel/locking/lockdep.c:3746
> [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
> [<ffffffff88139aff>] mutex_lock_nested+0x23f/0xf20 kernel/locking/mutex.c:621
> [< inline >] genl_lock net/netlink/genetlink.c:31
> [<ffffffff86cb5a11>] genl_lock_done+0x71/0xd0 net/netlink/genetlink.c:531
> [<ffffffff86ca5458>] netlink_sock_destruct+0xf8/0x400
> net/netlink/af_netlink.c:331
> [<ffffffff86a7b234>] __sk_destruct+0xf4/0x7f0 net/core/sock.c:1423
> [<ffffffff86a87d6c>] sk_destruct+0x4c/0x80 net/core/sock.c:1453
> [<ffffffff86a87dfc>] __sk_free+0x5c/0x230 net/core/sock.c:1461
> [<ffffffff86a87ff8>] sk_free+0x28/0x30 net/core/sock.c:1472
> [< inline >] sock_put include/net/sock.h:1591
> [<ffffffff86ca6cd1>] deferred_put_nlk_sk+0x31/0x40 net/netlink/af_netlink.c:652
> [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
> [<ffffffff815cbc9d>] rcu_do_batch.isra.70+0x9ed/0xe20 kernel/rcu/tree.c:2776
> [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
> [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
> [<ffffffff815cc55c>] rcu_process_callbacks+0x48c/0xd70 kernel/rcu/tree.c:3024
> [<ffffffff8814d53b>] __do_softirq+0x32b/0xca8 kernel/softirq.c:284
> [< inline >] invoke_softirq kernel/softirq.c:364
> [<ffffffff8141a941>] irq_exit+0x1d1/0x210 kernel/softirq.c:405
> [< inline >] exiting_irq arch/x86/include/asm/apic.h:659
> [<ffffffff8814ca30>] smp_apic_timer_interrupt+0x80/0xa0
> arch/x86/kernel/apic/apic.c:960
> [<ffffffff8814badc>] apic_timer_interrupt+0x8c/0xa0
> arch/x86/entry/entry_64.S:489
> <EOI> [ 287.580014] [<ffffffff8155c987>] ? lock_is_held+0x247/0x310
> [<ffffffff814b6bde>] ___might_sleep+0x59e/0x660 kernel/sched/core.c:7729
> [<ffffffff814b6d3a>] __might_sleep+0x9a/0x1a0 kernel/sched/core.c:7720
> [<ffffffff88142d08>] down_read+0x78/0x160 kernel/locking/rwsem.c:21
> [< inline >] anon_vma_lock_read include/linux/rmap.h:127
> [<ffffffff81968295>] validate_mm+0xe5/0x880 mm/mmap.c:347
> [<ffffffff8196bf0b>] vma_link+0x11b/0x180 mm/mmap.c:605
> [<ffffffff81977f46>] mmap_region+0x1076/0x1880 mm/mmap.c:1692
> [<ffffffff81978e4f>] do_mmap+0x6ff/0xe80 mm/mmap.c:1450
> [< inline >] do_mmap_pgoff include/linux/mm.h:2039
> [<ffffffff818fd527>] vm_mmap_pgoff+0x1b7/0x210 mm/util.c:305
> [< inline >] SYSC_mmap_pgoff mm/mmap.c:1500
> [<ffffffff8196f961>] SyS_mmap_pgoff+0x231/0x5e0 mm/mmap.c:1458
> [< inline >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
> [<ffffffff8124bf4b>] SyS_mmap+0x1b/0x30 arch/x86/kernel/sys_x86_64.c:86
> [<ffffffff88149dc5>] entry_SYSCALL_64_fastpath+0x23/0xc6
Issue was reported yesterday and is under investigation.
http://marc.info/?l=linux-netdev&m=148014004331663&w=2
Thanks !
^ 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