* [PATCH] 8139cp: set intr mask after its handler is registered
From: Jason Wang @ 2012-04-12 8:10 UTC (permalink / raw)
To: netdev, davem, linux-kernel
We set intr mask before its handler is registered, this does not work well when
8139cp is sharing irq line with other devices. As the irq could be enabled by
the device before 8139cp's hander is registered which may lead unhandled
irq. Fix this by introducing an helper cp_irq_enable() and call it after
request_irq().
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/ethernet/realtek/8139cp.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index abc7907..b3287c0 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -958,6 +958,11 @@ static inline void cp_start_hw (struct cp_private *cp)
cpw8(Cmd, RxOn | TxOn);
}
+static void cp_enable_irq(struct cp_private *cp)
+{
+ cpw16_f(IntrMask, cp_intr_mask);
+}
+
static void cp_init_hw (struct cp_private *cp)
{
struct net_device *dev = cp->dev;
@@ -997,8 +1002,6 @@ static void cp_init_hw (struct cp_private *cp)
cpw16(MultiIntr, 0);
- cpw16_f(IntrMask, cp_intr_mask);
-
cpw8_f(Cfg9346, Cfg9346_Lock);
}
@@ -1130,6 +1133,8 @@ static int cp_open (struct net_device *dev)
if (rc)
goto err_out_hw;
+ cp_enable_irq(cp);
+
netif_carrier_off(dev);
mii_check_media(&cp->mii_if, netif_msg_link(cp), true);
netif_start_queue(dev);
@@ -2031,6 +2036,7 @@ static int cp_resume (struct pci_dev *pdev)
/* FIXME: sh*t may happen if the Rx ring buffer is depleted */
cp_init_rings_index (cp);
cp_init_hw (cp);
+ cp_enable_irq(cp);
netif_start_queue (dev);
spin_lock_irqsave (&cp->lock, flags);
^ permalink raw reply related
* Re: [RFC v3] Add TCP encap_rcv hook
From: Eric Dumazet @ 2012-04-12 8:20 UTC (permalink / raw)
To: Simon Horman; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120412074159.GA10866-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
On Thu, 2012-04-12 at 16:42 +0900, Simon Horman wrote:
> This hook is based on a hook of the same name provided by UDP. It provides
> a way for to receive packets that have a TCP header and treat them in some
> alternate way.
>
> It is intended to be used by an implementation of the STT tunneling
> protocol within Open vSwtich's datapath. A prototype of such an
> implementation has been made.
>
> The STT draft is available at
> http://tools.ietf.org/html/draft-davie-stt-01
>
> My prototype STT implementation has been posted to the dev-UOEtcQmXneFl884UGnbwIQ@public.gmane.org
> The first version can be found at:
> http://www.mail-archive.com/dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org/msg08877.html
>
> Signed-off-by: Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
>
Hi Simon
Oh well, this is insane :(
> ---
> include/linux/tcp.h | 3 +++
> net/ipv4/tcp_ipv4.c | 23 ++++++++++++++++++++++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> v3
> * First post to netdev
> * Replace more UDP references with TCP
> * Move socket accesses to inside socket lock
> and release lock on return.
>
> v2
> * Fix comment to refer to TCP rather than UDP
> * Allow skb to continue traversing the stack if
> the encap_rcv callback returns a positive value.
> This is the same behaviour as the UDP hook.
>
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index b6c62d2..7210b23 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -472,6 +472,9 @@ struct tcp_sock {
> * contains related tcp_cookie_transactions fields.
> */
> struct tcp_cookie_values *cookie_values;
> +
> + /* For encapsulation sockets. */
> + int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
> };
>
This adds a new cache miss for all incoming tcp frames...
> static inline struct tcp_sock *tcp_sk(const struct sock *sk)
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 3a25cf7..9898f71 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1666,8 +1666,10 @@ int tcp_v4_rcv(struct sk_buff *skb)
> const struct iphdr *iph;
> const struct tcphdr *th;
> struct sock *sk;
> + struct tcp_sock *tp;
> int ret;
> struct net *net = dev_net(skb->dev);
> + int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
>
> if (skb->pkt_type != PACKET_HOST)
> goto discard_it;
> @@ -1726,9 +1728,27 @@ process:
>
> bh_lock_sock_nested(sk);
> ret = 0;
> +
> + tp = tcp_sk(sk);
> + encap_rcv = ACCESS_ONCE(tp->encap_rcv);
> + if (encap_rcv != NULL) {
and a new conditional...
> + /*
> + * This is an encapsulation socket so pass the skb to
> + * the socket's tcp_encap_rcv() hook. Otherwise, just
> + * fall through and pass this up the TCP socket.
> + * up->encap_rcv() returns the following value:
> + * <=0 if skb was successfully passed to the encap
> + * handler or was discarded by it.
> + * >0 if skb should be passed on to TCP.
> + */
> + if (encap_rcv(sk, skb) <= 0) {
> + ret = 0;
> + goto unlock_sock;
> + }
> + }
> +
> if (!sock_owned_by_user(sk)) {
> #ifdef CONFIG_NET_DMA
> - struct tcp_sock *tp = tcp_sk(sk);
> if (!tp->ucopy.dma_chan && tp->ucopy.pinned_list)
> tp->ucopy.dma_chan = dma_find_channel(DMA_MEMCPY);
> if (tp->ucopy.dma_chan)
> @@ -1744,6 +1764,7 @@ process:
> NET_INC_STATS_BH(net, LINUX_MIB_TCPBACKLOGDROP);
> goto discard_and_relse;
> }
> +unlock_sock:
> bh_unlock_sock(sk);
>
> sock_put(sk);
I dont know, this sounds as a hack. Since you obviously spent a lot of
time on this stuff, lets be constructive.
I really suggest you take a look at <linux/static_key.h>
So that on machines without any need for this encap_rcv, we dont even
need to fetch tp->encap_rcv
if (static_key_false(&stt_active)) {
/* stt might be used on this socket */
encap_rcv = ACCESS_ONCE(tp->encap_rcv);
if (encap_rcv) {
...
}
}
This way, if stt is not used/loaded, we have a single NOP
If stt is used, NOP is patched to a JMP stt_code
I probably implement this idea on UDP shortly so that you can have a
reference for your implementation.
^ permalink raw reply
* Re: [PATCH 1/1] netfilter: xt_recent: Add optional mask option for xt_recent
From: Denys Fedoryshchenko @ 2012-04-12 9:00 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Patrick McHardy, David S. Miller, netfilter-devel, netfilter,
coreteam, linux-kernel, netdev
In-Reply-To: <20120411231421.GA7038@1984>
Hi Pablo
On 2012-04-12 02:14, Pablo Neira Ayuso wrote:
> Hi Denys,
>
> On Tue, Mar 06, 2012 at 01:24:44PM +0200, Denys Fedoryshchenko wrote:
>> Use case for this feature:
>> 1)In some occasions if you need to allow,block,match specific
>> subnet.
>> 2)I can use recent as a trigger when netfilter rule matches, with
>> mask 0.0.0.0
>>
>> Example:
>>
>> If you ping 8.8.8.8, after that you can't ping 2.2.2.10
>
> Could you provide an useful example for this new feature?
>
> I also think you can make this with hashlimit, that allows you to
> set the network mask.
Yes, technically hashlimit can do a lot, but not everything. Especially
because xt_recent can be "fine-grained" in steps, depends on timeline of
event, and can be updated accordingly to time of reoccurred event. It is
generally not related to mask option, but mask gives power to block
subnets.
Why for example /24? Well, it is minimal mask for BGP announce :) It is
very often, that requesting ip has more ip's in same subnet
(load-balancing, or multiple ip's on dedicated server), and mask will be
highly useful for that, to reduce number of entries and to tighten weak
points (usually after ip blocked, they try from neighbor ip to check, if
destination just blocked single ip). Plus rttl and hitcount another
sweet things that are available in xt_recent, but aren't in hashlimit.
iptables -t mangle -N SIP
# If someone abuse our SIP, block him completely at least for 10
seconds, if he try again, update and block for new 120 seconds
iptables -t mangle -A SIP -m recent --name X --update --seconds 10
--mask 255.255.255.0 -j MARK --set-mark 0x1
# 120 - 600 seconds handle him over special relay (that will log his
query, but wont pass him to real SIP server)
iptables -t mangle -A SIP -m recent --name X --rcheck --seconds 600
--mask 255.255.255.0 -j MARK --set-mark 0x2
In this case i will log only invalid queries, but for example some DDoS
or scanners that flood servers by packets will be silently ignored.
Maybe if hitcount really bad, i will add them to ipset, and block
permanently, by -m set --add-set.
For me personally it is useful, because i have around 140 NAS servers,
and i give each of them /24 "gray" subnets, and in some cases i need to
handle bad users, that are changing dynamic ip and attacking from new ip
each time. I just block non-critical service for whole subnet then, till
technician on duty will solve issue completely. And sure if attack are
stopped, subnet will be unblocked "automagically".
Sure this feature not critical, or "a must", and if code are not good,
it is up to you, if it should be added or not.
^ permalink raw reply
* [PATCH net-next] udp: intoduce udp_encap_needed static_key
From: Eric Dumazet @ 2012-04-12 9:05 UTC (permalink / raw)
To: Simon Horman, David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1334218829.5300.5903.camel@edumazet-glaptop>
Most machines dont use UDP encapsulation (L2TP)
Adds a static_key so that udp_queue_rcv_skb() doesnt have to perform a
test if L2TP never setup the encap_rcv on a socket.
Idea of this patch came after Simon Horman proposal to add a hook on TCP
as well.
If static_key is not yet enabled, the fast path does a single JMP .
When static_key is enabled, JMP destination is patched to reach the real
encap_type/encap_rcv logic, possibly adding cache misses.
Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
---
include/net/udp.h | 1 +
net/ipv4/udp.c | 12 +++++++++++-
net/l2tp/l2tp_core.c | 1 +
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/net/udp.h b/include/net/udp.h
index 5d606d9..9671f5f 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -267,4 +267,5 @@ extern void udp_init(void);
extern int udp4_ufo_send_check(struct sk_buff *skb);
extern struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
netdev_features_t features);
+extern void udp_encap_enable(void);
#endif /* _UDP_H */
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index fe14105..ad1e0dd 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -107,6 +107,7 @@
#include <net/checksum.h>
#include <net/xfrm.h>
#include <trace/events/udp.h>
+#include <linux/static_key.h>
#include "udp_impl.h"
struct udp_table udp_table __read_mostly;
@@ -1379,6 +1380,14 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
}
+static struct static_key udp_encap_needed __read_mostly;
+void udp_encap_enable(void)
+{
+ if (!static_key_enabled(&udp_encap_needed))
+ static_key_slow_inc(&udp_encap_needed);
+}
+EXPORT_SYMBOL(udp_encap_enable);
+
/* returns:
* -1: error
* 0: success
@@ -1400,7 +1409,7 @@ int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
goto drop;
nf_reset(skb);
- if (up->encap_type) {
+ if (static_key_false(&udp_encap_needed) && up->encap_type) {
int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
/*
@@ -1760,6 +1769,7 @@ int udp_lib_setsockopt(struct sock *sk, int level, int optname,
/* FALLTHROUGH */
case UDP_ENCAP_L2TPINUDP:
up->encap_type = val;
+ udp_encap_enable();
break;
default:
err = -ENOPROTOOPT;
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 89ff8c6..f6732b6 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1424,6 +1424,7 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id, u32
/* Mark socket as an encapsulation socket. See net/ipv4/udp.c */
udp_sk(sk)->encap_type = UDP_ENCAP_L2TPINUDP;
udp_sk(sk)->encap_rcv = l2tp_udp_encap_recv;
+ udp_encap_enable();
}
sk->sk_user_data = tunnel;
^ permalink raw reply related
* [PATCH] net: smsc911x: fix RX FIFO fastforwarding when dropping packets
From: Will Deacon @ 2012-04-12 9:07 UTC (permalink / raw)
To: netdev; +Cc: Will Deacon, Steve Glendinning
The SMSC911x ethernet controller provides a mechanism for quickly
skipping to the start of the next frame in the receive FIFO, however
the current code passes the number of words to a function that expects
the number of bytes. This can corrupt the FIFO head in the case that
the fastforward mechanism is not used.
This patch fixes the callers of smsc911x_rx_fastforward to pass the
correct data size.
Cc: Steve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
drivers/net/ethernet/smsc/smsc911x.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index 4a69710..b5599bc 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -1228,7 +1228,7 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
"Discarding packet with error bit set");
/* Packet has an error, discard it and continue with
* the next */
- smsc911x_rx_fastforward(pdata, pktwords);
+ smsc911x_rx_fastforward(pdata, pktlength);
dev->stats.rx_dropped++;
continue;
}
@@ -1238,7 +1238,7 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
SMSC_WARN(pdata, rx_err,
"Unable to allocate skb for rx packet");
/* Drop the packet and stop this polling iteration */
- smsc911x_rx_fastforward(pdata, pktwords);
+ smsc911x_rx_fastforward(pdata, pktlength);
dev->stats.rx_dropped++;
break;
}
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH net-next] udp: intoduce udp_encap_needed static_key
From: Eric Dumazet @ 2012-04-12 9:10 UTC (permalink / raw)
To: Simon Horman
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
David Miller
In-Reply-To: <1334221528.5300.6008.camel@edumazet-glaptop>
On Thu, 2012-04-12 at 11:05 +0200, Eric Dumazet wrote:
> If static_key is not yet enabled, the fast path does a single JMP .
>
> When static_key is enabled, JMP destination is patched to reach the real
> encap_type/encap_rcv logic, possibly adding cache misses.
Small note Simon,
The jump trick is effective on x86 (and maybe some other arches) when
CONFIG_JUMP_LABEL=y
Else, its replaced by atomic_read(...) > 0, a cnditional jump but
reading a read_mostly/shared variable, instead of a per socket field.
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: ethtool: Add capability to retrieve plug-in module EEPROM
From: Stuart Hodgson @ 2012-04-12 9:18 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev, bruce.w.allan, mirq-linux, decot, amit.salecha,
alexander.h.duyck, davem, linux-kernel
In-Reply-To: <1334187728.2552.7.camel@bwh-desktop.uk.solarflarecom.com>
On 12/04/12 00:42, Ben Hutchings wrote:
> On Wed, 2012-04-11 at 19:16 +0100, Ben Hutchings wrote:
>> On Wed, 2012-04-11 at 17:50 +0100, Stuart Hodgson wrote:
>>> On 02/04/12 18:52, Ben Hutchings wrote:
>> [...]
>>>>> --- a/net/core/ethtool.c
>>>>> +++ b/net/core/ethtool.c
>> [...]
>>>>> + if (eeprom.offset + eeprom.len> modinfo.eeprom_len)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + data = kmalloc(PAGE_SIZE, GFP_USER);
>>>>> + if (!data)
>>>>> + return -ENOMEM;
>>>>
>>>> What if some device has a larger EEPROM? Surely this length should be
>>>> eeprom.len.
>>>>
>>>
>>> Do you mean what if the eeprom length in te device is larger than
>>> PAGE_SIZE?
>>
>> Yes.
>>
>>> If so then it should really use modinfo.eeprom_len since
>>> this the size of the data. eeprom.len could be arbitary.
>>
>> No, eeprom.len is the size of the data and we've already validated it at
>> this point.
>
> Maybe we should start by refactoring ethtool_get_eeprom() so we can
> reuse most of its code in ethtool_get_module_eeprom(), rather than
> having to worry about what the maximum size of a module EEPROM might be
> and whether we need a loop:
>
> Subject: ethtool: Split ethtool_get_eeprom() to allow for additional EEPROM accessors
>
> We want to support reading module (SFP+, XFP, ...) EEPROMs as well as
> NIC EEPROMs. They will need a different command number and driver
> operation, but the structure and arguments will be the same and so we
> can share most of the code here.
>
> Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
> ---
> net/core/ethtool.c | 24 +++++++++++++++++-------
> 1 files changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index beacdd9..ca7698f 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -751,18 +751,17 @@ static int ethtool_get_link(struct net_device *dev, char __user *useraddr)
> return 0;
> }
>
> -static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
> +static int ethtool_get_any_eeprom(struct net_device *dev, void __user *useraddr,
> + int (*getter)(struct net_device *,
> + struct ethtool_eeprom *, u8 *),
> + u32 total_len)
> {
> struct ethtool_eeprom eeprom;
> - const struct ethtool_ops *ops = dev->ethtool_ops;
> void __user *userbuf = useraddr + sizeof(eeprom);
> u32 bytes_remaining;
> u8 *data;
> int ret = 0;
>
> - if (!ops->get_eeprom || !ops->get_eeprom_len)
> - return -EOPNOTSUPP;
> -
> if (copy_from_user(&eeprom, useraddr, sizeof(eeprom)))
> return -EFAULT;
>
> @@ -771,7 +770,7 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
> return -EINVAL;
>
> /* Check for exceeding total eeprom len */
> - if (eeprom.offset + eeprom.len> ops->get_eeprom_len(dev))
> + if (eeprom.offset + eeprom.len> total_len)
> return -EINVAL;
>
> data = kmalloc(PAGE_SIZE, GFP_USER);
Should this not be eeprom.len?
> @@ -782,7 +781,7 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
> while (bytes_remaining> 0) {
> eeprom.len = min(bytes_remaining, (u32)PAGE_SIZE);
>
> - ret = ops->get_eeprom(dev,&eeprom, data);
> + ret = getter(dev,&eeprom, data);
> if (ret)
> break;
> if (copy_to_user(userbuf, data, eeprom.len)) {
> @@ -803,6 +802,17 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
> return ret;
> }
>
> +static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
> +{
> + const struct ethtool_ops *ops = dev->ethtool_ops;
> +
> + if (!ops->get_eeprom || !ops->get_eeprom_len)
> + return -EOPNOTSUPP;
> +
> + return ethtool_get_any_eeprom(dev, useraddr, ops->get_eeprom,
> + ops->get_eeprom_len(dev));
> +}
> +
> static int ethtool_set_eeprom(struct net_device *dev, void __user *useraddr)
> {
> struct ethtool_eeprom eeprom;
This would reduce the code size nicely between the two eeprom fetches.
Stu
^ permalink raw reply
* Re: [RFC PATCH 2/2] net: ethtool: Add capability to retrieve plug-in module EEPROM
From: Stuart Hodgson @ 2012-04-12 9:20 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, davem, linux-kernel
In-Reply-To: <1334169119.2552.17.camel@bwh-desktop.uk.solarflarecom.com>
On 11/04/12 19:31, Ben Hutchings wrote:
> On Wed, 2012-04-11 at 18:41 +0100, Stuart Hodgson wrote:
>> On 02/04/12 19:18, Ben Hutchings wrote:
>>> On Tue, 2012-03-27 at 18:51 +0100, Stuart Hodgson wrote:
> [...]
>>>> --- a/drivers/net/ethernet/sfc/ethtool.c
>>>> +++ b/drivers/net/ethernet/sfc/ethtool.c
> [...]
>>>> + payload_len = MCDI_DWORD(outbuf,
>>>> + GET_PHY_MEDIA_INFO_OUT_DATALEN);
>>>> +
>>>> + to_copy = (space_remaining< payload_len) ?
>>>> + space_remaining : payload_len;
>>>> +
>>>> + to_copy -= page_off;
>>>
>>> page_off is the number of bytes we need to discard from payload_len, but
>>> we don't want do discard that from space_remaining. I think the last
>>> two statements should be changed to:
>>>
>>> payload_len -= page_off;
>>> to_copy = (space_remaining< payload_len) ?
>>> space_remaining : payload_len;
>>>
>>
>> I am pretty sure that these two pieces of code are the same
>
> Suppose we start with ee->offset = 64, ee->len = 32. After the MCDI
> request returns and we assign payload_len from that, I believe we will
> have page_off = 64, payload_len = 128, space_remaining = 32.
>
> Work through the calculations from there and you'll see the problem.
>
> [...]
Yep, I go negative if len is shorter than offset.
>>>> + phy_cfg = efx->phy_data;
>>>> + modinfo->eeprom_len = mcdi_to_module_eeprom_len(phy_cfg->media);
>>>> + modinfo->type = SFF_8079;
>>> [...]
>>>
>>> I don't think this makes sense. If we're fixing the type as SFF_8079
>>> then why are we calling a function to get the length?
>>>
>>> Ben.
>>>
>>
>> What about adding an mcdi_to_module_eeprom_type in the same manner
>> as mcdi_to_module_eeprom_len and the other mapping functions?
>
> Could do, but I don't see the point of breaking this out into separate
> functions that are only used once. It's actually going to increase code
> duplication because you'll have to put the same PHY type checks in both
> of them.
>
> Ben.
>
I simply followed the precedent of mcdi_to_ethtool_media. I could
combine these functions into the module_info function such as
...
struct efx_mcdi_phy_data *phy_cfg;
phy_cfg = efx->phy_data;
modinfo->eeprom_len = 0;
modinfo->type = 0;
switch (phy_cfg->media) {
case MC_CMD_MEDIA_SFP_PLUS:
modinfo->type = ETH_MODULE_SFF_8079;
modinfo->eeprom_len = ETH_MODULE_SFF_8079_LEN;
break;
default:
break;
}
...
Stu
^ permalink raw reply
* Re: [PATCH] net: smsc911x: fix RX FIFO fastforwarding when dropping packets
From: Eric Dumazet @ 2012-04-12 9:20 UTC (permalink / raw)
To: Will Deacon; +Cc: netdev, Steve Glendinning
In-Reply-To: <1334221644-16056-1-git-send-email-will.deacon@arm.com>
On Thu, 2012-04-12 at 10:07 +0100, Will Deacon wrote:
> The SMSC911x ethernet controller provides a mechanism for quickly
> skipping to the start of the next frame in the receive FIFO, however
> the current code passes the number of words to a function that expects
> the number of bytes. This can corrupt the FIFO head in the case that
> the fastforward mechanism is not used.
>
> This patch fixes the callers of smsc911x_rx_fastforward to pass the
> correct data size.
>
> Cc: Steve Glendinning <steve.glendinning@smsc.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> drivers/net/ethernet/smsc/smsc911x.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
> index 4a69710..b5599bc 100644
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
> @@ -1228,7 +1228,7 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
> "Discarding packet with error bit set");
> /* Packet has an error, discard it and continue with
> * the next */
> - smsc911x_rx_fastforward(pdata, pktwords);
> + smsc911x_rx_fastforward(pdata, pktlength);
> dev->stats.rx_dropped++;
> continue;
> }
> @@ -1238,7 +1238,7 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
> SMSC_WARN(pdata, rx_err,
> "Unable to allocate skb for rx packet");
> /* Drop the packet and stop this polling iteration */
> - smsc911x_rx_fastforward(pdata, pktwords);
> + smsc911x_rx_fastforward(pdata, pktlength);
> dev->stats.rx_dropped++;
> break;
> }
Hum, looking at this driver, I see wrong code in lines 1246/1247
skb->data = skb->head;
skb_reset_tail_pointer(skb);
I suspect its hiding a buffer overflow bug or something.
netdev_alloc_skb() reserved NET_SKB_PAD bytes. A driver should not
un-reserve this headroom, or some networking setups can be very slow.
So
pdata->ops->rx_readfifo(pdata,
(unsigned int *)skb->head, pktwords);
also should be fixed to use skb->data instead.
^ permalink raw reply
* [PATCH] drivers/net/ethernet/xilinx/axi ethernet: Correct Copyright
From: Michal Simek @ 2012-04-12 11:11 UTC (permalink / raw)
To: davem; +Cc: netdev, John.Linn, danborkmann, anirudh, Michal Simek
Also fix MAINTAINERS file to reflect autorship.
Daniel and Ariane changed coding style but not any functional changes in the driver
itself.
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
MAINTAINERS | 4 ++--
drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 +---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 6 +++---
drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c | 6 +++---
4 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a127097..5d15fa6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7573,8 +7573,8 @@ F: Documentation/filesystems/xfs.txt
F: fs/xfs/
XILINX AXI ETHERNET DRIVER
-M: Ariane Keller <ariane.keller@tik.ee.ethz.ch>
-M: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
+M: Anirudha Sarangi <anirudh@xilinx.com>
+M: John Linn <John.Linn@xilinx.com>
S: Maintained
F: drivers/net/ethernet/xilinx/xilinx_axienet*
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index cc83af0..44b8d2b 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -2,9 +2,7 @@
* Definitions for Xilinx Axi Ethernet device driver.
*
* Copyright (c) 2009 Secret Lab Technologies, Ltd.
- * Copyright (c) 2010 Xilinx, Inc. All rights reserved.
- * Copyright (c) 2012 Daniel Borkmann, <daniel.borkmann@tik.ee.ethz.ch>
- * Copyright (c) 2012 Ariane Keller, <ariane.keller@tik.ee.ethz.ch>
+ * Copyright (c) 2010 - 2012 Xilinx, Inc. All rights reserved.
*/
#ifndef XILINX_AXIENET_H
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 2fcbeba..9c365e1 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -4,9 +4,9 @@
* Copyright (c) 2008 Nissin Systems Co., Ltd., Yoshio Kashiwagi
* Copyright (c) 2005-2008 DLA Systems, David H. Lynch Jr. <dhlii@dlasys.net>
* Copyright (c) 2008-2009 Secret Lab Technologies Ltd.
- * Copyright (c) 2010 Xilinx, Inc. All rights reserved.
- * Copyright (c) 2012 Daniel Borkmann, <daniel.borkmann@tik.ee.ethz.ch>
- * Copyright (c) 2012 Ariane Keller, <ariane.keller@tik.ee.ethz.ch>
+ * Copyright (c) 2010 - 2011 Michal Simek <monstr@monstr.eu>
+ * Copyright (c) 2010 - 2011 PetaLogix
+ * Copyright (c) 2010 - 2012 Xilinx, Inc. All rights reserved.
*
* This is a driver for the Xilinx Axi Ethernet which is used in the Virtex6
* and Spartan6.
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
index d70b6e7..e90e1f4 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
@@ -2,9 +2,9 @@
* MDIO bus driver for the Xilinx Axi Ethernet device
*
* Copyright (c) 2009 Secret Lab Technologies, Ltd.
- * Copyright (c) 2010 Xilinx, Inc. All rights reserved.
- * Copyright (c) 2012 Daniel Borkmann, <daniel.borkmann@tik.ee.ethz.ch>
- * Copyright (c) 2012 Ariane Keller, <ariane.keller@tik.ee.ethz.ch>
+ * Copyright (c) 2010 - 2011 Michal Simek <monstr@monstr.eu>
+ * Copyright (c) 2010 - 2011 PetaLogix
+ * Copyright (c) 2010 - 2012 Xilinx, Inc. All rights reserved.
*/
#include <linux/of_address.h>
--
1.7.10.rc3.1.gb306
^ permalink raw reply related
* Kernel panic with bridge networking
From: Massimo Cetra @ 2012-04-12 12:30 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]
Hello,
i am experiencing a panic whose logs are attached (grabbed with netconsole).
They look quite similar to what has been described here
http://www.spinics.net/lists/linux-net/msg17689.html
The patch proposed as the solution (commit
6b1e960fdbd75dcd9bcc3ba5ff8898ff1ad30b6e) seems to be applied (even with
small differences) but the problem persists.
The kernel is a debian linux-image-3.2.0-2-amd64 version 3.2.12-1
Any hint ?
I have checked the changelog of 3.2.13 and 3.2.14 and it doesn't seems
to be any commit regarding such problems.
Massimo Cetra
P.S.1: Please CC me as i'm not subscribed.
P.S.2: this bug has been submitted to debian as well
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668511
[-- Attachment #2: BUG1.txt --]
[-- Type: text/plain, Size: 25653 bytes --]
Apr 12 12:10:08 lamu [71020.539961] BUG: unable to handle kernel
Apr 12 12:10:08 NULL pointer dereference
Apr 12 12:10:08 lamu at 0000000000000018
Apr 12 12:10:08 lamu [71020.555654] IP:
Apr 12 12:10:08 lamu [<ffffffffa02e9336>] br_nf_forward_finish+0x2e/0x95 [bridge]
Apr 12 12:10:08 lamu [71020.569755] PGD 0
Apr 12 12:10:08 lamu
Apr 12 12:10:08 lamu [71020.573785] Oops: 0000 [#1]
Apr 12 12:10:08 SMP
Apr 12 12:10:08 lamu
Apr 12 12:10:08 lamu [71020.580257] CPU 0
Apr 12 12:10:08 lamu
Apr 12 12:10:08 lamu [71020.583912] Modules linked in:
Apr 12 12:10:08 lamu ipt_MASQUERADE
Apr 12 12:10:08 lamu iptable_nat
Apr 12 12:10:08 lamu nf_nat
Apr 12 12:10:08 lamu nf_conntrack_ipv4
Apr 12 12:10:08 lamu nf_defrag_ipv4
Apr 12 12:10:08 lamu ip_vs_rr
Apr 12 12:10:08 lamu ip_vs
Apr 12 12:10:08 lamu nf_conntrack
Apr 12 12:10:08 lamu libcrc32c
Apr 12 12:10:08 lamu ip6table_filter
Apr 12 12:10:08 lamu ip6_tables
Apr 12 12:10:08 lamu iptable_filter
Apr 12 12:10:08 lamu ip_tables
Apr 12 12:10:08 lamu ebtable_nat
Apr 12 12:10:08 lamu ebtables
Apr 12 12:10:08 lamu x_tables
Apr 12 12:10:08 lamu crc32c
Apr 12 12:10:08 lamu drbd
Apr 12 12:10:08 lamu lru_cache
Apr 12 12:10:08 lamu cn
Apr 12 12:10:08 lamu sit
Apr 12 12:10:08 lamu tunnel4
Apr 12 12:10:08 lamu tun
Apr 12 12:10:08 lamu bridge
Apr 12 12:10:08 lamu stp
Apr 12 12:10:08 lamu virtio_net
Apr 12 12:10:08 lamu virtio_blk
Apr 12 12:10:08 lamu virtio_rng
Apr 12 12:10:08 lamu rng_core
Apr 12 12:10:08 lamu virtio_pci
Apr 12 12:10:08 lamu virtio_ring
Apr 12 12:10:08 lamu virtio
Apr 12 12:10:08 lamu kvm_intel
Apr 12 12:10:08 lamu kvm
Apr 12 12:10:08 lamu ipmi_devintf
Apr 12 12:10:08 lamu ipmi_poweroff
Apr 12 12:10:08 lamu ipmi_si
Apr 12 12:10:08 lamu ipmi_watchdog
Apr 12 12:10:08 lamu ipmi_msghandler
Apr 12 12:10:08 lamu netconsole
Apr 12 12:10:08 lamu configfs
Apr 12 12:10:08 lamu loop
Apr 12 12:10:08 lamu option
Apr 12 12:10:08 lamu usb_wwan
Apr 12 12:10:08 lamu usbserial
Apr 12 12:10:08 lamu uas
Apr 12 12:10:08 lamu snd_pcm
Apr 12 12:10:08 lamu snd_page_alloc
Apr 12 12:10:08 lamu snd_timer
Apr 12 12:10:08 lamu snd
Apr 12 12:10:08 lamu iTCO_wdt
Apr 12 12:10:08 lamu iTCO_vendor_support
Apr 12 12:10:08 lamu psmouse
Apr 12 12:10:08 lamu i7core_edac
Apr 12 12:10:08 lamu edac_core
Apr 12 12:10:08 lamu processor
Apr 12 12:10:08 lamu button
Apr 12 12:10:08 lamu soundcore
Apr 12 12:10:08 lamu joydev
Apr 12 12:10:08 lamu serio_raw
Apr 12 12:10:08 lamu pcspkr
Apr 12 12:10:08 lamu evdev
Apr 12 12:10:08 lamu dcdbas
Apr 12 12:10:08 lamu thermal_sys
Apr 12 12:10:08 lamu ext3
Apr 12 12:10:08 lamu mbcache
Apr 12 12:10:08 lamu jbd
Apr 12 12:10:08 lamu dm_mod
Apr 12 12:10:08 lamu sr_mod
Apr 12 12:10:08 lamu cdrom
Apr 12 12:10:08 lamu ses
Apr 12 12:10:08 lamu sd_mod
Apr 12 12:10:08 lamu usbhid
Apr 12 12:10:08 lamu hid
Apr 12 12:10:08 lamu crc_t10dif
Apr 12 12:10:08 lamu enclosure
Apr 12 12:10:08 lamu ata_generic
Apr 12 12:10:08 lamu uhci_hcd
Apr 12 12:10:08 lamu ata_piix
Apr 12 12:10:08 lamu ehci_hcd
Apr 12 12:10:08 lamu libata
Apr 12 12:10:08 lamu usbcore
Apr 12 12:10:08 lamu megaraid_sas
Apr 12 12:10:08 lamu scsi_mod
Apr 12 12:10:08 lamu usb_common
Apr 12 12:10:08 lamu bnx2
Apr 12 12:10:08 lamu [last unloaded: usb_storage]
Apr 12 12:10:08 lamu
Apr 12 12:10:08 lamu [71020.733498]
Apr 12 12:10:08 lamu [71020.736475] Pid: 6997, comm: kvm Not tainted 3.2.0-2-amd64 #1
Apr 12 12:10:08 lamu Dell Inc. PowerEdge R410
Apr 12 12:10:08 lamu /0N051F
Apr 12 12:10:08 lamu
Apr 12 12:10:08 lamu [71020.753554] RIP: 0010:[<ffffffffa02e9336>]
Apr 12 12:10:08 lamu [<ffffffffa02e9336>] br_nf_forward_finish+0x2e/0x95 [bridge]
Apr 12 12:10:08 lamu [71020.772519] RSP: 0018:ffff88042fc03b18 EFLAGS: 00010293
Apr 12 12:10:08 lamu [71020.783126] RAX: 0000000000000000 RBX: ffff8802c3f911c0 RCX: 00000001010dee01
Apr 12 12:10:08 lamu [71020.797376] RDX: ffffffffa02e9308 RSI: 0000000000000282 RDI: ffff8802c3f911c0
Apr 12 12:10:08 lamu [71020.811629] RBP: ffff8802269c0000 R08: 0000000000000000 R09: ffff88042fc03ad0
Apr 12 12:10:08 lamu [71020.825878] R10: ffffffff8165aac0 R11: ffffffff8165aac0 R12: 0000000000000000
Apr 12 12:10:08 lamu [71020.840127] R13: ffff880424a40002 R14: ffff8802ca545c00 R15: ffff880424a40000
Apr 12 12:10:08 lamu [71020.854379] FS: 00007f7e7613d900(0000) GS:ffff88042fc00000(0000) knlGS:0000000000000000
Apr 12 12:10:08 lamu [71020.870553] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 12 12:10:08 lamu [71020.882027] CR2: 0000000000000018 CR3: 00000003e0369000 CR4: 00000000000026e0
Apr 12 12:10:08 lamu [71020.896276] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 12 12:10:08 lamu [71020.910527] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr 12 12:10:08 lamu [71020.924778] Process kvm (pid: 6997, threadinfo ffff8803d1f1e000, task ffff88042707c040)
Apr 12 12:10:08 lamu [71020.940776] Stack:
Apr 12 12:10:08 lamu [71020.944796] ffffffff80000000
Apr 12 12:10:08 lamu ffffffffa02e96db
Apr 12 12:10:08 lamu ffff8802c3f911c0
Apr 12 12:10:08 lamu ffff8802269c0000
Apr 12 12:10:08 lamu
Apr 12 12:10:08 lamu [71020.959629] ffff88022799c000
Apr 12 12:10:08 lamu ffffffffa02e9a67
Apr 12 12:10:08 lamu ffff880480000000
Apr 12 12:10:08 lamu 0000000280000000
Apr 12 12:10:08 lamu
Apr 12 12:10:08 lamu [71020.974464] ffff8802c3f911c0
Apr 12 12:10:08 lamu ffffffffa02efcd0
Apr 12 12:10:08 lamu ffffffff81691190
Apr 12 12:10:08 lamu 0000000000000002
Apr 12 12:10:08 lamu
Apr 12 12:10:08 lamu [71020.989299] Call Trace:
Apr 12 12:10:08 lamu [71020.994185] <IRQ>
Apr 12 12:10:08 lamu
Apr 12 12:10:08 lamu [71020.998394] [<ffffffffa02e96db>] ? br_parse_ip_options+0x3d/0x19a [bridge]
Apr 12 12:10:08 lamu [71021.012302] [<ffffffffa02e9a67>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
Apr 12 12:10:08 lamu [71021.025863] [<ffffffff812abe4d>] ? nf_iterate+0x41/0x77
Apr 12 12:10:08 lamu [71021.036474] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:08 lamu [71021.048994] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:08 lamu [71021.061510] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 12:10:08 lamu [71021.072643] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:08 lamu [71021.085162] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:08 lamu [71021.098894] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:08 lamu [71021.111413] [<ffffffffa02e485e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
Apr 12 12:10:08 lamu [71021.125144] [<ffffffffa02e49f2>] ? br_forward+0x16/0x5a [bridge]
Apr 12 12:10:08 lamu [71021.137318] [<ffffffffa02e551b>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
Apr 12 12:10:08 lamu [71021.151934] [<ffffffffa02e95ff>] ? br_nf_pre_routing_finish+0x1d0/0x1dd [bridge]
Apr 12 12:10:08 lamu [71021.166896] [<ffffffffa02e8ff0>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Apr 12 12:10:08 lamu [71021.179764] [<ffffffffa02e9f58>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
Apr 12 12:10:08 lamu [71021.193495] [<ffffffff812abe4d>] ? nf_iterate+0x41/0x77
Apr 12 12:10:08 lamu [71021.204106] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:08 lamu [71021.217837] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 12:10:08 lamu [71021.228967] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:08 lamu [71021.242700] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:08 lamu [71021.256433] [<ffffffffa02e5360>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
Apr 12 12:10:08 lamu [71021.270165] [<ffffffff810135ad>] ? paravirt_read_tsc+0x5/0x8
Apr 12 12:10:08 lamu [71021.281642] [<ffffffff81013622>] ? read_tsc+0x5/0x14
Apr 12 12:10:08 lamu [71021.291733] [<ffffffffa02e573c>] ? br_handle_frame+0x1b3/0x1cb [bridge]
Apr 12 12:10:08 lamu [71021.305120] [<ffffffffa02e5589>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
Apr 12 12:10:08 lamu [71021.319736] [<ffffffff812890cd>] ? __netif_receive_skb+0x324/0x41f
Apr 12 12:10:08 lamu [71021.332251] [<ffffffff81289234>] ? process_backlog+0x6c/0x123
Apr 12 12:10:08 lamu [71021.343901] [<ffffffff8128b11a>] ? net_rx_action+0xa1/0x1af
Apr 12 12:10:08 lamu [71021.355206] [<ffffffff81037013>] ? test_tsk_need_resched+0xa/0x13
Apr 12 12:10:08 lamu [71021.367552] [<ffffffff8104be98>] ? __do_softirq+0xb9/0x177
Apr 12 12:10:08 lamu [71021.378685] [<ffffffff8135026c>] ? call_softirq+0x1c/0x30
Apr 12 12:10:08 lamu [71021.389640] <EOI>
Apr 12 12:10:08 lamu
Apr 12 12:10:08 lamu [71021.393845] [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
Apr 12 12:10:08 lamu [71021.404454] [<ffffffff8128b40a>] ? netif_rx_ni+0x1e/0x27
Apr 12 12:10:08 lamu [71021.415239] [<ffffffffa02f6721>] ? tun_get_user+0x39a/0x3c2 [tun]
Apr 12 12:10:09 lamu [71021.427583] [<ffffffffa02f6a66>] ? tun_chr_poll+0xcd/0xcd [tun]
Apr 12 12:10:09 lamu [71021.439579] [<ffffffffa02f6ac4>] ? tun_chr_aio_write+0x5e/0x79 [tun]
Apr 12 12:10:09 lamu [71021.452445] [<ffffffff810f95d4>] ? do_sync_readv_writev+0x9a/0xd7
Apr 12 12:10:09 lamu [71021.464788] [<ffffffff8103642f>] ? should_resched+0x5/0x23
Apr 12 12:10:09 lamu [71021.475917] [<ffffffff810f8c56>] ? do_sync_read+0xab/0xe3
Apr 12 12:10:09 lamu [71021.486875] [<ffffffff81061a94>] ? enqueue_hrtimer+0x43/0x6a
Apr 12 12:10:09 lamu [71021.498350] [<ffffffff8103642f>] ? should_resched+0x5/0x23
Apr 12 12:10:09 lamu [71021.509483] [<ffffffff81162569>] ? security_file_permission+0x16/0x2d
Apr 12 12:10:09 lamu [71021.522520] [<ffffffff810f9838>] ? do_readv_writev+0xaf/0x11c
Apr 12 12:10:09 lamu [71021.534173] [<ffffffff8112abb6>] ? eventfd_ctx_read+0x162/0x174
Apr 12 12:10:09 lamu [71021.546174] [<ffffffff8103f467>] ? try_to_wake_up+0x197/0x197
Apr 12 12:10:09 lamu [71021.557825] [<ffffffff810f9a0d>] ? sys_writev+0x45/0x90
Apr 12 12:10:09 lamu [71021.568437] [<ffffffff8134e012>] ? system_call_fastpath+0x16/0x1b
Apr 12 12:10:09 lamu [71021.580778] Code:
Apr 12 12:10:09 53
Apr 12 12:10:09 48
Apr 12 12:10:09 89
Apr 12 12:10:09 fb
Apr 12 12:10:09 48
Apr 12 12:10:09 83
Apr 12 12:10:09 ec
Apr 12 12:10:09 10
Apr 12 12:10:09 66
Apr 12 12:10:09 81
Apr 12 12:10:09 7f
Apr 12 12:10:09 7e
Apr 12 12:10:09 08
Apr 12 12:10:09 06
Apr 12 12:10:09 4c
Apr 12 12:10:09 8b
Apr 12 12:10:09 a7
Apr 12 12:10:09 98
Apr 12 12:10:09 00
Apr 12 12:10:09 00
Apr 12 12:10:09 00
Apr 12 12:10:09 74
Apr 12 12:10:09 3d
Apr 12 12:10:09 e8
Apr 12 12:10:09 07
Apr 12 12:10:09 fe
Apr 12 12:10:09 ff
Apr 12 12:10:09 ff
Apr 12 12:10:09 66
Apr 12 12:10:09 3d
Apr 12 12:10:09 08
Apr 12 12:10:09 06
Apr 12 12:10:09 75
Apr 12 12:10:09 09
Apr 12 12:10:09 83
Apr 12 12:10:09 3d
Apr 12 12:10:09 98
Apr 12 12:10:09 6a
Apr 12 12:10:09 00
Apr 12 12:10:09 00
Apr 12 12:10:09 00
Apr 12 12:10:09 75
Apr 12 12:10:09 29
Apr 12 12:10:09 lamu
Apr 12 12:10:09 f6
Apr 12 12:10:09 44
Apr 12 12:10:09 24
Apr 12 12:10:09 18
Apr 12 12:10:09 lamu
Apr 12 12:10:09 lamu [71021.610392] ------------[ cut here ]------------
Apr 12 12:10:09 lamu [71021.610395] WARNING: at /build/buildd-linux-2.6_3.2.12-1-amd64-FiPNYf/linux-2.6-3.2.12/debian/build/source_amd64_none/kernel/softirq.c:159 _local_bh_enable_ip.isra.11+0x3d/0x88()
Apr 12 12:10:09 lamu [71021.610398] Hardware name: PowerEdge R410
Apr 12 12:10:09 lamu [71021.610399] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ip_vs_rr ip_vs nf_conntrack libcrc32c ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables crc32c drbd lru_cache cn sit tunnel4 tun bridge stp virtio_net virtio_blk virtio_rng rng_core virtio_pci virtio_ring virtio kvm_intel kvm ipmi_devintf ipmi_poweroff ipmi_si ipmi_watchdog ipmi_msghandler netconsole configfs loop option usb_wwan usbserial uas snd_pcm snd_page_alloc snd_timer snd iTCO_wdt iTCO_vendor_support psmouse i7core_edac edac_core processor button soundcore joydev serio_raw pcspkr evdev dcdbas thermal_sys ext3 mbcache jbd dm_mod sr_mod cdrom ses sd_mod usbhid hid crc_t10dif enclosure ata_generic uhci_hcd ata_piix ehci_hcd libata usbcore megaraid_sas scsi_mod usb_common bnx2 [last unloaded: usb_storage]
Apr 12 12:10:09 lamu [71021.610438] Pid: 6997, comm: kvm Not tainted 3.2.0-2-amd64 #1
Apr 12 12:10:09 lamu [71021.610439] Call Trace:
Apr 12 12:10:09 lamu [71021.610440] <IRQ> [<ffffffff81046879>] ? warn_slowpath_common+0x78/0x8c
Apr 12 12:10:09 lamu [71021.610447] [<ffffffff8104bd8a>] ? _local_bh_enable_ip.isra.11+0x3d/0x88
Apr 12 12:10:09 lamu [71021.610454] [<ffffffffa003d748>] ? bnx2_reg_rd_ind+0x31/0x38 [bnx2]
Apr 12 12:10:09 lamu [71021.610460] [<ffffffffa00467d7>] ? bnx2_poll+0x1b7/0x1c4 [bnx2]
Apr 12 12:10:09 lamu [71021.610466] [<ffffffff8129af69>] ? netpoll_poll_dev.part.16+0x9b/0x499
Apr 12 12:10:09 lamu [71021.610475] [<ffffffffa02e331a>] ? br_dev_xmit+0x12e/0x142 [bridge]
Apr 12 12:10:09 lamu [71021.610478] [<ffffffff8129b432>] ? netpoll_send_skb_on_dev+0xcb/0x201
Apr 12 12:10:09 lamu [71021.610483] [<ffffffffa021325c>] ? write_msg+0x98/0xf3 [netconsole]
Apr 12 12:10:09 lamu [71021.610487] [<ffffffff810469c2>] ? __call_console_drivers+0x72/0x83
Apr 12 12:10:09 lamu [71021.610490] [<ffffffff8104708e>] ? console_unlock+0x144/0x1e8
Apr 12 12:10:09 lamu [71021.610493] [<ffffffff810475b1>] ? vprintk+0x396/0x3d9
Apr 12 12:10:09 lamu [71021.610499] [<ffffffffa02e933b>] ? br_nf_forward_finish+0x33/0x95 [bridge]
Apr 12 12:10:09 lamu [71021.610504] [<ffffffffa02e930b>] ? br_nf_forward_finish+0x3/0x95 [bridge]
Apr 12 12:10:09 lamu [71021.610510] [<ffffffff81342a83>] ? printk+0x43/0x48
Apr 12 12:10:09 lamu [71021.610513] [<ffffffff8100fe6a>] ? show_registers+0x1de/0x20a
Apr 12 12:10:09 lamu [71021.610517] [<ffffffff81349f1e>] ? __die+0x8b/0xc8
Apr 12 12:10:09 lamu [71021.610520] [<ffffffff81342253>] ? no_context+0x1d6/0x20e
Apr 12 12:10:09 lamu [71021.610523] [<ffffffff810522ca>] ? __mod_timer+0x139/0x14b
Apr 12 12:10:09 lamu [71021.610526] [<ffffffff8134be99>] ? do_page_fault+0x1a8/0x337
Apr 12 12:10:09 lamu [71021.610531] [<ffffffffa03bef06>] ? ip_vs_conn_put+0x28/0x32 [ip_vs]
Apr 12 12:10:09 lamu [71021.610536] [<ffffffffa03c10e0>] ? ip_vs_out+0x2bd/0x432 [ip_vs]
Apr 12 12:10:09 lamu [71021.610539] [<ffffffff8128beef>] ? dev_hard_start_xmit+0x3fc/0x543
Apr 12 12:10:09 lamu [71021.610542] [<ffffffff813495f5>] ? page_fault+0x25/0x30
Apr 12 12:10:09 lamu [71021.610548] [<ffffffffa02e9308>] ? nf_bridge_update_protocol+0x20/0x20 [bridge]
Apr 12 12:10:09 lamu [71021.610554] [<ffffffffa02e9336>] ? br_nf_forward_finish+0x2e/0x95 [bridge]
Apr 12 12:10:09 lamu [71021.610559] [<ffffffffa02e9327>] ? br_nf_forward_finish+0x1f/0x95 [bridge]
Apr 12 12:10:09 lamu [71021.610565] [<ffffffffa02e96db>] ? br_parse_ip_options+0x3d/0x19a [bridge]
Apr 12 12:10:09 lamu [71021.610570] [<ffffffffa02e9a67>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
Apr 12 12:10:09 lamu [71021.610573] [<ffffffff812abe4d>] ? nf_iterate+0x41/0x77
Apr 12 12:10:09 lamu [71021.610578] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:09 lamu [71021.610582] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:09 lamu [71021.610585] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 12:10:09 lamu [71021.610590] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:09 lamu [71021.610595] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:09 lamu [71021.610599] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:09 lamu [71021.610604] [<ffffffffa02e485e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
Apr 12 12:10:09 lamu [71021.610608] [<ffffffffa02e49f2>] ? br_forward+0x16/0x5a [bridge]
Apr 12 12:10:09 lamu [71021.610613] [<ffffffffa02e551b>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
Apr 12 12:10:09 lamu [71021.610619] [<ffffffffa02e95ff>] ? br_nf_pre_routing_finish+0x1d0/0x1dd [bridge]
Apr 12 12:10:09 lamu [71021.610624] [<ffffffffa02e8ff0>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Apr 12 12:10:09 lamu [71021.610630] [<ffffffffa02e9f58>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
Apr 12 12:10:09 lamu [71021.610633] [<ffffffff812abe4d>] ? nf_iterate+0x41/0x77
Apr 12 12:10:09 lamu [71021.610638] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:09 lamu [71021.610641] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 12:10:09 lamu [71021.610646] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:09 lamu [71021.610651] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:09 lamu [71021.610656] [<ffffffffa02e5360>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
Apr 12 12:10:10 lamu [71021.610659] [<ffffffff810135ad>] ? paravirt_read_tsc+0x5/0x8
Apr 12 12:10:10 lamu [71021.610661] [<ffffffff81013622>] ? read_tsc+0x5/0x14
Apr 12 12:10:10 lamu [71021.610666] [<ffffffffa02e573c>] ? br_handle_frame+0x1b3/0x1cb [bridge]
Apr 12 12:10:10 lamu [71021.610671] [<ffffffffa02e5589>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
Apr 12 12:10:10 lamu [71021.610674] [<ffffffff812890cd>] ? __netif_receive_skb+0x324/0x41f
Apr 12 12:10:10 lamu [71021.610677] [<ffffffff81289234>] ? process_backlog+0x6c/0x123
Apr 12 12:10:10 lamu [71021.610681] [<ffffffff8128b11a>] ? net_rx_action+0xa1/0x1af
Apr 12 12:10:10 lamu [71021.610683] [<ffffffff81037013>] ? test_tsk_need_resched+0xa/0x13
Apr 12 12:10:10 lamu [71021.610686] [<ffffffff8104be98>] ? __do_softirq+0xb9/0x177
Apr 12 12:10:10 lamu [71021.610689] [<ffffffff8135026c>] ? call_softirq+0x1c/0x30
Apr 12 12:10:10 lamu [71021.610691] <EOI> [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
Apr 12 12:10:10 lamu [71021.610696] [<ffffffff8128b40a>] ? netif_rx_ni+0x1e/0x27
Apr 12 12:10:10 lamu [71021.610699] [<ffffffffa02f6721>] ? tun_get_user+0x39a/0x3c2 [tun]
Apr 12 12:10:10 lamu [71021.610703] [<ffffffffa02f6a66>] ? tun_chr_poll+0xcd/0xcd [tun]
Apr 12 12:10:10 lamu [71021.610707] [<ffffffffa02f6ac4>] ? tun_chr_aio_write+0x5e/0x79 [tun]
Apr 12 12:10:10 lamu [71021.610710] [<ffffffff810f95d4>] ? do_sync_readv_writev+0x9a/0xd7
Apr 12 12:10:10 lamu [71021.610712] [<ffffffff8103642f>] ? should_resched+0x5/0x23
Apr 12 12:10:10 lamu [71021.610715] [<ffffffff810f8c56>] ? do_sync_read+0xab/0xe3
Apr 12 12:10:10 lamu [71021.610718] [<ffffffff81061a94>] ? enqueue_hrtimer+0x43/0x6a
Apr 12 12:10:10 lamu [71021.610720] [<ffffffff8103642f>] ? should_resched+0x5/0x23
Apr 12 12:10:10 lamu [71021.610723] [<ffffffff81162569>] ? security_file_permission+0x16/0x2d
Apr 12 12:10:10 lamu [71021.610726] [<ffffffff810f9838>] ? do_readv_writev+0xaf/0x11c
Apr 12 12:10:10 lamu [71021.610729] [<ffffffff8112abb6>] ? eventfd_ctx_read+0x162/0x174
Apr 12 12:10:10 lamu [71021.610732] [<ffffffff8103f467>] ? try_to_wake_up+0x197/0x197
Apr 12 12:10:10 lamu [71021.610735] [<ffffffff810f9a0d>] ? sys_writev+0x45/0x90
Apr 12 12:10:10 lamu [71021.610738] [<ffffffff8134e012>] ? system_call_fastpath+0x16/0x1b
Apr 12 12:10:10 lamu [71021.610740] ---[ end trace 8375ccada030e5cf ]---
Apr 12 12:10:10 lamu [71022.752807] 01
Apr 12 12:10:10 49
Apr 12 12:10:10 8b
Apr 12 12:10:10 6c
Apr 12 12:10:10 24
Apr 12 12:10:10 08
Apr 12 12:10:10 74
Apr 12 12:10:10 12
Apr 12 12:10:10 8a
Apr 12 12:10:10 43
Apr 12 12:10:10 7d
Apr 12 12:10:10 83
Apr 12 12:10:10 e0
Apr 12 12:10:10 f8
Apr 12 12:10:10 83
Apr 12 12:10:10 c8
Apr 12 12:10:10 lamu
Apr 12 12:10:10 lamu [71022.764300] RIP
Apr 12 12:10:10 lamu [<ffffffffa02e9336>] br_nf_forward_finish+0x2e/0x95 [bridge]
Apr 12 12:10:10 lamu [71022.778567] RSP <ffff88042fc03b18>
Apr 12 12:10:10 lamu [71022.785531] CR2: 0000000000000018
Apr 12 12:10:10 lamu [71022.792904] ---[ end trace 8375ccada030e5d0 ]---
Apr 12 12:10:10 lamu [71022.802344] Kernel panic - not syncing: Fatal exception in interrupt
Apr 12 12:10:10 lamu [71022.815396] Pid: 6997, comm: kvm Tainted: G D W 3.2.0-2-amd64 #1
Apr 12 12:10:10 lamu [71022.829110] Call Trace:
Apr 12 12:10:10 lamu [71022.834258] <IRQ>
Apr 12 12:10:10 lamu [<ffffffff81342930>] ? panic+0x95/0x1a5
Apr 12 12:10:10 lamu [71022.845768] [<ffffffff81349e86>] ? oops_end+0xa9/0xb6
Apr 12 12:10:10 lamu [71022.856213] [<ffffffff8134227c>] ? no_context+0x1ff/0x20e
Apr 12 12:10:10 lamu [71022.867373] [<ffffffff810522ca>] ? __mod_timer+0x139/0x14b
Apr 12 12:10:10 lamu [71022.878693] [<ffffffff8134be99>] ? do_page_fault+0x1a8/0x337
Apr 12 12:10:10 lamu [71022.890360] [<ffffffffa03bef06>] ? ip_vs_conn_put+0x28/0x32 [ip_vs]
Apr 12 12:10:10 lamu [71022.903203] [<ffffffffa03c10e0>] ? ip_vs_out+0x2bd/0x432 [ip_vs]
Apr 12 12:10:10 lamu [71022.915544] [<ffffffff8128beef>] ? dev_hard_start_xmit+0x3fc/0x543
Apr 12 12:10:10 lamu [71022.928295] [<ffffffff813495f5>] ? page_fault+0x25/0x30
Apr 12 12:10:10 lamu [71022.939318] [<ffffffffa02e9308>] ? nf_bridge_update_protocol+0x20/0x20 [bridge]
Apr 12 12:10:10 lamu [71022.954340] [<ffffffffa02e9336>] ? br_nf_forward_finish+0x2e/0x95 [bridge]
Apr 12 12:10:10 lamu [71022.968527] [<ffffffffa02e9327>] ? br_nf_forward_finish+0x1f/0x95 [bridge]
Apr 12 12:10:10 lamu [71022.982717] [<ffffffffa02e96db>] ? br_parse_ip_options+0x3d/0x19a [bridge]
Apr 12 12:10:10 lamu [71022.996993] [<ffffffffa02e9a67>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
Apr 12 12:10:10 lamu [71023.010841] [<ffffffff812abe4d>] ? nf_iterate+0x41/0x77
Apr 12 12:10:10 lamu [71023.021812] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:10 lamu [71023.034570] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:10 lamu [71023.047401] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 12:10:10 lamu [71023.058757] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:10 lamu [71023.071501] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:10 lamu [71023.085667] [<ffffffffa02e4918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 12:10:10 lamu [71023.098483] [<ffffffffa02e485e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
Apr 12 12:10:10 lamu [71023.112500] [<ffffffffa02e49f2>] ? br_forward+0x16/0x5a [bridge]
Apr 12 12:10:10 lamu [71023.124825] [<ffffffffa02e551b>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
Apr 12 12:10:10 lamu [71023.139763] [<ffffffffa02e95ff>] ? br_nf_pre_routing_finish+0x1d0/0x1dd [bridge]
Apr 12 12:10:10 lamu [71023.154965] [<ffffffffa02e8ff0>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Apr 12 12:10:10 lamu [71023.168151] [<ffffffffa02e9f58>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
Apr 12 12:10:10 lamu [71023.182191] [<ffffffff812abe4d>] ? nf_iterate+0x41/0x77
Apr 12 12:10:10 lamu [71023.193200] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:10 lamu [71023.207169] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 12:10:10 lamu [71023.218614] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:10 lamu [71023.232581] [<ffffffffa02e537a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 12:10:10 lamu [71023.246548] [<ffffffffa02e5360>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
Apr 12 12:10:10 lamu [71023.260552] [<ffffffff810135ad>] ? paravirt_read_tsc+0x5/0x8
Apr 12 12:10:10 lamu [71023.272274] [<ffffffff81013622>] ? read_tsc+0x5/0x14
Apr 12 12:10:10 lamu [71023.282710] [<ffffffffa02e573c>] ? br_handle_frame+0x1b3/0x1cb [bridge]
Apr 12 12:10:10 lamu [71023.296308] [<ffffffffa02e5589>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
Apr 12 12:10:10 lamu [71023.296338] block drbd4: PingAck did not arrive in time.
Apr 12 12:10:10 lamu [71023.296347] block drbd4: peer( Secondary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
Apr 12 12:10:10 lamu [71023.343474] [<ffffffff812890cd>] ? __netif_receive_skb+0x324/0x41f
Apr 12 12:10:10 lamu [71023.356221] [<ffffffff81289234>] ? process_backlog+0x6c/0x123
Apr 12 12:10:10 lamu [71023.368057] [<ffffffff8128b11a>] ? net_rx_action+0xa1/0x1af
Apr 12 12:10:10 lamu [71023.379483] [<ffffffff81037013>] ? test_tsk_need_resched+0xa/0x13
Apr 12 12:10:10 lamu [71023.391998] [<ffffffff8104be98>] ? __do_softirq+0xb9/0x177
Apr 12 12:10:10 lamu [71023.403332] [<ffffffff8135026c>] ? call_softirq+0x1c/0x30
Apr 12 12:10:10 lamu [71023.414444] <EOI>
Apr 12 12:10:10 lamu [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
Apr 12 12:10:11 lamu [71023.426647] [<ffffffff8128b40a>] ? netif_rx_ni+0x1e/0x27
Apr 12 12:10:11 lamu [71023.437640] [<ffffffffa02f6721>] ? tun_get_user+0x39a/0x3c2 [tun]
Apr 12 12:10:11 lamu [71023.450264] [<ffffffffa02f6a66>] ? tun_chr_poll+0xcd/0xcd [tun]
Apr 12 12:10:11 lamu [71023.462501] [<ffffffffa02f6ac4>] ? tun_chr_aio_write+0x5e/0x79 [tun]
Apr 12 12:10:11 lamu [71023.475526] [<ffffffff810f95d4>] ? do_sync_readv_writev+0x9a/0xd7
Apr 12 12:10:11 lamu [71023.488074] [<ffffffff8103642f>] ? should_resched+0x5/0x23
Apr 12 12:10:11 lamu [71023.499357] [<ffffffff810f8c56>] ? do_sync_read+0xab/0xe3
Apr 12 12:10:11 lamu [71023.510429] [<ffffffff81061a94>] ? enqueue_hrtimer+0x43/0x6a
Apr 12 12:10:11 lamu [71023.522066] [<ffffffff8103642f>] ? should_resched+0x5/0x23
Apr 12 12:10:11 lamu [71023.533310] [<ffffffff81162569>] ? security_file_permission+0x16/0x2d
Apr 12 12:10:11 lamu [71023.546463] [<ffffffff810f9838>] ? do_readv_writev+0xaf/0x11c
Apr 12 12:10:11 lamu [71023.558352] [<ffffffff8112abb6>] ? eventfd_ctx_read+0x162/0x174
Apr 12 12:10:11 lamu [71023.570467] [<ffffffff8103f467>] ? try_to_wake_up+0x197/0x197
Apr 12 12:10:11 lamu [71023.582316] [<ffffffff810f9a0d>] ? sys_writev+0x45/0x90
Apr 12 12:10:11 lamu [71023.593177] [<ffffffff8134e012>] ? system_call_fastpath+0x16/0x1b
[-- Attachment #3: BUG2.txt --]
[-- Type: text/plain, Size: 17365 bytes --]
Apr 12 13:22:05 lamu [ 4116.902924] BUG: unable to handle kernel
Apr 12 13:22:05 NULL pointer dereference
Apr 12 13:22:05 lamu at 0000000000000018
Apr 12 13:22:05 lamu [ 4116.918581] IP:
Apr 12 13:22:05 lamu [<ffffffffa02d2336>] br_nf_forward_finish+0x2e/0x95 [bridge]
Apr 12 13:22:05 lamu [ 4116.932666] PGD 0
Apr 12 13:22:05 lamu
Apr 12 13:22:05 lamu [ 4116.936681] Oops: 0000 [#1]
Apr 12 13:22:05 SMP
Apr 12 13:22:05 lamu
Apr 12 13:22:05 lamu [ 4116.943136] CPU 0
Apr 12 13:22:05 lamu
Apr 12 13:22:05 lamu [ 4116.946792] Modules linked in:
Apr 12 13:22:05 lamu option
Apr 12 13:22:05 lamu usb_wwan
Apr 12 13:22:05 lamu usbserial
Apr 12 13:22:05 lamu usb_storage
Apr 12 13:22:05 lamu uas
Apr 12 13:22:05 lamu ipt_MASQUERADE
Apr 12 13:22:05 lamu iptable_nat
Apr 12 13:22:05 lamu nf_nat
Apr 12 13:22:05 lamu nf_conntrack_ipv4
Apr 12 13:22:05 lamu nf_defrag_ipv4
Apr 12 13:22:05 lamu ip_vs_rr
Apr 12 13:22:05 lamu ip_vs
Apr 12 13:22:05 lamu nf_conntrack
Apr 12 13:22:05 lamu libcrc32c
Apr 12 13:22:05 lamu ip6table_filter
Apr 12 13:22:05 lamu ip6_tables
Apr 12 13:22:05 lamu iptable_filter
Apr 12 13:22:05 lamu ip_tables
Apr 12 13:22:05 lamu ebtable_nat
Apr 12 13:22:05 lamu ebtables
Apr 12 13:22:05 lamu x_tables
Apr 12 13:22:05 lamu crc32c
Apr 12 13:22:05 lamu drbd
Apr 12 13:22:05 lamu lru_cache
Apr 12 13:22:05 lamu cn
Apr 12 13:22:05 lamu sit
Apr 12 13:22:05 lamu tunnel4
Apr 12 13:22:05 lamu tun
Apr 12 13:22:05 lamu bridge
Apr 12 13:22:05 lamu stp
Apr 12 13:22:05 lamu virtio_net
Apr 12 13:22:05 lamu virtio_blk
Apr 12 13:22:05 lamu virtio_rng
Apr 12 13:22:05 lamu rng_core
Apr 12 13:22:05 lamu virtio_pci
Apr 12 13:22:05 lamu virtio_ring
Apr 12 13:22:05 lamu virtio
Apr 12 13:22:05 lamu kvm_intel
Apr 12 13:22:05 lamu kvm
Apr 12 13:22:05 lamu ipmi_devintf
Apr 12 13:22:05 lamu ipmi_poweroff
Apr 12 13:22:05 lamu ipmi_si
Apr 12 13:22:05 lamu ipmi_watchdog
Apr 12 13:22:05 lamu ipmi_msghandler
Apr 12 13:22:05 lamu netconsole
Apr 12 13:22:05 lamu configfs
Apr 12 13:22:05 lamu loop
Apr 12 13:22:05 lamu snd_pcm
Apr 12 13:22:05 lamu snd_page_alloc
Apr 12 13:22:05 lamu iTCO_wdt
Apr 12 13:22:05 lamu snd_timer
Apr 12 13:22:05 lamu snd
Apr 12 13:22:05 lamu processor
Apr 12 13:22:05 lamu button
Apr 12 13:22:05 lamu iTCO_vendor_support
Apr 12 13:22:05 lamu joydev
Apr 12 13:22:05 lamu i7core_edac
Apr 12 13:22:05 lamu edac_core
Apr 12 13:22:05 lamu soundcore
Apr 12 13:22:05 lamu pcspkr
Apr 12 13:22:05 lamu psmouse
Apr 12 13:22:05 lamu serio_raw
Apr 12 13:22:05 lamu evdev
Apr 12 13:22:05 lamu thermal_sys
Apr 12 13:22:05 lamu dcdbas
Apr 12 13:22:05 lamu ext3
Apr 12 13:22:05 lamu mbcache
Apr 12 13:22:05 lamu jbd
Apr 12 13:22:05 lamu dm_mod
Apr 12 13:22:05 lamu sr_mod
Apr 12 13:22:05 lamu cdrom
Apr 12 13:22:05 lamu sd_mod
Apr 12 13:22:05 lamu ses
Apr 12 13:22:05 lamu usbhid
Apr 12 13:22:05 lamu hid
Apr 12 13:22:05 lamu enclosure
Apr 12 13:22:05 lamu crc_t10dif
Apr 12 13:22:05 lamu ata_generic
Apr 12 13:22:05 lamu ata_piix
Apr 12 13:22:05 lamu uhci_hcd
Apr 12 13:22:05 lamu libata
Apr 12 13:22:05 lamu ehci_hcd
Apr 12 13:22:05 lamu megaraid_sas
Apr 12 13:22:05 lamu usbcore
Apr 12 13:22:05 lamu scsi_mod
Apr 12 13:22:05 lamu usb_common
Apr 12 13:22:05 lamu bnx2
Apr 12 13:22:05 lamu [last unloaded: scsi_wait_scan]
Apr 12 13:22:05 lamu
Apr 12 13:22:05 lamu [ 4117.098774]
Apr 12 13:22:05 lamu [ 4117.101737] Pid: 5417, comm: kvm Not tainted 3.2.0-2-amd64 #1
Apr 12 13:22:05 lamu Dell Inc. PowerEdge R410
Apr 12 13:22:05 lamu /0N051F
Apr 12 13:22:05 lamu
Apr 12 13:22:05 lamu [ 4117.118781] RIP: 0010:[<ffffffffa02d2336>]
Apr 12 13:22:05 lamu [<ffffffffa02d2336>] br_nf_forward_finish+0x2e/0x95 [bridge]
Apr 12 13:22:05 lamu [ 4117.137734] RSP: 0018:ffff88042fc03b18 EFLAGS: 00010293
Apr 12 13:22:05 lamu [ 4117.148342] RAX: 0000000000000000 RBX: ffff88041a59cc80 RCX: 0000000000000006
Apr 12 13:22:05 lamu [ 4117.162591] RDX: ffffffffa02d2308 RSI: 00000001000ecc40 RDI: ffff88041a59cc80
Apr 12 13:22:05 lamu [ 4117.176840] RBP: ffff880424574000 R08: 0000000000000000 R09: ffff88042fc03ad0
Apr 12 13:22:05 lamu [ 4117.191088] R10: ffffffff8165aac0 R11: ffffffff8165aac0 R12: 0000000000000000
Apr 12 13:22:05 lamu [ 4117.205338] R13: ffff880225b90002 R14: ffff88042543c8c0 R15: ffff880225b90000
Apr 12 13:22:05 lamu [ 4117.219589] FS: 00007f673f979900(0000) GS:ffff88042fc00000(0000) knlGS:0000000000000000
Apr 12 13:22:05 lamu [ 4117.235765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 12 13:22:05 lamu [ 4117.247239] CR2: 0000000000000018 CR3: 00000001be517000 CR4: 00000000000026e0
Apr 12 13:22:05 lamu [ 4117.261488] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 12 13:22:05 lamu [ 4117.275738] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr 12 13:22:05 lamu [ 4117.289988] Process kvm (pid: 5417, threadinfo ffff8801be51e000, task ffff880226aea240)
Apr 12 13:22:05 lamu [ 4117.305985] Stack:
Apr 12 13:22:05 lamu [ 4117.310002] ffffffff80000000
Apr 12 13:22:05 lamu ffffffffa02d26db
Apr 12 13:22:05 lamu ffff88041a59cc80
Apr 12 13:22:05 lamu ffff880424574000
Apr 12 13:22:05 lamu
Apr 12 13:22:05 lamu [ 4117.324838] ffff880424411000
Apr 12 13:22:05 lamu ffffffffa02d2a67
Apr 12 13:22:05 lamu ffff880480000000
Apr 12 13:22:05 lamu 0000000200000000
Apr 12 13:22:05 lamu
Apr 12 13:22:05 lamu [ 4117.339670] ffff88041a59cc80
Apr 12 13:22:05 lamu ffffffffa02d8cd0
Apr 12 13:22:05 lamu ffffffff81691190
Apr 12 13:22:05 lamu 0000000000000002
Apr 12 13:22:05 lamu
Apr 12 13:22:05 lamu [ 4117.354501] Call Trace:
Apr 12 13:22:05 lamu [ 4117.359386] <IRQ>
Apr 12 13:22:05 lamu
Apr 12 13:22:05 lamu [ 4117.363594] [<ffffffffa02d26db>] ? br_parse_ip_options+0x3d/0x19a [bridge]
Apr 12 13:22:05 lamu [ 4117.377501] [<ffffffffa02d2a67>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
Apr 12 13:22:05 lamu [ 4117.391063] [<ffffffff812abe4d>] ? nf_iterate+0x41/0x77
Apr 12 13:22:05 lamu [ 4117.401673] [<ffffffffa02cd918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 13:22:05 lamu [ 4117.414191] [<ffffffffa02cd918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 13:22:05 lamu [ 4117.426708] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 13:22:05 lamu [ 4117.437839] [<ffffffffa02cd918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 13:22:05 lamu [ 4117.450358] [<ffffffffa02ce37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 13:22:05 lamu [ 4117.464092] [<ffffffffa02cd918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 13:22:05 lamu [ 4117.476612] [<ffffffffa02cd85e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
Apr 12 13:22:05 lamu [ 4117.490345] [<ffffffffa02cd9f2>] ? br_forward+0x16/0x5a [bridge]
Apr 12 13:22:05 lamu [ 4117.502517] [<ffffffffa02ce51b>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
Apr 12 13:22:05 lamu [ 4117.517132] [<ffffffffa02d25ff>] ? br_nf_pre_routing_finish+0x1d0/0x1dd [bridge]
Apr 12 13:22:05 lamu [ 4117.532096] [<ffffffffa02d1ff0>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Apr 12 13:22:05 lamu [ 4117.544963] [<ffffffffa02d2f58>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
Apr 12 13:22:05 lamu [ 4117.558695] [<ffffffff812abe4d>] ? nf_iterate+0x41/0x77
Apr 12 13:22:05 lamu [ 4117.569309] [<ffffffff8128affc>] ? napi_gro_receive+0x1d/0x2b
Apr 12 13:22:05 lamu [ 4117.580957] [<ffffffff8128aba6>] ? napi_skb_finish+0x1c/0x31
Apr 12 13:22:05 lamu [ 4117.592436] [<ffffffffa02ce37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 13:22:05 lamu [ 4117.606167] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 13:22:05 lamu [ 4117.617298] [<ffffffffa02ce37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 13:22:05 lamu [ 4117.631033] [<ffffffffa02ce37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 13:22:05 lamu [ 4117.644766] [<ffffffffa02ce360>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
Apr 12 13:22:05 lamu [ 4117.658498] [<ffffffff8128b06a>] ? napi_complete+0x28/0x37
Apr 12 13:22:05 lamu [ 4117.669629] [<ffffffffa02ce73c>] ? br_handle_frame+0x1b3/0x1cb [bridge]
Apr 12 13:22:05 lamu [ 4117.683016] [<ffffffffa02ce589>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
Apr 12 13:22:05 lamu [ 4117.697630] [<ffffffff812890cd>] ? __netif_receive_skb+0x324/0x41f
Apr 12 13:22:05 lamu [ 4117.710146] [<ffffffff81289234>] ? process_backlog+0x6c/0x123
Apr 12 13:22:06 lamu [ 4117.721797] [<ffffffff8128b11a>] ? net_rx_action+0xa1/0x1af
Apr 12 13:22:06 lamu [ 4117.733102] [<ffffffff81037013>] ? test_tsk_need_resched+0xa/0x13
Apr 12 13:22:06 lamu [ 4117.745446] [<ffffffff8104be98>] ? __do_softirq+0xb9/0x177
Apr 12 13:22:06 lamu [ 4117.756579] [<ffffffff8135026c>] ? call_softirq+0x1c/0x30
Apr 12 13:22:06 lamu [ 4117.767535] <EOI>
Apr 12 13:22:06 lamu
Apr 12 13:22:06 lamu [ 4117.771741] [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
Apr 12 13:22:06 lamu [ 4117.782350] [<ffffffff8128b40a>] ? netif_rx_ni+0x1e/0x27
Apr 12 13:22:06 lamu [ 4117.793134] [<ffffffffa025b721>] ? tun_get_user+0x39a/0x3c2 [tun]
Apr 12 13:22:06 lamu [ 4117.805477] [<ffffffffa025ba66>] ? tun_chr_poll+0xcd/0xcd [tun]
Apr 12 13:22:06 lamu [ 4117.817475] [<ffffffffa025bac4>] ? tun_chr_aio_write+0x5e/0x79 [tun]
Apr 12 13:22:06 lamu [ 4117.830342] [<ffffffff810f95d4>] ? do_sync_readv_writev+0x9a/0xd7
Apr 12 13:22:06 lamu [ 4117.842686] [<ffffffff8103642f>] ? should_resched+0x5/0x23
Apr 12 13:22:06 lamu [ 4117.853817] [<ffffffff810f8c56>] ? do_sync_read+0xab/0xe3
Apr 12 13:22:06 lamu [ 4117.864772] [<ffffffff8103642f>] ? should_resched+0x5/0x23
Apr 12 13:22:06 lamu [ 4117.875906] [<ffffffff81162569>] ? security_file_permission+0x16/0x2d
Apr 12 13:22:06 lamu [ 4117.888942] [<ffffffff810f9838>] ? do_readv_writev+0xaf/0x11c
Apr 12 13:22:06 lamu [ 4117.900596] [<ffffffff8112abb6>] ? eventfd_ctx_read+0x162/0x174
Apr 12 13:22:06 lamu [ 4117.912597] [<ffffffff8103f467>] ? try_to_wake_up+0x197/0x197
Apr 12 13:22:06 lamu [ 4117.924248] [<ffffffff810f9a0d>] ? sys_writev+0x45/0x90
Apr 12 13:22:06 lamu [ 4117.934859] [<ffffffff8134e012>] ? system_call_fastpath+0x16/0x1b
Apr 12 13:22:06 lamu [ 4117.947201] Code:
Apr 12 13:22:06 53
Apr 12 13:22:06 48
Apr 12 13:22:06 89
Apr 12 13:22:06 fb
Apr 12 13:22:06 48
Apr 12 13:22:06 83
Apr 12 13:22:06 ec
Apr 12 13:22:06 10
Apr 12 13:22:06 66
Apr 12 13:22:06 81
Apr 12 13:22:06 7f
Apr 12 13:22:06 7e
Apr 12 13:22:06 08
Apr 12 13:22:06 06
Apr 12 13:22:06 4c
Apr 12 13:22:06 8b
Apr 12 13:22:06 a7
Apr 12 13:22:06 98
Apr 12 13:22:06 00
Apr 12 13:22:06 00
Apr 12 13:22:06 00
Apr 12 13:22:06 74
Apr 12 13:22:06 3d
Apr 12 13:22:06 e8
Apr 12 13:22:06 07
Apr 12 13:22:06 fe
Apr 12 13:22:06 ff
Apr 12 13:22:06 ff
Apr 12 13:22:06 66
Apr 12 13:22:06 3d
Apr 12 13:22:06 08
Apr 12 13:22:06 06
Apr 12 13:22:06 75
Apr 12 13:22:06 09
Apr 12 13:22:06 83
Apr 12 13:22:06 3d
Apr 12 13:22:06 98
Apr 12 13:22:06 6a
Apr 12 13:22:06 00
Apr 12 13:22:06 00
Apr 12 13:22:06 00
Apr 12 13:22:06 75
Apr 12 13:22:06 29
Apr 12 13:22:06 lamu
Apr 12 13:22:06 f6
Apr 12 13:22:06 44
Apr 12 13:22:06 24
Apr 12 13:22:06 18
Apr 12 13:22:06 01
Apr 12 13:22:06 49
Apr 12 13:22:06 8b
Apr 12 13:22:06 6c
Apr 12 13:22:06 24
Apr 12 13:22:06 08
Apr 12 13:22:06 74
Apr 12 13:22:06 12
Apr 12 13:22:06 8a
Apr 12 13:22:06 43
Apr 12 13:22:06 7d
Apr 12 13:22:06 83
Apr 12 13:22:06 e0
Apr 12 13:22:06 f8
Apr 12 13:22:06 83
Apr 12 13:22:06 c8
Apr 12 13:22:06 lamu
Apr 12 13:22:06 lamu [ 4117.985837] RIP
Apr 12 13:22:06 lamu [<ffffffffa02d2336>] br_nf_forward_finish+0x2e/0x95 [bridge]
Apr 12 13:22:06 lamu [ 4118.000102] RSP <ffff88042fc03b18>
Apr 12 13:22:06 lamu [ 4118.007067] CR2: 0000000000000018
Apr 12 13:22:06 lamu [ 4118.014273] ---[ end trace c19a5656967502d9 ]---
Apr 12 13:22:06 lamu [ 4118.023651] Kernel panic - not syncing: Fatal exception in interrupt
Apr 12 13:22:06 lamu [ 4118.036551] Pid: 5417, comm: kvm Tainted: G D 3.2.0-2-amd64 #1
Apr 12 13:22:06 lamu [ 4118.050125] Call Trace:
Apr 12 13:22:06 lamu [ 4118.055141] <IRQ>
Apr 12 13:22:06 lamu [<ffffffff81342930>] ? panic+0x95/0x1a5
Apr 12 13:22:06 lamu [ 4118.066812] [<ffffffff81349e86>] ? oops_end+0xa9/0xb6
Apr 12 13:22:06 lamu [ 4118.077374] [<ffffffff8134227c>] ? no_context+0x1ff/0x20e
Apr 12 13:22:06 lamu [ 4118.088585] [<ffffffff810e9cd8>] ? virt_to_slab+0x6/0x16
Apr 12 13:22:06 lamu [ 4118.099505] [<ffffffff8134be99>] ? do_page_fault+0x1a8/0x337
Apr 12 13:22:06 lamu [ 4118.111234] [<ffffffffa03b4f06>] ? ip_vs_conn_put+0x28/0x32 [ip_vs]
Apr 12 13:22:06 lamu [ 4118.124097] [<ffffffffa03b70e0>] ? ip_vs_out+0x2bd/0x432 [ip_vs]
Apr 12 13:22:06 lamu [ 4118.136534] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 13:22:06 lamu [ 4118.147846] [<ffffffff813495f5>] ? page_fault+0x25/0x30
Apr 12 13:22:06 lamu [ 4118.158871] [<ffffffffa02d2308>] ? nf_bridge_update_protocol+0x20/0x20 [bridge]
Apr 12 13:22:06 lamu [ 4118.173852] [<ffffffffa02d2336>] ? br_nf_forward_finish+0x2e/0x95 [bridge]
Apr 12 13:22:06 lamu [ 4118.187919] [<ffffffffa02d2327>] ? br_nf_forward_finish+0x1f/0x95 [bridge]
Apr 12 13:22:06 lamu [ 4118.202024] [<ffffffffa02d26db>] ? br_parse_ip_options+0x3d/0x19a [bridge]
Apr 12 13:22:06 lamu [ 4118.216187] [<ffffffffa02d2a67>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
Apr 12 13:22:06 lamu [ 4118.230137] [<ffffffff812abe4d>] ? nf_iterate+0x41/0x77
Apr 12 13:22:06 lamu [ 4118.241005] [<ffffffffa02cd918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 13:22:06 lamu [ 4118.253701] [<ffffffffa02cd918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 13:22:06 lamu [ 4118.266471] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 13:22:06 lamu [ 4118.277931] [<ffffffffa02cd918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 13:22:06 lamu [ 4118.290618] [<ffffffffa02ce37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 13:22:06 lamu [ 4118.304695] [<ffffffffa02cd918>] ? __br_deliver+0xa0/0xa0 [bridge]
Apr 12 13:22:06 lamu [ 4118.317523] [<ffffffffa02cd85e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
Apr 12 13:22:06 lamu [ 4118.331508] [<ffffffffa02cd9f2>] ? br_forward+0x16/0x5a [bridge]
Apr 12 13:22:06 lamu [ 4118.343911] [<ffffffffa02ce51b>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
Apr 12 13:22:06 lamu [ 4118.358880] [<ffffffffa02d25ff>] ? br_nf_pre_routing_finish+0x1d0/0x1dd [bridge]
Apr 12 13:22:06 lamu [ 4118.374318] [<ffffffffa02d1ff0>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Apr 12 13:22:06 lamu [ 4118.387534] [<ffffffffa02d2f58>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
Apr 12 13:22:06 lamu [ 4118.401597] [<ffffffff812abe4d>] ? nf_iterate+0x41/0x77
Apr 12 13:22:06 lamu [ 4118.412543] [<ffffffff8128affc>] ? napi_gro_receive+0x1d/0x2b
Apr 12 13:22:06 lamu [ 4118.424529] [<ffffffff8128aba6>] ? napi_skb_finish+0x1c/0x31
Apr 12 13:22:06 lamu [ 4118.436261] [<ffffffffa02ce37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 13:22:06 lamu [ 4118.450326] [<ffffffff812abeeb>] ? nf_hook_slow+0x68/0x101
Apr 12 13:22:06 lamu [ 4118.461719] [<ffffffffa02ce37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 13:22:06 lamu [ 4118.475801] [<ffffffffa02ce37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Apr 12 13:22:06 lamu [ 4118.489866] [<ffffffffa02ce360>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
Apr 12 13:22:06 lamu [ 4118.503947] [<ffffffff8128b06a>] ? napi_complete+0x28/0x37
Apr 12 13:22:06 lamu [ 4118.515485] [<ffffffffa02ce73c>] ? br_handle_frame+0x1b3/0x1cb [bridge]
Apr 12 13:22:06 lamu [ 4118.529269] [<ffffffffa02ce589>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
Apr 12 13:22:06 lamu [ 4118.544220] [<ffffffff812890cd>] ? __netif_receive_skb+0x324/0x41f
Apr 12 13:22:06 lamu [ 4118.557192] [<ffffffff81289234>] ? process_backlog+0x6c/0x123
Apr 12 13:22:06 lamu [ 4118.569098] [<ffffffff8128b11a>] ? net_rx_action+0xa1/0x1af
Apr 12 13:22:06 lamu [ 4118.580632] [<ffffffff81037013>] ? test_tsk_need_resched+0xa/0x13
Apr 12 13:22:06 lamu [ 4118.593292] [<ffffffff8104be98>] ? __do_softirq+0xb9/0x177
Apr 12 13:22:06 lamu [ 4118.604759] [<ffffffff8135026c>] ? call_softirq+0x1c/0x30
Apr 12 13:22:06 lamu [ 4118.616040] <EOI>
Apr 12 13:22:06 lamu [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
Apr 12 13:22:06 lamu [ 4118.628382] [<ffffffff8128b40a>] ? netif_rx_ni+0x1e/0x27
Apr 12 13:22:06 lamu [ 4118.639571] [<ffffffffa025b721>] ? tun_get_user+0x39a/0x3c2 [tun]
Apr 12 13:22:06 lamu [ 4118.652220] [<ffffffffa025ba66>] ? tun_chr_poll+0xcd/0xcd [tun]
Apr 12 13:22:06 lamu [ 4118.664445] [<ffffffffa025bac4>] ? tun_chr_aio_write+0x5e/0x79 [tun]
Apr 12 13:22:06 lamu [ 4118.677553] [<ffffffff810f95d4>] ? do_sync_readv_writev+0x9a/0xd7
Apr 12 13:22:06 lamu [ 4118.690220] [<ffffffff8103642f>] ? should_resched+0x5/0x23
Apr 12 13:22:06 lamu [ 4118.701591] [<ffffffff810f8c56>] ? do_sync_read+0xab/0xe3
Apr 12 13:22:06 lamu [ 4118.712765] [<ffffffff8103642f>] ? should_resched+0x5/0x23
Apr 12 13:22:07 lamu [ 4118.724209] [<ffffffff81162569>] ? security_file_permission+0x16/0x2d
Apr 12 13:22:07 lamu [ 4118.737632] [<ffffffff810f9838>] ? do_readv_writev+0xaf/0x11c
Apr 12 13:22:07 lamu [ 4118.749500] [<ffffffff8112abb6>] ? eventfd_ctx_read+0x162/0x174
Apr 12 13:22:07 lamu [ 4118.761817] [<ffffffff8103f467>] ? try_to_wake_up+0x197/0x197
Apr 12 13:22:07 lamu [ 4118.773669] [<ffffffff810f9a0d>] ? sys_writev+0x45/0x90
Apr 12 13:22:07 lamu [ 4118.784671] [<ffffffff8134e012>] ? system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: Kernel panic with bridge networking
From: Eric Dumazet @ 2012-04-12 12:52 UTC (permalink / raw)
To: Massimo Cetra; +Cc: netdev, Peter Huang (Peng)
In-Reply-To: <4F86CACB.8010907@navynet.it>
On Thu, 2012-04-12 at 14:30 +0200, Massimo Cetra wrote:
> Hello,
>
> i am experiencing a panic whose logs are attached (grabbed with netconsole).
>
> They look quite similar to what has been described here
> http://www.spinics.net/lists/linux-net/msg17689.html
>
> The patch proposed as the solution (commit
> 6b1e960fdbd75dcd9bcc3ba5ff8898ff1ad30b6e) seems to be applied (even with
> small differences) but the problem persists.
>
> The kernel is a debian linux-image-3.2.0-2-amd64 version 3.2.12-1
>
> Any hint ?
> I have checked the changelog of 3.2.13 and 3.2.14 and it doesn't seems
> to be any commit regarding such problems.
>
> Massimo Cetra
>
> P.S.1: Please CC me as i'm not subscribed.
> P.S.2: this bug has been submitted to debian as well
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668511
>
Known issue, and we are waiting from a fix from Peter.
https://lkml.org/lkml/2012/3/31/17
Peter, any progress on your side ?
Thanks
^ permalink raw reply
* Re: [PATCH] net: smsc911x: fix RX FIFO fastforwarding when dropping packets
From: Will Deacon @ 2012-04-12 12:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org, Steve Glendinning
In-Reply-To: <1334222448.5300.6046.camel@edumazet-glaptop>
Hi Eric,
Thanks for taking a look.
On Thu, Apr 12, 2012 at 10:20:48AM +0100, Eric Dumazet wrote:
> On Thu, 2012-04-12 at 10:07 +0100, Will Deacon wrote:
> > diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
> > index 4a69710..b5599bc 100644
> > --- a/drivers/net/ethernet/smsc/smsc911x.c
> > +++ b/drivers/net/ethernet/smsc/smsc911x.c
> > @@ -1228,7 +1228,7 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
> > "Discarding packet with error bit set");
> > /* Packet has an error, discard it and continue with
> > * the next */
> > - smsc911x_rx_fastforward(pdata, pktwords);
> > + smsc911x_rx_fastforward(pdata, pktlength);
> > dev->stats.rx_dropped++;
> > continue;
> > }
[...]
> Hum, looking at this driver, I see wrong code in lines 1246/1247
>
> skb->data = skb->head;
> skb_reset_tail_pointer(skb);
>
> I suspect its hiding a buffer overflow bug or something.
Yes, you're right.
> netdev_alloc_skb() reserved NET_SKB_PAD bytes. A driver should not
> un-reserve this headroom, or some networking setups can be very slow.
>
> So
>
> pdata->ops->rx_readfifo(pdata,
> (unsigned int *)skb->head, pktwords);
>
> also should be fixed to use skb->data instead.
Right, this seems to do the trick (and can replace my original patch by
actually passing in the number of words to the fastforward function). I'm
not sure whether the skb_trim is really required, but it makes the data
format slightly clearer.
It would be nice to get some input from Steve, but his email address seems
to be bouncing at the moment.
Will
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index 4a69710..3f43c24 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -1166,10 +1166,8 @@ smsc911x_rx_counterrors(struct net_device *dev, unsigned int rxstat)
/* Quickly dumps bad packets */
static void
-smsc911x_rx_fastforward(struct smsc911x_data *pdata, unsigned int pktbytes)
+smsc911x_rx_fastforward(struct smsc911x_data *pdata, unsigned int pktwords)
{
- unsigned int pktwords = (pktbytes + NET_IP_ALIGN + 3) >> 2;
-
if (likely(pktwords >= 4)) {
unsigned int timeout = 500;
unsigned int val;
@@ -1233,7 +1231,7 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
continue;
}
- skb = netdev_alloc_skb(dev, pktlength + NET_IP_ALIGN);
+ skb = netdev_alloc_skb(dev, pktwords << 2);
if (unlikely(!skb)) {
SMSC_WARN(pdata, rx_err,
"Unable to allocate skb for rx packet");
@@ -1243,21 +1241,19 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
break;
}
- skb->data = skb->head;
- skb_reset_tail_pointer(skb);
-
- /* Align IP on 16B boundary */
- skb_reserve(skb, NET_IP_ALIGN);
- skb_put(skb, pktlength - 4);
+ skb_put(skb, pktwords << 2);
pdata->ops->rx_readfifo(pdata,
- (unsigned int *)skb->head, pktwords);
+ (unsigned int *)skb->data, pktwords);
+ skb_pull(skb, NET_IP_ALIGN);
+ skb_trim(skb, pktlength);
+
skb->protocol = eth_type_trans(skb, dev);
skb_checksum_none_assert(skb);
netif_receive_skb(skb);
/* Update counters */
dev->stats.rx_packets++;
- dev->stats.rx_bytes += (pktlength - 4);
+ dev->stats.rx_bytes += pktlength;
}
/* Return total received packets */
@@ -1565,7 +1561,7 @@ static int smsc911x_open(struct net_device *dev)
smsc911x_reg_write(pdata, FIFO_INT, temp);
/* set RX Data offset to 2 bytes for alignment */
- smsc911x_reg_write(pdata, RX_CFG, (2 << 8));
+ smsc911x_reg_write(pdata, RX_CFG, (NET_IP_ALIGN << 8));
/* enable NAPI polling before enabling RX interrupts */
napi_enable(&pdata->napi);
^ permalink raw reply related
* Re: [PATCH] net: smsc911x: fix RX FIFO fastforwarding when dropping packets
From: Eric Dumazet @ 2012-04-12 13:06 UTC (permalink / raw)
To: Will Deacon; +Cc: netdev@vger.kernel.org, Steve Glendinning
In-Reply-To: <20120412125355.GG16025@mudshark.cambridge.arm.com>
On Thu, 2012-04-12 at 13:53 +0100, Will Deacon wrote:
> Hi Eric,
>
> Thanks for taking a look.
>
> On Thu, Apr 12, 2012 at 10:20:48AM +0100, Eric Dumazet wrote:
> > On Thu, 2012-04-12 at 10:07 +0100, Will Deacon wrote:
> > > diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
> > > index 4a69710..b5599bc 100644
> > > --- a/drivers/net/ethernet/smsc/smsc911x.c
> > > +++ b/drivers/net/ethernet/smsc/smsc911x.c
> > > @@ -1228,7 +1228,7 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
> > > "Discarding packet with error bit set");
> > > /* Packet has an error, discard it and continue with
> > > * the next */
> > > - smsc911x_rx_fastforward(pdata, pktwords);
> > > + smsc911x_rx_fastforward(pdata, pktlength);
> > > dev->stats.rx_dropped++;
> > > continue;
> > > }
>
> [...]
>
> > Hum, looking at this driver, I see wrong code in lines 1246/1247
> >
> > skb->data = skb->head;
> > skb_reset_tail_pointer(skb);
> >
> > I suspect its hiding a buffer overflow bug or something.
>
> Yes, you're right.
>
> > netdev_alloc_skb() reserved NET_SKB_PAD bytes. A driver should not
> > un-reserve this headroom, or some networking setups can be very slow.
> >
> > So
> >
> > pdata->ops->rx_readfifo(pdata,
> > (unsigned int *)skb->head, pktwords);
> >
> > also should be fixed to use skb->data instead.
>
> Right, this seems to do the trick (and can replace my original patch by
> actually passing in the number of words to the fastforward function). I'm
> not sure whether the skb_trim is really required, but it makes the data
> format slightly clearer.
>
> It would be nice to get some input from Steve, but his email address seems
> to be bouncing at the moment.
>
> Will
>
>
> diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
> index 4a69710..3f43c24 100644
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
> @@ -1166,10 +1166,8 @@ smsc911x_rx_counterrors(struct net_device *dev, unsigned int rxstat)
>
> /* Quickly dumps bad packets */
> static void
> -smsc911x_rx_fastforward(struct smsc911x_data *pdata, unsigned int pktbytes)
> +smsc911x_rx_fastforward(struct smsc911x_data *pdata, unsigned int pktwords)
> {
> - unsigned int pktwords = (pktbytes + NET_IP_ALIGN + 3) >> 2;
> -
> if (likely(pktwords >= 4)) {
> unsigned int timeout = 500;
> unsigned int val;
> @@ -1233,7 +1231,7 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
> continue;
> }
>
> - skb = netdev_alloc_skb(dev, pktlength + NET_IP_ALIGN);
> + skb = netdev_alloc_skb(dev, pktwords << 2);
> if (unlikely(!skb)) {
> SMSC_WARN(pdata, rx_err,
> "Unable to allocate skb for rx packet");
> @@ -1243,21 +1241,19 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
> break;
> }
>
> - skb->data = skb->head;
> - skb_reset_tail_pointer(skb);
> -
> - /* Align IP on 16B boundary */
> - skb_reserve(skb, NET_IP_ALIGN);
> - skb_put(skb, pktlength - 4);
> + skb_put(skb, pktwords << 2);
You could remove this line and do it after skb_reserve() ?
> pdata->ops->rx_readfifo(pdata,
> - (unsigned int *)skb->head, pktwords);
> + (unsigned int *)skb->data, pktwords);
> + skb_pull(skb, NET_IP_ALIGN);
skb_reserve(skb, NET_IP_ALIGN);
skb_put(skb, pktlength - 4);
> + skb_trim(skb, pktlength);
and remove this skb_trim()
> +
> skb->protocol = eth_type_trans(skb, dev);
> skb_checksum_none_assert(skb);
> netif_receive_skb(skb);
>
> /* Update counters */
> dev->stats.rx_packets++;
> - dev->stats.rx_bytes += (pktlength - 4);
> + dev->stats.rx_bytes += pktlength;
Some drivers account for the FCS, some dont, I guess you can leave the
line as is
> }
>
> /* Return total received packets */
> @@ -1565,7 +1561,7 @@ static int smsc911x_open(struct net_device *dev)
> smsc911x_reg_write(pdata, FIFO_INT, temp);
>
> /* set RX Data offset to 2 bytes for alignment */
> - smsc911x_reg_write(pdata, RX_CFG, (2 << 8));
> + smsc911x_reg_write(pdata, RX_CFG, (NET_IP_ALIGN << 8));
Good ;)
>
> /* enable NAPI polling before enabling RX interrupts */
> napi_enable(&pdata->napi);
>
Thanks
^ permalink raw reply
* Re: [RFC v3] Add TCP encap_rcv hook
From: Simon Horman @ 2012-04-12 13:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1334218829.5300.5903.camel@edumazet-glaptop>
On Thu, Apr 12, 2012 at 10:20:29AM +0200, Eric Dumazet wrote:
> On Thu, 2012-04-12 at 16:42 +0900, Simon Horman wrote:
> > This hook is based on a hook of the same name provided by UDP. It provides
> > a way for to receive packets that have a TCP header and treat them in some
> > alternate way.
> >
> > It is intended to be used by an implementation of the STT tunneling
> > protocol within Open vSwtich's datapath. A prototype of such an
> > implementation has been made.
> >
> > The STT draft is available at
> > http://tools.ietf.org/html/draft-davie-stt-01
> >
> > My prototype STT implementation has been posted to the dev-UOEtcQmXneFl884UGnbwIQ@public.gmane.org
> > The first version can be found at:
> > http://www.mail-archive.com/dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org/msg08877.html
> >
> > Signed-off-by: Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> >
>
> Hi Simon
>
> Oh well, this is insane :(
>
> > ---
> > include/linux/tcp.h | 3 +++
> > net/ipv4/tcp_ipv4.c | 23 ++++++++++++++++++++++-
> > 2 files changed, 25 insertions(+), 1 deletion(-)
> >
> > v3
> > * First post to netdev
> > * Replace more UDP references with TCP
> > * Move socket accesses to inside socket lock
> > and release lock on return.
> >
> > v2
> > * Fix comment to refer to TCP rather than UDP
> > * Allow skb to continue traversing the stack if
> > the encap_rcv callback returns a positive value.
> > This is the same behaviour as the UDP hook.
> >
> > diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> > index b6c62d2..7210b23 100644
> > --- a/include/linux/tcp.h
> > +++ b/include/linux/tcp.h
> > @@ -472,6 +472,9 @@ struct tcp_sock {
> > * contains related tcp_cookie_transactions fields.
> > */
> > struct tcp_cookie_values *cookie_values;
> > +
> > + /* For encapsulation sockets. */
> > + int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
> > };
> >
>
> This adds a new cache miss for all incoming tcp frames...
>
> > static inline struct tcp_sock *tcp_sk(const struct sock *sk)
> > diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> > index 3a25cf7..9898f71 100644
> > --- a/net/ipv4/tcp_ipv4.c
> > +++ b/net/ipv4/tcp_ipv4.c
> > @@ -1666,8 +1666,10 @@ int tcp_v4_rcv(struct sk_buff *skb)
> > const struct iphdr *iph;
> > const struct tcphdr *th;
> > struct sock *sk;
> > + struct tcp_sock *tp;
> > int ret;
> > struct net *net = dev_net(skb->dev);
> > + int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
> >
> > if (skb->pkt_type != PACKET_HOST)
> > goto discard_it;
> > @@ -1726,9 +1728,27 @@ process:
> >
> > bh_lock_sock_nested(sk);
> > ret = 0;
> > +
> > + tp = tcp_sk(sk);
> > + encap_rcv = ACCESS_ONCE(tp->encap_rcv);
> > + if (encap_rcv != NULL) {
>
> and a new conditional...
>
> > + /*
> > + * This is an encapsulation socket so pass the skb to
> > + * the socket's tcp_encap_rcv() hook. Otherwise, just
> > + * fall through and pass this up the TCP socket.
> > + * up->encap_rcv() returns the following value:
> > + * <=0 if skb was successfully passed to the encap
> > + * handler or was discarded by it.
> > + * >0 if skb should be passed on to TCP.
> > + */
> > + if (encap_rcv(sk, skb) <= 0) {
> > + ret = 0;
> > + goto unlock_sock;
> > + }
> > + }
> > +
> > if (!sock_owned_by_user(sk)) {
> > #ifdef CONFIG_NET_DMA
> > - struct tcp_sock *tp = tcp_sk(sk);
> > if (!tp->ucopy.dma_chan && tp->ucopy.pinned_list)
> > tp->ucopy.dma_chan = dma_find_channel(DMA_MEMCPY);
> > if (tp->ucopy.dma_chan)
> > @@ -1744,6 +1764,7 @@ process:
> > NET_INC_STATS_BH(net, LINUX_MIB_TCPBACKLOGDROP);
> > goto discard_and_relse;
> > }
> > +unlock_sock:
> > bh_unlock_sock(sk);
> >
> > sock_put(sk);
>
> I dont know, this sounds as a hack. Since you obviously spent a lot of
> time on this stuff, lets be constructive.
Hi Eric,
Thanks, I didn't really expect my patch to go in smoothly as is.
Though it may well be my first brush with insanity.
>
> I really suggest you take a look at <linux/static_key.h>
>
> So that on machines without any need for this encap_rcv, we dont even
> need to fetch tp->encap_rcv
>
> if (static_key_false(&stt_active)) {
> /* stt might be used on this socket */
> encap_rcv = ACCESS_ONCE(tp->encap_rcv);
> if (encap_rcv) {
> ...
> }
> }
>
> This way, if stt is not used/loaded, we have a single NOP
>
> If stt is used, NOP is patched to a JMP stt_code
>
>
> I probably implement this idea on UDP shortly so that you can have a
> reference for your implementation.
Thanks, I see your UDP code now. I'll see about getting the same thing
working for TCP.
^ permalink raw reply
* Re: Regression due to "ath9k: fix going to full-sleep on PS idle"
From: John W. Linville @ 2012-04-12 13:20 UTC (permalink / raw)
To: Sujith Manoharan
Cc: Linus Torvalds, Heinz Diehl, linux-kernel, Greg KH, akpm, alan,
linux-wireless Mailing List, ath9k-devel@lists.ath9k.org,
David Miller, Network Development
In-Reply-To: <20358.25376.230264.236893@gargle.gargle.HOWL>
On Thu, Apr 12, 2012 at 10:37:44AM +0530, Sujith Manoharan wrote:
> Linus Torvalds wrote:
> > You guys need to fix the subject line (like this), and make sure that
> > the right people are cc'd. This is not a "stable" issue - stable
> > cannot revert stuff that hasn't been reverted upstream.
> >
> > So instead of stable and Greg, it should be netdev and Davem.
> >
> > David/John: multiple people are complaining about that commit. It
> > really should be reverted, or a fix found. It's broken.
> >
> > I can do the revert, but it would be better coming from the networking people.
>
> John has already reverted the commit:
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless.git;a=commit;h=011afa1ed8c408d694957d2474d89dc81a60b70c
Yes, I'll be pushing to Dave M shortly.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* RFC udp: improve __udp4_lib_lookup performance
From: Alexandru Copot @ 2012-04-12 13:35 UTC (permalink / raw)
To: netdev
UDP uses 2 hashtables for fast socket lookup. First hash uses port as
a lookup key and the second one uses (port, addr).
When an UDP packet is received, the destination socket must be found to
deliver it. If there are many UDP sockets bound to INADDR_ANY, 2 hash
searches are made in the second hash: first one looks for the pair
(dest address, dest port) but doesn't find the socket; the second search
finds the socket by hashing (INADDR_ANY, dest port).
Those 2 searches can be avoided and a lot of time saved if instead we
searched directly in the first hash.
We could count the number of INADDR_ANY bound UDP sockets and
make only one search when that value is above a certain threshold. However,
if there are also sockets bound on a specific address, the second hash
won't be used and that might hurt performance for this case.
What is your opinion on this ? Would the performance gained by
counting INADDR_ANY bound sockets outweigh the loss in performance
for the case of mixed INADDR_ANY/specific address bound sockets ?
Alexandru Copot
^ permalink raw reply
* Re: [PATCH] 8139cp: set intr mask after its handler is registered
From: Flavio Leitner @ 2012-04-12 13:45 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, davem, linux-kernel
In-Reply-To: <20120412081053.25774.41676.stgit@amd-6168-8-1.englab.nay.redhat.com>
On Thu, 12 Apr 2012 16:10:54 +0800
Jason Wang <jasowang@redhat.com> wrote:
> We set intr mask before its handler is registered, this does not work well when
> 8139cp is sharing irq line with other devices. As the irq could be enabled by
> the device before 8139cp's hander is registered which may lead unhandled
> irq. Fix this by introducing an helper cp_irq_enable() and call it after
> request_irq().
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Flavio Leitner <fbl@redhat.com>
fbl
^ permalink raw reply
* [PATCH] Phonet: change maintainer address
From: Rémi Denis-Courmont @ 2012-04-12 13:39 UTC (permalink / raw)
To: netdev; +Cc: Rémi Denis-Courmont
In-Reply-To: <1334237958-22855-1-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
nokia.com MX does not cope well with kernel.org.
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
---
MAINTAINERS | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d710c00..74f753e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5197,7 +5197,7 @@ S: Maintained
F: include/linux/personality.h
PHONET PROTOCOL
-M: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
+M: Remi Denis-Courmont <courmisch@gmail.com>
S: Supported
F: Documentation/networking/phonet.txt
F: include/linux/phonet.h
--
1.7.5.4
^ permalink raw reply related
* [PATCH] Phonet: missing headers (sparse)
From: Rémi Denis-Courmont @ 2012-04-12 13:39 UTC (permalink / raw)
To: netdev; +Cc: Rémi Denis-Courmont
In-Reply-To: <1334237958-22855-1-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
---
net/phonet/sysctl.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/phonet/sysctl.c b/net/phonet/sysctl.c
index cea1c7d..740bf20 100644
--- a/net/phonet/sysctl.c
+++ b/net/phonet/sysctl.c
@@ -27,6 +27,10 @@
#include <linux/errno.h>
#include <linux/init.h>
+#include <net/sock.h>
+#include <linux/phonet.h>
+#include <net/phonet/phonet.h>
+
#define DYNAMIC_PORT_MIN 0x40
#define DYNAMIC_PORT_MAX 0x7f
--
1.7.5.4
^ permalink raw reply related
* [PATCH] Phonet: phonet_net_id can be static (sparse)
From: Rémi Denis-Courmont @ 2012-04-12 13:39 UTC (permalink / raw)
To: netdev; +Cc: Rémi Denis-Courmont
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
---
net/phonet/pn_dev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/phonet/pn_dev.c b/net/phonet/pn_dev.c
index 9b9a85e..631cd51 100644
--- a/net/phonet/pn_dev.c
+++ b/net/phonet/pn_dev.c
@@ -44,7 +44,7 @@ struct phonet_net {
struct phonet_routes routes;
};
-int phonet_net_id __read_mostly;
+static int phonet_net_id __read_mostly;
static struct phonet_net *phonet_pernet(struct net *net)
{
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] net: smsc911x: fix RX FIFO fastforwarding when dropping packets
From: Will Deacon @ 2012-04-12 13:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org, Steve Glendinning
In-Reply-To: <1334235963.5300.6361.camel@edumazet-glaptop>
On Thu, Apr 12, 2012 at 02:06:03PM +0100, Eric Dumazet wrote:
> On Thu, 2012-04-12 at 13:53 +0100, Will Deacon wrote:
> > diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
> > index 4a69710..3f43c24 100644
> > --- a/drivers/net/ethernet/smsc/smsc911x.c
> > +++ b/drivers/net/ethernet/smsc/smsc911x.c
> > @@ -1166,10 +1166,8 @@ smsc911x_rx_counterrors(struct net_device *dev, unsigned int rxstat)
[...]
> > - skb->data = skb->head;
> > - skb_reset_tail_pointer(skb);
> > -
> > - /* Align IP on 16B boundary */
> > - skb_reserve(skb, NET_IP_ALIGN);
> > - skb_put(skb, pktlength - 4);
> > + skb_put(skb, pktwords << 2);
>
> You could remove this line and do it after skb_reserve() ?
>
> > pdata->ops->rx_readfifo(pdata,
> > - (unsigned int *)skb->head, pktwords);
> > + (unsigned int *)skb->data, pktwords);
> > + skb_pull(skb, NET_IP_ALIGN);
>
> skb_reserve(skb, NET_IP_ALIGN);
I don't think we want an skb_reserve at all, since the hardware shifts the
data in the RX FIFO, meaning that we will read two bytes of 0 anyway before
valid data.
> skb_put(skb, pktlength - 4);
I can move the put here if you like, but we need to use pktwords << 2 to
make sure that we read the leading and trailing zeroes inserted by the
hardware.
> > + skb_trim(skb, pktlength);
>
> and remove this skb_trim()
Can do, just thought it might help illustrate that we might have some padding
at the end.
> > /* Update counters */
> > dev->stats.rx_packets++;
> > - dev->stats.rx_bytes += (pktlength - 4);
> > + dev->stats.rx_bytes += pktlength;
>
> Some drivers account for the FCS, some dont, I guess you can leave the
> line as is
Sure.
Thanks for the comments,
Will
^ permalink raw reply
* Powerd Cloud Hosting and Server
From: woody @ 2012-04-12 13:34 UTC (permalink / raw)
Dear All,
We are one of the top Cloud Solution provider base in Hong Kong, with over 10+ years experience,
we providing better than good and lower cost service of CLoud Hosting (Cloud Server / Hosting / CDN)
Starting at $1.99, let's come to experience and enjoy our powerful cloud system.
Thanks for your time and appreciated to look arround our website.
http://www.cloudluca.com/
Best Regards,
The 36cloud Team
If you do not wish to further receive this event message, email "subscriber@dedicatedserver.com.hk" to unsubscribe this message or revoe your email from the list.
^ permalink raw reply
* Re: RFC udp: improve __udp4_lib_lookup performance
From: Eric Dumazet @ 2012-04-12 14:00 UTC (permalink / raw)
To: Alexandru Copot; +Cc: netdev
In-Reply-To: <CAHG7+CAt_YjxUp6+u9J47Ti1HA6hh_UkRMWQsXw4AsbEkvCu7w@mail.gmail.com>
On Thu, 2012-04-12 at 16:35 +0300, Alexandru Copot wrote:
> UDP uses 2 hashtables for fast socket lookup. First hash uses port as
> a lookup key and the second one uses (port, addr).
>
> When an UDP packet is received, the destination socket must be found to
> deliver it. If there are many UDP sockets bound to INADDR_ANY, 2 hash
> searches are made in the second hash: first one looks for the pair
> (dest address, dest port) but doesn't find the socket; the second search
> finds the socket by hashing (INADDR_ANY, dest port).
>
> Those 2 searches can be avoided and a lot of time saved if instead we
> searched directly in the first hash.
>
> We could count the number of INADDR_ANY bound UDP sockets and
> make only one search when that value is above a certain threshold. However,
> if there are also sockets bound on a specific address, the second hash
> won't be used and that might hurt performance for this case.
>
> What is your opinion on this ? Would the performance gained by
> counting INADDR_ANY bound sockets outweigh the loss in performance
> for the case of mixed INADDR_ANY/specific address bound sockets ?
I have no idea of your workload, but existing code is already very
optimized.
udp4_lib_lookup2() variants are only called when (hslot->count > 10)
If your workload have one 60000 UDP sockets bound on INADDR_ANY, I
suggest you check udp hash size and eventually increase it to the max ?
dmesg | grep "UDP hash"
Boot command : uhash_entries=65536
^ permalink raw reply
* Re: [PATCH] net: smsc911x: fix RX FIFO fastforwarding when dropping packets
From: Eric Dumazet @ 2012-04-12 14:01 UTC (permalink / raw)
To: Will Deacon; +Cc: netdev@vger.kernel.org, Steve Glendinning
In-Reply-To: <20120412134757.GH16025@mudshark.cambridge.arm.com>
On Thu, 2012-04-12 at 14:47 +0100, Will Deacon wrote:
>
> I don't think we want an skb_reserve at all, since the hardware shifts the
> data in the RX FIFO, meaning that we will read two bytes of 0 anyway before
> valid data.
>
> > skb_put(skb, pktlength - 4);
>
> I can move the put here if you like, but we need to use pktwords << 2 to
> make sure that we read the leading and trailing zeroes inserted by the
> hardware.
before calling linux stack, you'll have to skip those 2 bytes.
This is skb_reserve() purpose.
^ 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