* [PATCH RFC v3 3/3] virtio-net: optimize free_old_xmit_skbs stats
From: Michael S. Tsirkin @ 2014-10-20 6:52 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: Jason Wang, Rusty Russell, virtualization, netdev
In-Reply-To: <1413787824-16130-1-git-send-email-mst@redhat.com>
From: Jason Wang <jasowang@redhat.com>
We already have counters for sent packets and sent bytes.
Use them to reduce the number of u64_stats_update_begin/end().
Take care not to bother with stats update when called
speculatively.
Based on a patch by Jason Wang.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/virtio_net.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b83d39d..c2b69f8 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -233,16 +233,22 @@ static unsigned int free_old_xmit_skbs(struct netdev_queue *txq,
(skb = virtqueue_get_buf(sq->vq, &len)) != NULL) {
pr_debug("Sent skb %p\n", skb);
- u64_stats_update_begin(&stats->tx_syncp);
- stats->tx_bytes += skb->len;
bytes += skb->len;
- stats->tx_packets++;
- u64_stats_update_end(&stats->tx_syncp);
+ packets++;
dev_kfree_skb_any(skb);
- packets++;
}
+ /* Avoid overhead when no packets have been processed
+ * happens when called speculatively from start_xmit. */
+ if (!packets)
+ return 0;
+
+ u64_stats_update_begin(&stats->tx_syncp);
+ stats->tx_bytes += bytes;
+ stats->tx_packets += packets;
+ u64_stats_update_end(&stats->tx_syncp);
+
netdev_tx_completed_queue(txq, packets, bytes);
if (sq->vq->num_free >= 2+MAX_SKB_FRAGS)
--
MST
^ permalink raw reply related
* [PATCH net] tipc: fix lockdep warning when intra-node messages are delivered
From: Ying Xue @ 2014-10-20 6:46 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, erik.hugne, netdev, tipc-discussion
When running tipcTC&tipcTS test suite, below lockdep unsafe locking
scenario is reported:
[ 1109.997854]
[ 1109.997988] =================================
[ 1109.998290] [ INFO: inconsistent lock state ]
[ 1109.998575] 3.17.0-rc1+ #113 Not tainted
[ 1109.998762] ---------------------------------
[ 1109.998762] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 1109.998762] swapper/7/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 1109.998762] (slock-AF_TIPC){+.?...}, at: [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
[ 1109.998762] {SOFTIRQ-ON-W} state was registered at:
[ 1109.998762] [<ffffffff810a4770>] __lock_acquire+0x6a0/0x1d80
[ 1109.998762] [<ffffffff810a6555>] lock_acquire+0x95/0x1e0
[ 1109.998762] [<ffffffff81a2d1ce>] _raw_spin_lock+0x3e/0x80
[ 1109.998762] [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
[ 1109.998762] [<ffffffffa0004fe8>] tipc_link_xmit+0xa8/0xc0 [tipc]
[ 1109.998762] [<ffffffffa000ec6f>] tipc_sendmsg+0x15f/0x550 [tipc]
[ 1109.998762] [<ffffffffa000f165>] tipc_connect+0x105/0x140 [tipc]
[ 1109.998762] [<ffffffff817676ee>] SYSC_connect+0xae/0xc0
[ 1109.998762] [<ffffffff81767b7e>] SyS_connect+0xe/0x10
[ 1109.998762] [<ffffffff817a9788>] compat_SyS_socketcall+0xb8/0x200
[ 1109.998762] [<ffffffff81a306e5>] sysenter_dispatch+0x7/0x1f
[ 1109.998762] irq event stamp: 241060
[ 1109.998762] hardirqs last enabled at (241060): [<ffffffff8105a4ad>] __local_bh_enable_ip+0x6d/0xd0
[ 1109.998762] hardirqs last disabled at (241059): [<ffffffff8105a46f>] __local_bh_enable_ip+0x2f/0xd0
[ 1109.998762] softirqs last enabled at (241020): [<ffffffff81059a52>] _local_bh_enable+0x22/0x50
[ 1109.998762] softirqs last disabled at (241021): [<ffffffff8105a626>] irq_exit+0x96/0xc0
[ 1109.998762]
[ 1109.998762] other info that might help us debug this:
[ 1109.998762] Possible unsafe locking scenario:
[ 1109.998762]
[ 1109.998762] CPU0
[ 1109.998762] ----
[ 1109.998762] lock(slock-AF_TIPC);
[ 1109.998762] <Interrupt>
[ 1109.998762] lock(slock-AF_TIPC);
[ 1109.998762]
[ 1109.998762] *** DEADLOCK ***
[ 1109.998762]
[ 1109.998762] 2 locks held by swapper/7/0:
[ 1109.998762] #0: (rcu_read_lock){......}, at: [<ffffffff81782dc9>] __netif_receive_skb_core+0x69/0xb70
[ 1109.998762] #1: (rcu_read_lock){......}, at: [<ffffffffa0001c90>] tipc_l2_rcv_msg+0x40/0x260 [tipc]
[ 1109.998762]
[ 1109.998762] stack backtrace:
[ 1109.998762] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.17.0-rc1+ #113
[ 1109.998762] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 1109.998762] ffffffff82745830 ffff880016c03828 ffffffff81a209eb 0000000000000007
[ 1109.998762] ffff880017b3cac0 ffff880016c03888 ffffffff81a1c5ef 0000000000000001
[ 1109.998762] ffff880000000001 ffff880000000000 ffffffff81012d4f 0000000000000000
[ 1109.998762] Call Trace:
[ 1109.998762] <IRQ> [<ffffffff81a209eb>] dump_stack+0x4e/0x68
[ 1109.998762] [<ffffffff81a1c5ef>] print_usage_bug+0x1f1/0x202
[ 1109.998762] [<ffffffff81012d4f>] ? save_stack_trace+0x2f/0x50
[ 1109.998762] [<ffffffff810a406c>] mark_lock+0x28c/0x2f0
[ 1109.998762] [<ffffffff810a3440>] ? print_irq_inversion_bug.part.46+0x1f0/0x1f0
[ 1109.998762] [<ffffffff810a467d>] __lock_acquire+0x5ad/0x1d80
[ 1109.998762] [<ffffffff810a70dd>] ? trace_hardirqs_on+0xd/0x10
[ 1109.998762] [<ffffffff8108ace8>] ? sched_clock_cpu+0x98/0xc0
[ 1109.998762] [<ffffffff8108ad2b>] ? local_clock+0x1b/0x30
[ 1109.998762] [<ffffffff810a10dc>] ? lock_release_holdtime.part.29+0x1c/0x1a0
[ 1109.998762] [<ffffffff8108aa05>] ? sched_clock_local+0x25/0x90
[ 1109.998762] [<ffffffffa000dec0>] ? tipc_sk_get+0x60/0x80 [tipc]
[ 1109.998762] [<ffffffff810a6555>] lock_acquire+0x95/0x1e0
[ 1109.998762] [<ffffffffa0011969>] ? tipc_sk_rcv+0x49/0x2b0 [tipc]
[ 1109.998762] [<ffffffff810a6fb6>] ? trace_hardirqs_on_caller+0xa6/0x1c0
[ 1109.998762] [<ffffffff81a2d1ce>] _raw_spin_lock+0x3e/0x80
[ 1109.998762] [<ffffffffa0011969>] ? tipc_sk_rcv+0x49/0x2b0 [tipc]
[ 1109.998762] [<ffffffffa000dec0>] ? tipc_sk_get+0x60/0x80 [tipc]
[ 1109.998762] [<ffffffffa0011969>] tipc_sk_rcv+0x49/0x2b0 [tipc]
[ 1109.998762] [<ffffffffa00076bd>] tipc_rcv+0x5ed/0x960 [tipc]
[ 1109.998762] [<ffffffffa0001d1c>] tipc_l2_rcv_msg+0xcc/0x260 [tipc]
[ 1109.998762] [<ffffffffa0001c90>] ? tipc_l2_rcv_msg+0x40/0x260 [tipc]
[ 1109.998762] [<ffffffff81783345>] __netif_receive_skb_core+0x5e5/0xb70
[ 1109.998762] [<ffffffff81782dc9>] ? __netif_receive_skb_core+0x69/0xb70
[ 1109.998762] [<ffffffff81784eb9>] ? dev_gro_receive+0x259/0x4e0
[ 1109.998762] [<ffffffff817838f6>] __netif_receive_skb+0x26/0x70
[ 1109.998762] [<ffffffff81783acd>] netif_receive_skb_internal+0x2d/0x1f0
[ 1109.998762] [<ffffffff81785518>] napi_gro_receive+0xd8/0x240
[ 1109.998762] [<ffffffff815bf854>] e1000_clean_rx_irq+0x2c4/0x530
[ 1109.998762] [<ffffffff815c1a46>] e1000_clean+0x266/0x9c0
[ 1109.998762] [<ffffffff8108ad2b>] ? local_clock+0x1b/0x30
[ 1109.998762] [<ffffffff8108aa05>] ? sched_clock_local+0x25/0x90
[ 1109.998762] [<ffffffff817842b1>] net_rx_action+0x141/0x310
[ 1109.998762] [<ffffffff810bd710>] ? handle_fasteoi_irq+0xe0/0x150
[ 1109.998762] [<ffffffff81059fa6>] __do_softirq+0x116/0x4d0
[ 1109.998762] [<ffffffff8105a626>] irq_exit+0x96/0xc0
[ 1109.998762] [<ffffffff81a30d07>] do_IRQ+0x67/0x110
[ 1109.998762] [<ffffffff81a2ee2f>] common_interrupt+0x6f/0x6f
[ 1109.998762] <EOI> [<ffffffff8100d2b7>] ? default_idle+0x37/0x250
[ 1109.998762] [<ffffffff8100d2b5>] ? default_idle+0x35/0x250
[ 1109.998762] [<ffffffff8100dd1f>] arch_cpu_idle+0xf/0x20
[ 1109.998762] [<ffffffff810999fd>] cpu_startup_entry+0x27d/0x4d0
[ 1109.998762] [<ffffffff81034c78>] start_secondary+0x188/0x1f0
When intra-node messages are delivered from one process to another
process, tipc_link_xmit() doesn't disable BH before it directly calls
tipc_sk_rcv() on process context to forward messages to destination
socket. Meanwhile, if messages delivered by remote node arrive at the
node and their destinations are also the same socket, tipc_sk_rcv()
running on process context might be preempted by tipc_sk_rcv() running
BH context. As a result, the latter cannot obtain the socket lock as
the lock was obtained by the former, however, the former has no chance
to be run as the latter is owning the CPU now, so headlock happens. To
avoid it, BH should be always disabled in tipc_sk_rcv().
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/socket.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 3043f10..51bddc2 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1776,7 +1776,7 @@ int tipc_sk_rcv(struct sk_buff *buf)
sk = &tsk->sk;
/* Queue message */
- bh_lock_sock(sk);
+ spin_lock_bh(&sk->sk_lock.slock);
if (!sock_owned_by_user(sk)) {
rc = filter_rcv(sk, buf);
@@ -1787,7 +1787,7 @@ int tipc_sk_rcv(struct sk_buff *buf)
if (sk_add_backlog(sk, buf, limit))
rc = -TIPC_ERR_OVERLOAD;
}
- bh_unlock_sock(sk);
+ spin_unlock_bh(&sk->sk_lock.slock);
tipc_sk_put(tsk);
if (likely(!rc))
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH net] tipc: fix a potential deadlock
From: Ying Xue @ 2014-10-20 6:44 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, erik.hugne, netdev, tipc-discussion
Locking dependency detected below possible unsafe locking scenario:
CPU0 CPU1
T0: tipc_named_rcv() tipc_rcv()
T1: [grab nametble write lock]* [grab node lock]*
T2: tipc_update_nametbl() tipc_node_link_up()
T3: tipc_nodesub_subscribe() tipc_nametbl_publish()
T4: [grab node lock]* [grab nametble write lock]*
The opposite order of holding nametbl write lock and node lock on
above two different paths may result in a deadlock. If we move the
the updating of the name table after link state named out of node
lock, the reverse order of holding locks will be eliminated, and
as a result, the deadlock risk.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/node.c | 46 ++++++++++++++++++++++++++++------------------
net/tipc/node.h | 7 ++++++-
net/tipc/socket.c | 2 +-
3 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 90cee4a..5781634 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -219,11 +219,11 @@ void tipc_node_abort_sock_conns(struct list_head *conns)
void tipc_node_link_up(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
{
struct tipc_link **active = &n_ptr->active_links[0];
- u32 addr = n_ptr->addr;
n_ptr->working_links++;
- tipc_nametbl_publish(TIPC_LINK_STATE, addr, addr, TIPC_NODE_SCOPE,
- l_ptr->bearer_id, addr);
+ n_ptr->action_flags |= TIPC_NOTIFY_LINK_UP;
+ n_ptr->link_id = l_ptr->peer_bearer_id << 16 | l_ptr->bearer_id;
+
pr_info("Established link <%s> on network plane %c\n",
l_ptr->name, l_ptr->net_plane);
@@ -284,10 +284,10 @@ static void node_select_active_links(struct tipc_node *n_ptr)
void tipc_node_link_down(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
{
struct tipc_link **active;
- u32 addr = n_ptr->addr;
n_ptr->working_links--;
- tipc_nametbl_withdraw(TIPC_LINK_STATE, addr, l_ptr->bearer_id, addr);
+ n_ptr->action_flags |= TIPC_NOTIFY_LINK_DOWN;
+ n_ptr->link_id = l_ptr->peer_bearer_id << 16 | l_ptr->bearer_id;
if (!tipc_link_is_active(l_ptr)) {
pr_info("Lost standby link <%s> on network plane %c\n",
@@ -552,28 +552,30 @@ void tipc_node_unlock(struct tipc_node *node)
LIST_HEAD(conn_sks);
struct sk_buff_head waiting_sks;
u32 addr = 0;
- unsigned int flags = node->action_flags;
+ int flags = node->action_flags;
+ u32 link_id = 0;
- if (likely(!node->action_flags)) {
+ if (likely(!flags)) {
spin_unlock_bh(&node->lock);
return;
}
+ addr = node->addr;
+ link_id = node->link_id;
__skb_queue_head_init(&waiting_sks);
- if (node->action_flags & TIPC_WAKEUP_USERS) {
+
+ if (flags & TIPC_WAKEUP_USERS)
skb_queue_splice_init(&node->waiting_sks, &waiting_sks);
- node->action_flags &= ~TIPC_WAKEUP_USERS;
- }
- if (node->action_flags & TIPC_NOTIFY_NODE_DOWN) {
+
+ if (flags & TIPC_NOTIFY_NODE_DOWN) {
list_replace_init(&node->nsub, &nsub_list);
list_replace_init(&node->conn_sks, &conn_sks);
- node->action_flags &= ~TIPC_NOTIFY_NODE_DOWN;
}
- if (node->action_flags & TIPC_NOTIFY_NODE_UP) {
- node->action_flags &= ~TIPC_NOTIFY_NODE_UP;
- addr = node->addr;
- }
- node->action_flags &= ~TIPC_WAKEUP_BCAST_USERS;
+ node->action_flags &= ~(TIPC_WAKEUP_USERS | TIPC_NOTIFY_NODE_DOWN |
+ TIPC_NOTIFY_NODE_UP | TIPC_NOTIFY_LINK_UP |
+ TIPC_NOTIFY_LINK_DOWN |
+ TIPC_WAKEUP_BCAST_USERS);
+
spin_unlock_bh(&node->lock);
while (!skb_queue_empty(&waiting_sks))
@@ -588,6 +590,14 @@ void tipc_node_unlock(struct tipc_node *node)
if (flags & TIPC_WAKEUP_BCAST_USERS)
tipc_bclink_wakeup_users();
- if (addr)
+ if (flags & TIPC_NOTIFY_NODE_UP)
tipc_named_node_up(addr);
+
+ if (flags & TIPC_NOTIFY_LINK_UP)
+ tipc_nametbl_publish(TIPC_LINK_STATE, addr, addr,
+ TIPC_NODE_SCOPE, link_id, addr);
+
+ if (flags & TIPC_NOTIFY_LINK_DOWN)
+ tipc_nametbl_withdraw(TIPC_LINK_STATE, addr,
+ link_id, addr);
}
diff --git a/net/tipc/node.h b/net/tipc/node.h
index 67513c3..04e9145 100644
--- a/net/tipc/node.h
+++ b/net/tipc/node.h
@@ -53,6 +53,7 @@
* TIPC_WAIT_OWN_LINKS_DOWN: wait until peer node is declared down
* TIPC_NOTIFY_NODE_DOWN: notify node is down
* TIPC_NOTIFY_NODE_UP: notify node is up
+ * TIPC_DISTRIBUTE_NAME: publish or withdraw link state name type
*/
enum {
TIPC_WAIT_PEER_LINKS_DOWN = (1 << 1),
@@ -60,7 +61,9 @@ enum {
TIPC_NOTIFY_NODE_DOWN = (1 << 3),
TIPC_NOTIFY_NODE_UP = (1 << 4),
TIPC_WAKEUP_USERS = (1 << 5),
- TIPC_WAKEUP_BCAST_USERS = (1 << 6)
+ TIPC_WAKEUP_BCAST_USERS = (1 << 6),
+ TIPC_NOTIFY_LINK_UP = (1 << 7),
+ TIPC_NOTIFY_LINK_DOWN = (1 << 8)
};
/**
@@ -100,6 +103,7 @@ struct tipc_node_bclink {
* @working_links: number of working links to node (both active and standby)
* @link_cnt: number of links to node
* @signature: node instance identifier
+ * @link_id: local and remote bearer ids of changing link, if any
* @nsub: list of "node down" subscriptions monitoring node
* @rcu: rcu struct for tipc_node
*/
@@ -116,6 +120,7 @@ struct tipc_node {
int link_cnt;
int working_links;
u32 signature;
+ u32 link_id;
struct list_head nsub;
struct sk_buff_head waiting_sks;
struct list_head conn_sks;
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 75275c5..3043f10 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -2673,7 +2673,7 @@ static int tipc_ioctl(struct socket *sk, unsigned int cmd, unsigned long arg)
case SIOCGETLINKNAME:
if (copy_from_user(&lnr, argp, sizeof(lnr)))
return -EFAULT;
- if (!tipc_node_get_linkname(lnr.bearer_id, lnr.peer,
+ if (!tipc_node_get_linkname(lnr.bearer_id & 0xffff, lnr.peer,
lnr.linkname, TIPC_MAX_LINK_NAME)) {
if (copy_to_user(argp, &lnr, sizeof(lnr)))
return -EFAULT;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net] ax88179_178a: fix bonding failure
From: David Miller @ 2014-10-20 4:55 UTC (permalink / raw)
To: imorgan; +Cc: netdev
In-Reply-To: <alpine.LFD.2.11.1410190801050.5282@solo.int.primordial.ca>
From: Ian Morgan <imorgan@primordial.ca>
Date: Sun, 19 Oct 2014 08:05:13 -0400 (EDT)
> The following patch fixes a bug which causes the ax88179_178a driver to be
> incapable of being added to a bond.
>
> When I brought up the issue with the bonding maintainers, they indicated
> that the real problem was with the NIC driver which must return zero for
> success (of setting the MAC address). I see that several other NIC drivers
> follow that pattern by either simply always returing zero, or by passing
> through a negative (error) result while rewriting any positive return code
> to zero. With that same philisophy applied to the ax88179_178a driver, it
> allows it to work correctly with the bonding driver.
>
> I believe this is suitable for queuing in -stable, as it's a small, simple,
> and obvious fix that corrects a defect with no other known workaround.
>
> This patch is against vanilla 3.17(.0).
>
> Signed-off-by: Ian Morgan <imorgan@primordial.ca>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH stable v3.2 v3.4] ipv4: disable bh while doing route gc
From: David Miller @ 2014-10-20 4:23 UTC (permalink / raw)
To: ben; +Cc: mleitner, stable, netdev, hannes
In-Reply-To: <1413774581.31953.12.camel@decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 20 Oct 2014 04:09:41 +0100
> I've appplied this and the previous two patches mentioned ('ipv4: move
> route garbage collector to work queue' and 'ipv4: avoid parallel route
> cache gc executions'). But I didn't get the other two from you. The
> last batch of networking fixes I received and applied was dated
> 2014-08-07, and the next one I've seen is dated 2014-10-11 and has
> nothing for 3.2 or 3.4. Did I miss one between these?
I'm at the point where I'm personally not going to go back more than
four releases, anything more than that is rediculous.
And this time that was 3.17, 3.16, 3.14, and 3.10
^ permalink raw reply
* Re: [PATCH 3.4-stable v2] ipv6: reallocate addrconf router for ipv6 address when lo device up
From: Ben Hutchings @ 2014-10-20 3:14 UTC (permalink / raw)
To: chenweilong
Cc: David Miller, netdev, Greg Kroah-Hartman, stable, Sabrina Dubroca,
Hannes Frederic Sowa, Gao feng, Li Zefan
In-Reply-To: <53E1E4C9.4010006@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]
On Wed, 2014-08-06 at 16:18 +0800, chenweilong wrote:
> It fix the bug 67951 on bugzilla
> https://bugzilla.kernel.org/show_bug.cgi?id=67951
>
> The patch can't be applied directly, as it' used the function introduced
> by "commit 94e187c0" ip6_rt_put(), that patch can't be applied directly
> either.
>
> ====================
>
> From: Gao feng <gaofeng@cn.fujitsu.com>
>
> commit 33d99113b1102c2d2f8603b9ba72d89d915c13f5 upstream.
>
> This commit don't have a stable tag, but it fix the bug
> no reply after loopback down-up.It's very worthy to be
> applied to stable 3.4 kernels.
>
> The bug is 67951 on bugzilla
> https://bugzilla.kernel.org/show_bug.cgi?id=67951
[...]
It looks like this is needed for 3.2.y as well, so I've queued it up.
Thanks.
Ben.
--
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH stable v3.2 v3.4] ipv4: disable bh while doing route gc
From: Ben Hutchings @ 2014-10-20 3:09 UTC (permalink / raw)
To: David Miller; +Cc: mleitner, stable, netdev, hannes
In-Reply-To: <20141013.135127.1915115817707962111.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]
On Mon, 2014-10-13 at 13:51 -0400, David Miller wrote:
> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
> Date: Mon, 13 Oct 2014 14:03:30 -0300
>
> > Further tests revealed that after moving the garbage collector to a work
> > queue and protecting it with a spinlock may leave the system prone to
> > soft lockups if bottom half gets very busy.
> >
> > It was reproced with a set of firewall rules that REJECTed packets. If
> > the NIC bottom half handler ends up running on the same CPU that is
> > running the garbage collector on a very large cache, the garbage
> > collector will not be able to do its job due to the amount of work
> > needed for handling the REJECTs and also won't reschedule.
> >
> > The fix is to disable bottom half during the garbage collecting, as it
> > already was in the first place (most calls to it came from softirqs).
> >
> > Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> > Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Acked-by: David S. Miller <davem@davemloft.net>
> > Cc: stable@vger.kernel.org
>
> -stable folks, please integrate this directly, thanks!
I've appplied this and the previous two patches mentioned ('ipv4: move
route garbage collector to work queue' and 'ipv4: avoid parallel route
cache gc executions'). But I didn't get the other two from you. The
last batch of networking fixes I received and applied was dated
2014-08-07, and the next one I've seen is dated 2014-10-11 and has
nothing for 3.2 or 3.4. Did I miss one between these?
Ben.
--
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* RE: [PATCH net] r8152: use cancel_delayed_work for runtime suspend
From: Hayes Wang @ 2014-10-20 2:19 UTC (permalink / raw)
To: Oliver Neukum
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, nic_swsd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1413661699.19391.2.camel-AfvqVibwNMkMNNZnWhT/Jw@public.gmane.org>
Oliver Neukum [mailto:oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org]
> Sent: Sunday, October 19, 2014 3:48 AM
[...]
> The diagnosis is good, the fix is not good. It opens a race
> during which the queued work can touch a suspended device.
The delayed work would wake up the device by
calling usb_autopm_get_interface() before
accessing the device. Besides, there is a mutex
to avoid the race.
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2014-10-20 1:03 UTC (permalink / raw)
To: torvalds; +Cc: pablo, akpm, netdev, linux-kernel
In-Reply-To: <CA+55aFz4UdVbZKPKwkesj0=1Yu7jLDP3Q3-jwe45b7gRU+0rog@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun, 19 Oct 2014 17:32:15 -0700
> Looks like the module license issue was just overlooked when moving
> the code out in commit c8d7b98bec43 ("netfilter: move nf_send_resetX()
> code to nf_reject_ipvX modules").
I think Pablo has a patch pending to address this, and indeed he does:
http://marc.info/?l=linux-netdev&m=141293491712312&w=2
Pablo please push this to me soon, thanks.
^ permalink raw reply
* Re: [PATCH 2/4] net: make skb_gso_segment error handling more robust
From: David Miller @ 2014-10-20 0:39 UTC (permalink / raw)
To: fw; +Cc: netdev, edumazet
In-Reply-To: <1413751340-19621-3-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Sun, 19 Oct 2014 22:42:19 +0200
> skb_gso_segment has three possible return values:
> 1. a pointer to the first segmented skb
> 2. an errno value (IS_ERR())
> 3. NULL. This can happen when GSO is used for header verification.
>
> However, several callers currently test IS_ERR instead of IS_ERR_OR_NULL
> and would oops when NULL is returned.
>
> Note that these call sites should never actually see such a NULL return
> value; all callers mask out the GSO bits in the feature argument.
>
> However, in the past, there have been issues with some protocol handlers
> erronously not respecting the specified feature mask in some cases.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
I don't think it makes sense to return PTR_ERR(p) when
p is NULL.
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2014-10-20 0:32 UTC (permalink / raw)
To: David Miller, Pablo Neira Ayuso
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List
In-Reply-To: <20141019.132314.264021750039480460.davem@davemloft.net>
On Sun, Oct 19, 2014 at 10:23 AM, David Miller <davem@davemloft.net> wrote:
>
> A quick batch of bug fixes:
Ho humm.. Here's another networking issue with the current kernel:
nf_reject_ipv6: module license 'unspecified' taints kernel.
Disabling lock debugging due to kernel taint
nf_reject_ipv6: Unknown symbol ip6_local_out (err 0)
Hmm? I'm not sure this is new, but I hadn't noticed it before. The
"unknown symbol" seems to be simply because ip6_local_out is GPL-only,
and without a proper license, 'nf_reject_ipv6' not only taints the
kernel but doesn't link properly..
Looks like the module license issue was just overlooked when moving
the code out in commit c8d7b98bec43 ("netfilter: move nf_send_resetX()
code to nf_reject_ipvX modules").
Linus
^ permalink raw reply
* Re: [PATCH 0/3] net: minor gso encapsulation fixes
From: Florian Westphal @ 2014-10-19 20:55 UTC (permalink / raw)
To: netdev
In-Reply-To: <1413751340-19621-1-git-send-email-fw@strlen.de>
Florian Westphal <fw@strlen.de> wrote:
> The following series fixes a minor bug in the gro segmentation handlers
> when handling encapsulation offloads.
In case you're wondering, 'is there a 4th patch in this series'?
There was, I intentionally did not send it (IMO its -next material)
but forgot to adjust the "PATCH x/y" part of the subject lines.
^ permalink raw reply
* [PATCH 3/4] net: core: handle encapsulation offloads when computing segment lengths
From: Florian Westphal @ 2014-10-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: edumazet, Florian Westphal
In-Reply-To: <1413751340-19621-1-git-send-email-fw@strlen.de>
if ->encapsulation is set we have to use inner_tcp_hdrlen and add the
size of the inner network headers too.
This is 'mostly harmless'; tbf might send skb that is slightly over
quota or drop skb even if it would have fit.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/core/skbuff.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7b3df0d..eb4b48b 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4059,15 +4059,22 @@ EXPORT_SYMBOL_GPL(skb_scrub_packet);
unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)
{
const struct skb_shared_info *shinfo = skb_shinfo(skb);
+ unsigned int thlen = 0;
- if (likely(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)))
- return tcp_hdrlen(skb) + shinfo->gso_size;
+ if (skb->encapsulation) {
+ thlen = skb_inner_transport_header(skb) -
+ skb_transport_header(skb);
+ if (likely(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)))
+ thlen += inner_tcp_hdrlen(skb);
+ } else if (likely(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))) {
+ thlen = tcp_hdrlen(skb);
+ }
/* UFO sets gso_size to the size of the fragmentation
* payload, i.e. the size of the L4 (UDP) header is already
* accounted for.
*/
- return shinfo->gso_size;
+ return thlen + shinfo->gso_size;
}
EXPORT_SYMBOL_GPL(skb_gso_transport_seglen);
--
2.0.4
^ permalink raw reply related
* [PATCH 2/4] net: make skb_gso_segment error handling more robust
From: Florian Westphal @ 2014-10-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: edumazet, Florian Westphal
In-Reply-To: <1413751340-19621-1-git-send-email-fw@strlen.de>
skb_gso_segment has three possible return values:
1. a pointer to the first segmented skb
2. an errno value (IS_ERR())
3. NULL. This can happen when GSO is used for header verification.
However, several callers currently test IS_ERR instead of IS_ERR_OR_NULL
and would oops when NULL is returned.
Note that these call sites should never actually see such a NULL return
value; all callers mask out the GSO bits in the feature argument.
However, in the past, there have been issues with some protocol handlers
erronously not respecting the specified feature mask in some cases.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/ipv4/ip_output.c | 2 +-
net/netfilter/nfnetlink_queue_core.c | 2 +-
net/openvswitch/datapath.c | 2 +-
net/xfrm/xfrm_output.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index e35b712..88a0ee3 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -231,7 +231,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)
*/
features = netif_skb_features(skb);
segs = skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK);
- if (IS_ERR(segs)) {
+ if (IS_ERR_OR_NULL(segs)) {
kfree_skb(skb);
return -ENOMEM;
}
diff --git a/net/netfilter/nfnetlink_queue_core.c b/net/netfilter/nfnetlink_queue_core.c
index a82077d..7c60ccd 100644
--- a/net/netfilter/nfnetlink_queue_core.c
+++ b/net/netfilter/nfnetlink_queue_core.c
@@ -665,7 +665,7 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)
* returned by nf_queue. For instance, callers rely on -ECANCELED to
* mean 'ignore this hook'.
*/
- if (IS_ERR(segs))
+ if (IS_ERR_OR_NULL(segs))
goto out_err;
queued = 0;
err = 0;
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 2e31d9e..f98f708 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -322,7 +322,7 @@ static int queue_gso_packets(struct datapath *dp, struct sk_buff *skb,
int err;
segs = __skb_gso_segment(skb, NETIF_F_SG, false);
- if (IS_ERR(segs))
+ if (IS_ERR_OR_NULL(segs))
return PTR_ERR(segs);
/* Queue all of the segments. */
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 499d6c1..eef4334 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -155,7 +155,7 @@ static int xfrm_output_gso(struct sk_buff *skb)
segs = skb_gso_segment(skb, 0);
kfree_skb(skb);
- if (IS_ERR(segs))
+ if (IS_ERR_OR_NULL(segs))
return PTR_ERR(segs);
do {
--
2.0.4
^ permalink raw reply related
* [PATCH 1/4] net: gso: use feature flag argument in all protocol gso handlers
From: Florian Westphal @ 2014-10-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: edumazet, Florian Westphal, Pravin B Shelar
In-Reply-To: <1413751340-19621-1-git-send-email-fw@strlen.de>
skb_gso_segment() has a 'features' argument representing offload features
available to the output path.
A few handlers, e.g. GRE, instead re-fetch the features of skb->dev and use
those instead of the provided ones when handing encapsulation/tunnels.
Depending on dev->hw_enc_features of the output device skb_gso_segment() can
then return NULL even when the caller has disabled all GSO feature bits,
as segmentation of inner header thinks device will take care of segmentation.
This e.g. affects the tbf scheduler, which will silently drop GRE-encap GSO skbs
that did not fit the remaining token quota as the segmentation does not work
when device supports corresponding hw offload capabilities.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/ipv4/af_inet.c | 2 +-
net/ipv4/gre_offload.c | 2 +-
net/ipv4/udp_offload.c | 2 +-
net/ipv6/ip6_offload.c | 2 +-
net/mpls/mpls_gso.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 92db7a6..8b7fe5b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1246,7 +1246,7 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
encap = SKB_GSO_CB(skb)->encap_level > 0;
if (encap)
- features = skb->dev->hw_enc_features & netif_skb_features(skb);
+ features &= skb->dev->hw_enc_features;
SKB_GSO_CB(skb)->encap_level += ihl;
skb_reset_transport_header(skb);
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index a777295..e084534 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -68,7 +68,7 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
skb->mac_len = skb_inner_network_offset(skb);
/* segment inner packet. */
- enc_features = skb->dev->hw_enc_features & netif_skb_features(skb);
+ enc_features = skb->dev->hw_enc_features & features;
segs = skb_mac_gso_segment(skb, enc_features);
if (IS_ERR_OR_NULL(segs)) {
skb_gso_error_unwind(skb, protocol, ghl, mac_offset, mac_len);
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 507310e..6480cea 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -58,7 +58,7 @@ static struct sk_buff *__skb_udp_tunnel_segment(struct sk_buff *skb,
skb->encap_hdr_csum = 1;
/* segment inner packet. */
- enc_features = skb->dev->hw_enc_features & netif_skb_features(skb);
+ enc_features = skb->dev->hw_enc_features & features;
segs = gso_inner_segment(skb, enc_features);
if (IS_ERR_OR_NULL(segs)) {
skb_gso_error_unwind(skb, protocol, tnl_hlen, mac_offset,
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 9034f76..820cdb1 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -89,7 +89,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
encap = SKB_GSO_CB(skb)->encap_level > 0;
if (encap)
- features = skb->dev->hw_enc_features & netif_skb_features(skb);
+ features &= skb->dev->hw_enc_features;
SKB_GSO_CB(skb)->encap_level += sizeof(*ipv6h);
ipv6h = ipv6_hdr(skb);
diff --git a/net/mpls/mpls_gso.c b/net/mpls/mpls_gso.c
index e28ed2e..f0f5309 100644
--- a/net/mpls/mpls_gso.c
+++ b/net/mpls/mpls_gso.c
@@ -48,7 +48,7 @@ static struct sk_buff *mpls_gso_segment(struct sk_buff *skb,
__skb_push(skb, skb->mac_len);
/* Segment inner packet. */
- mpls_features = skb->dev->mpls_features & netif_skb_features(skb);
+ mpls_features = skb->dev->mpls_features & features;
segs = skb_mac_gso_segment(skb, mpls_features);
--
2.0.4
^ permalink raw reply related
* [PATCH 0/3] net: minor gso encapsulation fixes
From: Florian Westphal @ 2014-10-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: edumazet
The following series fixes a minor bug in the gro segmentation handlers
when handling encapsulation offloads.
Theoretically this could cause kernel panic when the stack tries
to software-segment such a GRE offload packet, but it looks like there
is only one affected call site (tbf scheduler) and it handles NULL
return value.
I've included a followup patch to add IS_ERR_OR_NULL checks to all
the various skb_gso_segment call sites.
While looking into this, I also found that size computation of the individual
segments is incorrect as we do not consider skb->encapsulation.
core/skbuff.c | 13 ++++++++++---
ipv4/af_inet.c | 2 +-
ipv4/gre_offload.c | 2 +-
ipv4/ip_output.c | 2 +-
ipv4/udp_offload.c | 2 +-
ipv6/ip6_offload.c | 2 +-
mpls/mpls_gso.c | 2 +-
netfilter/nfnetlink_queue_core.c | 2 +-
openvswitch/datapath.c | 2 +-
xfrm/xfrm_output.c | 2 +-
10 files changed, 19 insertions(+), 12 deletions(-)
^ permalink raw reply
* qdisc running
From: Jamal Hadi Salim @ 2014-10-19 19:24 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: john Fastabend, Herbert Xu, netdev@vger.kernel.org, eric Dumazet
Jesper,
You asked at the meeting the point to qdisc running.
Original intent is to allow only one cpu to enter the lower half of the
qdisc path. IOW, if one cpu was already in the qdisc then that guy
could be used to dequeue packets. i.e this is good for batching.
Original idea was Herbert's with major improvement from Eric
and a small one from me.
For history of different tried approaches look at:
Look at slide 2:
http://vger.kernel.org/netconf2011_slides/jamal_netconf2011.pdf
then download the **amazing** flash animations which describe
that history.
http://vger.kernel.org/netconf2011_slides/netconf-2011-flash.tgz
Follow the bullets in slide2 and map to the flash animations.
If you go over them, you'll see it is still needed.
I think someone oughta put those **amazing** animations on some
website;->
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] ipv6: tcp_v6_iff: fix compilation error on CONFIG_IPV6=n
From: Eric Dumazet @ 2014-10-19 18:50 UTC (permalink / raw)
To: Manfred Schlaegl; +Cc: David S. Miller, netdev, linux-kernel, Manfred Schlaegl
In-Reply-To: <5443FD47.7040003@gmx.at>
On Sun, 2014-10-19 at 20:04 +0200, Manfred Schlaegl wrote:
> If CONFIG_IPV6=n, then h6 in struct tcp_skb_cb.header is missing which
> leads to compilation-errors on tcp_v6_iff like:
>
> In file included from net/core/sock.c:140:0:
> include/net/tcp.h: In function ‘tcp_v6_iif’:
> include/net/tcp.h:738:32: error: ‘union <anonymous>’ has no member named
> ‘h6’
>
> This fix solves the problem by removing tcp_v6_iif, in case of
> CONFIG_IPV6=n.
>
> Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
> ---
Yes, this was fixed yesterday, thanks.
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=815afe1785da727ee48cd8e63ac4a3ec6c7459b3
^ permalink raw reply
* [PATCH] ipv6: tcp_v6_iff: fix compilation error on CONFIG_IPV6=n
From: Manfred Schlaegl @ 2014-10-19 18:04 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Manfred Schlaegl
If CONFIG_IPV6=n, then h6 in struct tcp_skb_cb.header is missing which
leads to compilation-errors on tcp_v6_iff like:
In file included from net/core/sock.c:140:0:
include/net/tcp.h: In function ‘tcp_v6_iif’:
include/net/tcp.h:738:32: error: ‘union <anonymous>’ has no member named
‘h6’
This fix solves the problem by removing tcp_v6_iif, in case of
CONFIG_IPV6=n.
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
---
include/net/tcp.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c9766f8..4062b4f 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -730,6 +730,7 @@ struct tcp_skb_cb {
#define TCP_SKB_CB(__skb) ((struct tcp_skb_cb *)&((__skb)->cb[0]))
+#if IS_ENABLED(CONFIG_IPV6)
/* This is the variant of inet6_iif() that must be used by TCP,
* as TCP moves IP6CB into a different location in skb->cb[]
*/
@@ -737,6 +738,7 @@ static inline int tcp_v6_iif(const struct sk_buff *skb)
{
return TCP_SKB_CB(skb)->header.h6.iif;
}
+#endif
/* Due to TSO, an SKB can be composed of multiple actual
* packets. To keep these tracked properly, we use this.
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] net: s6gmac: remove driver
From: David Miller @ 2014-10-19 17:28 UTC (permalink / raw)
To: jcmvbkbc; +Cc: dg, netdev, linux-kernel
In-Reply-To: <CAMo8BfJ-wvDoDmm+HLHvC3VRUshdqU4eJchOGYt_YJsUktap8Q@mail.gmail.com>
From: Max Filippov <jcmvbkbc@gmail.com>
Date: Sun, 19 Oct 2014 21:26:05 +0400
> On Sun, Oct 19, 2014 at 8:45 PM, David Miller <davem@davemloft.net> wrote:
>> From: Daniel Glöckner <dg@emlix.com>
>> Date: Sun, 19 Oct 2014 00:49:05 +0200
>>
>>> The s6000 Xtensa support is removed from the kernel. There are no
>>> other chips using this driver.
>>
>> That's not what I see in Linus's current tree:
>
> David, s6000 removal is queued for 3.18.
Then there is zero reason for me to apply this to my networking
tree.
^ permalink raw reply
* Re: [PATCH] net: s6gmac: remove driver
From: Max Filippov @ 2014-10-19 17:26 UTC (permalink / raw)
To: David Miller; +Cc: Daniel Glöckner, netdev, LKML
In-Reply-To: <20141019.124542.141206969262552652.davem@davemloft.net>
On Sun, Oct 19, 2014 at 8:45 PM, David Miller <davem@davemloft.net> wrote:
> From: Daniel Glöckner <dg@emlix.com>
> Date: Sun, 19 Oct 2014 00:49:05 +0200
>
>> The s6000 Xtensa support is removed from the kernel. There are no
>> other chips using this driver.
>
> That's not what I see in Linus's current tree:
David, s6000 removal is queued for 3.18.
--
Thanks.
-- Max
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2014-10-19 17:23 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
A quick batch of bug fixes:
1) Fix build with IPV6 disabled, from Eric Dumazet.
2) Several more cases of caching SKB data pointers across
calls to pskb_may_pull(), thus referencing potentially
free'd memory. From Li RongQing.
3) DSA phy code tests operation presence improperly, instead
of going:
if (x->ops->foo)
r = x->ops->foo(args);
it was going:
if (x->ops->foo(args))
r = x->ops->foo(args);
Fix from Andew Lunn.
Please pull, thanks a lot.
The following changes since commit f2d9da1a8375cbe53df5b415d059429013a3a79f:
bna: fix skb->truesize underestimation (2014-10-17 23:56:33 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to 228b16cb13dfa2f77354a9b144a07e86e2dda01c:
Net: DSA: Fix checking for get_phy_flags function (2014-10-19 12:46:31 -0400)
----------------------------------------------------------------
Andrew Lunn (1):
Net: DSA: Fix checking for get_phy_flags function
Eric Dumazet (1):
tcp: fix build error if IPv6 is not enabled
Li RongQing (3):
ipv4: fix a potential use after free in gre_offload.c
ipv6: fix a potential use after free in ip6_offload.c
ipv6: fix a potential use after free in sit.c
include/net/tcp.h | 2 ++
net/dsa/slave.c | 2 +-
net/ipv4/gre_offload.c | 6 +++---
net/ipv6/ip6_offload.c | 1 +
net/ipv6/sit.c | 6 +++---
5 files changed, 10 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: Fw: [Bug 86531] New: Kernel panic when using nmap
From: Alexei Starovoitov @ 2014-10-19 16:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20141019221149.2b590638@uryu.home.lan>
On Sun, Oct 19, 2014 at 6:41 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
>
> Begin forwarded message:
>
> Date: Sun, 19 Oct 2014 08:02:37 -0700
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 86531] New: Kernel panic when using nmap
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=86531
>
> Bug ID: 86531
> Summary: Kernel panic when using nmap
> Product: Networking
> Version: 2.5
> Kernel Version: 3.17.1
> Hardware: x86-64
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> Assignee: shemminger@linux-foundation.org
> Reporter: alxchk@gmail.com
> Regression: No
>
> Created attachment 154181
> --> https://bugzilla.kernel.org/attachment.cgi?id=154181&action=edit
> Crash log #1
>
> Strange crash appears the second time this day for me, when I starting nmap for
> scanning. Couldn't find any dependency. Anyway, dumps attached.
that's fixed in net tree and already in Linus's as well:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e0ee9c12157dc74e49e4731e0d07512e7d1ceb95
^ permalink raw reply
* Re: [PATCH v2] Net: DSA: Fix checking for get_phy_flags function
From: David Miller @ 2014-10-19 16:46 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, netdev
In-Reply-To: <1413729707-1682-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 19 Oct 2014 16:41:47 +0200
> The check for the presence or not of the optional switch function
> get_phy_flags() called the function, rather than checked to see if it
> is a NULL pointer. This causes a derefernce of a NULL pointer on all
> switch chips except the sf2, the only switch to implement this call.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Fixes: 6819563e646a ("net: dsa: allow switch drivers to specify phy_device::dev_flags")
> Cc: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: s6gmac: remove driver
From: David Miller @ 2014-10-19 16:45 UTC (permalink / raw)
To: dg; +Cc: netdev, linux-kernel
In-Reply-To: <1413672545-8535-1-git-send-email-dg@emlix.com>
From: Daniel Glöckner <dg@emlix.com>
Date: Sun, 19 Oct 2014 00:49:05 +0200
> The s6000 Xtensa support is removed from the kernel. There are no
> other chips using this driver.
That's not what I see in Linus's current tree:
[davem@localhost linux]$ git grep XTENSA_VARIANT_S6000
arch/xtensa/Kconfig:config XTENSA_VARIANT_S6000
arch/xtensa/Kconfig: default "s6000" if XTENSA_VARIANT_S6000
^ 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