Netdev List
 help / color / mirror / Atom feed
* Re: [patch net-next 0/4] net: introduce and use IFF_LIFE_ADDR_CHANGE
From: Jiri Pirko @ 2012-06-28 15:41 UTC (permalink / raw)
  To: Richard Cochran
  Cc: mst, netdev, shimoda.hiroaki, virtualization, danny.kukawka,
	edumazet, davem
In-Reply-To: <20120628151507.GA5920@localhost.localdomain>

Thu, Jun 28, 2012 at 05:15:07PM CEST, richardcochran@gmail.com wrote:
>On Thu, Jun 28, 2012 at 04:10:35PM +0200, Jiri Pirko wrote:
>> three drivers updated, but this can be used in many others.
>> 
>> Jiri Pirko (4):
>>   net: introduce new priv_flag indicating iface capable of change mac
>>     when running
>>   virtio_net: use IFF_LIFE_ADDR_CHANGE priv_flag
>>   team: use IFF_LIFE_ADDR_CHANGE priv_flag
>>   dummy: use IFF_LIFE_ADDR_CHANGE priv_flag
>
>I think you must mean LIVE and not LIFE...

Good point. I will change it and repost, but I will give it some time so
people can express themselves.

Thanks!

Jirka
>
>Thanks,
>Richard
>
>
>> 
>>  drivers/net/dummy.c      |   15 ++-------------
>>  drivers/net/team/team.c  |    9 +++++----
>>  drivers/net/virtio_net.c |   11 +++++------
>>  include/linux/if.h       |    2 ++
>>  net/ethernet/eth.c       |    2 +-
>>  5 files changed, 15 insertions(+), 24 deletions(-)
>> 
>> -- 
>> 1.7.10.4
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH net-next] em_canid: Ematch rule to match CAN frames according to their CAN IDs
From: Rostislav Lisovy @ 2012-06-28 15:35 UTC (permalink / raw)
  To: Kurt Van Dijck
  Cc: Oliver Hartkopp, Eric Dumazet, netdev, linux-can, lartc, pisa,
	sojkam1
In-Reply-To: <20120627093325.GB410@vandijck-laurijssen.be>

On Wed, 2012-06-27 at 11:33 +0200, Kurt Van Dijck wrote: 
> Oliver, Rostislav,
> 
> I was just looking into this. I think the matching itself
> may be simplified by eliminating checks 'that have already been made'.

Thank you for your remarks, I have removed all of the unnecessary
CAN_EFF_MASK masking.

Regards;
Rostislav 


^ permalink raw reply

* Re: [PATCH v2] sctp: be more restrictive in transport selection on bundled sacks
From: Neil Horman @ 2012-06-28 15:33 UTC (permalink / raw)
  To: Vlad Yasevich; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <4FEB6296.5050603@gmail.com>

On Wed, Jun 27, 2012 at 03:44:22PM -0400, Vlad Yasevich wrote:
> On 06/27/2012 01:28 PM, Neil Horman wrote:
> >On Wed, Jun 27, 2012 at 11:10:26AM -0400, Vlad Yasevich wrote:
> >>
> >>I didn't think of this yesterday, but I think it would be much
> >>better to use pkt->transport here since you are adding the chunk to
> >>the packet and it will go out on the transport of the packet.  You
> >>are also guaranteed that pkt->transport is set.
> >>
> >I don't think it really matters, as the chunk transport is used to lookup the
> >packet that we append to, and if the chunk transport is unset, its somewhat
> >questionable as to weather we should bundle, but if packet->transport is set,
> >its probably worth it to avoid the extra conditional.
> >
> 
> Just looked at the code flow.  chunk->transport may not be set until
> the end of sctp_packet_append_chunk.  For new data, transport may
> not be set.  For retransmitted data, transport is set to last
> transport data was sent on.  So, we could be looking at the wrong
> transport.  What you are trying to decided is if the current
> transport we will be used can take the SACK, but you may not be
> looking at the current transport. Looking at packet->transport is
> the correct thing to do.
> 
> -vlad
> 
So, I agree after what you said above, that this is the right thing to do.  That
said, I just tested the change with the SCTP_RR test in netperf, and it wound up
giving me horrid performance (Its reporting about 5 transactions per second).
It appears that whats happening is that, because the test alternates which
transports it sends out, and because it waits for a sack of teh prior packet
before it sends out the next transaction, we're always missing the bundle
opportunity, and always waiting for the 200ms timeout for the sack to occur.
While I know this is a pessimal case, it really seems bad to me.  It seems that
because I was using chunk->transport previously, I luckily got the transport
wrong sometimes, and it managed to bundle more often.

So I'm not sure what to do here.  I had really wanted to avoid adding a sysctl
here, but given that this is likely a corner cases, it seems that might be the
best approach.  Do you have any thoughts?

Neil

^ permalink raw reply

* Re: [patch net-next 1/4] net: introduce new priv_flag indicating iface capable of change mac when running
From: Eric Dumazet @ 2012-06-28 15:24 UTC (permalink / raw)
  To: Jiri Pirko
  Cc: mst, netdev, shimoda.hiroaki, virtualization, danny.kukawka,
	edumazet, davem
In-Reply-To: <1340892639-1111-2-git-send-email-jpirko@redhat.com>

On Thu, 2012-06-28 at 16:10 +0200, Jiri Pirko wrote:
> Introduce IFF_LIFE_ADDR_CHANGE priv_flag and use it to disable
> netif_running() check in eth_mac_addr()
> 
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> ---
>  include/linux/if.h |    2 ++
>  net/ethernet/eth.c |    2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/if.h b/include/linux/if.h
> index f995c66..fd9ee7c 100644
> --- a/include/linux/if.h
> +++ b/include/linux/if.h
> @@ -81,6 +81,8 @@
>  #define IFF_UNICAST_FLT	0x20000		/* Supports unicast filtering	*/
>  #define IFF_TEAM_PORT	0x40000		/* device used as team port */
>  #define IFF_SUPP_NOFCS	0x80000		/* device supports sending custom FCS */
> +#define IFF_LIFE_ADDR_CHANGE 0x100000	/* device supports hardware address
> +					 * change when it's running */
>  
> 
>  #define IF_GET_IFACE	0x0001		/* for querying only */
> diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
> index 36e5880..8f8ded4 100644
> --- a/net/ethernet/eth.c
> +++ b/net/ethernet/eth.c
> @@ -283,7 +283,7 @@ int eth_mac_addr(struct net_device *dev, void *p)
>  {
>  	struct sockaddr *addr = p;
>  
> -	if (netif_running(dev))
> +	if (!(dev->priv_flags & IFF_LIFE_ADDR_CHANGE) && netif_running(dev))
>  		return -EBUSY;
>  	if (!is_valid_ether_addr(addr->sa_data))
>  		return -EADDRNOTAVAIL;

Since the memcpy() is not atomic, there is a small window where a reader
could get a half-changed mac address. I guess its a detail.

^ permalink raw reply

* Re: LOCKDEP complaints in l2tp_xmit_skb()
From: Eric Dumazet @ 2012-06-28 15:23 UTC (permalink / raw)
  To: Tom Parkin; +Cc: David Miller, netdev
In-Reply-To: <20120628152010.GC2507@raven>

On Thu, 2012-06-28 at 16:20 +0100, Tom Parkin wrote:

> Ha, yes, fair enough ;-)
> 
> FWIW, I'm no longer seeing splat #1 from my previous report, but I do
> still see splat #2.  Since they both ended up tripping over in
> l2tp_xmit_skb() I had assumed they were symptoms of the same root
> cause -- my mistake.
> 

Fixing the #2 issue should be easy, I think.

I'll send an official submission asap for #1

thanks

^ permalink raw reply

* Re: LOCKDEP complaints in l2tp_xmit_skb()
From: Tom Parkin @ 2012-06-28 15:20 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1340895642.13187.107.camel@edumazet-glaptop>

[-- Attachment #1: Type: text/plain, Size: 5767 bytes --]

On Thu, Jun 28, 2012 at 05:00:42PM +0200, Eric Dumazet wrote:
> On Thu, 2012-06-28 at 15:33 +0100, Tom Parkin wrote:
> > On Thu, Jun 28, 2012 at 01:22:31PM +0200, Eric Dumazet wrote:
> > > On Thu, 2012-06-28 at 10:57 +0200, Eric Dumazet wrote:
> > > > On Thu, 2012-06-28 at 08:56 +0200, Eric Dumazet wrote:
> > > > 
> > > > > [PATCH] net: Qdisc busylock gets its own lockdep class
> > > > > 
> > > > > Tom Parkin reported following LOCKDEP splat :
> > > > ..
> > > > > 
> > > > > Instruct lockdep that each Qdisc busylock is independant, or else
> > > > > bonding or various tunnels can trigger a splat.
> > > > > 
> > > > > Reported-by: Tom Parkin <tparkin@katalix.com>
> > > > > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > > > > ---
> > > > 
> > > > I reproduced the bug using a bond0 device, adding a qdisc on it,
> > > > (one Qdisc on bond0, and a Qdisc on the slave too)
> > > > 
> > > > Problem with this patch is I have following message :
> > > > 
> > > > BUG: key ffff88..... not in .data!
> > > > 
> > > > No more LOCKDEP splat, but patch not good as is.
> > > 
> > > I tested the alternative following patch with my bonding setup,
> > > could you test it with l2tp ?
> > >
> > 
> > I've tested against my l2tp test configuration and I still see LOCKDEP
> > splats:
> > 
> > 2tp_core: L2TP core driver, V2.0
> > 2tp_netlink: L2TP netlink interface
> > 2tp_eth: L2TP ethernet pseudowire support (L2TPv3)
> > 
> > ============================================
> >  INFO: possible recursive locking detected ]
> > .5.0-rc2-net-lockdep-u64-sync-007-+ #1 Not tainted
> > --------------------------------------------
> > wapper/0/0 is trying to acquire lock:
> > (slock-AF_INET){+.-...}, at: [<f862abff>] l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
> > 
> > ut task is already holding lock:
> > (slock-AF_INET){+.-...}, at: [<c15333d7>] ip_send_reply+0x107/0x2b0
> > 
> > ther info that might help us debug this:
> > Possible unsafe locking scenario:
> > 
> >       CPU0
> >       ----
> >  lock(slock-AF_INET);
> >  lock(slock-AF_INET);
> > 
> > *** DEADLOCK ***
> > 
> > May be due to missing lock nesting notation
> > 
> >  locks held by swapper/0/0:
> > #0:  (rcu_read_lock){.+.+..}, at: [<c14f7824>] __netif_receive_skb+0xe4/0x8d0
> > #1:  (rcu_read_lock){.+.+..}, at: [<c152bd4c>] ip_local_deliver_finish+0x3c/0x4c0
> > #2:  (slock-AF_INET){+.-...}, at: [<c15333d7>] ip_send_reply+0x107/0x2b0
> > #3:  (rcu_read_lock){.+.+..}, at: [<c1531456>] ip_finish_output+0x106/0x710
> > #4:  (rcu_read_lock_bh){.+....}, at: [<c14fa670>] dev_queue_xmit+0x0/0xbd0
> > 
> > tack backtrace:
> > id: 0, comm: swapper/0 Not tainted 3.5.0-rc2-net-lockdep-u64-sync-007-+ #1
> > all Trace:
> > [<c10a7b32>] __lock_acquire+0xd52/0x17d0
> > [<c10a334b>] ? trace_hardirqs_off+0xb/0x10
> > [<c10a8b48>] lock_acquire+0x88/0x120
> > [<f862abff>] ? l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
> > [<c16157bb>] _raw_spin_lock+0x3b/0x70
> > [<f862abff>] ? l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
> > [<f862abff>] l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
> > [<f851a32d>] l2tp_eth_dev_xmit+0x2d/0x40 [l2tp_eth]
> > [<c14fa32f>] dev_hard_start_xmit+0x49f/0x7e0
> > [<c14f9ee1>] ? dev_hard_start_xmit+0x51/0x7e0
> > [<c1515819>] sch_direct_xmit+0xa9/0x250
> > [<c16157e1>] ? _raw_spin_lock+0x61/0x70
> > [<c14fa83f>] dev_queue_xmit+0x1cf/0xbd0
> > [<c14fa670>] ? dev_hard_start_xmit+0x7e0/0x7e0
> > [<c1531537>] ip_finish_output+0x1e7/0x710
> > [<c1531456>] ? ip_finish_output+0x106/0x710
> > [<c1532770>] ? ip_output+0x60/0x120
> > [<c10a585b>] ? trace_hardirqs_on+0xb/0x10
> > [<c153278b>] ip_output+0x7b/0x120
> > [<c1532fc9>] ? __ip_make_skb+0x229/0x360
> > [<c1531b95>] ip_local_out+0x25/0x80
> > [<c1533117>] ip_send_skb+0x17/0x70
> > [<c153319b>] ip_push_pending_frames+0x2b/0x40
> > [<c1533495>] ip_send_reply+0x1c5/0x2b0
> > [<c107efef>] ? sched_clock_cpu+0xcf/0x150
> > [<c154f253>] tcp_v4_send_ack+0x1a3/0x260
> > [<c1552430>] ? tcp_timewait_state_process+0x90/0x3c0
> > [<c15514ef>] tcp_v4_rcv+0x3ff/0xc20
> > [<c152bdff>] ip_local_deliver_finish+0xef/0x4c0
> > [<c152bd4c>] ? ip_local_deliver_finish+0x3c/0x4c0
> > [<c152c40f>] ip_local_deliver+0x3f/0x80
> > [<c152b844>] ip_rcv_finish+0x174/0x640
> > [<c152c671>] ip_rcv+0x221/0x320
> > [<c14f7f11>] __netif_receive_skb+0x7d1/0x8d0
> > [<c14f7824>] ? __netif_receive_skb+0xe4/0x8d0
> > [<c14f80b7>] process_backlog+0xa7/0x170
> > [<c14f88dd>] net_rx_action+0x11d/0x210
> > [<c104d990>] ? local_bh_enable_ip+0xd0/0xd0
> > [<c104da27>] __do_softirq+0x97/0x1f0
> > [<c104d990>] ? local_bh_enable_ip+0xd0/0xd0
> > <IRQ>  [<c104ddce>] ? irq_exit+0x7e/0xa0
> > [<c161e02b>] ? do_IRQ+0x4b/0xc0
> > [<c161de75>] ? common_interrupt+0x35/0x3c
> > [<c10380d5>] ? native_safe_halt+0x5/0x10
> > [<c1018bdf>] ? default_idle+0x4f/0x1e0
> > [<c1018dc1>] ? amd_e400_idle+0x51/0x100
> > [<c10199c9>] ? cpu_idle+0xb9/0xe0
> > [<c15eab3e>] ? rest_init+0x112/0x124
> > [<c15eaa2c>] ? __read_lock_failed+0x14/0x14
> > [<c1907a11>] ? start_kernel+0x376/0x37c
> > [<c19074d6>] ? repair_env_string+0x51/0x51
> > [<c19072f8>] ? i386_start_kernel+0x9b/0xa2
> > 
> 
> Yes, but this is not the splat I fixed.
> 
> You reported two different splats, didnt you ?
> 
> I fixed a core network issue, I am sure guys who wrote l2tp can fix the
> l2tp one ;)

Ha, yes, fair enough ;-)

FWIW, I'm no longer seeing splat #1 from my previous report, but I do
still see splat #2.  Since they both ended up tripping over in
l2tp_xmit_skb() I had assumed they were symptoms of the same root
cause -- my mistake.

Tom
-- 
Tom Parkin
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: [patch net-next 0/4] net: introduce and use IFF_LIFE_ADDR_CHANGE
From: Richard Cochran @ 2012-06-28 15:15 UTC (permalink / raw)
  To: Jiri Pirko
  Cc: netdev, davem, rusty, mst, virtualization, edumazet,
	danny.kukawka, shimoda.hiroaki
In-Reply-To: <1340892639-1111-1-git-send-email-jpirko@redhat.com>

On Thu, Jun 28, 2012 at 04:10:35PM +0200, Jiri Pirko wrote:
> three drivers updated, but this can be used in many others.
> 
> Jiri Pirko (4):
>   net: introduce new priv_flag indicating iface capable of change mac
>     when running
>   virtio_net: use IFF_LIFE_ADDR_CHANGE priv_flag
>   team: use IFF_LIFE_ADDR_CHANGE priv_flag
>   dummy: use IFF_LIFE_ADDR_CHANGE priv_flag

I think you must mean LIVE and not LIFE...

Thanks,
Richard


> 
>  drivers/net/dummy.c      |   15 ++-------------
>  drivers/net/team/team.c  |    9 +++++----
>  drivers/net/virtio_net.c |   11 +++++------
>  include/linux/if.h       |    2 ++
>  net/ethernet/eth.c       |    2 +-
>  5 files changed, 15 insertions(+), 24 deletions(-)
> 
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: LOCKDEP complaints in l2tp_xmit_skb()
From: Eric Dumazet @ 2012-06-28 15:00 UTC (permalink / raw)
  To: Tom Parkin; +Cc: David Miller, netdev
In-Reply-To: <20120628143302.GB2507@raven>

On Thu, 2012-06-28 at 15:33 +0100, Tom Parkin wrote:
> On Thu, Jun 28, 2012 at 01:22:31PM +0200, Eric Dumazet wrote:
> > On Thu, 2012-06-28 at 10:57 +0200, Eric Dumazet wrote:
> > > On Thu, 2012-06-28 at 08:56 +0200, Eric Dumazet wrote:
> > > 
> > > > [PATCH] net: Qdisc busylock gets its own lockdep class
> > > > 
> > > > Tom Parkin reported following LOCKDEP splat :
> > > ..
> > > > 
> > > > Instruct lockdep that each Qdisc busylock is independant, or else
> > > > bonding or various tunnels can trigger a splat.
> > > > 
> > > > Reported-by: Tom Parkin <tparkin@katalix.com>
> > > > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > > > ---
> > > 
> > > I reproduced the bug using a bond0 device, adding a qdisc on it,
> > > (one Qdisc on bond0, and a Qdisc on the slave too)
> > > 
> > > Problem with this patch is I have following message :
> > > 
> > > BUG: key ffff88..... not in .data!
> > > 
> > > No more LOCKDEP splat, but patch not good as is.
> > 
> > I tested the alternative following patch with my bonding setup,
> > could you test it with l2tp ?
> >
> 
> I've tested against my l2tp test configuration and I still see LOCKDEP
> splats:
> 
> 2tp_core: L2TP core driver, V2.0
> 2tp_netlink: L2TP netlink interface
> 2tp_eth: L2TP ethernet pseudowire support (L2TPv3)
> 
> ============================================
>  INFO: possible recursive locking detected ]
> .5.0-rc2-net-lockdep-u64-sync-007-+ #1 Not tainted
> --------------------------------------------
> wapper/0/0 is trying to acquire lock:
> (slock-AF_INET){+.-...}, at: [<f862abff>] l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
> 
> ut task is already holding lock:
> (slock-AF_INET){+.-...}, at: [<c15333d7>] ip_send_reply+0x107/0x2b0
> 
> ther info that might help us debug this:
> Possible unsafe locking scenario:
> 
>       CPU0
>       ----
>  lock(slock-AF_INET);
>  lock(slock-AF_INET);
> 
> *** DEADLOCK ***
> 
> May be due to missing lock nesting notation
> 
>  locks held by swapper/0/0:
> #0:  (rcu_read_lock){.+.+..}, at: [<c14f7824>] __netif_receive_skb+0xe4/0x8d0
> #1:  (rcu_read_lock){.+.+..}, at: [<c152bd4c>] ip_local_deliver_finish+0x3c/0x4c0
> #2:  (slock-AF_INET){+.-...}, at: [<c15333d7>] ip_send_reply+0x107/0x2b0
> #3:  (rcu_read_lock){.+.+..}, at: [<c1531456>] ip_finish_output+0x106/0x710
> #4:  (rcu_read_lock_bh){.+....}, at: [<c14fa670>] dev_queue_xmit+0x0/0xbd0
> 
> tack backtrace:
> id: 0, comm: swapper/0 Not tainted 3.5.0-rc2-net-lockdep-u64-sync-007-+ #1
> all Trace:
> [<c10a7b32>] __lock_acquire+0xd52/0x17d0
> [<c10a334b>] ? trace_hardirqs_off+0xb/0x10
> [<c10a8b48>] lock_acquire+0x88/0x120
> [<f862abff>] ? l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
> [<c16157bb>] _raw_spin_lock+0x3b/0x70
> [<f862abff>] ? l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
> [<f862abff>] l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
> [<f851a32d>] l2tp_eth_dev_xmit+0x2d/0x40 [l2tp_eth]
> [<c14fa32f>] dev_hard_start_xmit+0x49f/0x7e0
> [<c14f9ee1>] ? dev_hard_start_xmit+0x51/0x7e0
> [<c1515819>] sch_direct_xmit+0xa9/0x250
> [<c16157e1>] ? _raw_spin_lock+0x61/0x70
> [<c14fa83f>] dev_queue_xmit+0x1cf/0xbd0
> [<c14fa670>] ? dev_hard_start_xmit+0x7e0/0x7e0
> [<c1531537>] ip_finish_output+0x1e7/0x710
> [<c1531456>] ? ip_finish_output+0x106/0x710
> [<c1532770>] ? ip_output+0x60/0x120
> [<c10a585b>] ? trace_hardirqs_on+0xb/0x10
> [<c153278b>] ip_output+0x7b/0x120
> [<c1532fc9>] ? __ip_make_skb+0x229/0x360
> [<c1531b95>] ip_local_out+0x25/0x80
> [<c1533117>] ip_send_skb+0x17/0x70
> [<c153319b>] ip_push_pending_frames+0x2b/0x40
> [<c1533495>] ip_send_reply+0x1c5/0x2b0
> [<c107efef>] ? sched_clock_cpu+0xcf/0x150
> [<c154f253>] tcp_v4_send_ack+0x1a3/0x260
> [<c1552430>] ? tcp_timewait_state_process+0x90/0x3c0
> [<c15514ef>] tcp_v4_rcv+0x3ff/0xc20
> [<c152bdff>] ip_local_deliver_finish+0xef/0x4c0
> [<c152bd4c>] ? ip_local_deliver_finish+0x3c/0x4c0
> [<c152c40f>] ip_local_deliver+0x3f/0x80
> [<c152b844>] ip_rcv_finish+0x174/0x640
> [<c152c671>] ip_rcv+0x221/0x320
> [<c14f7f11>] __netif_receive_skb+0x7d1/0x8d0
> [<c14f7824>] ? __netif_receive_skb+0xe4/0x8d0
> [<c14f80b7>] process_backlog+0xa7/0x170
> [<c14f88dd>] net_rx_action+0x11d/0x210
> [<c104d990>] ? local_bh_enable_ip+0xd0/0xd0
> [<c104da27>] __do_softirq+0x97/0x1f0
> [<c104d990>] ? local_bh_enable_ip+0xd0/0xd0
> <IRQ>  [<c104ddce>] ? irq_exit+0x7e/0xa0
> [<c161e02b>] ? do_IRQ+0x4b/0xc0
> [<c161de75>] ? common_interrupt+0x35/0x3c
> [<c10380d5>] ? native_safe_halt+0x5/0x10
> [<c1018bdf>] ? default_idle+0x4f/0x1e0
> [<c1018dc1>] ? amd_e400_idle+0x51/0x100
> [<c10199c9>] ? cpu_idle+0xb9/0xe0
> [<c15eab3e>] ? rest_init+0x112/0x124
> [<c15eaa2c>] ? __read_lock_failed+0x14/0x14
> [<c1907a11>] ? start_kernel+0x376/0x37c
> [<c19074d6>] ? repair_env_string+0x51/0x51
> [<c19072f8>] ? i386_start_kernel+0x9b/0xa2
> 

Yes, but this is not the splat I fixed.

You reported two different splats, didnt you ?

I fixed a core network issue, I am sure guys who wrote l2tp can fix the
l2tp one ;)

^ permalink raw reply

* Re: [PATCH] net: Use NLMSG_DEFAULT_SIZE in combination with nlmsg_new()
From: Eric Dumazet @ 2012-06-28 14:55 UTC (permalink / raw)
  To: Thomas Graf
  Cc: davem, netdev, Jiri Pirko, Dmitry Eremin-Solenikov, Sergey Lapin,
	Johannes Berg, Lauro Ramos Venancio, Aloisio Almeida Jr,
	Samuel Ortiz
In-Reply-To: <caecbaa2f181c17908fbd61264e1acb9c5cb1fe1.1340891841.git.tgraf@suug.ch>

On Thu, 2012-06-28 at 15:57 +0200, Thomas Graf wrote:
> Using NLMSG_GOODSIZE results in multiple pages being used as
> nlmsg_new() will automatically add the size of the netlink
> header to the payload thus exceeding the page limit.

On the other hand, this limits to 3776 bytes for each recvmsg() call.

Maybe this can add a regression if one of the file needed to store more
than 3776 bytes in the answer ?

For GFP_KERNEL allocations, I am not sure we really need to limit to
order-0 pages...

Unless you can point a real bug, this patch is not for net tree, but
net-next.

^ permalink raw reply

* [PATCH] gianfar: Fix RXICr/TXICr programming for multi-queue mode
From: Claudiu Manoil @ 2012-06-28 14:40 UTC (permalink / raw)
  To: netdev, davem

The correct behavior is to program the interrupt coalescing regs
(RXICr/TXICr) in accordance with the Rx/Tx Q's "rx/txcoalescing"
flag. That is, if the coalescing flag is 0 for a given Rx/Tx queue
then the corresponding coalescing register should be cleared.
This behavior is correctly implemented for the single-queue mode
(SQ_SG_MODE), but not for the multi-queue mode (MQ_MG_MODE).
This fixes the later case.

Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
 drivers/net/ethernet/freescale/gianfar.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index f00a095..af16f9f 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1815,18 +1815,16 @@ void gfar_configure_coalescing(struct gfar_private *priv,
 	if (priv->mode == MQ_MG_MODE) {
 		baddr = &regs->txic0;
 		for_each_set_bit(i, &tx_mask, priv->num_tx_queues) {
-			if (likely(priv->tx_queue[i]->txcoalescing)) {
-				gfar_write(baddr + i, 0);
+			gfar_write(baddr + i, 0);
+			if (likely(priv->tx_queue[i]->txcoalescing))
 				gfar_write(baddr + i, priv->tx_queue[i]->txic);
-			}
 		}
 
 		baddr = &regs->rxic0;
 		for_each_set_bit(i, &rx_mask, priv->num_rx_queues) {
-			if (likely(priv->rx_queue[i]->rxcoalescing)) {
-				gfar_write(baddr + i, 0);
+			gfar_write(baddr + i, 0);
+			if (likely(priv->rx_queue[i]->rxcoalescing))
 				gfar_write(baddr + i, priv->rx_queue[i]->rxic);
-			}
 		}
 	}
 }
-- 
1.6.6

^ permalink raw reply related

* IPV4 , IPV6 & Colocation Service
From: Dedicatedhk @ 2012-06-28 14:34 UTC (permalink / raw)


Whether you're looking for rack space or bandwidth, we are a smart business decision for IP Transit. We specializes in high quality wholesale bandwidth/rack space.

We have our own datacenter in Hong Kong & provide email/application/web rental service to clients.We are APNIC member & provide clean IPV4/IPV6 to clients.

Pls send us email for further information.Thanks,

Boris
boris@dedicatedserver.com.hk

If you do not wish to further receive this event message, email "borislamsv2@gmail.com" to unsubscribe this message or remove your email from the list.

^ permalink raw reply

* Re: LOCKDEP complaints in l2tp_xmit_skb()
From: Tom Parkin @ 2012-06-28 14:33 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1340882551.13187.96.camel@edumazet-glaptop>

[-- Attachment #1: Type: text/plain, Size: 4708 bytes --]

On Thu, Jun 28, 2012 at 01:22:31PM +0200, Eric Dumazet wrote:
> On Thu, 2012-06-28 at 10:57 +0200, Eric Dumazet wrote:
> > On Thu, 2012-06-28 at 08:56 +0200, Eric Dumazet wrote:
> > 
> > > [PATCH] net: Qdisc busylock gets its own lockdep class
> > > 
> > > Tom Parkin reported following LOCKDEP splat :
> > ..
> > > 
> > > Instruct lockdep that each Qdisc busylock is independant, or else
> > > bonding or various tunnels can trigger a splat.
> > > 
> > > Reported-by: Tom Parkin <tparkin@katalix.com>
> > > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > > ---
> > 
> > I reproduced the bug using a bond0 device, adding a qdisc on it,
> > (one Qdisc on bond0, and a Qdisc on the slave too)
> > 
> > Problem with this patch is I have following message :
> > 
> > BUG: key ffff88..... not in .data!
> > 
> > No more LOCKDEP splat, but patch not good as is.
> 
> I tested the alternative following patch with my bonding setup,
> could you test it with l2tp ?
>

I've tested against my l2tp test configuration and I still see LOCKDEP
splats:

2tp_core: L2TP core driver, V2.0
2tp_netlink: L2TP netlink interface
2tp_eth: L2TP ethernet pseudowire support (L2TPv3)

============================================
 INFO: possible recursive locking detected ]
.5.0-rc2-net-lockdep-u64-sync-007-+ #1 Not tainted
--------------------------------------------
wapper/0/0 is trying to acquire lock:
(slock-AF_INET){+.-...}, at: [<f862abff>] l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]

ut task is already holding lock:
(slock-AF_INET){+.-...}, at: [<c15333d7>] ip_send_reply+0x107/0x2b0

ther info that might help us debug this:
Possible unsafe locking scenario:

      CPU0
      ----
 lock(slock-AF_INET);
 lock(slock-AF_INET);

*** DEADLOCK ***

May be due to missing lock nesting notation

 locks held by swapper/0/0:
#0:  (rcu_read_lock){.+.+..}, at: [<c14f7824>] __netif_receive_skb+0xe4/0x8d0
#1:  (rcu_read_lock){.+.+..}, at: [<c152bd4c>] ip_local_deliver_finish+0x3c/0x4c0
#2:  (slock-AF_INET){+.-...}, at: [<c15333d7>] ip_send_reply+0x107/0x2b0
#3:  (rcu_read_lock){.+.+..}, at: [<c1531456>] ip_finish_output+0x106/0x710
#4:  (rcu_read_lock_bh){.+....}, at: [<c14fa670>] dev_queue_xmit+0x0/0xbd0

tack backtrace:
id: 0, comm: swapper/0 Not tainted 3.5.0-rc2-net-lockdep-u64-sync-007-+ #1
all Trace:
[<c10a7b32>] __lock_acquire+0xd52/0x17d0
[<c10a334b>] ? trace_hardirqs_off+0xb/0x10
[<c10a8b48>] lock_acquire+0x88/0x120
[<f862abff>] ? l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
[<c16157bb>] _raw_spin_lock+0x3b/0x70
[<f862abff>] ? l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
[<f862abff>] l2tp_xmit_skb+0x13f/0x8e0 [l2tp_core]
[<f851a32d>] l2tp_eth_dev_xmit+0x2d/0x40 [l2tp_eth]
[<c14fa32f>] dev_hard_start_xmit+0x49f/0x7e0
[<c14f9ee1>] ? dev_hard_start_xmit+0x51/0x7e0
[<c1515819>] sch_direct_xmit+0xa9/0x250
[<c16157e1>] ? _raw_spin_lock+0x61/0x70
[<c14fa83f>] dev_queue_xmit+0x1cf/0xbd0
[<c14fa670>] ? dev_hard_start_xmit+0x7e0/0x7e0
[<c1531537>] ip_finish_output+0x1e7/0x710
[<c1531456>] ? ip_finish_output+0x106/0x710
[<c1532770>] ? ip_output+0x60/0x120
[<c10a585b>] ? trace_hardirqs_on+0xb/0x10
[<c153278b>] ip_output+0x7b/0x120
[<c1532fc9>] ? __ip_make_skb+0x229/0x360
[<c1531b95>] ip_local_out+0x25/0x80
[<c1533117>] ip_send_skb+0x17/0x70
[<c153319b>] ip_push_pending_frames+0x2b/0x40
[<c1533495>] ip_send_reply+0x1c5/0x2b0
[<c107efef>] ? sched_clock_cpu+0xcf/0x150
[<c154f253>] tcp_v4_send_ack+0x1a3/0x260
[<c1552430>] ? tcp_timewait_state_process+0x90/0x3c0
[<c15514ef>] tcp_v4_rcv+0x3ff/0xc20
[<c152bdff>] ip_local_deliver_finish+0xef/0x4c0
[<c152bd4c>] ? ip_local_deliver_finish+0x3c/0x4c0
[<c152c40f>] ip_local_deliver+0x3f/0x80
[<c152b844>] ip_rcv_finish+0x174/0x640
[<c152c671>] ip_rcv+0x221/0x320
[<c14f7f11>] __netif_receive_skb+0x7d1/0x8d0
[<c14f7824>] ? __netif_receive_skb+0xe4/0x8d0
[<c14f80b7>] process_backlog+0xa7/0x170
[<c14f88dd>] net_rx_action+0x11d/0x210
[<c104d990>] ? local_bh_enable_ip+0xd0/0xd0
[<c104da27>] __do_softirq+0x97/0x1f0
[<c104d990>] ? local_bh_enable_ip+0xd0/0xd0
<IRQ>  [<c104ddce>] ? irq_exit+0x7e/0xa0
[<c161e02b>] ? do_IRQ+0x4b/0xc0
[<c161de75>] ? common_interrupt+0x35/0x3c
[<c10380d5>] ? native_safe_halt+0x5/0x10
[<c1018bdf>] ? default_idle+0x4f/0x1e0
[<c1018dc1>] ? amd_e400_idle+0x51/0x100
[<c10199c9>] ? cpu_idle+0xb9/0xe0
[<c15eab3e>] ? rest_init+0x112/0x124
[<c15eaa2c>] ? __read_lock_failed+0x14/0x14
[<c1907a11>] ? start_kernel+0x376/0x37c
[<c19074d6>] ? repair_env_string+0x51/0x51
[<c19072f8>] ? i386_start_kernel+0x9b/0xa2

-- 
Tom Parkin
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* [patch net-next 4/4] dummy: use IFF_LIFE_ADDR_CHANGE priv_flag
From: Jiri Pirko @ 2012-06-28 14:10 UTC (permalink / raw)
  To: netdev
  Cc: davem, rusty, mst, virtualization, edumazet, danny.kukawka,
	shimoda.hiroaki
In-Reply-To: <1340892639-1111-1-git-send-email-jpirko@redhat.com>

Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
 drivers/net/dummy.c |   15 ++-------------
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index bab0158..0352246 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -40,18 +40,6 @@
 
 static int numdummies = 1;
 
-static int dummy_set_address(struct net_device *dev, void *p)
-{
-	struct sockaddr *sa = p;
-
-	if (!is_valid_ether_addr(sa->sa_data))
-		return -EADDRNOTAVAIL;
-
-	dev->addr_assign_type &= ~NET_ADDR_RANDOM;
-	memcpy(dev->dev_addr, sa->sa_data, ETH_ALEN);
-	return 0;
-}
-
 /* fake multicast ability */
 static void set_multicast_list(struct net_device *dev)
 {
@@ -118,7 +106,7 @@ static const struct net_device_ops dummy_netdev_ops = {
 	.ndo_start_xmit		= dummy_xmit,
 	.ndo_validate_addr	= eth_validate_addr,
 	.ndo_set_rx_mode	= set_multicast_list,
-	.ndo_set_mac_address	= dummy_set_address,
+	.ndo_set_mac_address	= eth_mac_addr,
 	.ndo_get_stats64	= dummy_get_stats64,
 };
 
@@ -134,6 +122,7 @@ static void dummy_setup(struct net_device *dev)
 	dev->tx_queue_len = 0;
 	dev->flags |= IFF_NOARP;
 	dev->flags &= ~IFF_MULTICAST;
+	dev->priv_flags |= IFF_LIFE_ADDR_CHANGE;
 	dev->features	|= NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO;
 	dev->features	|= NETIF_F_HW_CSUM | NETIF_F_HIGHDMA | NETIF_F_LLTX;
 	eth_hw_addr_random(dev);
-- 
1.7.10.4

^ permalink raw reply related

* [patch net-next 3/4] team: use IFF_LIFE_ADDR_CHANGE priv_flag
From: Jiri Pirko @ 2012-06-28 14:10 UTC (permalink / raw)
  To: netdev; +Cc: mst, shimoda.hiroaki, virtualization, danny.kukawka, edumazet,
	davem
In-Reply-To: <1340892639-1111-1-git-send-email-jpirko@redhat.com>

Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
 drivers/net/team/team.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 5350eea..019d658 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1188,10 +1188,11 @@ static int team_set_mac_address(struct net_device *dev, void *p)
 {
 	struct team *team = netdev_priv(dev);
 	struct team_port *port;
-	struct sockaddr *addr = p;
+	int err;
 
-	dev->addr_assign_type &= ~NET_ADDR_RANDOM;
-	memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN);
+	err = eth_mac_addr(dev, p);
+	if (err)
+		return err;
 	rcu_read_lock();
 	list_for_each_entry_rcu(port, &team->port_list, list)
 		if (team->ops.port_change_mac)
@@ -1393,7 +1394,7 @@ static void team_setup(struct net_device *dev)
 	 * bring us to promisc mode in case a unicast addr is added.
 	 * Let this up to underlay drivers.
 	 */
-	dev->priv_flags |= IFF_UNICAST_FLT;
+	dev->priv_flags |= IFF_UNICAST_FLT | IFF_LIFE_ADDR_CHANGE;
 
 	dev->features |= NETIF_F_LLTX;
 	dev->features |= NETIF_F_GRO;
-- 
1.7.10.4

^ permalink raw reply related

* [patch net-next 2/4] virtio_net: use IFF_LIFE_ADDR_CHANGE priv_flag
From: Jiri Pirko @ 2012-06-28 14:10 UTC (permalink / raw)
  To: netdev; +Cc: mst, shimoda.hiroaki, virtualization, danny.kukawka, edumazet,
	davem
In-Reply-To: <1340892639-1111-1-git-send-email-jpirko@redhat.com>

Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
 drivers/net/virtio_net.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 36a16d5..6a0f526 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -679,12 +679,11 @@ static int virtnet_set_mac_address(struct net_device *dev, void *p)
 {
 	struct virtnet_info *vi = netdev_priv(dev);
 	struct virtio_device *vdev = vi->vdev;
-	struct sockaddr *addr = p;
+	int ret;
 
-	if (!is_valid_ether_addr(addr->sa_data))
-		return -EADDRNOTAVAIL;
-	memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN);
-	dev->addr_assign_type &= ~NET_ADDR_RANDOM;
+	ret = eth_mac_addr(dev, p);
+	if (ret)
+		return ret;
 
 	if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC))
 		vdev->config->set(vdev, offsetof(struct virtio_net_config, mac),
@@ -1063,7 +1062,7 @@ static int virtnet_probe(struct virtio_device *vdev)
 		return -ENOMEM;
 
 	/* Set up network device as normal. */
-	dev->priv_flags |= IFF_UNICAST_FLT;
+	dev->priv_flags |= IFF_UNICAST_FLT | IFF_LIFE_ADDR_CHANGE;
 	dev->netdev_ops = &virtnet_netdev;
 	dev->features = NETIF_F_HIGHDMA;
 
-- 
1.7.10.4

^ permalink raw reply related

* [patch net-next 1/4] net: introduce new priv_flag indicating iface capable of change mac when running
From: Jiri Pirko @ 2012-06-28 14:10 UTC (permalink / raw)
  To: netdev; +Cc: mst, shimoda.hiroaki, virtualization, danny.kukawka, edumazet,
	davem
In-Reply-To: <1340892639-1111-1-git-send-email-jpirko@redhat.com>

Introduce IFF_LIFE_ADDR_CHANGE priv_flag and use it to disable
netif_running() check in eth_mac_addr()

Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
 include/linux/if.h |    2 ++
 net/ethernet/eth.c |    2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/if.h b/include/linux/if.h
index f995c66..fd9ee7c 100644
--- a/include/linux/if.h
+++ b/include/linux/if.h
@@ -81,6 +81,8 @@
 #define IFF_UNICAST_FLT	0x20000		/* Supports unicast filtering	*/
 #define IFF_TEAM_PORT	0x40000		/* device used as team port */
 #define IFF_SUPP_NOFCS	0x80000		/* device supports sending custom FCS */
+#define IFF_LIFE_ADDR_CHANGE 0x100000	/* device supports hardware address
+					 * change when it's running */
 
 
 #define IF_GET_IFACE	0x0001		/* for querying only */
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 36e5880..8f8ded4 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -283,7 +283,7 @@ int eth_mac_addr(struct net_device *dev, void *p)
 {
 	struct sockaddr *addr = p;
 
-	if (netif_running(dev))
+	if (!(dev->priv_flags & IFF_LIFE_ADDR_CHANGE) && netif_running(dev))
 		return -EBUSY;
 	if (!is_valid_ether_addr(addr->sa_data))
 		return -EADDRNOTAVAIL;
-- 
1.7.10.4

^ permalink raw reply related

* [patch net-next 0/4] net: introduce and use IFF_LIFE_ADDR_CHANGE
From: Jiri Pirko @ 2012-06-28 14:10 UTC (permalink / raw)
  To: netdev; +Cc: mst, shimoda.hiroaki, virtualization, danny.kukawka, edumazet,
	davem

three drivers updated, but this can be used in many others.

Jiri Pirko (4):
  net: introduce new priv_flag indicating iface capable of change mac
    when running
  virtio_net: use IFF_LIFE_ADDR_CHANGE priv_flag
  team: use IFF_LIFE_ADDR_CHANGE priv_flag
  dummy: use IFF_LIFE_ADDR_CHANGE priv_flag

 drivers/net/dummy.c      |   15 ++-------------
 drivers/net/team/team.c  |    9 +++++----
 drivers/net/virtio_net.c |   11 +++++------
 include/linux/if.h       |    2 ++
 net/ethernet/eth.c       |    2 +-
 5 files changed, 15 insertions(+), 24 deletions(-)

-- 
1.7.10.4

^ permalink raw reply

* Re: [PATCH] net: Use NLMSG_DEFAULT_SIZE in combination with nlmsg_new()
From: Jiri Pirko @ 2012-06-28 14:04 UTC (permalink / raw)
  To: Thomas Graf
  Cc: davem, netdev, Dmitry Eremin-Solenikov, Sergey Lapin,
	Johannes Berg, Lauro Ramos Venancio, Aloisio Almeida Jr,
	Samuel Ortiz
In-Reply-To: <caecbaa2f181c17908fbd61264e1acb9c5cb1fe1.1340891841.git.tgraf@suug.ch>

I was thinking about similar patch a week ago.

Reviewed-by: Jiri Pirko <jpirko@redhat.com>

Thu, Jun 28, 2012 at 03:57:45PM CEST, tgraf@suug.ch wrote:
>Using NLMSG_GOODSIZE results in multiple pages being used as
>nlmsg_new() will automatically add the size of the netlink
>header to the payload thus exceeding the page limit.
>
>NLMSG_DEFAULT_SIZE takes this into account.
>
>Signed-off-by: Thomas Graf <tgraf@suug.ch>
>Cc: Jiri Pirko <jpirko@redhat.com>
>Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>Cc: Sergey Lapin <slapin@ossfans.org>
>Cc: Johannes Berg <johannes@sipsolutions.net>
>Cc: Lauro Ramos Venancio <lauro.venancio@openbossa.org>
>Cc: Aloisio Almeida Jr <aloisio.almeida@openbossa.org>
>Cc: Samuel Ortiz <sameo@linux.intel.com>
>---
> drivers/net/team/team.c               |    8 ++++----
> drivers/net/wireless/mac80211_hwsim.c |    2 +-
> include/net/genetlink.h               |    2 ++
> net/ieee802154/netlink.c              |    4 ++--
> net/ieee802154/nl-mac.c               |    2 +-
> net/ieee802154/nl-phy.c               |    2 +-
> net/l2tp/l2tp_netlink.c               |    6 +++---
> net/nfc/netlink.c                     |   18 +++++++++---------
> net/wireless/nl80211.c                |   26 +++++++++++++-------------
> 9 files changed, 36 insertions(+), 34 deletions(-)
>
>diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
>index 5350eea..89853c3 100644
>--- a/drivers/net/team/team.c
>+++ b/drivers/net/team/team.c
>@@ -1476,7 +1476,7 @@ static int team_nl_cmd_noop(struct sk_buff *skb, struct genl_info *info)
> 	void *hdr;
> 	int err;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		return -ENOMEM;
> 
>@@ -1538,7 +1538,7 @@ static int team_nl_send_generic(struct genl_info *info, struct team *team,
> 	struct sk_buff *skb;
> 	int err;
> 
>-	skb = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!skb)
> 		return -ENOMEM;
> 
>@@ -1648,7 +1648,7 @@ static int __send_and_alloc_skb(struct sk_buff **pskb,
> 		if (err)
> 			return err;
> 	}
>-	*pskb = genlmsg_new(NLMSG_DEFAULT_SIZE - GENL_HDRLEN, GFP_KERNEL);
>+	*pskb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!*pskb)
> 		return -ENOMEM;
> 	return 0;
>@@ -2016,7 +2016,7 @@ static int team_nl_send_event_port_list_get(struct team *team)
> 	int err;
> 	struct net *net = dev_net(team->dev);
> 
>-	skb = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!skb)
> 		return -ENOMEM;
> 
>diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
>index a0b7cfd..a9ba3f7 100644
>--- a/drivers/net/wireless/mac80211_hwsim.c
>+++ b/drivers/net/wireless/mac80211_hwsim.c
>@@ -571,7 +571,7 @@ static void mac80211_hwsim_tx_frame_nl(struct ieee80211_hw *hw,
> 			skb_dequeue(&data->pending);
> 	}
> 
>-	skb = genlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
>+	skb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_ATOMIC);
> 	if (skb == NULL)
> 		goto nla_put_failure;
> 
>diff --git a/include/net/genetlink.h b/include/net/genetlink.h
>index ccb6888..48905cd 100644
>--- a/include/net/genetlink.h
>+++ b/include/net/genetlink.h
>@@ -5,6 +5,8 @@
> #include <net/netlink.h>
> #include <net/net_namespace.h>
> 
>+#define GENLMSG_DEFAULT_SIZE (NLMSG_DEFAULT_SIZE - GENL_HDRLEN)
>+
> /**
>  * struct genl_multicast_group - generic netlink multicast group
>  * @name: name of the multicast group, names are per-family
>diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
>index c8097ae..97351e1 100644
>--- a/net/ieee802154/netlink.c
>+++ b/net/ieee802154/netlink.c
>@@ -44,7 +44,7 @@ struct genl_family nl802154_family = {
> struct sk_buff *ieee802154_nl_create(int flags, u8 req)
> {
> 	void *hdr;
>-	struct sk_buff *msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
>+	struct sk_buff *msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
> 	unsigned long f;
> 
> 	if (!msg)
>@@ -80,7 +80,7 @@ struct sk_buff *ieee802154_nl_new_reply(struct genl_info *info,
> 		int flags, u8 req)
> {
> 	void *hdr;
>-	struct sk_buff *msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
>+	struct sk_buff *msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
> 
> 	if (!msg)
> 		return NULL;
>diff --git a/net/ieee802154/nl-mac.c b/net/ieee802154/nl-mac.c
>index ca92587..1e99171 100644
>--- a/net/ieee802154/nl-mac.c
>+++ b/net/ieee802154/nl-mac.c
>@@ -530,7 +530,7 @@ static int ieee802154_list_iface(struct sk_buff *skb,
> 	if (!dev)
> 		return -ENODEV;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		goto out_dev;
> 
>diff --git a/net/ieee802154/nl-phy.c b/net/ieee802154/nl-phy.c
>index eed2916..d54be34 100644
>--- a/net/ieee802154/nl-phy.c
>+++ b/net/ieee802154/nl-phy.c
>@@ -101,7 +101,7 @@ static int ieee802154_list_phy(struct sk_buff *skb,
> 	if (!phy)
> 		return -ENODEV;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		goto out_dev;
> 
>diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
>index ddc553e..d71cd92 100644
>--- a/net/l2tp/l2tp_netlink.c
>+++ b/net/l2tp/l2tp_netlink.c
>@@ -72,7 +72,7 @@ static int l2tp_nl_cmd_noop(struct sk_buff *skb, struct genl_info *info)
> 	void *hdr;
> 	int ret = -ENOBUFS;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg) {
> 		ret = -ENOMEM;
> 		goto out;
>@@ -353,7 +353,7 @@ static int l2tp_nl_cmd_tunnel_get(struct sk_buff *skb, struct genl_info *info)
> 		goto out;
> 	}
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg) {
> 		ret = -ENOMEM;
> 		goto out;
>@@ -699,7 +699,7 @@ static int l2tp_nl_cmd_session_get(struct sk_buff *skb, struct genl_info *info)
> 		goto out;
> 	}
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg) {
> 		ret = -ENOMEM;
> 		goto out;
>diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
>index 03c31db..f4f07f9 100644
>--- a/net/nfc/netlink.c
>+++ b/net/nfc/netlink.c
>@@ -167,7 +167,7 @@ int nfc_genl_targets_found(struct nfc_dev *dev)
> 
> 	dev->genl_data.poll_req_pid = 0;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
> 	if (!msg)
> 		return -ENOMEM;
> 
>@@ -195,7 +195,7 @@ int nfc_genl_target_lost(struct nfc_dev *dev, u32 target_idx)
> 	struct sk_buff *msg;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		return -ENOMEM;
> 
>@@ -226,7 +226,7 @@ int nfc_genl_tm_activated(struct nfc_dev *dev, u32 protocol)
> 	struct sk_buff *msg;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		return -ENOMEM;
> 
>@@ -258,7 +258,7 @@ int nfc_genl_tm_deactivated(struct nfc_dev *dev)
> 	struct sk_buff *msg;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		return -ENOMEM;
> 
>@@ -288,7 +288,7 @@ int nfc_genl_device_added(struct nfc_dev *dev)
> 	struct sk_buff *msg;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		return -ENOMEM;
> 
>@@ -321,7 +321,7 @@ int nfc_genl_device_removed(struct nfc_dev *dev)
> 	struct sk_buff *msg;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		return -ENOMEM;
> 
>@@ -434,7 +434,7 @@ int nfc_genl_dep_link_up_event(struct nfc_dev *dev, u32 target_idx,
> 
> 	pr_debug("DEP link is up\n");
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
> 	if (!msg)
> 		return -ENOMEM;
> 
>@@ -473,7 +473,7 @@ int nfc_genl_dep_link_down_event(struct nfc_dev *dev)
> 
> 	pr_debug("DEP link is down\n");
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
> 	if (!msg)
> 		return -ENOMEM;
> 
>@@ -514,7 +514,7 @@ static int nfc_genl_get_device(struct sk_buff *skb, struct genl_info *info)
> 	if (!dev)
> 		return -ENODEV;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg) {
> 		rc = -ENOMEM;
> 		goto out_putdev;
>diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
>index 7ae54b8..cbdc0fd 100644
>--- a/net/wireless/nl80211.c
>+++ b/net/wireless/nl80211.c
>@@ -7210,7 +7210,7 @@ void nl80211_send_scan_start(struct cfg80211_registered_device *rdev,
> {
> 	struct sk_buff *msg;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		return;
> 
>@@ -7286,7 +7286,7 @@ void nl80211_send_sched_scan(struct cfg80211_registered_device *rdev,
> {
> 	struct sk_buff *msg;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		return;
> 
>@@ -7502,7 +7502,7 @@ void nl80211_send_connect_result(struct cfg80211_registered_device *rdev,
> 	struct sk_buff *msg;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> 	if (!msg)
> 		return;
> 
>@@ -7542,7 +7542,7 @@ void nl80211_send_roamed(struct cfg80211_registered_device *rdev,
> 	struct sk_buff *msg;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> 	if (!msg)
> 		return;
> 
>@@ -7580,7 +7580,7 @@ void nl80211_send_disconnected(struct cfg80211_registered_device *rdev,
> 	struct sk_buff *msg;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> 	if (!msg)
> 		return;
> 
>@@ -7842,7 +7842,7 @@ void nl80211_send_sta_event(struct cfg80211_registered_device *rdev,
> {
> 	struct sk_buff *msg;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> 	if (!msg)
> 		return;
> 
>@@ -7863,7 +7863,7 @@ void nl80211_send_sta_del_event(struct cfg80211_registered_device *rdev,
> 	struct sk_buff *msg;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> 	if (!msg)
> 		return;
> 
>@@ -8026,7 +8026,7 @@ nl80211_send_cqm_rssi_notify(struct cfg80211_registered_device *rdev,
> 	struct nlattr *pinfoattr;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> 	if (!msg)
> 		return;
> 
>@@ -8069,7 +8069,7 @@ void nl80211_gtk_rekey_notify(struct cfg80211_registered_device *rdev,
> 	struct nlattr *rekey_attr;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> 	if (!msg)
> 		return;
> 
>@@ -8113,7 +8113,7 @@ void nl80211_pmksa_candidate_notify(struct cfg80211_registered_device *rdev,
> 	struct nlattr *attr;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> 	if (!msg)
> 		return;
> 
>@@ -8157,7 +8157,7 @@ void nl80211_ch_switch_notify(struct cfg80211_registered_device *rdev,
> 	struct sk_buff *msg;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> 	if (!msg)
> 		return;
> 
>@@ -8192,7 +8192,7 @@ nl80211_send_cqm_pktloss_notify(struct cfg80211_registered_device *rdev,
> 	struct nlattr *pinfoattr;
> 	void *hdr;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> 	if (!msg)
> 		return;
> 
>@@ -8236,7 +8236,7 @@ void cfg80211_probe_status(struct net_device *dev, const u8 *addr,
> 	void *hdr;
> 	int err;
> 
>-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
>+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> 	if (!msg)
> 		return;
> 
>-- 
>1.7.7.6
>

^ permalink raw reply

* [PATCH] net: Use NLMSG_DEFAULT_SIZE in combination with nlmsg_new()
From: Thomas Graf @ 2012-06-28 13:57 UTC (permalink / raw)
  To: davem
  Cc: netdev, Jiri Pirko, Dmitry Eremin-Solenikov, Sergey Lapin,
	Johannes Berg, Lauro Ramos Venancio, Aloisio Almeida Jr,
	Samuel Ortiz

Using NLMSG_GOODSIZE results in multiple pages being used as
nlmsg_new() will automatically add the size of the netlink
header to the payload thus exceeding the page limit.

NLMSG_DEFAULT_SIZE takes this into account.

Signed-off-by: Thomas Graf <tgraf@suug.ch>
Cc: Jiri Pirko <jpirko@redhat.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Sergey Lapin <slapin@ossfans.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Lauro Ramos Venancio <lauro.venancio@openbossa.org>
Cc: Aloisio Almeida Jr <aloisio.almeida@openbossa.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
 drivers/net/team/team.c               |    8 ++++----
 drivers/net/wireless/mac80211_hwsim.c |    2 +-
 include/net/genetlink.h               |    2 ++
 net/ieee802154/netlink.c              |    4 ++--
 net/ieee802154/nl-mac.c               |    2 +-
 net/ieee802154/nl-phy.c               |    2 +-
 net/l2tp/l2tp_netlink.c               |    6 +++---
 net/nfc/netlink.c                     |   18 +++++++++---------
 net/wireless/nl80211.c                |   26 +++++++++++++-------------
 9 files changed, 36 insertions(+), 34 deletions(-)

diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 5350eea..89853c3 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1476,7 +1476,7 @@ static int team_nl_cmd_noop(struct sk_buff *skb, struct genl_info *info)
 	void *hdr;
 	int err;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		return -ENOMEM;
 
@@ -1538,7 +1538,7 @@ static int team_nl_send_generic(struct genl_info *info, struct team *team,
 	struct sk_buff *skb;
 	int err;
 
-	skb = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!skb)
 		return -ENOMEM;
 
@@ -1648,7 +1648,7 @@ static int __send_and_alloc_skb(struct sk_buff **pskb,
 		if (err)
 			return err;
 	}
-	*pskb = genlmsg_new(NLMSG_DEFAULT_SIZE - GENL_HDRLEN, GFP_KERNEL);
+	*pskb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!*pskb)
 		return -ENOMEM;
 	return 0;
@@ -2016,7 +2016,7 @@ static int team_nl_send_event_port_list_get(struct team *team)
 	int err;
 	struct net *net = dev_net(team->dev);
 
-	skb = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!skb)
 		return -ENOMEM;
 
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index a0b7cfd..a9ba3f7 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -571,7 +571,7 @@ static void mac80211_hwsim_tx_frame_nl(struct ieee80211_hw *hw,
 			skb_dequeue(&data->pending);
 	}
 
-	skb = genlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
+	skb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_ATOMIC);
 	if (skb == NULL)
 		goto nla_put_failure;
 
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index ccb6888..48905cd 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -5,6 +5,8 @@
 #include <net/netlink.h>
 #include <net/net_namespace.h>
 
+#define GENLMSG_DEFAULT_SIZE (NLMSG_DEFAULT_SIZE - GENL_HDRLEN)
+
 /**
  * struct genl_multicast_group - generic netlink multicast group
  * @name: name of the multicast group, names are per-family
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index c8097ae..97351e1 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -44,7 +44,7 @@ struct genl_family nl802154_family = {
 struct sk_buff *ieee802154_nl_create(int flags, u8 req)
 {
 	void *hdr;
-	struct sk_buff *msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
+	struct sk_buff *msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
 	unsigned long f;
 
 	if (!msg)
@@ -80,7 +80,7 @@ struct sk_buff *ieee802154_nl_new_reply(struct genl_info *info,
 		int flags, u8 req)
 {
 	void *hdr;
-	struct sk_buff *msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
+	struct sk_buff *msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
 
 	if (!msg)
 		return NULL;
diff --git a/net/ieee802154/nl-mac.c b/net/ieee802154/nl-mac.c
index ca92587..1e99171 100644
--- a/net/ieee802154/nl-mac.c
+++ b/net/ieee802154/nl-mac.c
@@ -530,7 +530,7 @@ static int ieee802154_list_iface(struct sk_buff *skb,
 	if (!dev)
 		return -ENODEV;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		goto out_dev;
 
diff --git a/net/ieee802154/nl-phy.c b/net/ieee802154/nl-phy.c
index eed2916..d54be34 100644
--- a/net/ieee802154/nl-phy.c
+++ b/net/ieee802154/nl-phy.c
@@ -101,7 +101,7 @@ static int ieee802154_list_phy(struct sk_buff *skb,
 	if (!phy)
 		return -ENODEV;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		goto out_dev;
 
diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index ddc553e..d71cd92 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -72,7 +72,7 @@ static int l2tp_nl_cmd_noop(struct sk_buff *skb, struct genl_info *info)
 	void *hdr;
 	int ret = -ENOBUFS;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg) {
 		ret = -ENOMEM;
 		goto out;
@@ -353,7 +353,7 @@ static int l2tp_nl_cmd_tunnel_get(struct sk_buff *skb, struct genl_info *info)
 		goto out;
 	}
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg) {
 		ret = -ENOMEM;
 		goto out;
@@ -699,7 +699,7 @@ static int l2tp_nl_cmd_session_get(struct sk_buff *skb, struct genl_info *info)
 		goto out;
 	}
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg) {
 		ret = -ENOMEM;
 		goto out;
diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index 03c31db..f4f07f9 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -167,7 +167,7 @@ int nfc_genl_targets_found(struct nfc_dev *dev)
 
 	dev->genl_data.poll_req_pid = 0;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
 	if (!msg)
 		return -ENOMEM;
 
@@ -195,7 +195,7 @@ int nfc_genl_target_lost(struct nfc_dev *dev, u32 target_idx)
 	struct sk_buff *msg;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		return -ENOMEM;
 
@@ -226,7 +226,7 @@ int nfc_genl_tm_activated(struct nfc_dev *dev, u32 protocol)
 	struct sk_buff *msg;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		return -ENOMEM;
 
@@ -258,7 +258,7 @@ int nfc_genl_tm_deactivated(struct nfc_dev *dev)
 	struct sk_buff *msg;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		return -ENOMEM;
 
@@ -288,7 +288,7 @@ int nfc_genl_device_added(struct nfc_dev *dev)
 	struct sk_buff *msg;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		return -ENOMEM;
 
@@ -321,7 +321,7 @@ int nfc_genl_device_removed(struct nfc_dev *dev)
 	struct sk_buff *msg;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		return -ENOMEM;
 
@@ -434,7 +434,7 @@ int nfc_genl_dep_link_up_event(struct nfc_dev *dev, u32 target_idx,
 
 	pr_debug("DEP link is up\n");
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
 	if (!msg)
 		return -ENOMEM;
 
@@ -473,7 +473,7 @@ int nfc_genl_dep_link_down_event(struct nfc_dev *dev)
 
 	pr_debug("DEP link is down\n");
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
 	if (!msg)
 		return -ENOMEM;
 
@@ -514,7 +514,7 @@ static int nfc_genl_get_device(struct sk_buff *skb, struct genl_info *info)
 	if (!dev)
 		return -ENODEV;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg) {
 		rc = -ENOMEM;
 		goto out_putdev;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7ae54b8..cbdc0fd 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7210,7 +7210,7 @@ void nl80211_send_scan_start(struct cfg80211_registered_device *rdev,
 {
 	struct sk_buff *msg;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		return;
 
@@ -7286,7 +7286,7 @@ void nl80211_send_sched_scan(struct cfg80211_registered_device *rdev,
 {
 	struct sk_buff *msg;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		return;
 
@@ -7502,7 +7502,7 @@ void nl80211_send_connect_result(struct cfg80211_registered_device *rdev,
 	struct sk_buff *msg;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
 	if (!msg)
 		return;
 
@@ -7542,7 +7542,7 @@ void nl80211_send_roamed(struct cfg80211_registered_device *rdev,
 	struct sk_buff *msg;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
 	if (!msg)
 		return;
 
@@ -7580,7 +7580,7 @@ void nl80211_send_disconnected(struct cfg80211_registered_device *rdev,
 	struct sk_buff *msg;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
 	if (!msg)
 		return;
 
@@ -7842,7 +7842,7 @@ void nl80211_send_sta_event(struct cfg80211_registered_device *rdev,
 {
 	struct sk_buff *msg;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
 	if (!msg)
 		return;
 
@@ -7863,7 +7863,7 @@ void nl80211_send_sta_del_event(struct cfg80211_registered_device *rdev,
 	struct sk_buff *msg;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
 	if (!msg)
 		return;
 
@@ -8026,7 +8026,7 @@ nl80211_send_cqm_rssi_notify(struct cfg80211_registered_device *rdev,
 	struct nlattr *pinfoattr;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
 	if (!msg)
 		return;
 
@@ -8069,7 +8069,7 @@ void nl80211_gtk_rekey_notify(struct cfg80211_registered_device *rdev,
 	struct nlattr *rekey_attr;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
 	if (!msg)
 		return;
 
@@ -8113,7 +8113,7 @@ void nl80211_pmksa_candidate_notify(struct cfg80211_registered_device *rdev,
 	struct nlattr *attr;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
 	if (!msg)
 		return;
 
@@ -8157,7 +8157,7 @@ void nl80211_ch_switch_notify(struct cfg80211_registered_device *rdev,
 	struct sk_buff *msg;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
 	if (!msg)
 		return;
 
@@ -8192,7 +8192,7 @@ nl80211_send_cqm_pktloss_notify(struct cfg80211_registered_device *rdev,
 	struct nlattr *pinfoattr;
 	void *hdr;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
 	if (!msg)
 		return;
 
@@ -8236,7 +8236,7 @@ void cfg80211_probe_status(struct net_device *dev, const u8 *addr,
 	void *hdr;
 	int err;
 
-	msg = nlmsg_new(NLMSG_GOODSIZE, gfp);
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
 	if (!msg)
 		return;
 
-- 
1.7.7.6

^ permalink raw reply related

* Bridged networking panics
From: Massimo Cetra @ 2012-06-28 13:57 UTC (permalink / raw)
  To: netdev, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

Hi all,

i'm attaching 3 panics of a 3.2.X kernel.
The panics were obtained with a 3.2.20 from debian testing and from a 
vanilla compile of 3.2.21.

Those panics have been already posted some months ago [1] but are not fixed.

The problems seems related to bridged networking.
Whenever there is a bridged aliased interface (like br0:1 br0:2 etcc), 
the server will panic after some time. The more the network load, the 
shortest the uptime.
Removing (ifconfig br0:1 down) or adding back an interface seems to help 
the panic to appear.

Any more hints ?

MC

[1] for example http://comments.gmane.org/gmane.linux.network/226912

[-- Attachment #2: 3.2.20.2-1.txt --]
[-- Type: text/plain, Size: 16034 bytes --]

Jun 28 13:18:35 172.30.1.2 [ 295.504843] BUG: unable to handle kernel 
Jun 28 13:18:35 172.30.1.2 [ 295.520628] IP:
Jun 28 13:18:35 172.30.1.2 [ 295.534792] PGD 0 
Jun 28 13:18:35 172.30.1.2 
Jun 28 13:18:35 172.30.1.2 [ 295.538889] Oops: 0000 [#1] 
Jun 28 13:18:35 172.30.1.2 SMP
Jun 28 13:18:35 172.30.1.2 
Jun 28 13:18:35 172.30.1.2 [ 295.545471] CPU 0 
Jun 28 13:18:35 172.30.1.2 
Jun 28 13:18:35 172.30.1.2 [ 295.549169] Modules linked in:
Jun 28 13:18:35 172.30.1.2 
Jun 28 13:18:35 172.30.1.2 [ 295.691502] 
Jun 28 13:18:35 172.30.1.2 [ 295.694506] Pid: 7754, comm: kvm Not tainted 3.2.0-2-amd64 #1
Jun 28 13:18:35 172.30.1.2 /0N051F
Jun 28 13:18:35 172.30.1.2 
Jun 28 13:18:35 172.30.1.2 [ 295.711720] RIP: 0010:[<ffffffffa01c333d>] 
Jun 28 13:18:35 172.30.1.2 [ 295.730738] RSP: 0018:ffff88042fc03b18  EFLAGS: 00010293
Jun 28 13:18:35 172.30.1.2 [ 295.741389] RAX: 0000000000000000 RBX: ffff880411b9eec0 RCX: 00000000fffffba0
Jun 28 13:18:35 172.30.1.2 [ 295.755682] RDX: ffffffffa01c330f RSI: 0000000000000282 RDI: ffff880411b9eec0
Jun 28 13:18:35 172.30.1.2 [ 295.769975] RBP: ffff880226688000 R08: 0000000000000000 R09: ffff88042fc03ad0
Jun 28 13:18:35 172.30.1.2 [ 295.784268] R10: ffffffff8165ab00 R11: ffffffff8165ab00 R12: 0000000000000000
Jun 28 13:18:35 172.30.1.2 [ 295.798561] R13: ffff880225bec002 R14: ffff8804131987c0 R15: ffff880225bec000
Jun 28 13:18:35 172.30.1.2 [ 295.812854] FS:  00007fc06177d900(0000) GS:ffff88042fc00000(0000) knlGS:0000000000000000
Jun 28 13:18:35 172.30.1.2 [ 295.829070] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 28 13:18:35 172.30.1.2 [ 295.840587] CR2: 0000000000000018 CR3: 0000000409d7b000 CR4: 00000000000026e0
Jun 28 13:18:35 172.30.1.2 [ 295.854880] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun 28 13:18:35 172.30.1.2 [ 295.869175] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jun 28 13:18:35 172.30.1.2 [ 295.883469] Process kvm (pid: 7754, threadinfo ffff88040bcc6000, task ffff880424ca2100)
Jun 28 13:18:35 172.30.1.2 [ 295.899512] Stack:
Jun 28 13:18:35 172.30.1.2 [ 295.903571]  ffffffff80000000
Jun 28 13:18:35 172.30.1.2 
Jun 28 13:18:35 172.30.1.2 [ 295.918613]  ffff880425367000
Jun 28 13:18:35 172.30.1.2 
Jun 28 13:18:35 172.30.1.2 [ 295.933657]  ffff880411b9eec0
Jun 28 13:18:35 172.30.1.2 
Jun 28 13:18:35 172.30.1.2 [ 295.948699] Call Trace:
Jun 28 13:18:35 172.30.1.2 [ 295.953626]  <IRQ> 
Jun 28 13:18:35 172.30.1.2 
Jun 28 13:18:35 172.30.1.2 [ 295.957918]  [<ffffffffa01c3714>] ? br_parse_ip_options+0x3d/0x19a [bridge]
Jun 28 13:18:35 172.30.1.2 [ 295.971866]  [<ffffffffa01c3aa0>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 295.985469]  [<ffffffff812ad0ed>] ? nf_iterate+0x41/0x77
Jun 28 13:18:36 172.30.1.2 [ 295.996123]  [<ffffffffa01be941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.008687]  [<ffffffffa01be941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.021245]  [<ffffffff812ad18b>] ? nf_hook_slow+0x68/0x101
Jun 28 13:18:36 172.30.1.2 [ 296.032418]  [<ffffffffa01be941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.044981]  [<ffffffffa01bf3a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.058757]  [<ffffffffa01be941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.071319]  [<ffffffffa01be887>] ? NF_HOOK.constprop.10+0x3c/0x56 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.085267]  [<ffffffffa01bea1b>] ? br_forward+0x16/0x5a [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.097480]  [<ffffffffa01bf543>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.112141]  [<ffffffffa01c3638>] ? br_nf_pre_routing_finish+0x1ee/0x1fb [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.127146]  [<ffffffffa01c2ff7>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.140055]  [<ffffffffa01c3f91>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.153828]  [<ffffffff812ad0ed>] ? nf_iterate+0x41/0x77
Jun 28 13:18:36 172.30.1.2 [ 296.164482]  [<ffffffffa01bf3a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.178255]  [<ffffffff812ad18b>] ? nf_hook_slow+0x68/0x101
Jun 28 13:18:36 172.30.1.2 [ 296.189430]  [<ffffffffa01bf3a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.203206]  [<ffffffffa01bf3a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.216982]  [<ffffffffa01bf388>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.230757]  [<ffffffff810135ad>] ? paravirt_read_tsc+0x5/0x8
Jun 28 13:18:36 172.30.1.2 [ 296.242274]  [<ffffffff81013622>] ? read_tsc+0x5/0x14
Jun 28 13:18:36 172.30.1.2 [ 296.252409]  [<ffffffffa01bf764>] ? br_handle_frame+0x1b3/0x1cb [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.265837]  [<ffffffffa01bf5b1>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.280498]  [<ffffffff8128a306>] ? __netif_receive_skb+0x324/0x41f
Jun 28 13:18:36 172.30.1.2 [ 296.293058]  [<ffffffff8128a46d>] ? process_backlog+0x6c/0x123
Jun 28 13:18:36 172.30.1.2 [ 296.304751]  [<ffffffff8128c351>] ? net_rx_action+0xa1/0x1af
Jun 28 13:18:36 172.30.1.2 [ 296.316098]  [<ffffffff8103703b>] ? test_tsk_need_resched+0xa/0x13
Jun 28 13:18:36 172.30.1.2 [ 296.328486]  [<ffffffff8104bee4>] ? __do_softirq+0xb9/0x177
Jun 28 13:18:36 172.30.1.2 [ 296.339662]  [<ffffffff8135162c>] ? call_softirq+0x1c/0x30
Jun 28 13:18:36 172.30.1.2 [ 296.350656]  <EOI> 
Jun 28 13:18:36 172.30.1.2 
Jun 28 13:18:36 172.30.1.2 [ 296.354946]  [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
Jun 28 13:18:36 172.30.1.2 [ 296.365597]  [<ffffffff8128c641>] ? netif_rx_ni+0x1e/0x27
Jun 28 13:18:36 172.30.1.2 [ 296.376425]  [<ffffffffa028b721>] ? tun_get_user+0x39a/0x3c2 [tun]
Jun 28 13:18:36 172.30.1.2 [ 296.388811]  [<ffffffffa028ba66>] ? tun_chr_poll+0xcd/0xcd [tun]
Jun 28 13:18:36 172.30.1.2 [ 296.400851]  [<ffffffffa028bac4>] ? tun_chr_aio_write+0x5e/0x79 [tun]
Jun 28 13:18:36 172.30.1.2 [ 296.413760]  [<ffffffff810f97f8>] ? do_sync_readv_writev+0x9a/0xd7
Jun 28 13:18:36 172.30.1.2 [ 296.426145]  [<ffffffff81036457>] ? should_resched+0x5/0x23
Jun 28 13:18:36 172.30.1.2 [ 296.437316]  [<ffffffff81036457>] ? should_resched+0x5/0x23
Jun 28 13:18:36 172.30.1.2 [ 296.448491]  [<ffffffff81162ea1>] ? security_file_permission+0x16/0x2d
Jun 28 13:18:36 172.30.1.2 [ 296.461569]  [<ffffffff810f9a5c>] ? do_readv_writev+0xaf/0x11c
Jun 28 13:18:36 172.30.1.2 [ 296.473266]  [<ffffffff8112aebe>] ? eventfd_ctx_read+0x162/0x174
Jun 28 13:18:36 172.30.1.2 [ 296.485310]  [<ffffffff8103f48f>] ? try_to_wake_up+0x197/0x197
Jun 28 13:18:36 172.30.1.2 [ 296.497001]  [<ffffffff810f9c31>] ? sys_writev+0x45/0x90
Jun 28 13:18:36 172.30.1.2 [ 296.507653]  [<ffffffff8134f3d2>] ? system_call_fastpath+0x16/0x1b
Jun 28 13:18:36 172.30.1.2 [ 296.520038] Code: 
Jun 28 13:18:36 172.30.1.2 53
Jun 28 13:18:36 172.30.1.2 48
Jun 28 13:18:36 172.30.1.2 89
Jun 28 13:18:36 172.30.1.2 fb
Jun 28 13:18:36 172.30.1.2 48
Jun 28 13:18:36 172.30.1.2 83
Jun 28 13:18:36 172.30.1.2 ec
Jun 28 13:18:36 172.30.1.2 10
Jun 28 13:18:36 172.30.1.2 66
Jun 28 13:18:36 172.30.1.2 81
Jun 28 13:18:36 172.30.1.2 7f
Jun 28 13:18:36 172.30.1.2 7e
Jun 28 13:18:36 172.30.1.2 08
Jun 28 13:18:36 172.30.1.2 06
Jun 28 13:18:36 172.30.1.2 4c
Jun 28 13:18:36 172.30.1.2 8b
Jun 28 13:18:36 172.30.1.2 a7
Jun 28 13:18:36 172.30.1.2 98
Jun 28 13:18:36 172.30.1.2 00
Jun 28 13:18:36 172.30.1.2 00
Jun 28 13:18:36 172.30.1.2 00
Jun 28 13:18:36 172.30.1.2 74
Jun 28 13:18:36 172.30.1.2 3d
Jun 28 13:18:36 172.30.1.2 e8
Jun 28 13:18:36 172.30.1.2 07
Jun 28 13:18:36 172.30.1.2 fe
Jun 28 13:18:36 172.30.1.2 ff
Jun 28 13:18:36 172.30.1.2 ff
Jun 28 13:18:36 172.30.1.2 66
Jun 28 13:18:36 172.30.1.2 3d
Jun 28 13:18:36 172.30.1.2 08
Jun 28 13:18:36 172.30.1.2 06
Jun 28 13:18:36 172.30.1.2 75
Jun 28 13:18:36 172.30.1.2 09
Jun 28 13:18:36 172.30.1.2 83
Jun 28 13:18:36 172.30.1.2 3d
Jun 28 13:18:36 172.30.1.2 91
Jun 28 13:18:36 172.30.1.2 6a
Jun 28 13:18:36 172.30.1.2 00
Jun 28 13:18:36 172.30.1.2 00
Jun 28 13:18:36 172.30.1.2 00
Jun 28 13:18:36 172.30.1.2 75
Jun 28 13:18:36 172.30.1.2 29
Jun 28 13:18:36 172.30.1.2 
Jun 28 13:18:36 172.30.1.2 f6
Jun 28 13:18:36 172.30.1.2 44
Jun 28 13:18:36 172.30.1.2 24
Jun 28 13:18:36 172.30.1.2 18
Jun 28 13:18:36 172.30.1.2 01
Jun 28 13:18:36 172.30.1.2 49
Jun 28 13:18:36 172.30.1.2 8b
Jun 28 13:18:36 172.30.1.2 6c
Jun 28 13:18:36 172.30.1.2 24
Jun 28 13:18:36 172.30.1.2 08
Jun 28 13:18:36 172.30.1.2 74
Jun 28 13:18:36 172.30.1.2 12
Jun 28 13:18:36 172.30.1.2 8a
Jun 28 13:18:36 172.30.1.2 43
Jun 28 13:18:36 172.30.1.2 7d
Jun 28 13:18:36 172.30.1.2 83
Jun 28 13:18:36 172.30.1.2 e0
Jun 28 13:18:36 172.30.1.2 f8
Jun 28 13:18:36 172.30.1.2 83
Jun 28 13:18:36 172.30.1.2 c8
Jun 28 13:18:36 172.30.1.2 
Jun 28 13:18:36 172.30.1.2 [ 296.561479] RIP 
Jun 28 13:18:36 172.30.1.2 [ 296.575830]  RSP <ffff88042fc03b18>
Jun 28 13:18:36 172.30.1.2 [ 296.582838] CR2: 0000000000000018
Jun 28 13:18:36 172.30.1.2 [ 296.589912] ---[ end trace c5e13ce92514d70f ]---
Jun 28 13:18:36 172.30.1.2 [ 296.599302] Kernel panic - not syncing: Fatal exception in interrupt
Jun 28 13:18:36 172.30.1.2 [ 296.612171] Pid: 7754, comm: kvm Tainted: G      D      3.2.0-2-amd64 #1
Jun 28 13:18:36 172.30.1.2 [ 296.625731] Call Trace:
Jun 28 13:18:36 172.30.1.2 [ 296.630786]  <IRQ> 
Jun 28 13:18:36 172.30.1.2 [ 296.642245]  [<ffffffff8134b246>] ? oops_end+0xa9/0xb6
Jun 28 13:18:36 172.30.1.2 [ 296.652680]  [<ffffffff8134362d>] ? no_context+0x1ff/0x20e
Jun 28 13:18:36 172.30.1.2 [ 296.663873]  [<ffffffff81052316>] ? __mod_timer+0x139/0x14b
Jun 28 13:18:36 172.30.1.2 [ 296.675175]  [<ffffffff8134d259>] ? do_page_fault+0x1a8/0x337
Jun 28 13:18:36 172.30.1.2 [ 296.686892]  [<ffffffffa03caf06>] ? ip_vs_conn_put+0x28/0x32 [ip_vs]
Jun 28 13:18:36 172.30.1.2 [ 296.699794]  [<ffffffffa03cd0e0>] ? ip_vs_out+0x2bd/0x432 [ip_vs]
Jun 28 13:18:36 172.30.1.2 [ 296.712179]  [<ffffffff812ad18b>] ? nf_hook_slow+0x68/0x101
Jun 28 13:18:36 172.30.1.2 [ 296.723614]  [<ffffffff8134a9b5>] ? page_fault+0x25/0x30
Jun 28 13:18:36 172.30.1.2 [ 296.734519]  [<ffffffffa01c330f>] ? nf_bridge_update_protocol+0x20/0x20 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.749474]  [<ffffffffa01c333d>] ? br_nf_forward_finish+0x2e/0x95 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.763549]  [<ffffffffa01c332e>] ? br_nf_forward_finish+0x1f/0x95 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.777632]  [<ffffffffa01c3714>] ? br_parse_ip_options+0x3d/0x19a [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.791715]  [<ffffffffa01c3aa0>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.805450]  [<ffffffff812ad0ed>] ? nf_iterate+0x41/0x77
Jun 28 13:18:36 172.30.1.2 [ 296.816247]  [<ffffffffa01be941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.829003]  [<ffffffffa01be941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.841695]  [<ffffffff812ad18b>] ? nf_hook_slow+0x68/0x101
Jun 28 13:18:36 172.30.1.2 [ 296.852992]  [<ffffffffa01be941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.865687]  [<ffffffffa01bf3a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.879725]  [<ffffffffa01be941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.892411]  [<ffffffffa01be887>] ? NF_HOOK.constprop.10+0x3c/0x56 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.906483]  [<ffffffffa01bea1b>] ? br_forward+0x16/0x5a [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.918889]  [<ffffffffa01bf543>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.933723]  [<ffffffffa01c3638>] ? br_nf_pre_routing_finish+0x1ee/0x1fb [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.948918]  [<ffffffffa01c2ff7>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.962024]  [<ffffffffa01c3f91>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
Jun 28 13:18:36 172.30.1.2 [ 296.975994]  [<ffffffff812ad0ed>] ? nf_iterate+0x41/0x77
Jun 28 13:18:37 172.30.1.2 [ 296.986837]  [<ffffffffa01bf3a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 13:18:37 172.30.1.2 [ 297.000802]  [<ffffffff812ad18b>] ? nf_hook_slow+0x68/0x101
Jun 28 13:18:37 172.30.1.2 [ 297.012107]  [<ffffffffa01bf3a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 13:18:37 172.30.1.2 [ 297.026146]  [<ffffffffa01bf3a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 13:18:37 172.30.1.2 [ 297.040021]  [<ffffffffa01bf388>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
Jun 28 13:18:37 172.30.1.2 [ 297.053999]  [<ffffffff810135ad>] ? paravirt_read_tsc+0x5/0x8
Jun 28 13:18:37 172.30.1.2 [ 297.065638]  [<ffffffff81013622>] ? read_tsc+0x5/0x14
Jun 28 13:18:37 172.30.1.2 [ 297.075900]  [<ffffffffa01bf764>] ? br_handle_frame+0x1b3/0x1cb [bridge]
Jun 28 13:18:37 172.30.1.2 [ 297.089449]  [<ffffffffa01bf5b1>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
Jun 28 13:18:37 172.30.1.2 [ 297.104301]  [<ffffffff8128a306>] ? __netif_receive_skb+0x324/0x41f
Jun 28 13:18:37 172.30.1.2 [ 297.116984]  [<ffffffff8128a46d>] ? process_backlog+0x6c/0x123
Jun 28 13:18:37 172.30.1.2 [ 297.128799]  [<ffffffff8128c351>] ? net_rx_action+0xa1/0x1af
Jun 28 13:18:37 172.30.1.2 [ 297.140267]  [<ffffffff8103703b>] ? test_tsk_need_resched+0xa/0x13
Jun 28 13:18:37 172.30.1.2 [ 297.152847]  [<ffffffff8104bee4>] ? __do_softirq+0xb9/0x177
Jun 28 13:18:37 172.30.1.2 [ 297.164227]  [<ffffffff8135162c>] ? call_softirq+0x1c/0x30
Jun 28 13:18:37 172.30.1.2 [ 297.175344]  <EOI> 
Jun 28 13:18:37 172.30.1.2 [ 297.187521]  [<ffffffff8128c641>] ? netif_rx_ni+0x1e/0x27
Jun 28 13:18:37 172.30.1.2 [ 297.198537]  [<ffffffffa028b721>] ? tun_get_user+0x39a/0x3c2 [tun]
Jun 28 13:18:37 172.30.1.2 [ 297.211100]  [<ffffffffa028ba66>] ? tun_chr_poll+0xcd/0xcd [tun]
Jun 28 13:18:37 172.30.1.2 [ 297.223376]  [<ffffffffa028bac4>] ? tun_chr_aio_write+0x5e/0x79 [tun]
Jun 28 13:18:37 172.30.1.2 [ 297.236417]  [<ffffffff810f97f8>] ? do_sync_readv_writev+0x9a/0xd7
Jun 28 13:18:37 172.30.1.2 [ 297.248994]  [<ffffffff81036457>] ? should_resched+0x5/0x23
Jun 28 13:18:37 172.30.1.2 [ 297.260291]  [<ffffffff81036457>] ? should_resched+0x5/0x23
Jun 28 13:18:37 172.30.1.2 [ 297.271594]  [<ffffffff81162ea1>] ? security_file_permission+0x16/0x2d
Jun 28 13:18:37 172.30.1.2 [ 297.284804]  [<ffffffff810f9a5c>] ? do_readv_writev+0xaf/0x11c
Jun 28 13:18:37 172.30.1.2 [ 297.296692]  [<ffffffff8112aebe>] ? eventfd_ctx_read+0x162/0x174
Jun 28 13:18:37 172.30.1.2 [ 297.308933]  [<ffffffff8103f48f>] ? try_to_wake_up+0x197/0x197
Jun 28 13:18:37 172.30.1.2 [ 297.320754]  [<ffffffff810f9c31>] ? sys_writev+0x45/0x90
Jun 28 13:18:37 172.30.1.2 [ 297.331532]  [<ffffffff8134f3d2>] ? system_call_fastpath+0x16/0x1b
Jun 28 13:18:37 mork mach_down[22201]: [22388]: info: Taking over resource group 172.30.1.99/24/br1/172.30.1.255
Jun 28 13:18:37 mork ResourceManager[22392]: [22414]: info: Acquiring resource group: mindy 172.30.1.99/24/br1/172.30.1.255
Jun 28 13:19:24 mork mon[12667]: failure for mail2 mxmon 1340882364 172.30.1.22
Jun 28 13:19:24 mork mon[12667]: calling alert marksolmail.down.alert for mail2/mxmon (/usr/lib/mon/alert.d/marksolmail.down.alert,-h) 172.30.1.22
Jun 28 13:20:25 mork mon[12667]: failure for mail2 mxmon 1340882425 172.30.1.22
Jun 28 13:21:25 mork mon[12667]: failure for mail2 mxmon 1340882485 172.30.1.22
Jun 28 13:22:25 mork mon[12667]: failure for mail2 mxmon 1340882545 172.30.1.22
Jun 28 13:23:12 mork ResourceManager[22956]: [22966]: info: Releasing resource group: mindy 172.30.1.99/24/br1/172.30.1.255
Jun 28 13:23:12 mork ResourceManager[22956]: [22983]: info: Running /etc/ha.d/resource.d/IPaddr 172.30.1.99/24/br1/172.30.1.255 stop
Jun 28 13:23:12 mork ResourceManager[22956]: [22984]: debug: Starting /etc/ha.d/resource.d/IPaddr 172.30.1.99/24/br1/172.30.1.255 stop
Jun 28 13:23:12 mork ResourceManager[22956]: [23030]: debug: /etc/ha.d/resource.d/IPaddr 172.30.1.99/24/br1/172.30.1.255 stop done. RC=0
Jun 28 13:23:25 mork mon[12667]: failure for mail2 mxmon 1340882605 172.30.1.22

[-- Attachment #3: 3.2.20.2-2.txt --]
[-- Type: text/plain, Size: 17032 bytes --]

Jun 28 14:16:03 172.30.1.2 [ 3193.846371] BUG: unable to handle kernel 
Jun 28 14:16:03 172.30.1.2 [ 3193.862035] IP:
Jun 28 14:16:03 172.30.1.2 [ 3193.876118] PGD 0 
Jun 28 14:16:03 172.30.1.2 
Jun 28 14:16:03 172.30.1.2 [ 3193.880134] Oops: 0000 [#1] 
Jun 28 14:16:03 172.30.1.2 SMP
Jun 28 14:16:03 172.30.1.2 
Jun 28 14:16:03 172.30.1.2 [ 3193.886590] CPU 0 
Jun 28 14:16:03 172.30.1.2 
Jun 28 14:16:03 172.30.1.2 [ 3193.890246] Modules linked in:
Jun 28 14:16:03 172.30.1.2 
Jun 28 14:16:03 172.30.1.2 [ 3194.029137] 
Jun 28 14:16:03 172.30.1.2 [ 3194.032099] Pid: 0, comm: swapper/0 Not tainted 3.2.0-2-amd64 #1
Jun 28 14:16:03 172.30.1.2 /0N051F
Jun 28 14:16:03 172.30.1.2 
Jun 28 14:16:03 172.30.1.2 [ 3194.049664] RIP: 0010:[<ffffffffa01dc33d>] 
Jun 28 14:16:03 172.30.1.2 [ 3194.068599] RSP: 0018:ffff88042fc039b0  EFLAGS: 00010293
Jun 28 14:16:03 172.30.1.2 [ 3194.079206] RAX: 0000000000000000 RBX: ffff8802f335f980 RCX: 0000000000000006
Jun 28 14:16:03 172.30.1.2 [ 3194.093456] RDX: ffffffffa01dc30f RSI: 00000001000b4640 RDI: ffff8802f335f980
Jun 28 14:16:03 172.30.1.2 [ 3194.107706] RBP: ffff880424ce6000 R08: 0000000000000000 R09: ffff88042fc03968
Jun 28 14:16:03 172.30.1.2 [ 3194.121957] R10: ffffffff8165ab00 R11: ffffffff8165ab00 R12: 0000000000000000
Jun 28 14:16:03 172.30.1.2 [ 3194.136206] R13: ffff880426cc1002 R14: ffff8802e094f140 R15: ffff880426cc1000
Jun 28 14:16:03 172.30.1.2 [ 3194.150456] FS:  0000000000000000(0000) GS:ffff88042fc00000(0000) knlGS:0000000000000000
Jun 28 14:16:03 172.30.1.2 [ 3194.166629] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jun 28 14:16:03 172.30.1.2 [ 3194.178104] CR2: 0000000000000018 CR3: 00000001c304d000 CR4: 00000000000026e0
Jun 28 14:16:03 172.30.1.2 [ 3194.192353] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun 28 14:16:03 172.30.1.2 [ 3194.206602] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jun 28 14:16:03 172.30.1.2 [ 3194.220852] Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff8160d020)
Jun 28 14:16:03 172.30.1.2 [ 3194.237370] Stack:
Jun 28 14:16:03 172.30.1.2 [ 3194.241387]  ffffffff80000000
Jun 28 14:16:03 172.30.1.2 
Jun 28 14:16:03 172.30.1.2 [ 3194.256222]  ffff880424d4c000
Jun 28 14:16:03 172.30.1.2 
Jun 28 14:16:03 172.30.1.2 [ 3194.271056]  ffff8802f335f980
Jun 28 14:16:03 172.30.1.2 
Jun 28 14:16:03 172.30.1.2 [ 3194.285891] Call Trace:
Jun 28 14:16:03 172.30.1.2 [ 3194.290776]  <IRQ> 
Jun 28 14:16:03 172.30.1.2 
Jun 28 14:16:03 172.30.1.2 [ 3194.294987]  [<ffffffffa01dc714>] ? br_parse_ip_options+0x3d/0x19a [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.308893]  [<ffffffffa01dcaa0>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.322456]  [<ffffffff812ad0ed>] ? nf_iterate+0x41/0x77
Jun 28 14:16:03 172.30.1.2 [ 3194.333067]  [<ffffffffa01d7941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.345586]  [<ffffffffa01d7941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.358104]  [<ffffffff812ad18b>] ? nf_hook_slow+0x68/0x101
Jun 28 14:16:03 172.30.1.2 [ 3194.369235]  [<ffffffffa01d7941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.381756]  [<ffffffffa01d83a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.395489]  [<ffffffffa01d7941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.408007]  [<ffffffffa01d7887>] ? NF_HOOK.constprop.10+0x3c/0x56 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.421913]  [<ffffffffa01d7a1b>] ? br_forward+0x16/0x5a [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.434086]  [<ffffffffa01d8543>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.448703]  [<ffffffffa01dc638>] ? br_nf_pre_routing_finish+0x1ee/0x1fb [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.463664]  [<ffffffffa01dbff7>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.476529]  [<ffffffffa01dcf91>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.490260]  [<ffffffff812ad0ed>] ? nf_iterate+0x41/0x77
Jun 28 14:16:03 172.30.1.2 [ 3194.500871]  [<ffffffffa01d83a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.514600]  [<ffffffff812ad18b>] ? nf_hook_slow+0x68/0x101
Jun 28 14:16:03 172.30.1.2 [ 3194.525732]  [<ffffffffa01d83a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.539466]  [<ffffffffa01d83a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.553200]  [<ffffffffa01d8388>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.566933]  [<ffffffff812bd793>] ? tcp_gro_receive+0x83/0x1d8
Jun 28 14:16:03 172.30.1.2 [ 3194.578586]  [<ffffffffa01d8764>] ? br_handle_frame+0x1b3/0x1cb [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.591971]  [<ffffffffa01d85b1>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
Jun 28 14:16:03 172.30.1.2 [ 3194.606588]  [<ffffffff8128a306>] ? __netif_receive_skb+0x324/0x41f
Jun 28 14:16:03 172.30.1.2 [ 3194.619106]  [<ffffffff8128bd61>] ? netif_receive_skb+0x63/0x69
Jun 28 14:16:03 172.30.1.2 [ 3194.630927]  [<ffffffff8128c233>] ? napi_gro_receive+0x1d/0x2b
Jun 28 14:16:03 172.30.1.2 [ 3194.642577]  [<ffffffff8128bddd>] ? napi_skb_finish+0x1c/0x31
Jun 28 14:16:03 172.30.1.2 [ 3194.654057]  [<ffffffffa00b6460>] ? bnx2_poll_work+0x84a/0x95d [bnx2]
Jun 28 14:16:03 172.30.1.2 [ 3194.666926]  [<ffffffff8103f47f>] ? try_to_wake_up+0x187/0x197
Jun 28 14:16:03 172.30.1.2 [ 3194.678579]  [<ffffffffa00b6716>] ? bnx2_poll+0xf6/0x1c4 [bnx2]
Jun 28 14:16:03 172.30.1.2 [ 3194.690402]  [<ffffffff8128c351>] ? net_rx_action+0xa1/0x1af
Jun 28 14:16:03 172.30.1.2 [ 3194.701706]  [<ffffffff81037d6e>] ? __wake_up+0x35/0x46
Jun 28 14:16:03 172.30.1.2 [ 3194.712143]  [<ffffffff8104bee4>] ? __do_softirq+0xb9/0x177
Jun 28 14:16:03 172.30.1.2 [ 3194.723276]  [<ffffffff8106a8e7>] ? clockevents_program_event+0xaa/0xce
Jun 28 14:16:04 172.30.1.2 [ 3194.736491]  [<ffffffff8135162c>] ? call_softirq+0x1c/0x30
Jun 28 14:16:04 172.30.1.2 [ 3194.747450]  [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
Jun 28 14:16:04 172.30.1.2 [ 3194.758059]  [<ffffffff8104c14c>] ? irq_exit+0x3c/0x9a
Jun 28 14:16:04 172.30.1.2 [ 3194.768320]  [<ffffffff8100f615>] ? do_IRQ+0x82/0x98
Jun 28 14:16:04 172.30.1.2 [ 3194.778239]  [<ffffffff8134a6ee>] ? common_interrupt+0x6e/0x6e
Jun 28 14:16:04 172.30.1.2 [ 3194.789886]  <EOI> 
Jun 28 14:16:04 172.30.1.2 
Jun 28 14:16:04 172.30.1.2 [ 3194.794091]  [<ffffffff811aed74>] ? timerqueue_add+0x80/0xa0
Jun 28 14:16:04 172.30.1.2 [ 3194.805397]  [<ffffffff811ec569>] ? intel_idle+0xea/0x119
Jun 28 14:16:04 172.30.1.2 [ 3194.816179]  [<ffffffff811ec548>] ? intel_idle+0xc9/0x119
Jun 28 14:16:04 172.30.1.2 [ 3194.826966]  [<ffffffff8126c573>] ? cpuidle_idle_call+0xec/0x179
Jun 28 14:16:04 172.30.1.2 [ 3194.838963]  [<ffffffff8100d248>] ? cpu_idle+0xa5/0xf2
Jun 28 14:16:04 172.30.1.2 [ 3194.849225]  [<ffffffff816aab33>] ? start_kernel+0x3b3/0x3be
Jun 28 14:16:04 172.30.1.2 [ 3194.860528]  [<ffffffff816aa140>] ? early_idt_handlers+0x140/0x140
Jun 28 14:16:04 172.30.1.2 [ 3194.872870]  [<ffffffff816aa3c4>] ? x86_64_start_kernel+0x104/0x111
Jun 28 14:16:04 172.30.1.2 [ 3194.885386] Code: 
Jun 28 14:16:04 172.30.1.2 53
Jun 28 14:16:04 172.30.1.2 48
Jun 28 14:16:04 172.30.1.2 89
Jun 28 14:16:04 172.30.1.2 fb
Jun 28 14:16:04 172.30.1.2 48
Jun 28 14:16:04 172.30.1.2 83
Jun 28 14:16:04 172.30.1.2 ec
Jun 28 14:16:04 172.30.1.2 10
Jun 28 14:16:04 172.30.1.2 66
Jun 28 14:16:04 172.30.1.2 81
Jun 28 14:16:04 172.30.1.2 7f
Jun 28 14:16:04 172.30.1.2 7e
Jun 28 14:16:04 172.30.1.2 08
Jun 28 14:16:04 172.30.1.2 06
Jun 28 14:16:04 172.30.1.2 4c
Jun 28 14:16:04 172.30.1.2 8b
Jun 28 14:16:04 172.30.1.2 a7
Jun 28 14:16:04 172.30.1.2 98
Jun 28 14:16:04 172.30.1.2 00
Jun 28 14:16:04 172.30.1.2 00
Jun 28 14:16:04 172.30.1.2 00
Jun 28 14:16:04 172.30.1.2 74
Jun 28 14:16:04 172.30.1.2 3d
Jun 28 14:16:04 172.30.1.2 e8
Jun 28 14:16:04 172.30.1.2 07
Jun 28 14:16:04 172.30.1.2 fe
Jun 28 14:16:04 172.30.1.2 ff
Jun 28 14:16:04 172.30.1.2 ff
Jun 28 14:16:04 172.30.1.2 66
Jun 28 14:16:04 172.30.1.2 3d
Jun 28 14:16:04 172.30.1.2 08
Jun 28 14:16:04 172.30.1.2 06
Jun 28 14:16:04 172.30.1.2 75
Jun 28 14:16:04 172.30.1.2 09
Jun 28 14:16:04 172.30.1.2 83
Jun 28 14:16:04 172.30.1.2 3d
Jun 28 14:16:04 172.30.1.2 91
Jun 28 14:16:04 172.30.1.2 6a
Jun 28 14:16:04 172.30.1.2 00
Jun 28 14:16:04 172.30.1.2 00
Jun 28 14:16:04 172.30.1.2 00
Jun 28 14:16:04 172.30.1.2 75
Jun 28 14:16:04 172.30.1.2 29
Jun 28 14:16:04 172.30.1.2 
Jun 28 14:16:04 172.30.1.2 f6
Jun 28 14:16:04 172.30.1.2 44
Jun 28 14:16:04 172.30.1.2 24
Jun 28 14:16:04 172.30.1.2 18
Jun 28 14:16:04 172.30.1.2 01
Jun 28 14:16:04 172.30.1.2 49
Jun 28 14:16:04 172.30.1.2 8b
Jun 28 14:16:04 172.30.1.2 6c
Jun 28 14:16:04 172.30.1.2 24
Jun 28 14:16:04 172.30.1.2 08
Jun 28 14:16:04 172.30.1.2 74
Jun 28 14:16:04 172.30.1.2 12
Jun 28 14:16:04 172.30.1.2 8a
Jun 28 14:16:04 172.30.1.2 43
Jun 28 14:16:04 172.30.1.2 7d
Jun 28 14:16:04 172.30.1.2 83
Jun 28 14:16:04 172.30.1.2 e0
Jun 28 14:16:04 172.30.1.2 f8
Jun 28 14:16:04 172.30.1.2 83
Jun 28 14:16:04 172.30.1.2 c8
Jun 28 14:16:04 172.30.1.2 
Jun 28 14:16:04 172.30.1.2 [ 3194.924067] RIP 
Jun 28 14:16:04 172.30.1.2 [ 3194.938333]  RSP <ffff88042fc039b0>
Jun 28 14:16:04 172.30.1.2 [ 3194.945299] CR2: 0000000000000018
Jun 28 14:16:04 172.30.1.2 [ 3194.952668] ---[ end trace c28d39074732fa49 ]---
Jun 28 14:16:04 172.30.1.2 [ 3194.962197] Kernel panic - not syncing: Fatal exception in interrupt
Jun 28 14:16:04 172.30.1.2 [ 3194.975155] Pid: 0, comm: swapper/0 Tainted: G      D      3.2.0-2-amd64 #1
Jun 28 14:16:04 172.30.1.2 [ 3194.989324] Call Trace:
Jun 28 14:16:04 172.30.1.2 [ 3194.994443]  <IRQ> 
Jun 28 14:16:04 172.30.1.2 [ 3195.006177]  [<ffffffff8134b246>] ? oops_end+0xa9/0xb6
Jun 28 14:16:04 172.30.1.2 [ 3195.016744]  [<ffffffff8134362d>] ? no_context+0x1ff/0x20e
Jun 28 14:16:04 172.30.1.2 [ 3195.028010]  [<ffffffff810e9e7c>] ? virt_to_slab+0x6/0x16
Jun 28 14:16:04 172.30.1.2 [ 3195.039098]  [<ffffffff810e9f1f>] ? __cache_free.isra.41+0x3d/0x198
Jun 28 14:16:04 172.30.1.2 [ 3195.051922]  [<ffffffff8134d259>] ? do_page_fault+0x1a8/0x337
Jun 28 14:16:04 172.30.1.2 [ 3195.063621]  [<ffffffffa03cbf06>] ? ip_vs_conn_put+0x28/0x32 [ip_vs]
Jun 28 14:16:04 172.30.1.2 [ 3195.076593]  [<ffffffffa03ce0e0>] ? ip_vs_out+0x2bd/0x432 [ip_vs]
Jun 28 14:16:04 172.30.1.2 [ 3195.089052]  [<ffffffffa01d7847>] ? br_dev_queue_push_xmit+0x9b/0x9f [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.103656]  [<ffffffff8134a9b5>] ? page_fault+0x25/0x30
Jun 28 14:16:04 172.30.1.2 [ 3195.114563]  [<ffffffffa01dc30f>] ? nf_bridge_update_protocol+0x20/0x20 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.129719]  [<ffffffffa01dc33d>] ? br_nf_forward_finish+0x2e/0x95 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.143939]  [<ffffffffa01dc714>] ? br_parse_ip_options+0x3d/0x19a [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.158197]  [<ffffffffa01dcaa0>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.172126]  [<ffffffff812ad0ed>] ? nf_iterate+0x41/0x77
Jun 28 14:16:04 172.30.1.2 [ 3195.183162]  [<ffffffffa01d7941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.195973]  [<ffffffffa01d7941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.208757]  [<ffffffff812ad18b>] ? nf_hook_slow+0x68/0x101
Jun 28 14:16:04 172.30.1.2 [ 3195.220300]  [<ffffffffa01d7941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.233150]  [<ffffffffa01d83a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.247306]  [<ffffffffa01d7941>] ? __br_deliver+0xa0/0xa0 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.260078]  [<ffffffffa01d7887>] ? NF_HOOK.constprop.10+0x3c/0x56 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.274354]  [<ffffffffa01d7a1b>] ? br_forward+0x16/0x5a [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.286828]  [<ffffffffa01d8543>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.301718]  [<ffffffffa01dc638>] ? br_nf_pre_routing_finish+0x1ee/0x1fb [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.317041]  [<ffffffffa01dbff7>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.330274]  [<ffffffffa01dcf91>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.344275]  [<ffffffff812ad0ed>] ? nf_iterate+0x41/0x77
Jun 28 14:16:04 172.30.1.2 [ 3195.355232]  [<ffffffffa01d83a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.369214]  [<ffffffff812ad18b>] ? nf_hook_slow+0x68/0x101
Jun 28 14:16:04 172.30.1.2 [ 3195.380687]  [<ffffffffa01d83a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.394806]  [<ffffffffa01d83a2>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.408906]  [<ffffffffa01d8388>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.423003]  [<ffffffff812bd793>] ? tcp_gro_receive+0x83/0x1d8
Jun 28 14:16:04 172.30.1.2 [ 3195.434976]  [<ffffffffa01d8764>] ? br_handle_frame+0x1b3/0x1cb [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.448742]  [<ffffffffa01d85b1>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
Jun 28 14:16:04 172.30.1.2 [ 3195.463742]  [<ffffffff8128a306>] ? __netif_receive_skb+0x324/0x41f
Jun 28 14:16:04 172.30.1.2 [ 3195.476522]  [<ffffffff8128bd61>] ? netif_receive_skb+0x63/0x69
Jun 28 14:16:04 172.30.1.2 [ 3195.488591]  [<ffffffff8128c233>] ? napi_gro_receive+0x1d/0x2b
Jun 28 14:16:04 172.30.1.2 [ 3195.500581]  [<ffffffff8128bddd>] ? napi_skb_finish+0x1c/0x31
Jun 28 14:16:04 172.30.1.2 [ 3195.512350]  [<ffffffffa00b6460>] ? bnx2_poll_work+0x84a/0x95d [bnx2]
Jun 28 14:16:04 172.30.1.2 [ 3195.525547]  [<ffffffff8103f47f>] ? try_to_wake_up+0x187/0x197
Jun 28 14:16:04 172.30.1.2 [ 3195.537480]  [<ffffffffa00b6716>] ? bnx2_poll+0xf6/0x1c4 [bnx2]
Jun 28 14:16:04 172.30.1.2 [ 3195.549671]  [<ffffffff8128c351>] ? net_rx_action+0xa1/0x1af
Jun 28 14:16:04 172.30.1.2 [ 3195.561264]  [<ffffffff81037d6e>] ? __wake_up+0x35/0x46
Jun 28 14:16:04 172.30.1.2 [ 3195.572052]  [<ffffffff8104bee4>] ? __do_softirq+0xb9/0x177
Jun 28 14:16:04 172.30.1.2 [ 3195.583508]  [<ffffffff8106a8e7>] ? clockevents_program_event+0xaa/0xce
Jun 28 14:16:04 172.30.1.2 [ 3195.597050]  [<ffffffff8135162c>] ? call_softirq+0x1c/0x30
Jun 28 14:16:04 172.30.1.2 [ 3195.608366]  [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
Jun 28 14:16:04 172.30.1.2 [ 3195.619247]  [<ffffffff8104c14c>] ? irq_exit+0x3c/0x9a
Jun 28 14:16:04 172.30.1.2 [ 3195.629829]  [<ffffffff8100f615>] ? do_IRQ+0x82/0x98
Jun 28 14:16:04 172.30.1.2 [ 3195.640035]  [<ffffffff8134a6ee>] ? common_interrupt+0x6e/0x6e
Jun 28 14:16:04 172.30.1.2 [ 3195.652030]  <EOI> 
Jun 28 14:16:04 172.30.1.2 [ 3195.665050]  [<ffffffff811ec569>] ? intel_idle+0xea/0x119
Jun 28 14:16:04 172.30.1.2 [ 3195.676195]  [<ffffffff811ec548>] ? intel_idle+0xc9/0x119
Jun 28 14:16:04 172.30.1.2 [ 3195.687278]  [<ffffffff8126c573>] ? cpuidle_idle_call+0xec/0x179
Jun 28 14:16:04 172.30.1.2 [ 3195.699551]  [<ffffffff8100d248>] ? cpu_idle+0xa5/0xf2
Jun 28 14:16:04 172.30.1.2 [ 3195.710072]  [<ffffffff816aab33>] ? start_kernel+0x3b3/0x3be
Jun 28 14:16:04 172.30.1.2 [ 3195.721740]  [<ffffffff816aa140>] ? early_idt_handlers+0x140/0x140
Jun 28 14:16:05 172.30.1.2 [ 3195.734358]  [<ffffffff816aa3c4>] ? x86_64_start_kernel+0x104/0x111
Jun 28 14:16:05 172.30.1.2 [ 3195.747405] ------------[ cut here ]------------
Jun 28 14:16:05 172.30.1.2 [ 3195.756678] WARNING: at /build/buildd-linux_3.2.20-1-amd64-lTzScn/linux-3.2.20/arch/x86/kernel/smp.c:119 try_to_wake_up+0x158/0x197()
Jun 28 14:16:05 172.30.1.2 [ 3195.780697] Hardware name: PowerEdge R410
Jun 28 14:16:05 172.30.1.2 [ 3195.788744] Modules linked in:
Jun 28 14:16:05 172.30.1.2 
Jun 28 14:16:05 172.30.1.2 [ 3195.930822] Pid: 4659, comm: kvm Tainted: G      D      3.2.0-2-amd64 #1
Jun 28 14:16:05 172.30.1.2 [ 3195.944245] Call Trace:
Jun 28 14:16:05 172.30.1.2 [ 3195.949175]  [<ffffffff810468fd>] ? warn_slowpath_common+0x78/0x8c
Jun 28 14:16:05 172.30.1.2 [ 3195.961562]  [<ffffffff8103f450>] ? try_to_wake_up+0x158/0x197
Jun 28 14:16:05 172.30.1.2 [ 3195.973256]  [<ffffffff811071e2>] ? pollwake+0x4d/0x52
Jun 28 14:16:05 172.30.1.2 [ 3195.983560]  [<ffffffff8103f48f>] ? try_to_wake_up+0x197/0x197
Jun 28 14:16:05 172.30.1.2 [ 3195.995254]  [<ffffffff810360b2>] ? __wake_up_common+0x40/0x77
Jun 28 14:16:05 172.30.1.2 [ 3196.006949]  [<ffffffff8112ad43>] ? eventfd_write+0x1a3/0x1bc
Jun 28 14:16:05 172.30.1.2 [ 3196.018467]  [<ffffffff8103f48f>] ? try_to_wake_up+0x197/0x197
Jun 28 14:16:05 172.30.1.2 [ 3196.030162]  [<ffffffff810f947f>] ? vfs_write+0xa2/0xe9
Jun 28 14:16:05 172.30.1.2 [ 3196.040649]  [<ffffffffa022a5fb>] ? kvm_on_user_return+0x36/0x5c [kvm]
Jun 28 14:16:05 172.30.1.2 [ 3196.053728]  [<ffffffff810f965c>] ? sys_write+0x45/0x6b
Jun 28 14:16:05 172.30.1.2 [ 3196.064206]  [<ffffffff8134f3d2>] ? system_call_fastpath+0x16/0x1b
Jun 28 14:16:05 172.30.1.2 [ 3196.076589] ---[ end trace c28d39074732fa4a ]---

[-- Attachment #4: 3.2.21-1.txt --]
[-- Type: text/plain, Size: 23789 bytes --]

Jun 28 15:29:19 172.30.1.2 [ 304.578777] BUG: unable to handle kernel 
Jun 28 15:29:19 172.30.1.2 [ 304.594562] IP:
Jun 28 15:29:19 172.30.1.2 [ 304.608732] PGD 0 
Jun 28 15:29:19 172.30.1.2 
Jun 28 15:29:19 172.30.1.2 [ 304.612831] Oops: 0000 [#1] 
Jun 28 15:29:19 172.30.1.2 SMP
Jun 28 15:29:19 172.30.1.2 
Jun 28 15:29:19 172.30.1.2 [ 304.619414] CPU 0 
Jun 28 15:29:19 172.30.1.2 
Jun 28 15:29:19 172.30.1.2 [ 304.623112] Modules linked in:
Jun 28 15:29:19 172.30.1.2 
Jun 28 15:29:19 172.30.1.2 [ 304.765458] 
Jun 28 15:29:19 172.30.1.2 [ 304.768463] Pid: 4486, comm: kvm Not tainted 3.2.21 #1
Jun 28 15:29:19 172.30.1.2 /0N051F
Jun 28 15:29:19 172.30.1.2 
Jun 28 15:29:19 172.30.1.2 [ 304.784464] RIP: 0010:[<ffffffffa01d09d0>] 
Jun 28 15:29:19 172.30.1.2 [ 304.803483] RSP: 0018:ffff88042fc03960  EFLAGS: 00010287
Jun 28 15:29:19 172.30.1.2 [ 304.814133] RAX: 0000000000000008 RBX: ffff880422148d80 RCX: ffff88042fc03706
Jun 28 15:29:19 172.30.1.2 [ 304.828426] RDX: 0000000000000000 RSI: 0000000100003f40 RDI: ffff880422148d80
Jun 28 15:29:19 172.30.1.2 [ 304.842719] RBP: ffff880221d2c000 R08: 0000000000000000 R09: ffff88042fc03918
Jun 28 15:29:19 172.30.1.2 [ 304.857012] R10: ffffffff8180b240 R11: ffff880422148d80 R12: ffff880221bc8000
Jun 28 15:29:19 172.30.1.2 [ 304.871303] R13: ffff880418d91500 R14: ffff880221bc8002 R15: ffff880420cdf000
Jun 28 15:29:19 172.30.1.2 [ 304.885595] FS:  00007f8d47807900(0000) GS:ffff88042fc00000(0000) knlGS:0000000000000000
Jun 28 15:29:19 172.30.1.2 [ 304.901811] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 28 15:29:19 172.30.1.2 [ 304.913328] CR2: 0000000000000018 CR3: 000000041c3d1000 CR4: 00000000000026e0
Jun 28 15:29:19 172.30.1.2 [ 304.927620] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun 28 15:29:19 172.30.1.2 [ 304.941912] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jun 28 15:29:19 172.30.1.2 [ 304.956205] Process kvm (pid: 4486, threadinfo ffff88040f24e000, task ffff8804215f9510)
Jun 28 15:29:19 172.30.1.2 [ 304.972247] Stack:
Jun 28 15:29:19 172.30.1.2 [ 304.976307]  0000000080000000
Jun 28 15:29:19 172.30.1.2 
Jun 28 15:29:19 172.30.1.2 [ 304.991349]  ffff880221d2c000
Jun 28 15:29:19 172.30.1.2 
Jun 28 15:29:19 172.30.1.2 [ 305.006392]  ffff880422148d80
Jun 28 15:29:19 172.30.1.2 
Jun 28 15:29:19 172.30.1.2 [ 305.021434] Call Trace:
Jun 28 15:29:19 172.30.1.2 [ 305.026360]  <IRQ> 
Jun 28 15:29:19 172.30.1.2 
Jun 28 15:29:19 172.30.1.2 [ 305.030651]  [<ffffffffa01d0c91>] ? br_nf_forward_ip+0x214/0x231 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.044255]  [<ffffffff812c7de1>] ? nf_iterate+0x41/0x77
Jun 28 15:29:19 172.30.1.2 [ 305.054909]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.067122]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.079336]  [<ffffffff812c7f3a>] ? nf_hook_slow+0x68/0xfd
Jun 28 15:29:19 172.30.1.2 [ 305.090336]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.102552]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.113898]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.126113]  [<ffffffffa01cb96e>] ? T.963+0x3c/0x56 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.137460]  [<ffffffffa01ca753>] ? __br_fdb_get+0x10/0x83 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.150021]  [<ffffffffa01cc61d>] ? br_handle_frame_finish+0x1a7/0x211 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.164680]  [<ffffffffa01d1598>] ? br_nf_pre_routing_finish+0x222/0x22f [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.179685]  [<ffffffffa01d03b5>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.192593]  [<ffffffffa01d135b>] ? br_nf_pre_routing+0x4fc/0x517 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.206366]  [<ffffffff812ce172>] ? T.1028+0x4f/0x4f
Jun 28 15:29:19 172.30.1.2 [ 305.216322]  [<ffffffff812c7de1>] ? nf_iterate+0x41/0x77
Jun 28 15:29:19 172.30.1.2 [ 305.226975]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.238320]  [<ffffffff812c7f3a>] ? nf_hook_slow+0x68/0xfd
Jun 28 15:29:19 172.30.1.2 [ 305.249320]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.260669]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.272015]  [<ffffffffa01cc45c>] ? T.947+0x3c/0x56 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.283363]  [<ffffffffa01cc84a>] ? br_handle_frame+0x1c3/0x1d9 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.296790]  [<ffffffffa01cc687>] ? br_handle_frame_finish+0x211/0x211 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.311448]  [<ffffffff812a74f2>] ? __netif_receive_skb+0x37a/0x490
Jun 28 15:29:19 172.30.1.2 [ 305.324009]  [<ffffffff81013a01>] ? read_tsc+0x5/0x16
Jun 28 15:29:19 172.30.1.2 [ 305.334139]  [<ffffffff812a799f>] ? netif_receive_skb+0x67/0x6d
Jun 28 15:29:19 172.30.1.2 [ 305.346005]  [<ffffffff812a7f0b>] ? napi_gro_receive+0x1f/0x2d
Jun 28 15:29:19 172.30.1.2 [ 305.357697]  [<ffffffff812a7a79>] ? napi_skb_finish+0x1c/0x31
Jun 28 15:29:19 172.30.1.2 [ 305.369220]  [<ffffffffa0009a21>] ? bnx2_poll_work+0x8db/0x9f4 [bnx2]
Jun 28 15:29:19 172.30.1.2 [ 305.382128]  [<ffffffffa00092f4>] ? bnx2_poll_work+0x1ae/0x9f4 [bnx2]
Jun 28 15:29:19 172.30.1.2 [ 305.395036]  [<ffffffffa01cc45c>] ? T.947+0x3c/0x56 [bridge]
Jun 28 15:29:19 172.30.1.2 [ 305.406383]  [<ffffffffa0009cfc>] ? bnx2_poll+0x116/0x1f2 [bnx2]
Jun 28 15:29:19 172.30.1.2 [ 305.418421]  [<ffffffff812a74f2>] ? __netif_receive_skb+0x37a/0x490
Jun 28 15:29:19 172.30.1.2 [ 305.430980]  [<ffffffff812a8038>] ? net_rx_action+0xa8/0x207
Jun 28 15:29:19 172.30.1.2 [ 305.442327]  [<ffffffff8106637e>] ? hrtimer_get_next_event+0x7f/0x9a
Jun 28 15:29:19 172.30.1.2 [ 305.455060]  [<ffffffff8104f11e>] ? __do_softirq+0xc4/0x1a0
Jun 28 15:29:19 172.30.1.2 [ 305.466234]  [<ffffffff81097905>] ? handle_irq_event_percpu+0x166/0x184
Jun 28 15:29:19 172.30.1.2 [ 305.479490]  [<ffffffff8136bd6c>] ? call_softirq+0x1c/0x30
Jun 28 15:29:19 172.30.1.2 [ 305.490492]  [<ffffffff8100fa3f>] ? do_softirq+0x3f/0x79
Jun 28 15:29:19 172.30.1.2 [ 305.501142]  [<ffffffff8104eeee>] ? irq_exit+0x44/0xb5
Jun 28 15:29:19 172.30.1.2 [ 305.511446]  [<ffffffff8100f38a>] ? do_IRQ+0x94/0xaa
Jun 28 15:29:19 172.30.1.2 [ 305.521407]  [<ffffffff813647ee>] ? common_interrupt+0x6e/0x6e
Jun 28 15:29:19 172.30.1.2 [ 305.533098]  <EOI> 
Jun 28 15:29:19 172.30.1.2 
Jun 28 15:29:20 172.30.1.2 [ 305.537386]  [<ffffffff81364498>] ? _raw_spin_unlock_irqrestore+0xb/0x11
Jun 28 15:29:20 172.30.1.2 [ 305.550816]  [<ffffffff81045f07>] ? try_to_wake_up+0x181/0x190
Jun 28 15:29:20 172.30.1.2 [ 305.562510]  [<ffffffff81071764>] ? wake_futex+0x2b/0x47
Jun 28 15:29:20 172.30.1.2 [ 305.573161]  [<ffffffff81073949>] ? do_futex+0x3de/0x84a
Jun 28 15:29:20 172.30.1.2 [ 305.583814]  [<ffffffff810dfff1>] ? do_brk+0x2ca/0x326
Jun 28 15:29:20 172.30.1.2 [ 305.594119]  [<ffffffff81073ee4>] ? sys_futex+0x12f/0x147
Jun 28 15:29:20 172.30.1.2 [ 305.604945]  [<ffffffff81369b12>] ? system_call_fastpath+0x16/0x1b
Jun 28 15:29:20 172.30.1.2 [ 305.617329] Code: 
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 10
Jun 28 15:29:20 172.30.1.2 75
Jun 28 15:29:20 172.30.1.2 25
Jun 28 15:29:20 172.30.1.2 66
Jun 28 15:29:20 172.30.1.2 3d
Jun 28 15:29:20 172.30.1.2 81
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 75
Jun 28 15:29:20 172.30.1.2 1f
Jun 28 15:29:20 172.30.1.2 8b
Jun 28 15:29:20 172.30.1.2 87
Jun 28 15:29:20 172.30.1.2 c8
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 48
Jun 28 15:29:20 172.30.1.2 8b
Jun 28 15:29:20 172.30.1.2 8f
Jun 28 15:29:20 172.30.1.2 d8
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 66
Jun 28 15:29:20 172.30.1.2 81
Jun 28 15:29:20 172.30.1.2 7c
Jun 28 15:29:20 172.30.1.2 01
Jun 28 15:29:20 172.30.1.2 10
Jun 28 15:29:20 172.30.1.2 08
Jun 28 15:29:20 172.30.1.2 06
Jun 28 15:29:20 172.30.1.2 75
Jun 28 15:29:20 172.30.1.2 09
Jun 28 15:29:20 172.30.1.2 83
Jun 28 15:29:20 172.30.1.2 3d
Jun 28 15:29:20 172.30.1.2 f2
Jun 28 15:29:20 172.30.1.2 63
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 00
Jun 28 15:29:20 172.30.1.2 75
Jun 28 15:29:20 172.30.1.2 3c
Jun 28 15:29:20 172.30.1.2 f6>
Jun 28 15:29:20 172.30.1.2 42
Jun 28 15:29:20 172.30.1.2 18
Jun 28 15:29:20 172.30.1.2 01
Jun 28 15:29:20 172.30.1.2 48
Jun 28 15:29:20 172.30.1.2 8b
Jun 28 15:29:20 172.30.1.2 6a
Jun 28 15:29:20 172.30.1.2 08
Jun 28 15:29:20 172.30.1.2 74
Jun 28 15:29:20 172.30.1.2 10
Jun 28 15:29:20 172.30.1.2 8a
Jun 28 15:29:20 172.30.1.2 
Jun 28 15:29:20 172.30.1.2 [ 305.652454] ------------[ cut here ]------------
Jun 28 15:29:20 172.30.1.2 [ 305.652457] WARNING: at kernel/softirq.c:159 _local_bh_enable_ip+0x41/0x8b()
Jun 28 15:29:20 172.30.1.2 [ 305.652459] Hardware name: PowerEdge R410
Jun 28 15:29:20 172.30.1.2 [ 305.652460] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter ip6_tables iptable_filter ip_tables x_tables ip_vs_rr ip_vs nf_conntrack crc32c libcrc32c drbd lru_cache cn tun 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 bridge stp snd_pcm i7core_edac dcdbas edac_core iTCO_wdt iTCO_vendor_support processor psmouse snd_timer snd soundcore snd_page_alloc pcspkr serio_raw joydev thermal_sys button evdev ext3 mbcache jbd dm_mod sr_mod cdrom sd_mod ses usbhid hid crc_t10dif enclosure ata_generic uhci_hcd ata_piix ehci_hcd libata megaraid_sas usbcore scsi_mod usb_common bnx2 [last unloaded: scsi_wait_scan]
Jun 28 15:29:20 172.30.1.2 [ 305.652495] Pid: 4486, comm: kvm Not tainted 3.2.21 #1
Jun 28 15:29:20 172.30.1.2 [ 305.652496] Call Trace:
Jun 28 15:29:20 172.30.1.2 [ 305.652497]  <IRQ>  [<ffffffff81049810>] ? warn_slowpath_common+0x78/0x8c
Jun 28 15:29:20 172.30.1.2 [ 305.652503]  [<ffffffff8104efa0>] ? _local_bh_enable_ip+0x41/0x8b
Jun 28 15:29:20 172.30.1.2 [ 305.652508]  [<ffffffffa0000648>] ? bnx2_reg_rd_ind+0x31/0x38 [bnx2]
Jun 28 15:29:20 172.30.1.2 [ 305.652514]  [<ffffffffa0009dc8>] ? bnx2_poll+0x1e2/0x1f2 [bnx2]
Jun 28 15:29:20 172.30.1.2 [ 305.652520]  [<ffffffff812b6b62>] ? netpoll_poll_dev+0xab/0x4ad
Jun 28 15:29:20 172.30.1.2 [ 305.652525]  [<ffffffffa0006ba0>] ? bnx2_start_xmit+0x411/0x55d [bnx2]
Jun 28 15:29:20 172.30.1.2 [ 305.652531]  [<ffffffff810f693e>] ? ____cache_alloc+0xc6/0x20d
Jun 28 15:29:20 172.30.1.2 [ 305.652535]  [<ffffffff812b7075>] ? netpoll_send_skb_on_dev+0x111/0x215
Jun 28 15:29:20 172.30.1.2 [ 305.652541]  [<ffffffffa01ca6d2>] ? br_dev_xmit+0x136/0x150 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652544]  [<ffffffff812b7033>] ? netpoll_send_skb_on_dev+0xcf/0x215
Jun 28 15:29:20 172.30.1.2 [ 305.652551]  [<ffffffff811c3157>] ? delay_tsc+0x2b/0x74
Jun 28 15:29:20 172.30.1.2 [ 305.652555]  [<ffffffffa0167272>] ? write_msg+0x9f/0x102 [netconsole]
Jun 28 15:29:20 172.30.1.2 [ 305.652558]  [<ffffffff810499e6>] ? __call_console_drivers+0x75/0x86
Jun 28 15:29:20 172.30.1.2 [ 305.652561]  [<ffffffff8104a084>] ? console_unlock+0x13d/0x1e8
Jun 28 15:29:20 172.30.1.2 [ 305.652564]  [<ffffffff8104a707>] ? vprintk+0x39e/0x3e5
Jun 28 15:29:20 172.30.1.2 [ 305.652570]  [<ffffffffa01d09db>] ? br_nf_forward_finish+0x53/0xc0 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652576]  [<ffffffffa01d09a5>] ? br_nf_forward_finish+0x1d/0xc0 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652579]  [<ffffffff81362842>] ? printk+0x40/0x46
Jun 28 15:29:20 172.30.1.2 [ 305.652583]  [<ffffffff8100fff9>] ? show_registers+0x1e2/0x211
Jun 28 15:29:20 172.30.1.2 [ 305.652586]  [<ffffffff813652dd>] ? __die+0x8e/0xc9
Jun 28 15:29:20 172.30.1.2 [ 305.652589]  [<ffffffff8102fcd0>] ? no_context+0x1d6/0x20c
Jun 28 15:29:20 172.30.1.2 [ 305.652592]  [<ffffffff810f53c3>] ? virt_to_slab+0x9/0x3c
Jun 28 15:29:20 172.30.1.2 [ 305.652595]  [<ffffffff81367534>] ? do_page_fault+0x1ad/0x34c
Jun 28 15:29:20 172.30.1.2 [ 305.652601]  [<ffffffffa03fcd93>] ? ip_vs_notrack+0x6e/0xa6 [ip_vs]
Jun 28 15:29:20 172.30.1.2 [ 305.652606]  [<ffffffffa03fbdec>] ? ip_vs_conn_put+0x29/0x2f [ip_vs]
Jun 28 15:29:20 172.30.1.2 [ 305.652610]  [<ffffffffa03fde1a>] ? ip_vs_out+0x33c/0x49d [ip_vs]
Jun 28 15:29:20 172.30.1.2 [ 305.652613]  [<ffffffff812a896b>] ? dev_hard_start_xmit+0x3fd/0x571
Jun 28 15:29:20 172.30.1.2 [ 305.652617]  [<ffffffff81364ab5>] ? page_fault+0x25/0x30
Jun 28 15:29:20 172.30.1.2 [ 305.652623]  [<ffffffffa01d09d0>] ? br_nf_forward_finish+0x48/0xc0 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652628]  [<ffffffffa01d0c91>] ? br_nf_forward_ip+0x214/0x231 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652631]  [<ffffffff812c7de1>] ? nf_iterate+0x41/0x77
Jun 28 15:29:20 172.30.1.2 [ 305.652636]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652641]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652644]  [<ffffffff812c7f3a>] ? nf_hook_slow+0x68/0xfd
Jun 28 15:29:20 172.30.1.2 [ 305.652648]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652654]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652658]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652663]  [<ffffffffa01cb96e>] ? T.963+0x3c/0x56 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652668]  [<ffffffffa01ca753>] ? __br_fdb_get+0x10/0x83 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652673]  [<ffffffffa01cc61d>] ? br_handle_frame_finish+0x1a7/0x211 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652678]  [<ffffffffa01d1598>] ? br_nf_pre_routing_finish+0x222/0x22f [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652684]  [<ffffffffa01d03b5>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652689]  [<ffffffffa01d135b>] ? br_nf_pre_routing+0x4fc/0x517 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652692]  [<ffffffff812ce172>] ? T.1028+0x4f/0x4f
Jun 28 15:29:20 172.30.1.2 [ 305.652695]  [<ffffffff812c7de1>] ? nf_iterate+0x41/0x77
Jun 28 15:29:20 172.30.1.2 [ 305.652700]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652703]  [<ffffffff812c7f3a>] ? nf_hook_slow+0x68/0xfd
Jun 28 15:29:20 172.30.1.2 [ 305.652708]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652713]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652718]  [<ffffffffa01cc45c>] ? T.947+0x3c/0x56 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652723]  [<ffffffffa01cc84a>] ? br_handle_frame+0x1c3/0x1d9 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652728]  [<ffffffffa01cc687>] ? br_handle_frame_finish+0x211/0x211 [bridge]
Jun 28 15:29:20 172.30.1.2 [ 305.652731]  [<ffffffff812a74f2>] ? __netif_receive_skb+0x37a/0x490
Jun 28 15:29:20 172.30.1.2 [ 305.652734]  [<ffffffff81013a01>] ? read_tsc+0x5/0x16
Jun 28 15:29:20 172.30.1.2 [ 305.652736]  [<ffffffff812a799f>] ? netif_receive_skb+0x67/0x6d
Jun 28 15:29:20 172.30.1.2 [ 305.652739]  [<ffffffff812a7f0b>] ? napi_gro_receive+0x1f/0x2d
Jun 28 15:29:20 172.30.1.2 [ 305.652742]  [<ffffffff812a7a79>] ? napi_skb_finish+0x1c/0x31
Jun 28 15:29:21 172.30.1.2 [ 305.652747]  [<ffffffffa0009a21>] ? bnx2_poll_work+0x8db/0x9f4 [bnx2]
Jun 28 15:29:21 172.30.1.2 [ 305.652752]  [<ffffffffa00092f4>] ? bnx2_poll_work+0x1ae/0x9f4 [bnx2]
Jun 28 15:29:21 172.30.1.2 [ 305.652757]  [<ffffffffa01cc45c>] ? T.947+0x3c/0x56 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 305.652762]  [<ffffffffa0009cfc>] ? bnx2_poll+0x116/0x1f2 [bnx2]
Jun 28 15:29:21 172.30.1.2 [ 305.652765]  [<ffffffff812a74f2>] ? __netif_receive_skb+0x37a/0x490
Jun 28 15:29:21 172.30.1.2 [ 305.652768]  [<ffffffff812a8038>] ? net_rx_action+0xa8/0x207
Jun 28 15:29:21 172.30.1.2 [ 305.652771]  [<ffffffff8106637e>] ? hrtimer_get_next_event+0x7f/0x9a
Jun 28 15:29:21 172.30.1.2 [ 305.652774]  [<ffffffff8104f11e>] ? __do_softirq+0xc4/0x1a0
Jun 28 15:29:21 172.30.1.2 [ 305.652776]  [<ffffffff81097905>] ? handle_irq_event_percpu+0x166/0x184
Jun 28 15:29:21 172.30.1.2 [ 305.652780]  [<ffffffff8136bd6c>] ? call_softirq+0x1c/0x30
Jun 28 15:29:21 172.30.1.2 [ 305.652782]  [<ffffffff8100fa3f>] ? do_softirq+0x3f/0x79
Jun 28 15:29:21 172.30.1.2 [ 305.652785]  [<ffffffff8104eeee>] ? irq_exit+0x44/0xb5
Jun 28 15:29:21 172.30.1.2 [ 305.652787]  [<ffffffff8100f38a>] ? do_IRQ+0x94/0xaa
Jun 28 15:29:21 172.30.1.2 [ 305.652790]  [<ffffffff813647ee>] ? common_interrupt+0x6e/0x6e
Jun 28 15:29:21 172.30.1.2 [ 305.652792]  <EOI>  [<ffffffff81364498>] ? _raw_spin_unlock_irqrestore+0xb/0x11
Jun 28 15:29:21 172.30.1.2 [ 305.652797]  [<ffffffff81045f07>] ? try_to_wake_up+0x181/0x190
Jun 28 15:29:21 172.30.1.2 [ 305.652799]  [<ffffffff81071764>] ? wake_futex+0x2b/0x47
Jun 28 15:29:21 172.30.1.2 [ 305.652802]  [<ffffffff81073949>] ? do_futex+0x3de/0x84a
Jun 28 15:29:21 172.30.1.2 [ 305.652804]  [<ffffffff810dfff1>] ? do_brk+0x2ca/0x326
Jun 28 15:29:21 172.30.1.2 [ 305.652807]  [<ffffffff81073ee4>] ? sys_futex+0x12f/0x147
Jun 28 15:29:21 172.30.1.2 [ 305.652810]  [<ffffffff81369b12>] ? system_call_fastpath+0x16/0x1b
Jun 28 15:29:21 172.30.1.2 [ 305.652812] ---[ end trace 33ba304ebe73322b ]---
Jun 28 15:29:21 172.30.1.2 [ 306.782187] 43 
Jun 28 15:29:21 172.30.1.2 7d
Jun 28 15:29:21 172.30.1.2 83
Jun 28 15:29:21 172.30.1.2 e0
Jun 28 15:29:21 172.30.1.2 f8
Jun 28 15:29:21 172.30.1.2 83
Jun 28 15:29:21 172.30.1.2 c8
Jun 28 15:29:21 172.30.1.2 03
Jun 28 15:29:21 172.30.1.2 88
Jun 28 15:29:21 172.30.1.2 43
Jun 28 15:29:21 172.30.1.2 
Jun 28 15:29:21 172.30.1.2 [ 306.790953] RIP 
Jun 28 15:29:21 172.30.1.2 [ 306.805304]  RSP <ffff88042fc03960>
Jun 28 15:29:21 172.30.1.2 [ 306.817583] CR2: 0000000000000018
Jun 28 15:29:21 172.30.1.2 [ 306.824706] ---[ end trace 33ba304ebe73322c ]---
Jun 28 15:29:21 172.30.1.2 [ 306.834283] Kernel panic - not syncing: Fatal exception in interrupt
Jun 28 15:29:21 172.30.1.2 [ 306.847312] Pid: 4486, comm: kvm Tainted: G      D W    3.2.21 #1
Jun 28 15:29:21 172.30.1.2 [ 306.859837] Call Trace:
Jun 28 15:29:21 172.30.1.2 [ 306.865093]  <IRQ> 
Jun 28 15:29:21 172.30.1.2 [ 306.876993]  [<ffffffff81049da9>] ? kmsg_dump+0xb2/0xdd
Jun 28 15:29:21 172.30.1.2 [ 306.887798]  [<ffffffff813653c1>] ? oops_end+0xa9/0xb6
Jun 28 15:29:21 172.30.1.2 [ 306.898438]  [<ffffffff8102fcf9>] ? no_context+0x1ff/0x20c
Jun 28 15:29:21 172.30.1.2 [ 306.909769]  [<ffffffff810f53c3>] ? virt_to_slab+0x9/0x3c
Jun 28 15:29:21 172.30.1.2 [ 306.920924]  [<ffffffff81367534>] ? do_page_fault+0x1ad/0x34c
Jun 28 15:29:21 172.30.1.2 [ 306.932780]  [<ffffffffa03fcd93>] ? ip_vs_notrack+0x6e/0xa6 [ip_vs]
Jun 28 15:29:21 172.30.1.2 [ 306.945675]  [<ffffffffa03fbdec>] ? ip_vs_conn_put+0x29/0x2f [ip_vs]
Jun 28 15:29:21 172.30.1.2 [ 306.958743]  [<ffffffffa03fde1a>] ? ip_vs_out+0x33c/0x49d [ip_vs]
Jun 28 15:29:21 172.30.1.2 [ 306.971339]  [<ffffffff812a896b>] ? dev_hard_start_xmit+0x3fd/0x571
Jun 28 15:29:21 172.30.1.2 [ 306.984312]  [<ffffffff81364ab5>] ? page_fault+0x25/0x30
Jun 28 15:29:21 172.30.1.2 [ 306.995300]  [<ffffffffa01d09d0>] ? br_nf_forward_finish+0x48/0xc0 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.009564]  [<ffffffffa01d0c91>] ? br_nf_forward_ip+0x214/0x231 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.023567]  [<ffffffff812c7de1>] ? nf_iterate+0x41/0x77
Jun 28 15:29:21 172.30.1.2 [ 307.034624]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.047239]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.059782]  [<ffffffff812c7f3a>] ? nf_hook_slow+0x68/0xfd
Jun 28 15:29:21 172.30.1.2 [ 307.071240]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.083788]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.095464]  [<ffffffffa01cba5a>] ? br_deliver+0x2d/0x2d [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.108227]  [<ffffffffa01cb96e>] ? T.963+0x3c/0x56 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.119901]  [<ffffffffa01ca753>] ? __br_fdb_get+0x10/0x83 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.132796]  [<ffffffffa01cc61d>] ? br_handle_frame_finish+0x1a7/0x211 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.147785]  [<ffffffffa01d1598>] ? br_nf_pre_routing_finish+0x222/0x22f [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.163124]  [<ffffffffa01d03b5>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.176369]  [<ffffffffa01d135b>] ? br_nf_pre_routing+0x4fc/0x517 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.190541]  [<ffffffff812ce172>] ? T.1028+0x4f/0x4f
Jun 28 15:29:21 172.30.1.2 [ 307.200832]  [<ffffffff812c7de1>] ? nf_iterate+0x41/0x77
Jun 28 15:29:21 172.30.1.2 [ 307.211813]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.223490]  [<ffffffff812c7f3a>] ? nf_hook_slow+0x68/0xfd
Jun 28 15:29:21 172.30.1.2 [ 307.234827]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.246623]  [<ffffffffa01cc476>] ? T.947+0x56/0x56 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.258233]  [<ffffffffa01cc45c>] ? T.947+0x3c/0x56 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.269846]  [<ffffffffa01cc84a>] ? br_handle_frame+0x1c3/0x1d9 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.283539]  [<ffffffffa01cc687>] ? br_handle_frame_finish+0x211/0x211 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.298466]  [<ffffffff812a74f2>] ? __netif_receive_skb+0x37a/0x490
Jun 28 15:29:21 172.30.1.2 [ 307.311298]  [<ffffffff81013a01>] ? read_tsc+0x5/0x16
Jun 28 15:29:21 172.30.1.2 [ 307.321743]  [<ffffffff812a799f>] ? netif_receive_skb+0x67/0x6d
Jun 28 15:29:21 172.30.1.2 [ 307.334023]  [<ffffffff812a7f0b>] ? napi_gro_receive+0x1f/0x2d
Jun 28 15:29:21 172.30.1.2 [ 307.346044]  [<ffffffff812a7a79>] ? napi_skb_finish+0x1c/0x31
Jun 28 15:29:21 172.30.1.2 [ 307.357884]  [<ffffffffa0009a21>] ? bnx2_poll_work+0x8db/0x9f4 [bnx2]
Jun 28 15:29:21 172.30.1.2 [ 307.371057]  [<ffffffffa00092f4>] ? bnx2_poll_work+0x1ae/0x9f4 [bnx2]
Jun 28 15:29:21 172.30.1.2 [ 307.384236]  [<ffffffffa01cc45c>] ? T.947+0x3c/0x56 [bridge]
Jun 28 15:29:21 172.30.1.2 [ 307.395847]  [<ffffffffa0009cfc>] ? bnx2_poll+0x116/0x1f2 [bnx2]
Jun 28 15:29:21 172.30.1.2 [ 307.408147]  [<ffffffff812a74f2>] ? __netif_receive_skb+0x37a/0x490
Jun 28 15:29:21 172.30.1.2 [ 307.421034]  [<ffffffff812a8038>] ? net_rx_action+0xa8/0x207
Jun 28 15:29:21 172.30.1.2 [ 307.432644]  [<ffffffff8106637e>] ? hrtimer_get_next_event+0x7f/0x9a
Jun 28 15:29:21 172.30.1.2 [ 307.445688]  [<ffffffff8104f11e>] ? __do_softirq+0xc4/0x1a0
Jun 28 15:29:21 172.30.1.2 [ 307.457118]  [<ffffffff81097905>] ? handle_irq_event_percpu+0x166/0x184
Jun 28 15:29:21 172.30.1.2 [ 307.470749]  [<ffffffff8136bd6c>] ? call_softirq+0x1c/0x30
Jun 28 15:29:21 172.30.1.2 [ 307.482114]  [<ffffffff8100fa3f>] ? do_softirq+0x3f/0x79
Jun 28 15:29:21 172.30.1.2 [ 307.493077]  [<ffffffff8104eeee>] ? irq_exit+0x44/0xb5
Jun 28 15:29:21 172.30.1.2 [ 307.503654]  [<ffffffff8100f38a>] ? do_IRQ+0x94/0xaa
Jun 28 15:29:21 172.30.1.2 [ 307.513875]  [<ffffffff813647ee>] ? common_interrupt+0x6e/0x6e
Jun 28 15:29:21 172.30.1.2 [ 307.525807]  <EOI> 
Jun 28 15:29:22 172.30.1.2 [ 307.541012]  [<ffffffff81045f07>] ? try_to_wake_up+0x181/0x190
Jun 28 15:29:22 172.30.1.2 [ 307.552919]  [<ffffffff81071764>] ? wake_futex+0x2b/0x47
Jun 28 15:29:22 172.30.1.2 [ 307.563873]  [<ffffffff81073949>] ? do_futex+0x3de/0x84a
Jun 28 15:29:22 172.30.1.2 [ 307.574792]  [<ffffffff810dfff1>] ? do_brk+0x2ca/0x326
Jun 28 15:29:22 172.30.1.2 [ 307.585363]  [<ffffffff81073ee4>] ? sys_futex+0x12f/0x147
Jun 28 15:29:22 172.30.1.2 [ 307.596418]  [<ffffffff81369b12>] ? system_call_fastpath+0x16/0x1b

^ permalink raw reply

* RFC: replace packets already in queue
From: Erdt, Ralph @ 2012-06-28 13:18 UTC (permalink / raw)
  To: netdev@vger.kernel.org

(I've send this email already in the lartc mailing list. Short after this I found the list seems dead (http://dir.gmane.org/gmane.linux.network.routing). I hope this is the correct place to ask. If not - please give me a note, where I can ask this.)

----------

Hello.

I'm writing a kernel module (net/sched) which replaces packets in the queue. I'm glad hearing your option.

Background:
In very low bandwidth network (<=9.6Kbps, shared, etc.) its hard (rather: impossible) to get all packets sent.
But some of the packets contain information, which gets obsolete over time. E.g. (GPS) positions, which will be sent periodically. If the application sends a new packet while an old position packet is still in the queue, the old packet is obsolete. This can be dropped. But just dropping the old packet and queuing the new packet will result in never sending a packet of this type.

So I'm writing a tc-qdisc scheduler module, which replaces packets in the queue on enqueuing, when this properties are given:
- UDPv4
- not fragmented
- (TOS & bitmask) = givenCompare; (bitmask and compare are adjustable)
- same source IP
- same destination IP
- same destination port
- same TOS
So, the packet got sent over the time - but with the actual information.

What do you think? Is this module worth to get released to kernel.org? Have you any other comments?

Greetings
Ralph Erdt

^ permalink raw reply

* Re: [PATCH] net: nfc: fix panic in accept()
From: John W. Linville @ 2012-06-28 13:42 UTC (permalink / raw)
  To: Samuel Ortiz
  Cc: Sasha Levin, Eric Dumazet, Dave Jones, David Miller,
	lauro.venancio-430g2QfJUUCGglJvpFV4uA,
	aloisio.almeida-430g2QfJUUCGglJvpFV4uA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-wireless
In-Reply-To: <20120628125612.GG4846@sortiz-mobl>

On Thu, Jun 28, 2012 at 02:56:12PM +0200, Samuel Ortiz wrote:
> Hi Sasha,
> 
> On Thu, Jun 28, 2012 at 02:11:38PM +0200, Sasha Levin wrote:
> > Hi Samuel,
> > 
> > On Mon, Jun 25, 2012 at 7:15 PM, Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> > > Hi Eric,
> > >
> > > On Mon, Jun 25, 2012 at 05:53:32PM +0200, Eric Dumazet wrote:
> > >> From: Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > >>
> > >> Sasha Levin reported following panic :
> > > I applied a similar patch, more consistent with the rest of the NFC socket
> > > code, still with you as the author. See here:
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/sameo/nfc-3.0.git;a=commit;h=631c301f20558525a641fadffc0126affd3dc4a4
> > 
> > Could this tree be included in -next please?
> No, wireless-next is already included in -next. The above patch is making its
> way upstream, it's in the wireless.git tree and should hit davem's net tree
> soon.

FWIW, lots (or most?) of the bug fix trees get pulled into -next
as well.  Having the nfc tree go there makes sense to me.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org			might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [RFC PATCH net-next] ipvs: add missing lock in ip_vs_ftp_init_conn()
From: Xiaotian Feng @ 2012-06-28 13:36 UTC (permalink / raw)
  To: netdev, lvs-devel, netfilter-devel, netfilter, coreteam
  Cc: linux-kernel, Xiaotian Feng, Xiaotian Feng, Wensong Zhang,
	Simon Horman, Julian Anastasov, Pablo Neira Ayuso,
	Patrick McHardy, David S. Miller

We met a kernel panic in 2.6.32.43 kernel:

[2680191.848044] IPVS: ip_vs_conn_hash(): request for already hashed, called from run_timer_softirq+0x175/0x1d0
<snip>
[2680311.849009] general protection fault: 0000 [#1] SMP
[2680311.853001] RIP: 0010:[<ffffffff815f155c>]  [<ffffffff815f155c>] ip_vs_conn_expire+0xdc/0x2f0
[2680311.853001] RSP: 0018:ffff880028303e70  EFLAGS: 00010202
[2680311.853001] RAX: dead000000200200 RBX: ffff8801aad00b80 RCX: 0000000000001d90
[2680311.853001] RDX: dead000000100100 RSI: 000000004fd59800 RDI: ffff8801aad00c08
<snip>
[2680311.853001] Call Trace:
[2680311.853001]  <IRQ>
[2680311.853001]  [<ffffffff815f1480>] ? ip_vs_conn_expire+0x0/0x2f0
[2680311.853001]  [<ffffffff8104e2a5>] run_timer_softirq+0x175/0x1d0
[2680311.853001]  [<ffffffff81021a48>] ? lapic_next_event+0x18/0x20
[2680311.853001]  [<ffffffff81049a13>] __do_softirq+0xb3/0x150
[2680311.853001]  [<ffffffff8100cc5c>] call_softirq+0x1c/0x30
[2680311.853001]  [<ffffffff8100ea9a>] do_softirq+0x4a/0x80
[2680311.853001]  [<ffffffff81049957>] irq_exit+0x77/0x80
[2680311.853001]  [<ffffffff81021f2c>] smp_apic_timer_interrupt+0x6c/0xa0
[2680311.853001]  [<ffffffff8100c633>] apic_timer_interrupt+0x13/0x20
[2680311.853001]  <EOI>
[2680311.853001]  [<ffffffff81013b52>] ? mwait_idle+0x52/0x70
[2680311.853001]  [<ffffffff8100a7b0>] ? enter_idle+0x20/0x30
[2680311.853001]  [<ffffffff8100ac62>] ? cpu_idle+0x52/0x80
[2680311.853001]  [<ffffffff816d504d>] ? start_secondary+0x19d/0x280

rax and rdx is LIST_POISON1 and LIST_POISON2, so kernel is list_del() on an already deleted
connection and result the general protect fault.

The "request for already hashed" warning, told us someone might change the connection flags
incorrectly, like described in commit aea9d711, it changes the connection flags, but doesn't
put the connection back to the list. So ip_vs_conn_hash() throw a warning and return.
Later, when ip_vs_conn_expire fire again, ip_vs_conn_unhash() will find the HASHED connection
and list_del() it, then kernel panic happened.

After code review, the only chance that kernel change connection flag without protection is
in ip_vs_ftp_init_conn().

Signed-off-by: Xiaotian Feng <dannyfeng@tencent.com>
Cc: Wensong Zhang <wensong@linux-vs.org>
Cc: Simon Horman <horms@verge.net.au>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: "David S. Miller" <davem@davemloft.net> 
---
 net/netfilter/ipvs/ip_vs_ftp.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
index b20b29c..c2bc264 100644
--- a/net/netfilter/ipvs/ip_vs_ftp.c
+++ b/net/netfilter/ipvs/ip_vs_ftp.c
@@ -65,8 +65,10 @@ static int ip_vs_ftp_pasv;
 static int
 ip_vs_ftp_init_conn(struct ip_vs_app *app, struct ip_vs_conn *cp)
 {
+	spin_lock(&cp->lock);
 	/* We use connection tracking for the command connection */
 	cp->flags |= IP_VS_CONN_F_NFCT;
+	spin_unlock(&cp->lock);
 	return 0;
 }
 
-- 
1.7.1


^ permalink raw reply related

* Re: [PATCH net-next] em_canid: Ematch rule to match CAN frames according to their CAN IDs
From: Rostislav Lisovy @ 2012-06-28 13:35 UTC (permalink / raw)
  To: Oliver Hartkopp; +Cc: Eric Dumazet, netdev, linux-can, lartc, pisa, sojkam1
In-Reply-To: <4FEA169C.1070709@hartkopp.net>

Hello Oliver;

On Tue, 2012-06-26 at 22:07 +0200, Oliver Hartkopp wrote: 
> I found some time for a review. See details inline ...
> 
I agree with quite everything except for following...


> > +				match = true;
> 
> 
> match = 1;
> 
egrep -r "= true;" ./linux-source | wc -l
returns 6770 -- why don't you like "= true"?


> > +				break;
> > +			}
> > +		}
> > +	} else { /* SFF */
> > +		can_id &= CAN_SFF_MASK;
> > +		match = test_bit(can_id, cm->match_sff);
> > +	}
> > +
> 
> 
> return match;
> 
match() function must return 1 or 0, however (from my experience)
test_bit() returns 0 and non-0 (strictly speaking, in my case, 0 and
-1).


> > +				&conf[i],
> > +				sizeof(struct can_filter));
> > +
> > +			cm->eff_rules_count++;
> > +		} else {
> > +			continue;
> > +		}
> 
> 
> omit { } around continue
> 
http://lxr.linux.no/#linux+v3.4.4/Documentation/CodingStyle#L169


> > +	}
> > +
> > +	/* Process SFF frame rules */
> > +	for (i = 0; i < cm->rules_count; i++) {
> > +		if ((conf[i].can_id & CAN_EFF_FLAG) &&
> > +		    (conf[i].can_mask & CAN_EFF_FLAG)) {
> 
> 
> What if CAN_EFF_FLAG is set in can_id but not in can_mask ?
> 
There were small misunderstanding from my side -- this will be rewritten
in the way that EFF_FLAG in mask will determine if we care about the
value of EFF_FLAG in an identifier -- i.e. when EFF_FLAG is set in the
mask, the rule will be added as SFF or EFF only depending on EFF_FLAG
value in the identifier. If EFF_FLAG is 0 in the mask, the rule will be
added as both SFF and EFF.

Regards;
Rostislav


^ permalink raw reply

* ipsec and snat: mtu question‏
From: Marco Berizzi @ 2012-06-28 13:08 UTC (permalink / raw)
  To: netdev



Hello everybody.
 
Kindly, I would like to ask for explanations
about a linux ipsec gateway snatting packets.
 
Here is the network schema.
 
customer private network 10.16.0.0/16
|
|
+ipsec customer gateway (checkpoint)
||
||---ipsec tunnel 10.16.0.0/16<->172.16.128.0/28 (des3/md5)
||   mtu=1446
||
++ linux_gw_snat ipsec gateway (SNAT all packets from 172.22.1.0/24 to 172.16.128.1)
|| 
||---ipsec tunnel 10.16.0.0/16<->172.22.1.0/24 (aes/sha1/ipcomp)
||   mtu=1430
||
+linux_final ipsec gateway
|
|
client 172.22.1.50
 
SYN packet start behind the linux_final (172.22.1.50)
for 10.16.237.66 customer network. MSS is 1460 byte.
DF flag is set on outgoing packets.
Packet travel inside the ipsec tunnel: tunnel mtu is
1430
At the linux_gw_snat, the packet get decryped, snatted
(ip src change from 172.22.1.50 to 172.16.128.1) and
encryped again.
Packets are delivered to the checkpoint: tunnel mtu is
1446
Checkpoint deliver the decryped packet to 10.16.237.66
So far, so good.
 
At some point, 10.16.237.66 will send a 1500 byte
packet for 172.16.128.1: checkpoint will reply with
an icmp packet too large need to frag: mtu is 1446
 
10.16.237.66 will send back a 1446 byte packet to
the checkpoint which will encrypt and deliver to the
linux_gw_snat which will decrypt and deSNAT. Now
linux_gw_snat must send this 1446 byte packet to
172.22.1.50 but mtu is only 1430: packet will be
dropped (DF is set).
 
Now, IMHO, linux_gw_snat should send an imcp message
to 10.16.237.66 telling that max mtu is 1430, but I
don't see any icmp packet.
Is this the expected behaviour?
 
TIA
 
PS: linux_gw_snat is 3.3.5
 		 	   		  

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox