* [PATCH V2 0/3] handle polling errors in vhost/vhost_net
From: Jason Wang @ 2013-01-05 9:34 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang
This is an update version of last version to fix the handling of polling errors
in vhost/vhost_net.
Currently, vhost and vhost_net ignores errors of polling which can lead kernel
crashing for buggy/malicious userspace. Fix this by extending the idea of tx
polling state to all other vhost_polls and changing the state only when polling
succeed.
Jason Wang (3):
vhost_net: correct error handling in vhost_net_set_backend()
vhost: handle polling errors
tuntap: don't add to waitqueue when POLLERR
drivers/net/tun.c | 5 +--
drivers/vhost/net.c | 89 ++++++++++++++++++++----------------------------
drivers/vhost/vhost.c | 25 +++++++++++---
drivers/vhost/vhost.h | 11 +++++-
4 files changed, 68 insertions(+), 62 deletions(-)
^ permalink raw reply
* [PATCH V2 3/3] tuntap: don't add to waitqueue when POLLERR
From: Jason Wang @ 2013-01-05 9:34 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang
In-Reply-To: <1357378446-19656-1-git-send-email-jasowang@redhat.com>
Currently, tun_chr_poll() returns POLLERR after waitqueue adding during device
unregistration. This would confuse some of its user such as vhost which assume
when POLLERR is returned, it wasn't added to the waitqueue. Fix this by
returning POLLERR before adding to waitqueue.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index fbd106e..f9c0049 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -886,7 +886,7 @@ static unsigned int tun_chr_poll(struct file *file, poll_table *wait)
struct sock *sk;
unsigned int mask = 0;
- if (!tun)
+ if (!tun || tun->dev->reg_state != NETREG_REGISTERED)
return POLLERR;
sk = tfile->socket.sk;
@@ -903,9 +903,6 @@ static unsigned int tun_chr_poll(struct file *file, poll_table *wait)
sock_writeable(sk)))
mask |= POLLOUT | POLLWRNORM;
- if (tun->dev->reg_state != NETREG_REGISTERED)
- mask = POLLERR;
-
tun_put(tun);
return mask;
}
--
1.7.1
^ permalink raw reply related
* [PATCH V2 2/3] vhost: handle polling errors
From: Jason Wang @ 2013-01-05 9:34 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang
In-Reply-To: <1357378446-19656-1-git-send-email-jasowang@redhat.com>
Currently, polling error were ignored in vhost. This may lead some issues (e.g
kenrel crash when passing a tap fd to vhost before calling TUNSETIFF). Fix this
by:
- extend the idea of vhost_net_poll_state to all kinds of vhost_polls
- change the state only when polling is succeed
- let vhost_poll_start() report errors to the caller. If the polling fails in
ioctls, the error would be report to userspace. If the polling fails in the
data path, an error message would be logged.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 75 +++++++++++++++++-------------------------------
drivers/vhost/vhost.c | 25 +++++++++++++---
drivers/vhost/vhost.h | 11 ++++++-
3 files changed, 57 insertions(+), 54 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index d10ad6f..a8ed8e6 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -64,20 +64,10 @@ enum {
VHOST_NET_VQ_MAX = 2,
};
-enum vhost_net_poll_state {
- VHOST_NET_POLL_DISABLED = 0,
- VHOST_NET_POLL_STARTED = 1,
- VHOST_NET_POLL_STOPPED = 2,
-};
-
struct vhost_net {
struct vhost_dev dev;
struct vhost_virtqueue vqs[VHOST_NET_VQ_MAX];
struct vhost_poll poll[VHOST_NET_VQ_MAX];
- /* Tells us whether we are polling a socket for TX.
- * We only do this when socket buffer fills up.
- * Protected by tx vq lock. */
- enum vhost_net_poll_state tx_poll_state;
/* Number of TX recently submitted.
* Protected by tx vq lock. */
unsigned tx_packets;
@@ -155,24 +145,6 @@ static void copy_iovec_hdr(const struct iovec *from, struct iovec *to,
}
}
-/* Caller must have TX VQ lock */
-static void tx_poll_stop(struct vhost_net *net)
-{
- if (likely(net->tx_poll_state != VHOST_NET_POLL_STARTED))
- return;
- vhost_poll_stop(net->poll + VHOST_NET_VQ_TX);
- net->tx_poll_state = VHOST_NET_POLL_STOPPED;
-}
-
-/* Caller must have TX VQ lock */
-static void tx_poll_start(struct vhost_net *net, struct socket *sock)
-{
- if (unlikely(net->tx_poll_state != VHOST_NET_POLL_STOPPED))
- return;
- vhost_poll_start(net->poll + VHOST_NET_VQ_TX, sock->file);
- net->tx_poll_state = VHOST_NET_POLL_STARTED;
-}
-
/* In case of DMA done not in order in lower device driver for some reason.
* upend_idx is used to track end of used idx, done_idx is used to track head
* of used idx. Once lower device DMA done contiguously, we will signal KVM
@@ -227,6 +199,7 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success)
static void handle_tx(struct vhost_net *net)
{
struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
+ struct vhost_poll *poll = net->poll + VHOST_NET_VQ_TX;
unsigned out, in, s;
int head;
struct msghdr msg = {
@@ -252,7 +225,8 @@ static void handle_tx(struct vhost_net *net)
wmem = atomic_read(&sock->sk->sk_wmem_alloc);
if (wmem >= sock->sk->sk_sndbuf) {
mutex_lock(&vq->mutex);
- tx_poll_start(net, sock);
+ if (vhost_poll_start(poll, sock->file))
+ vq_err(vq, "Fail to poll TX\n");
mutex_unlock(&vq->mutex);
return;
}
@@ -261,7 +235,7 @@ static void handle_tx(struct vhost_net *net)
vhost_disable_notify(&net->dev, vq);
if (wmem < sock->sk->sk_sndbuf / 2)
- tx_poll_stop(net);
+ vhost_poll_stop(poll);
hdr_size = vq->vhost_hlen;
zcopy = vq->ubufs;
@@ -283,7 +257,10 @@ static void handle_tx(struct vhost_net *net)
wmem = atomic_read(&sock->sk->sk_wmem_alloc);
if (wmem >= sock->sk->sk_sndbuf * 3 / 4) {
- tx_poll_start(net, sock);
+ if (vhost_poll_start(poll, sock->file)) {
+ vq_err(vq, "Fail to poll TX\n");
+ break;
+ }
set_bit(SOCK_ASYNC_NOSPACE, &sock->flags);
break;
}
@@ -294,7 +271,10 @@ static void handle_tx(struct vhost_net *net)
(vq->upend_idx - vq->done_idx) :
(vq->upend_idx + UIO_MAXIOV - vq->done_idx);
if (unlikely(num_pends > VHOST_MAX_PEND)) {
- tx_poll_start(net, sock);
+ if (vhost_poll_start(poll, sock->file)) {
+ vq_err(vq, "Fail to poll TX\n");
+ break;
+ }
set_bit(SOCK_ASYNC_NOSPACE, &sock->flags);
break;
}
@@ -360,7 +340,8 @@ static void handle_tx(struct vhost_net *net)
}
vhost_discard_vq_desc(vq, 1);
if (err == -EAGAIN || err == -ENOBUFS)
- tx_poll_start(net, sock);
+ if (vhost_poll_start(poll, sock->file))
+ vq_err(vq, "fail to poll TX\n");
break;
}
if (err != len)
@@ -623,7 +604,6 @@ static int vhost_net_open(struct inode *inode, struct file *f)
vhost_poll_init(n->poll + VHOST_NET_VQ_TX, handle_tx_net, POLLOUT, dev);
vhost_poll_init(n->poll + VHOST_NET_VQ_RX, handle_rx_net, POLLIN, dev);
- n->tx_poll_state = VHOST_NET_POLL_DISABLED;
f->private_data = n;
@@ -633,29 +613,26 @@ static int vhost_net_open(struct inode *inode, struct file *f)
static void vhost_net_disable_vq(struct vhost_net *n,
struct vhost_virtqueue *vq)
{
+ int index = vq - n->vqs;
if (!vq->private_data)
return;
- if (vq == n->vqs + VHOST_NET_VQ_TX) {
- tx_poll_stop(n);
- n->tx_poll_state = VHOST_NET_POLL_DISABLED;
- } else
- vhost_poll_stop(n->poll + VHOST_NET_VQ_RX);
+ vhost_poll_stop(n->poll + index);
}
-static void vhost_net_enable_vq(struct vhost_net *n,
- struct vhost_virtqueue *vq)
+static int vhost_net_enable_vq(struct vhost_net *n,
+ struct vhost_virtqueue *vq)
{
+ int err, index = vq - n->vqs;
struct socket *sock;
sock = rcu_dereference_protected(vq->private_data,
lockdep_is_held(&vq->mutex));
if (!sock)
- return;
- if (vq == n->vqs + VHOST_NET_VQ_TX) {
- n->tx_poll_state = VHOST_NET_POLL_STOPPED;
- tx_poll_start(n, sock);
- } else
- vhost_poll_start(n->poll + VHOST_NET_VQ_RX, sock->file);
+ return 0;
+
+ n->poll[index].state = VHOST_POLL_STOPPED;
+ err = vhost_poll_start(n->poll + index, sock->file);
+ return err;
}
static struct socket *vhost_net_stop_vq(struct vhost_net *n,
@@ -833,7 +810,9 @@ static long vhost_net_set_backend(struct vhost_net *n, unsigned index, int fd)
r = vhost_init_used(vq);
if (r)
goto err_used;
- vhost_net_enable_vq(n, vq);
+ r = vhost_net_enable_vq(n, vq);
+ if (r)
+ goto err_used;
oldubufs = vq->ubufs;
vq->ubufs = ubufs;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 34389f7..5464ee4 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -77,26 +77,39 @@ void vhost_poll_init(struct vhost_poll *poll, vhost_work_fn_t fn,
init_poll_funcptr(&poll->table, vhost_poll_func);
poll->mask = mask;
poll->dev = dev;
+ poll->state = VHOST_POLL_DISABLED;
vhost_work_init(&poll->work, fn);
}
-/* Start polling a file. We add ourselves to file's wait queue. The caller must
- * keep a reference to a file until after vhost_poll_stop is called. */
-void vhost_poll_start(struct vhost_poll *poll, struct file *file)
+/* Start polling a file. We try to add ourselves to file's wait queue. The
+ * caller must keep a reference to a file until after vhost_poll_stop is
+ * called. The file must guarantee that ourselves were not added to the
+ * waitqueue when POLLERR were returned by poll(), vhost_poll_stop() depends on
+ * this behavior. */
+int vhost_poll_start(struct vhost_poll *poll, struct file *file)
{
unsigned long mask;
+ if (unlikely(poll->state != VHOST_POLL_STOPPED))
+ return 0;
mask = file->f_op->poll(file, &poll->table);
+ if (mask & POLLERR)
+ return -EINVAL;
if (mask)
vhost_poll_wakeup(&poll->wait, 0, 0, (void *)mask);
+ poll->state = VHOST_POLL_STARTED;
+ return 0;
}
/* Stop polling a file. After this function returns, it becomes safe to drop the
* file reference. You must also flush afterwards. */
void vhost_poll_stop(struct vhost_poll *poll)
{
+ if (likely(poll->state != VHOST_POLL_STARTED))
+ return;
remove_wait_queue(poll->wqh, &poll->wait);
+ poll->state = VHOST_POLL_STOPPED;
}
static bool vhost_work_seq_done(struct vhost_dev *dev, struct vhost_work *work,
@@ -791,8 +804,10 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp)
if (filep)
fput(filep);
- if (pollstart && vq->handle_kick)
- vhost_poll_start(&vq->poll, vq->kick);
+ if (pollstart && vq->handle_kick) {
+ vq->poll.state = VHOST_POLL_STOPPED;
+ r = vhost_poll_start(&vq->poll, vq->kick);
+ }
mutex_unlock(&vq->mutex);
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 2639c58..4eb06e9 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -26,6 +26,12 @@ struct vhost_work {
unsigned done_seq;
};
+enum vhost_poll_state {
+ VHOST_POLL_DISABLED = 0,
+ VHOST_POLL_STARTED = 1,
+ VHOST_POLL_STOPPED = 2,
+};
+
/* Poll a file (eventfd or socket) */
/* Note: there's nothing vhost specific about this structure. */
struct vhost_poll {
@@ -35,6 +41,9 @@ struct vhost_poll {
struct vhost_work work;
unsigned long mask;
struct vhost_dev *dev;
+ /* Tells us whether we are polling a file.
+ * Protected by vq lock. */
+ enum vhost_poll_state state;
};
void vhost_work_init(struct vhost_work *work, vhost_work_fn_t fn);
@@ -42,7 +51,7 @@ void vhost_work_queue(struct vhost_dev *dev, struct vhost_work *work);
void vhost_poll_init(struct vhost_poll *poll, vhost_work_fn_t fn,
unsigned long mask, struct vhost_dev *dev);
-void vhost_poll_start(struct vhost_poll *poll, struct file *file);
+int vhost_poll_start(struct vhost_poll *poll, struct file *file);
void vhost_poll_stop(struct vhost_poll *poll);
void vhost_poll_flush(struct vhost_poll *poll);
void vhost_poll_queue(struct vhost_poll *poll);
--
1.7.1
^ permalink raw reply related
* [PATCH V2 1/3] vhost_net: correct error handling in vhost_net_set_backend()
From: Jason Wang @ 2013-01-05 9:34 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang
In-Reply-To: <1357378446-19656-1-git-send-email-jasowang@redhat.com>
Currently, when vhost_init_used() fails the sock refcnt and ubufs were
leaked. Correct this by calling vhost_init_used() before assigning ubufs and
restoring the oldsock when it fails.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index ebd08b2..d10ad6f 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -827,15 +827,16 @@ static long vhost_net_set_backend(struct vhost_net *n, unsigned index, int fd)
r = PTR_ERR(ubufs);
goto err_ubufs;
}
- oldubufs = vq->ubufs;
- vq->ubufs = ubufs;
+
vhost_net_disable_vq(n, vq);
rcu_assign_pointer(vq->private_data, sock);
- vhost_net_enable_vq(n, vq);
-
r = vhost_init_used(vq);
if (r)
- goto err_vq;
+ goto err_used;
+ vhost_net_enable_vq(n, vq);
+
+ oldubufs = vq->ubufs;
+ vq->ubufs = ubufs;
n->tx_packets = 0;
n->tx_zcopy_err = 0;
@@ -859,6 +860,11 @@ static long vhost_net_set_backend(struct vhost_net *n, unsigned index, int fd)
mutex_unlock(&n->dev.mutex);
return 0;
+err_used:
+ rcu_assign_pointer(vq->private_data, oldsock);
+ vhost_net_enable_vq(n, vq);
+ if (ubufs)
+ vhost_ubuf_put_and_wait(ubufs);
err_ubufs:
fput(sock->file);
err_vq:
--
1.7.1
^ permalink raw reply related
* [3.8-rc] regression: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
From: Jörg Otte @ 2013-01-05 9:01 UTC (permalink / raw)
To: Linux Kernel Mailing List, David S. Miller, Francois Romieu,
netdev
I frequently see the following in the syslog:
[ 184.552914] ------------[ cut here ]------------
[ 184.552927] WARNING: at
/data/kernel/linux/net/sched/sch_generic.c:254
dev_watchdog+0xf2/0x151()
[ 184.552929] Hardware name: LIFEBOOK AH532
[ 184.552932] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
[ 184.552937] Pid: 0, comm: swapper/1 Not tainted
3.8.0-rc2-b11-00221-gd1c3ed6 #15
[ 184.552939] Call Trace:
[ 184.552941] <IRQ> [<ffffffff8138d4a2>] ? dev_watchdog+0xf2/0x151
[ 184.552953] [<ffffffff81025c8a>] ? warn_slowpath_common+0x73/0x87
[ 184.552956] [<ffffffff8138d3b0>] ? netif_tx_unlock+0x49/0x49
[ 184.552961] [<ffffffff81025d02>] ? warn_slowpath_fmt+0x45/0x4a
[ 184.552967] [<ffffffff8138d332>] ? netif_tx_lock+0x40/0x75
[ 184.552971] [<ffffffff8138d4a2>] ? dev_watchdog+0xf2/0x151
[ 184.552977] [<ffffffff8102f1a1>] ? call_timer_fn.isra.32+0x1d/0x73
[ 184.552981] [<ffffffff8102f34b>] ? run_timer_softirq+0x154/0x194
[ 184.552988] [<ffffffff8104cb84>] ? timekeeping_get_ns.constprop.6+0xd/0x31
[ 184.552992] [<ffffffff8102b4a5>] ? __do_softirq+0x96/0x139
[ 184.552997] [<ffffffff8146b00c>] ? call_softirq+0x1c/0x26
[ 184.553002] [<ffffffff81003cf4>] ? do_softirq+0x2e/0x62
[ 184.553006] [<ffffffff8102b615>] ? irq_exit+0x3d/0x98
[ 184.553011] [<ffffffff810184ad>] ? smp_apic_timer_interrupt+0x73/0x80
[ 184.553018] [<ffffffff8146aa0a>] ? apic_timer_interrupt+0x6a/0x70
[ 184.553020] <EOI> [<ffffffff81326f2b>] ? cpuidle_wrap_enter+0x38/0x69
[ 184.553033] [<ffffffff81326f27>] ? cpuidle_wrap_enter+0x34/0x69
[ 184.553039] [<ffffffff81326d81>] ? cpuidle_enter_state+0xa/0x31
[ 184.553044] [<ffffffff81326e41>] ? cpuidle_idle_call+0x99/0xb9
[ 184.553050] [<ffffffff81009059>] ? cpu_idle+0x99/0xe0
[ 184.553056] [<ffffffff8145e3a4>] ? start_secondary+0x1d6/0x1dc
[ 184.553059] ---[ end trace 54db26a54b22f673 ]---
[ 184.587487] r8169 0000:02:00.0 eth0: link up
It's a regression, it never happend before 3.8-rc.
-- Jörg
^ permalink raw reply
* Re: [PATCH v2 net-next] softirq: reduce latencies
From: Sedat Dilek @ 2013-01-05 8:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, LKML
[ QUOTE ]
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Jan 2013 23:49:40 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> In various network workloads, __do_softirq() latencies can be up
> to 20 ms if HZ=1000, and 200 ms if HZ=100.
>
> This is because we iterate 10 times in the softirq dispatcher,
> and some actions can consume a lot of cycles.
>
> This patch changes the fallback to ksoftirqd condition to :
>
> - A time limit of 2 ms.
> - need_resched() being set on current task
>
> When one of this condition is met, we wakeup ksoftirqd for further
> softirq processing if we still have pending softirqs.
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
[ /QUOTE ]
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> (against Linux v3.8-rc2)
^ permalink raw reply
* Re: [PATCH 19/19] netfilter: gre: fix resource leak when unregister gre proto
From: Pablo Neira Ayuso @ 2013-01-05 3:50 UTC (permalink / raw)
To: Gao feng; +Cc: netfilter-devel, netdev, canqunzhang, kaber, ebiederm
In-Reply-To: <1356662206-2260-20-git-send-email-gaofeng@cn.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
Hi Gao,
On Fri, Dec 28, 2012 at 10:36:46AM +0800, Gao feng wrote:
> Currectly we unregister proto before all conntrack entries of
> this proto being destroyed. so in function destroy_conntrack
> we can't find proper l4proto to call l4proto->destroy.
> this will cause resource leak.
Good catch.
But better to remove the entries before unregistering the protocol
tracker, so l4proto->destroy is always called.
Patch attached.
[-- Attachment #2: 0001-netfilter-nf_conntrack-fix-memory-leak-during-unregi.patch --]
[-- Type: text/x-diff, Size: 1523 bytes --]
>From 1c082b3ef4c9bf8bfd0159142ce6ffc49aa7bab2 Mon Sep 17 00:00:00 2001
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 4 Jan 2013 22:09:44 +0100
Subject: [PATCH] netfilter: nf_conntrack: fix memory leak during
unregistration with GRE entries
Protocol trackers are unregistered before conntrack entries of that
type are removed. For that reason, l4proto->destroy is never called
and that results in leaking the keymap.
Fix this by releasing entries before unregistering protocols.
Reported-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_proto.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/nf_conntrack_proto.c b/net/netfilter/nf_conntrack_proto.c
index 51e928d..29cd353 100644
--- a/net/netfilter/nf_conntrack_proto.c
+++ b/net/netfilter/nf_conntrack_proto.c
@@ -488,6 +488,9 @@ void nf_conntrack_l4proto_unregister(struct net *net,
{
struct nf_proto_net *pn = NULL;
+ /* Remove all contrack entries before unregistration */
+ nf_ct_iterate_cleanup(net, kill_l4proto, l4proto);
+
if (net == &init_net)
nf_conntrack_l4proto_unregister_net(l4proto);
@@ -497,9 +500,6 @@ void nf_conntrack_l4proto_unregister(struct net *net,
pn->users--;
nf_ct_l4proto_unregister_sysctl(net, pn, l4proto);
-
- /* Remove all contrack entries for this protocol */
- nf_ct_iterate_cleanup(net, kill_l4proto, l4proto);
}
EXPORT_SYMBOL_GPL(nf_conntrack_l4proto_unregister);
--
1.7.10.4
^ permalink raw reply related
* [PATCH] drivers/net: remove orphaned references to micro channel
From: Paul Gortmaker @ 2013-01-05 2:57 UTC (permalink / raw)
To: netdev; +Cc: Paul Gortmaker
We threw away the microchannel support, but the removal wasn't
completely trivial since there was namespace overlap with the
machine check support, and hence some orphaned dependencies
survived the deletion. This attempts to sweep those up and
send them to the bit-bucket.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/ethernet/3com/Kconfig | 6 +++---
drivers/net/ethernet/8390/Kconfig | 9 +++------
drivers/net/ethernet/8390/Makefile | 1 -
drivers/net/ethernet/amd/Kconfig | 4 ++--
drivers/net/ethernet/fujitsu/Kconfig | 4 ++--
drivers/net/ethernet/i825xx/Kconfig | 2 +-
drivers/net/ethernet/intel/Kconfig | 2 +-
7 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/3com/Kconfig b/drivers/net/ethernet/3com/Kconfig
index eb56174..8c417ed 100644
--- a/drivers/net/ethernet/3com/Kconfig
+++ b/drivers/net/ethernet/3com/Kconfig
@@ -5,7 +5,7 @@
config NET_VENDOR_3COM
bool "3Com devices"
default y
- depends on ISA || EISA || MCA || PCI || PCMCIA
+ depends on ISA || EISA || PCI || PCMCIA
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
@@ -33,8 +33,8 @@ config EL1
will be called 3c501.
config EL3
- tristate "3c509/3c529 (MCA)/3c579 \"EtherLink III\" support"
- depends on (ISA || EISA || MCA)
+ tristate "3c509/3c579 \"EtherLink III\" support"
+ depends on (ISA || EISA)
---help---
If you have a network (Ethernet) card belonging to the 3Com
EtherLinkIII series, say Y and read the Ethernet-HOWTO, available
diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index e1219e0..8801217 100644
--- a/drivers/net/ethernet/8390/Kconfig
+++ b/drivers/net/ethernet/8390/Kconfig
@@ -6,8 +6,8 @@ config NET_VENDOR_8390
bool "National Semi-conductor 8390 devices"
default y
depends on NET_VENDOR_NATSEMI && (AMIGA_PCMCIA || PCI || SUPERH || \
- ISA || MCA || EISA || MAC || M32R || MACH_TX49XX || \
- MCA_LEGACY || H8300 || ARM || MIPS || ZORRO || PCMCIA || \
+ ISA || EISA || MAC || M32R || MACH_TX49XX || \
+ H8300 || ARM || MIPS || ZORRO || PCMCIA || \
EXPERIMENTAL)
---help---
If you have a network (Ethernet) card belonging to this class, say Y
@@ -188,10 +188,7 @@ config NE2000
If you have a PCI NE2000 card however, say N here and Y to "PCI
NE2000 and clone support" under "EISA, VLB, PCI and on board
- controllers" below. If you have a NE2000 card and are running on
- an MCA system (a bus system used on some IBM PS/2 computers and
- laptops), say N here and Y to "NE/2 (ne2000 MCA version) support",
- below.
+ controllers" below.
To compile this driver as a module, choose M here. The module
will be called ne.
diff --git a/drivers/net/ethernet/8390/Makefile b/drivers/net/ethernet/8390/Makefile
index f43038b..8fb462c 100644
--- a/drivers/net/ethernet/8390/Makefile
+++ b/drivers/net/ethernet/8390/Makefile
@@ -16,7 +16,6 @@ obj-$(CONFIG_HYDRA) += hydra.o 8390.o
obj-$(CONFIG_LNE390) += lne390.o 8390.o
obj-$(CONFIG_MCF8390) += mcf8390.o 8390.o
obj-$(CONFIG_NE2000) += ne.o 8390p.o
-obj-$(CONFIG_NE2_MCA) += ne2.o 8390p.o
obj-$(CONFIG_NE2K_PCI) += ne2k-pci.o 8390.o
obj-$(CONFIG_NE3210) += ne3210.o 8390.o
obj-$(CONFIG_NE_H8300) += ne-h8300.o 8390.o
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 8350f4b..3046133 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -7,7 +7,7 @@ config NET_VENDOR_AMD
default y
depends on DIO || MACH_DECSTATION || MVME147 || ATARI || SUN3 || \
SUN3X || SBUS || PCI || ZORRO || (ISA && ISA_DMA_API) || \
- (ARM && ARCH_EBSA110) || ISA || EISA || MCA || PCMCIA
+ (ARM && ARCH_EBSA110) || ISA || EISA || PCMCIA
---help---
If you have a network (Ethernet) chipset belonging to this class,
say Y.
@@ -107,7 +107,7 @@ config DECLANCE
config DEPCA
tristate "DEPCA, DE10x, DE200, DE201, DE202, DE422 support"
- depends on (ISA || EISA || MCA)
+ depends on (ISA || EISA)
select CRC32
---help---
If you have a network (Ethernet) card of this type, say Y and read
diff --git a/drivers/net/ethernet/fujitsu/Kconfig b/drivers/net/ethernet/fujitsu/Kconfig
index dffee9d..aca1568 100644
--- a/drivers/net/ethernet/fujitsu/Kconfig
+++ b/drivers/net/ethernet/fujitsu/Kconfig
@@ -5,7 +5,7 @@
config NET_VENDOR_FUJITSU
bool "Fujitsu devices"
default y
- depends on ISA || PCMCIA || ((ISA || MCA_LEGACY) && EXPERIMENTAL)
+ depends on ISA || PCMCIA || (ISA && EXPERIMENTAL)
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
@@ -19,7 +19,7 @@ if NET_VENDOR_FUJITSU
config AT1700
tristate "AT1700/1720 support (EXPERIMENTAL)"
- depends on (ISA || MCA_LEGACY) && EXPERIMENTAL
+ depends on ISA && EXPERIMENTAL
select CRC32
---help---
If you have a network (Ethernet) card of this type, say Y and read
diff --git a/drivers/net/ethernet/i825xx/Kconfig b/drivers/net/ethernet/i825xx/Kconfig
index 959faf7..70f8c2d 100644
--- a/drivers/net/ethernet/i825xx/Kconfig
+++ b/drivers/net/ethernet/i825xx/Kconfig
@@ -6,7 +6,7 @@ config NET_VENDOR_I825XX
bool "Intel (82586/82593/82596) devices"
default y
depends on NET_VENDOR_INTEL && (ISA || ISA_DMA_API || ARM || \
- ARCH_ACORN || MCA || MCA_LEGACY || SNI_RM || SUN3 || \
+ ARCH_ACORN || SNI_RM || SUN3 || \
GSC || BVME6000 || MVME16x || EXPERIMENTAL)
---help---
If you have a network (Ethernet) card belonging to this class, say Y
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index ddee406..bde4f3d 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -6,7 +6,7 @@ config NET_VENDOR_INTEL
bool "Intel devices"
default y
depends on PCI || PCI_MSI || ISA || ISA_DMA_API || ARM || \
- ARCH_ACORN || MCA || MCA_LEGACY || SNI_RM || SUN3 || \
+ ARCH_ACORN || SNI_RM || SUN3 || \
GSC || BVME6000 || MVME16x || \
(ARM && ARCH_IXP4XX && IXP4XX_NPE && IXP4XX_QMGR) || \
EXPERIMENTAL
--
1.8.1
^ permalink raw reply related
* Re: load/unload dccp module caused oops
From: CAI Qian @ 2013-01-05 2:02 UTC (permalink / raw)
To: Christoph Lameter
Cc: netdev, Dave Miller, stable, linux-kernel, Pekka Enberg,
Glauber Costa
In-Reply-To: <0000013c0618832c-11b14217-2010-4cdb-abb3-c1afcbc44145-000000@email.amazonses.com>
----- Original Message -----
> From: "Christoph Lameter" <cl@linux.com>
> To: "CAI Qian" <caiqian@redhat.com>
> Cc: netdev@vger.kernel.org, "Dave Miller" <davem@redhat.com>, stable@vger.kernel.org, "linux-kernel"
> <linux-kernel@vger.kernel.org>, "Pekka Enberg" <penberg@kernel.org>, "Glauber Costa" <glommer@parallels.com>
> Sent: Friday, January 4, 2013 11:05:35 PM
> Subject: Re: load/unload dccp module caused oops
>
> See the fix available here:
>
> https://patchwork.kernel.org/patch/1909861/
Excellent! Thanks Christoph.
Tested-by: CAI Qian <caiqian@redhat.com>
>
>
> On Fri, 4 Jan 2013, CAI Qian wrote:
>
> > The bisecting pointed out this commit fixed the problem in
> > the mainline.
> >
> > 3c58346525d82625e68e24f071804c2dc057b6f4
> > slab: Simplify bootstrap
> >
> > However, simply back-ported this single commit to the 3.7.1
> > stable wasn't enough to fix it. My guess is that there are
> > some other slab/slub commits required to fix this. Keep digging...
> >
> > The kernel config used the SLUB,
> > http://people.redhat.com/qcai/stable/.config
> >
> > CAI Qian
> >
> > ----- Original Message -----
> > > From: "CAI Qian" <caiqian@redhat.com>
> > > To: netdev@vger.kernel.org
> > > Cc: "Dave Miller" <davem@redhat.com>, stable@vger.kernel.org
> > > Sent: Friday, January 4, 2013 9:57:43 AM
> > > Subject: Re: load/unload dccp module caused
> > >
> > > Adding the netdev as Dave suggested.
> > >
> > > ----- Original Message -----
> > > > From: "CAI Qian" <caiqian@redhat.com>
> > > > To: stable@vger.kernel.org
> > > > Cc: "Dave Miller" <davem@redhat.com>
> > > > Sent: Monday, December 31, 2012 5:42:59 PM
> > > > Subject: load/unload dccp module caused
> > > >
> > > > Just a head up that load and then unload the dccp module
> > > > caused an oops below using the current stable kernel - v3.7.1.
> > > > Some additional data point here: the mainline v3.6 release has
> > > > no such problem, so this looks like a regression. The mainline
> > > > v3.8-rc1 also has no such problem, so it looks like it has
> > > > already been fixed there but looks like yet queued up for the
> > > > stable yet (tested a few commits in Greg's stable-queue and
> > > > Dave's net-stable queue did not find anything obvious to fix
> > > > this). I am in-process to bisect to figure out the one that
> > > > need to back-port right now.
> > > >
> > > > [ 93.809573]
> > > > =============================================================================
> > > > [ 93.809577] BUG kmalloc-16 (Tainted: G B ): Objects
> > > > remaining in kmalloc-16 on kmem_cache_close()
> > > > [ 93.809580]
> > > > -----------------------------------------------------------------------------
> > > > [ 93.809580]
> > > > ...
> > > > [ 356.336244] INFO: Object 0xc0000000fa1f0aa0 @offset=2720
> > > > [ 356.336247] INFO: Object 0xc0000000fa1f0ab0 @offset=2736
> > > > [ 356.336249] INFO: Object 0xc0000000fa1f0ac0 @offset=2752
> > > > [ 356.336254] INFO: Object 0xc0000000fa1f0ad0 @offset=2768
> > > > [ 356.336257] INFO: Object 0xc0000000fa1f0ae0 @offset=2784
> > > > [ 356.336259] INFO: Object 0xc0000000fa1f0af0 @offset=2800
> > > > [ 356.336262] INFO: Object 0xc0000000fa1f0b80 @offset=2944
> > > > [ 356.336264] INFO: Object 0xc0000000fa1f0bd0 @offset=3024
> > > > [ 356.336271] INFO: Object 0xc0000000fa1f1870 @offset=6256
> > > > [ 356.336274] INFO: Object 0xc0000000fa1f1880 @offset=6272
> > > > [ 356.336276] INFO: Object 0xc0000000fa1f1890 @offset=6288
> > > > [ 356.346976] INFO: Object 0xc0000000fa1f18a0 @offset=6304
> > > > [ 356.346979] INFO: Object 0xc0000000fa1f18b0 @offset=6320
> > > > [ 356.346981] INFO: Object 0xc0000000fa1f1950 @offset=6480
> > > > [ 356.346986] INFO: Object 0xc0000000fa1f1960 @offset=6496
> > > > [ 356.346989] INFO: Object 0xc0000000fa1f1970 @offset=6512
> > > > [ 356.346991] INFO: Object 0xc0000000fa1f1980 @offset=6528
> > > > [ 356.346994] INFO: Object 0xc0000000fa1f1990 @offset=6544
> > > > [ 356.346997] INFO: Object 0xc0000000fa1f19a0 @offset=6560
> > > > [ 356.346999] INFO: Object 0xc0000000fa1f19b0 @offset=6576
> > > > [ 356.347005] INFO: Object 0xc0000000fa1f19c0 @offset=6592
> > > > [ 356.347008] INFO: Object 0xc0000000fa1f19d0 @offset=6608
> > > > [ 356.347010] INFO: Object 0xc0000000fa1f19e0 @offset=6624
> > > > [ 356.347012] INFO: Object 0xc0000000fa1f19f0 @offset=6640
> > > > [ 356.347081] kmem_cache_destroy kmalloc-16: Slab cache still
> > > > has
> > > > objects
> > > > ...
> > > > [441283.322161] BUG: unable to handle kernel NULL pointer
> > > > dereference
> > > > at (null)
> > > > [441283.331020] IP: [<ffffffff811785f9>]
> > > > __kmem_cache_shutdown+0xa9/0x2f0
> > > > [441283.338320] PGD 105568f067 PUD 104a086067 PMD 0
> > > > [441283.343600] Oops: 0000 [#1] SMP
> > > > [441283.347318] Modules linked in: dccp(-) nf_tproxy_core
> > > > deflate
> > > > zlib_deflate lzo nls_koi8_u nls_cp932 ts_kmp sctp libcrc32c
> > > > binfmt_misc des_generic md4 nls_utf8 cifs dns_resolver sg
> > > > iTCO_wdt
> > > > kvm_intel igb iTCO_vendor_support coretemp kvm crc32c_intel
> > > > lpc_ich
> > > > i7core_edac edac_core i2c_i801 i2c_core mfd_core pcspkr
> > > > microcode
> > > > ioatdma dca sr_mod cdrom ata_generic sd_mod pata_acpi
> > > > crc_t10dif
> > > > ata_piix libata megaraid_sas dm_mirror dm_region_hash dm_log
> > > > dm_mod
> > > > [last unloaded: inet_diag]
> > > > [441283.395187] CPU 6
> > > > [441283.397337] Pid: 40979, comm: modprobe Tainted: G B
> > > > 3.7.1+ #10 QCI QSSC-S4R/QSSC-S4R
> > > > [441283.407245] RIP: 0010:[<ffffffff811785f9>]
> > > > [<ffffffff811785f9>]
> > > > __kmem_cache_shutdown+0xa9/0x2f0
> > > > [441283.417256] RSP: 0018:ffff88205247de08 EFLAGS: 00010292
> > > > [441283.423280] RAX: ffff881059780001 RBX: ffff88085acfa000
> > > > RCX:
> > > > 00000000001c7d72
> > > > [441283.431336] RDX: 00000000001c7d71 RSI: 0000000000000ff0
> > > > RDI:
> > > > ffff88085f802600
> > > > [441283.439394] RBP: ffff88205247de68 R08: 0000000000016940
> > > > R09:
> > > > ffff88105fd36940
> > > > [441283.447451] R10: ffffea004165e000 R11: ffffffff81178721
> > > > R12:
> > > > ffffffffffffffe0
> > > > [441283.455508] R13: ffff88085acf9000 R14: ffff88085f802500
> > > > R15:
> > > > ffffea00216b3e40
> > > > [441283.463565] FS: 00007fd36f206740(0000)
> > > > GS:ffff88105fc20000(0000)
> > > > knlGS:0000000000000000
> > > > [441283.472687] CS: 0010 DS: 0000 ES: 0000 CR0:
> > > > 000000008005003b
> > > > [441283.479194] CR2: 00007fd545ae9c74 CR3: 000000104a273000
> > > > CR4:
> > > > 00000000000007e0
> > > > [441283.487251] DR0: 0000000000000000 DR1: 0000000000000000
> > > > DR2:
> > > > 0000000000000000
> > > > [441283.495308] DR3: 0000000000000000 DR6: 00000000ffff0ff0
> > > > DR7:
> > > > 0000000000000400
> > > > [441283.503366] Process modprobe (pid: 40979, threadinfo
> > > > ffff88205247c000, task ffff8820493fb240)
> > > > [441283.512974] Stack:
> > > > [441283.515312] ffffffffa0169760 ffff8810597800c0
> > > > 0000000000000000
> > > > 0000000000000000
> > > > [441283.523705] ffff88085f8010d0 ffff88085f8010c0
> > > > ffff88205247de68
> > > > ffff88085f802500
> > > > [441283.532104] ffff88085f802568 0000000000000000
> > > > 00000000011ec578
> > > > 0000000000000000
> > > > [441283.540499] Call Trace:
> > > > [441283.543328] [<ffffffff8114993a>]
> > > > kmem_cache_destroy+0x3a/0xe0
> > > > [441283.549941] [<ffffffffa0164c0a>] tfrc_li_exit+0x1a/0x30
> > > > [dccp]
> > > > [441283.556649] [<ffffffffa01635e8>] tfrc_lib_exit+0x18/0x20
> > > > [dccp]
> > > > [441283.563451] [<ffffffffa01583e6>]
> > > > ccid_cleanup_builtins+0x26/0x30
> > > > [dccp]
> > > > [441283.571032] [<ffffffffa0164e33>] dccp_fini+0xe/0x1db
> > > > [dccp]
> > > > [441283.577449] [<ffffffffa0164e25>] ?
> > > > scaled_div.part.0+0x6/0x6
> > > > [dccp]
> > > > [441283.584639] [<ffffffff810bc3fe>]
> > > > sys_delete_module+0x16e/0x2d0
> > > > [441283.591342] [<ffffffff810d851c>] ?
> > > > __audit_syscall_entry+0xcc/0x300
> > > > [441283.598530] [<ffffffff810d8b3c>] ?
> > > > __audit_syscall_exit+0x3ec/0x450
> > > > [441283.605719] [<ffffffff815d3b99>]
> > > > system_call_fastpath+0x16/0x1b
> > > > [441283.612516] Code: 48 39 d7 4d 89 ec 75 41 e9 55 01 00 00 0f
> > > > 1f
> > > > 44
> > > > 00 00 e8 0b f7 16 00 48 8b 55 c8 4c 89 fe 4c 89 f7 48 83 6a 08
> > > > 01
> > > > e8
> > > > 97 c6 ff ff <49> 8b 44 24 20 49 8d 7c 24 20 4d 89 e7 48 83 e8
> > > > 20 48
> > > > 39 7d c0
> > > > [441283.634440] RIP [<ffffffff811785f9>]
> > > > __kmem_cache_shutdown+0xa9/0x2f0
> > > > [441283.641831] RSP <ffff88205247de08>
> > > > [441283.645817] CR2: 0000000000000000
> > > > [441283.649815] ---[ end trace 8e20d31634421a27 ]---
> > > >
> > > > CAI Qian
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe
> > > > stable"
> > > > in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at
> > > > http://vger.kernel.org/majordomo-info.html
> > > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe stable"
> > > in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at
> > > http://vger.kernel.org/majordomo-info.html
> > >
> >
>
^ permalink raw reply
* Re: NULL pointer dereference in veth_stats_one
From: Eric Dumazet @ 2013-01-05 1:42 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Tom Parkin, David Miller, netdev
In-Reply-To: <1357331112.2693.33.camel@bwh-desktop.uk.solarflarecom.com>
From: Eric Dumazet <edumazet@google.com>
On Fri, 2013-01-04 at 20:25 +0000, Ben Hutchings wrote:
> Anything calling dev_get_stats() must have a counted or RCU reference to
> the device, and netdev_run_todo() waits for those to go away. For
> mutually referencing devices we want a kind of weak reference and we
> have no good way to implement those.
OK, so to be on the safe side I added RCU barriers/synchro everywhere.
Thanks !
[PATCH v2 net-next] veth: avoid a NULL deref in veth_stats_one
commit 2681128f0ced8a (veth: extend device features) added a NULL deref
in veth_stats_one(), as veth_get_stats64() was not testing if the peer
device was setup or not.
At init time, we call dev_get_stats() before veth pair is fully setup.
[ 178.854758] [<ffffffffa00f5677>] veth_get_stats64+0x47/0x70 [veth]
[ 178.861013] [<ffffffff814f0a2d>] dev_get_stats+0x6d/0x130
[ 178.866486] [<ffffffff81504efc>] rtnl_fill_ifinfo+0x47c/0x930
[ 178.872299] [<ffffffff81505b93>] rtmsg_ifinfo+0x83/0x100
[ 178.877678] [<ffffffff81505cc6>] rtnl_configure_link+0x76/0xa0
[ 178.883580] [<ffffffffa00f52fa>] veth_newlink+0x16a/0x350 [veth]
[ 178.889654] [<ffffffff815061cc>] rtnl_newlink+0x4dc/0x5e0
[ 178.895128] [<ffffffff81505e1e>] ? rtnl_newlink+0x12e/0x5e0
[ 178.900769] [<ffffffff8150587d>] rtnetlink_rcv_msg+0x11d/0x310
[ 178.906669] [<ffffffff81505760>] ? __rtnl_unlock+0x20/0x20
[ 178.912225] [<ffffffff81521f89>] netlink_rcv_skb+0xa9/0xd0
[ 178.917779] [<ffffffff81502d55>] rtnetlink_rcv+0x25/0x40
[ 178.923159] [<ffffffff815218d1>] netlink_unicast+0x1b1/0x230
[ 178.928887] [<ffffffff81521c4e>] netlink_sendmsg+0x2fe/0x3b0
[ 178.934615] [<ffffffff814dbe22>] sock_sendmsg+0xd2/0xf0
So we must check if peer was setup in veth_get_stats64()
As pointed out by Ben Hutchings, priv->peer is missing proper
synchronization. Adding RCU protection is a safe and well documented
way to make sure we don't access about to be freed or already
freed data.
Reported-by: Tom Parkin <tparkin@katalix.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/veth.c | 58 +++++++++++++++++++++++++++++--------------
1 file changed, 40 insertions(+), 18 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 8b2e112..e778bff 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -32,7 +32,7 @@ struct pcpu_vstats {
};
struct veth_priv {
- struct net_device *peer;
+ struct net_device __rcu *peer;
atomic64_t dropped;
};
@@ -89,10 +89,10 @@ static int veth_get_sset_count(struct net_device *dev, int sset)
static void veth_get_ethtool_stats(struct net_device *dev,
struct ethtool_stats *stats, u64 *data)
{
- struct veth_priv *priv;
+ struct veth_priv *priv = netdev_priv(dev);
+ struct net_device *peer = rtnl_dereference(priv->peer);
- priv = netdev_priv(dev);
- data[0] = priv->peer->ifindex;
+ data[0] = peer ? peer->ifindex : 0;
}
static const struct ethtool_ops veth_ethtool_ops = {
@@ -107,9 +107,15 @@ static const struct ethtool_ops veth_ethtool_ops = {
static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct veth_priv *priv = netdev_priv(dev);
- struct net_device *rcv = priv->peer;
+ struct net_device *rcv;
int length = skb->len;
+ rcu_read_lock();
+ rcv = rcu_dereference(priv->peer);
+ if (unlikely(!rcv)) {
+ kfree_skb(skb);
+ goto drop;
+ }
/* don't change ip_summed == CHECKSUM_PARTIAL, as that
* will cause bad checksum on forwarded packets
*/
@@ -125,9 +131,10 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
stats->packets++;
u64_stats_update_end(&stats->syncp);
} else {
+drop:
atomic64_inc(&priv->dropped);
}
-
+ rcu_read_unlock();
return NETDEV_TX_OK;
}
@@ -162,30 +169,36 @@ static struct rtnl_link_stats64 *veth_get_stats64(struct net_device *dev,
struct rtnl_link_stats64 *tot)
{
struct veth_priv *priv = netdev_priv(dev);
+ struct net_device *peer;
struct pcpu_vstats one;
tot->tx_dropped = veth_stats_one(&one, dev);
tot->tx_bytes = one.bytes;
tot->tx_packets = one.packets;
- tot->rx_dropped = veth_stats_one(&one, priv->peer);
- tot->rx_bytes = one.bytes;
- tot->rx_packets = one.packets;
+ rcu_read_lock();
+ peer = rcu_dereference(priv->peer);
+ if (peer) {
+ tot->rx_dropped = veth_stats_one(&one, peer);
+ tot->rx_bytes = one.bytes;
+ tot->rx_packets = one.packets;
+ }
+ rcu_read_unlock();
return tot;
}
static int veth_open(struct net_device *dev)
{
- struct veth_priv *priv;
+ struct veth_priv *priv = netdev_priv(dev);
+ struct net_device *peer = rtnl_dereference(priv->peer);
- priv = netdev_priv(dev);
- if (priv->peer == NULL)
+ if (!peer)
return -ENOTCONN;
- if (priv->peer->flags & IFF_UP) {
+ if (peer->flags & IFF_UP) {
netif_carrier_on(dev);
- netif_carrier_on(priv->peer);
+ netif_carrier_on(peer);
}
return 0;
}
@@ -195,7 +208,7 @@ static int veth_close(struct net_device *dev)
struct veth_priv *priv = netdev_priv(dev);
netif_carrier_off(dev);
- netif_carrier_off(priv->peer);
+ netif_carrier_off(rtnl_dereference(priv->peer));
return 0;
}
@@ -380,10 +393,10 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
*/
priv = netdev_priv(dev);
- priv->peer = peer;
+ rcu_assign_pointer(priv->peer, peer);
priv = netdev_priv(peer);
- priv->peer = dev;
+ rcu_assign_pointer(priv->peer, dev);
return 0;
err_register_dev:
@@ -404,7 +417,16 @@ static void veth_dellink(struct net_device *dev, struct list_head *head)
struct net_device *peer;
priv = netdev_priv(dev);
- peer = priv->peer;
+ peer = rtnl_dereference(priv->peer);
+
+ /* Note : dellink() is called from default_device_exit_batch(),
+ * before a rcu_synchronize() point. The devices are guaranteed
+ * not being freed before one RCU grace period.
+ */
+ RCU_INIT_POINTER(priv->peer, NULL);
+
+ priv = netdev_priv(peer);
+ RCU_INIT_POINTER(priv->peer, NULL);
unregister_netdevice_queue(dev, head);
unregister_netdevice_queue(peer, head);
^ permalink raw reply related
* Re: [PATCH 1/2] usbnet: allow status interrupt URB to always be active
From: Dan Williams @ 2013-01-05 1:26 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Elina Pasheva, netdev, linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <2212516.GkG3xP33yG@linux-5eaq.site>
On Fri, 2013-01-04 at 23:16 +0100, Oliver Neukum wrote:
> On Friday 04 January 2013 10:48:16 Dan Williams wrote:
> > Some drivers (ex sierra_net) need the status interrupt URB
> > active even when the device is closed, because they receive
> > custom indications from firmware. Allow sub-drivers to set
> > a flag that submits the status interrupt URB on probe and
> > keeps the URB alive over device open/close. The URB is still
> > killed/re-submitted for suspend/resume, as before.
> >
> > Signed-off-by: Dan Williams <dcbw@redhat.com>
> > ---
> > Oliver: alternatively, is there a problem with *always*
> > submitting the interrupt URB, and then simply not calling
> > the subdriver's .status function when the netdev is
> > closed? That would be a much simpler patch.
>
> That is quite radical. We have no idea what a device
> does when we do not react to a status update. I would
> much prefer to not take the risk.
> Besides, we don't use bandwidth if we don't have to.
Ok, so scratch the alternative. Thus, does the posted patch look like
the right course of action?
If I wasn't clear enough before, sierra_net needs to listen to the
status interrupt URB to receive the custom Restart indication as part of
the driver's device setup. Thus for sierra_net at least, tying the
status interrupt URB submission to device open/close isn't right.
I'd previously done a patch to handle this all in sierra_net, but the
problem there is suspend/resume: without directly accessing the usbnet
structure's ->suspend_count member (icky!) sierra_net can't correctly
kill/submit the URB itself. So I went with a flag to usbnet that Sierra
can set.
Dan
^ permalink raw reply
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Eric Wong @ 2013-01-05 1:07 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, netdev, linux-kernel, Rik van Riel, Minchan Kim,
Andrew Morton, Linus Torvalds
In-Reply-To: <20130104160148.GB3885@suse.de>
Mel Gorman <mgorman@suse.de> wrote:
> On Wed, Jan 02, 2013 at 08:08:48PM +0000, Eric Wong wrote:
> > Instead, I disabled THP+compaction under v3.7.1 and I've been unable to
> > reproduce the issue without THP+compaction.
> >
>
> Implying that it's stuck in compaction somewhere. It could be the case
> that compaction alters timing enough to trigger another bug. You say it
> tests differently depending on whether TCP or unix sockets are used
> which might indicate multiple problems. However, lets try and see if
> compaction is the primary problem or not.
I've only managed to encounter this issue with TCP sockets.
No luck reproducing the issue with Unix sockets, not even with 90K
buffers as suggested by Eric Dumazet. This seems unique to TCP.
Fwiw, I also tried going back to a 16K MTU on loopback a few days ago,
but was still able to reproduce the issue, so
commit 0cf833aefaa85bbfce3ff70485e5534e09254773 doesn't seem
to be a culprit, either.
> > As I mention in http://mid.gmane.org/20121229113434.GA13336@dcvr.yhbt.net
> > I run my below test (`toosleepy') with heavy network and disk activity
> > for a long time before hitting this.
> >
>
> Using a 3.7.1 or 3.8-rc2 kernel, can you reproduce the problem and then
> answer the following questions please?
OK, I'm on 3.8-rc2.
> 1. What are the contents of /proc/vmstat at the time it is stuck?
nr_free_pages 1998
nr_inactive_anon 3401
nr_active_anon 3349
nr_inactive_file 94361
nr_active_file 10929
nr_unevictable 0
nr_mlock 0
nr_anon_pages 6643
nr_mapped 2255
nr_file_pages 105400
nr_dirty 44
nr_writeback 0
nr_slab_reclaimable 0
nr_slab_unreclaimable 0
nr_page_table_pages 697
nr_kernel_stack 161
nr_unstable 0
nr_bounce 0
nr_vmscan_write 0
nr_vmscan_immediate_reclaim 0
nr_writeback_temp 0
nr_isolated_anon 0
nr_isolated_file 0
nr_shmem 114
nr_dirtied 1076168
nr_written 46330
nr_anon_transparent_hugepages 0
nr_free_cma 0
nr_dirty_threshold 22495
nr_dirty_background_threshold 11247
pgpgin 4398164
pgpgout 188556
pswpin 0
pswpout 0
pgalloc_dma 369887
pgalloc_dma32 28406230
pgalloc_normal 0
pgalloc_movable 0
pgfree 28779104
pgactivate 18160
pgdeactivate 17404
pgfault 34862559
pgmajfault 358
pgrefill_dma 14076
pgrefill_dma32 3328
pgrefill_normal 0
pgrefill_movable 0
pgsteal_kswapd_dma 12708
pgsteal_kswapd_dma32 917837
pgsteal_kswapd_normal 0
pgsteal_kswapd_movable 0
pgsteal_direct_dma 73
pgsteal_direct_dma32 4085
pgsteal_direct_normal 0
pgsteal_direct_movable 0
pgscan_kswapd_dma 12708
pgscan_kswapd_dma32 918789
pgscan_kswapd_normal 0
pgscan_kswapd_movable 0
pgscan_direct_dma 73
pgscan_direct_dma32 4115
pgscan_direct_normal 0
pgscan_direct_movable 0
pgscan_direct_throttle 0
pginodesteal 0
slabs_scanned 257024
kswapd_inodesteal 69910
kswapd_low_wmark_hit_quickly 2165
kswapd_high_wmark_hit_quickly 275
kswapd_skip_congestion_wait 0
pageoutrun 13412
allocstall 73
pgrotated 3
pgmigrate_success 448
pgmigrate_fail 0
compact_migrate_scanned 14860
compact_free_scanned 219867
compact_isolated 1652
compact_stall 33
compact_fail 10
compact_success 23
unevictable_pgs_culled 1058
unevictable_pgs_scanned 0
unevictable_pgs_rescued 1671
unevictable_pgs_mlocked 1671
unevictable_pgs_munlocked 1671
unevictable_pgs_cleared 0
unevictable_pgs_stranded 0
thp_fault_alloc 0
thp_fault_fallback 0
thp_collapse_alloc 0
thp_collapse_alloc_failed 0
thp_split 0
thp_zero_page_alloc 0
thp_zero_page_alloc_failed 0
> 2. What are the contents of /proc/PID/stack for every toosleepy
> process when they are stuck?
Oops, I needed a rebuild with CONFIG_STACKTRACE=y (it took some effort
to get the right combination of options).
I probably enabled a few more debugging options than I needed and it
seems to have taken longer to reproduce the issue. Unfortunately I was
distracted when toosleepy got stuck and missed the change to inspect
before hitting ETIMEDOUT :x
Attempting to reproduce the issue while I'm looking.
> 3. Can you do a sysrq+m and post the resulting dmesg?
SysRq : Show Memory
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 144
CPU 1: hi: 186, btch: 31 usd: 160
active_anon:3358 inactive_anon:3379 isolated_anon:0
active_file:10615 inactive_file:92319 isolated_file:0
unevictable:0 dirty:3 writeback:0 unstable:0
free:2240 slab_reclaimable:0 slab_unreclaimable:0
mapped:2333 shmem:114 pagetables:697 bounce:0
free_cma:0
DMA free:2408kB min:84kB low:104kB high:124kB active_anon:8kB inactive_anon:44kB active_file:824kB inactive_file:11512kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15676kB managed:15900kB mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:112kB pagetables:20kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 489 489 489
DMA32 free:6552kB min:2784kB low:3480kB high:4176kB active_anon:13424kB inactive_anon:13472kB active_file:41636kB inactive_file:357764kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:500952kB managed:491396kB mlocked:0kB dirty:12kB writeback:0kB mapped:9316kB shmem:456kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:1160kB pagetables:2768kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 52*4kB (UMR) 13*8kB (UMR) 4*16kB (R) 2*32kB (R) 1*64kB (R) 1*128kB (R) 1*256kB (R) 1*512kB (R) 1*1024kB (R) 0*2048kB 0*4096kB = 2424kB
DMA32: 1608*4kB (UM) 15*8kB (M) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6552kB
103053 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 392188kB
Total swap = 392188kB
131054 pages RAM
3477 pages reserved
283467 pages shared
111732 pages non-shared
> What I'm looking for is a throttling bug (if pgscan_direct_throttle is
> elevated), an isolated page accounting bug (nr_isolated_* is elevated
> and process is stuck in congestion_wait in a too_many_isolated() loop)
> or a free page accounting bug (big difference between nr_free_pages and
> buddy list figures).
>
> I'll try reproducing this early next week if none of that shows an
> obvious candidate.
Thanks! I'll try to get you more information as soon as possible.
^ permalink raw reply
* Re: [PATCH] mv643xx_eth: Fix a possible deadlock upon ifdown
From: David Miller @ 2013-01-04 23:20 UTC (permalink / raw)
To: lkundrak; +Cc: buytenh, netdev, linux-kernel
In-Reply-To: <1357309063-20236-1-git-send-email-lkundrak@v3.sk>
From: Lubomir Rintel <lkundrak@v3.sk>
Date: Fri, 4 Jan 2013 15:17:43 +0100
> @@ -943,7 +943,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget, int force)
> struct netdev_queue *nq = netdev_get_tx_queue(mp->dev, txq->index);
> int reclaimed;
>
> - __netif_tx_lock(nq, smp_processor_id());
> + __netif_tx_lock_bh(nq);
I still don't understand why this change is necessary.
The TX reclaim function is invoked in software interrupt context in
all of the places where this lockdep warning might matter.
^ permalink raw reply
* Re: [PATCH net-next] ndisc: Remove unused space at tail of skb for ndisc messages. (TAKE 3)
From: David Miller @ 2013-01-04 23:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: yoshfuji, netdev
In-Reply-To: <1357315219.1678.1461.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 04 Jan 2013 08:00:19 -0800
> On Fri, 2013-01-04 at 22:58 +0900, YOSHIFUJI Hideaki wrote:
>> Currently, the size of skb allocated for NDISC is MAX_HEADER +
>> LL_RESERVED_SPACE(dev) + packet length + dev->needed_tailroom,
>> but only LL_RESERVED_SPACE(dev) bytes is "reserved" for headers.
>> As a result, the skb looks like this (after construction of the
>> message):
>>
>> head data tail end
>> +--------------------------------------------------------------+
>> + | | | |
>> +--------------------------------------------------------------+
>> |<-hlen---->|<---ipv6 packet------>|<--tlen-->|<--MAX_HEADER-->|
>> =LL_ = dev
>> RESERVED_ ->needed_
>> SPACE(dev) tailroom
>>
>> As the name implies, "MAX_HEADER" is used for headers, and should
>> be "reserved" in prior to packet construction. Or, if some space
>> is really required at the tail of ther skb, it should be
>> explicitly documented.
>>
>> We have several option after construction of NDISC message:
>>
>> Option 1:
>>
>> head data tail end
>> +---------------------------------------------+
>> + | | |
>> +---------------------------------------------+
>> |<-hlen---->|<---ipv6 packet------>|<--tlen-->|
>> =LL_ = dev
>> RESERVED_ ->needed_
>> SPACE(dev) tailroom
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, thanks for your persistence.
^ permalink raw reply
* Re: [PATCH v3 1/1 net-next] NET: FEC: dynamtic check DMA desc buff type
From: David Miller @ 2013-01-04 23:16 UTC (permalink / raw)
To: Frank.Li; +Cc: lznuaa, s.hauer, linux-arm-kernel, shawn.guo, netdev
In-Reply-To: <1357265063-30528-1-git-send-email-Frank.Li@freescale.com>
From: Frank Li <Frank.Li@freescale.com>
Date: Fri, 4 Jan 2013 10:04:23 +0800
> MX6 and mx28 support enhanced DMA descriptor buff to support 1588
> ptp. But MX25, MX3x, MX5x can't support enhanced DMA descriptor buff.
> Check fec type and choose correct DMA descriptor buff type.
>
> Remove static config CONFIG_FEC_PTP.
> ptp function will be auto detected.
>
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH resent] net/ipv4/ipconfig: really display the BOOTP/DHCP server's address.
From: David Miller @ 2013-01-04 23:14 UTC (permalink / raw)
To: phdm; +Cc: netdev
In-Reply-To: <1357236132-12574-1-git-send-email-phdm@macqel.be>
From: Philippe De Muyter <phdm@macqel.be>
Date: Thu, 3 Jan 2013 19:02:12 +0100
> Up to now, the debug and info messages from the ipconfig subsytem
> claim to display the IP address of the DHCP/BOOTP server but
> display instead the IP address of the bootserver. Fix that.
>
> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Applied.
^ permalink raw reply
* Re: [PATCH] ip-sysctl: fix spelling errors
From: David Miller @ 2013-01-04 23:12 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20130103095029.40579b3f@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 3 Jan 2013 09:50:29 -0800
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next/master] ethernet/broadcom/tg3: Fix sparse warning: constant 0x7fffffffffffffff is so big it is long long
From: David Miller @ 2013-01-04 23:11 UTC (permalink / raw)
To: peterhuewe
Cc: mcarlson, nsujir, mchan, netdev, linux-kernel, fengguang.wu,
kbuild
In-Reply-To: <1357223030-29155-1-git-send-email-peterhuewe@gmx.de>
From: Peter Huewe <peterhuewe@gmx.de>
Date: Thu, 3 Jan 2013 15:23:50 +0100
> Sparse complains that:
> drivers/net/ethernet/broadcom/tg3.c:5670:55: sparse: constant
> 0x7fffffffffffffff is so big it is long long (on x86/32 bit)
>
> so we suffix the constant with LL in the header file.
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] usbnet: allow status interrupt URB to always be active
From: Oliver Neukum @ 2013-01-04 22:16 UTC (permalink / raw)
To: Dan Williams; +Cc: Elina Pasheva, netdev, linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <1357318096.5370.15.camel@dcbw.foobar.com>
On Friday 04 January 2013 10:48:16 Dan Williams wrote:
> Some drivers (ex sierra_net) need the status interrupt URB
> active even when the device is closed, because they receive
> custom indications from firmware. Allow sub-drivers to set
> a flag that submits the status interrupt URB on probe and
> keeps the URB alive over device open/close. The URB is still
> killed/re-submitted for suspend/resume, as before.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
> ---
> Oliver: alternatively, is there a problem with *always*
> submitting the interrupt URB, and then simply not calling
> the subdriver's .status function when the netdev is
> closed? That would be a much simpler patch.
That is quite radical. We have no idea what a device
does when we do not react to a status update. I would
much prefer to not take the risk.
Besides, we don't use bandwidth if we don't have to.
Regards
Oliver
^ permalink raw reply
* RE: Support for Marvell 88E1510 and 88E1116R
From: Steven Wang @ 2013-01-04 22:11 UTC (permalink / raw)
To: Michal Simek
Cc: Lars-Peter Clausen, netdev@vger.kernel.org, Christian Hohnstaedt,
Srinivas Kandagatla, David Miller, LKML, John Linn, Sam Bobrowicz,
Rick Hoover
In-Reply-To: <CAHTX3dKu=1azOvTM7n6M9u8AL_ujkJ5e89SeZG4fV7Q--PEAgA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]
Hi, Michal,
I have generated the patch and cleaned up the codes.
The codes was originally written by Rick Hoover.
I have sent it via git send-email command to you and git@xilinx.com.
I also attached the patch here just in case the email failed to go through.
Best Regards,
Steve
-----Original Message-----
From: Michal Simek [mailto:monstr@monstr.eu]
Sent: Friday, January 4, 2013 1:41 AM
To: Steven Wang
Cc: Lars-Peter Clausen; netdev@vger.kernel.org; Christian Hohnstaedt; Srinivas Kandagatla; David Miller; LKML; John Linn; Sam Bobrowicz; Rick Hoover
Subject: Re: Support for Marvell 88E1510 and 88E1116R
Hi Steve,
2013/1/2 Steven Wang <steven.wang@digilentinc.com>:
> Hi, Michal,
>
> We do have the Ethernet support for 88E1510 (used on ZedBoard) in our
> repository. The commit is
> https://github.com/Digilent/linux-digilent/commit/ae635e5fff35e9fe5928
> b4aca7264a1e5313a6b8 Or, I can send the patch to you if you need.
I know. Can you please clean this patch and send it to mainline for review?
(Remove comment and that emacps connection).
I will add this patch to our tree to support this patch.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian
[-- Attachment #2: 0001-Digilent-Marvell-PHY-Added-a-new-entry-for-88E1510-P.patch --]
[-- Type: application/octet-stream, Size: 2401 bytes --]
From 54ef0b3262c0657c2efaeb4d0f0cbb4d3b9efdd0 Mon Sep 17 00:00:00 2001
From: Rick Hoover <RHoover@digilentinc.com>
Date: Fri, 4 Jan 2013 13:56:54 -0800
Subject: [PATCH] Digilent: Marvell PHY: Added a new entry for 88E1510 PHYs
Added a new entry for 88E1510.
Added PHY initialization routine for 88E1510.
Signed-off-by: Tinghui WANG (Steven) <steven.wang@digilentinc.com>
---
drivers/net/phy/marvell.c | 26 ++++++++++++++++++++++++++
include/linux/marvell_phy.h | 1 +
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index e91397e..7acc633 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -350,6 +350,17 @@ static int m88e1318_config_aneg(struct phy_device *phydev)
return m88e1121_config_aneg(phydev);
}
+static int m88e1510_config_aneg(struct phy_device *phydev)
+{
+ int err;
+
+ err = m88e1318_config_aneg(phydev);
+ if (err < 0)
+ return err;
+
+ return marvell_of_reg_init(phydev);
+}
+
static int m88e1116r_config_init(struct phy_device *phydev)
{
int temp;
@@ -887,6 +898,20 @@ static struct phy_driver marvell_drivers[] = {
.config_intr = &marvell_config_intr,
.driver = { .owner = THIS_MODULE },
},
+ {
+ .phy_id = MARVELL_PHY_ID_88E1510,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
+ .name = "Marvell 88E1510",
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_aneg = &m88e1510_config_aneg,
+ .read_status = &marvell_read_status,
+ .ack_interrupt = &marvell_ack_interrupt,
+ .config_intr = &marvell_config_intr,
+ .did_interrupt = &m88e1121_did_interrupt,
+ .driver = { .owner = THIS_MODULE },
+ },
+
};
static int __init marvell_init(void)
@@ -915,6 +940,7 @@ static struct mdio_device_id __maybe_unused marvell_tbl[] = {
{ 0x01410e30, 0xfffffff0 },
{ 0x01410e90, 0xfffffff0 },
{ 0x01410e40, 0xfffffff0 },
+ { 0x01410dd0, 0xfffffff0 },
{ }
};
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index ec41025..8e9a029 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -15,6 +15,7 @@
#define MARVELL_PHY_ID_88E1240 0x01410e30
#define MARVELL_PHY_ID_88E1318S 0x01410e90
#define MARVELL_PHY_ID_88E1116R 0x01410e40
+#define MARVELL_PHY_ID_88E1510 0x01410dd0
/* struct phy_device dev_flags definitions */
#define MARVELL_PHY_M1145_FLAGS_RESISTANCE 0x00000001
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 0/2] smsc95xx enhancements
From: David Miller @ 2013-01-04 21:51 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev, ming.lei, oneukum, gregkh
In-Reply-To: <1357218016-2586-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Thu, 3 Jan 2013 13:00:14 +0000
> Two driver enhancements for net-next. There's ongoing discussion around
> the best way to improve autosuspend moving forwards but in the meantime
> the second patch in this set enables autosuspend for supported parts in
> most situations.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next] softirq: reduce latencies
From: David Miller @ 2013-01-04 21:49 UTC (permalink / raw)
To: eric.dumazet; +Cc: bhutchings, akpm, netdev, linux-kernel, therbert
In-Reply-To: <1357285780.21409.28416.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Jan 2013 23:49:40 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> In various network workloads, __do_softirq() latencies can be up
> to 20 ms if HZ=1000, and 200 ms if HZ=100.
>
> This is because we iterate 10 times in the softirq dispatcher,
> and some actions can consume a lot of cycles.
>
> This patch changes the fallback to ksoftirqd condition to :
>
> - A time limit of 2 ms.
> - need_resched() being set on current task
>
> When one of this condition is met, we wakeup ksoftirqd for further
> softirq processing if we still have pending softirqs.
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] mac802154: fix NOHZ local_softirq_pending 08 warning
From: David Miller @ 2013-01-04 21:47 UTC (permalink / raw)
To: alex.aring
Cc: alex.bluesman.smirnov, dbaryshkov, linux-zigbee-devel, mkl,
netdev, alex.aring
In-Reply-To: <1357124470-2375-1-git-send-email-alex.aring@gmail.com>
From: Alexander Aring <alex.aring@googlemail.com>
Date: Wed, 2 Jan 2013 12:01:10 +0100
> When using nanosleep() in an userspace application we get a
> ratelimit warning
>
> NOHZ: local_softirq_pending 08
>
> for 10 times.
>
> This patch replaces netif_rx() with netif_rx_ni() which has
> to be used from process/softirq context.
> The process/softirq context will be called from fakelb driver.
>
> See linux-kernel commit 481a819 for similar fix.
>
> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: UDP multi-core performance on a single socket and SO_REUSEPORT
From: Mark Zealey @ 2013-01-04 21:46 UTC (permalink / raw)
To: Tom Herbert; +Cc: Eric Dumazet, netdev
In-Reply-To: <CA+mtBx_+xR5Y5zEn6nxQ=++FEWKUw+zHzP4MamM_EEF-mMXB1Q@mail.gmail.com>
On 04/01/13 20:47, Tom Herbert wrote:
> I believe the hard part of making SO_REUSEPORT was on the TCP side in
> dealing with state in req structs which we have not resolved. UDP
> SO_REUSEPORT seems to be working pretty well.
Does anyone have a SO_REUSEPORT UDP patch for a modern networking stack?
There have been a number of changes and new functions added since the
2010 patch that I found so I couldn't get it to work properly on 3.7.1.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] ipv6: document ndisc_notify in networking/ip-sysctl.txt
From: David Miller @ 2013-01-04 21:36 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20130101103531.GA31191@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 1 Jan 2013 11:35:31 +0100
> I slipped in a new sysctl without proper documentation. I would like to
> make up for this now.
>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied, 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