* Re: a problem tcp_v4_err()
From: Alexey Kuznetsov @ 2010-11-12 18:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: Patrick McHardy, David Lamparter, Eric Paris, Hua Zhong, netdev,
linux-kernel, davem, pekkas, jmorris, yoshfuji, paul.moore,
Damian Lukowski
In-Reply-To: <1289586477.3185.273.camel@edumazet-laptop>
Hello!
> Oh well, it seems you are right (backlog processing)
Exactly.
Alexey
^ permalink raw reply
* Re: [PATCH 4/10] Fix leaking of kernel heap addresses in net/
From: Stephen Hemminger @ 2010-11-12 18:33 UTC (permalink / raw)
To: Dan Rosenberg
Cc: Eric Dumazet, David Miller, socketcan, kuznet, urs.thuermann,
yoshfuji, kaber, jmorris, remi.denis-courmont, pekkas, sri,
vladislav.yasevich, tj, lizf, joe, hadi, ebiederm, adobriyan,
jpirko, johannes.berg, daniel.lezcano, xemul, socketcan-core,
netdev, linux-sctp, torvalds
In-Reply-To: <1289582682.3090.323.camel@Dan>
On Fri, 12 Nov 2010 12:24:42 -0500
Dan Rosenberg <drosenberg@vsecurity.com> wrote:
>
> >
> > Also, the whole idea needs to be under a config option, so only
> > the paranoid idiots turn it on.
>
> If that's what's necessary to get it accepted, I'm willing to do that.
> But when a solution does not negatively impact usability or performance
> and improves security, even in a small way, why should it not be enabled
> by default? Of course it's my responsibility to first propose a
> solution that is acceptable from a usability/debugging standpoint, but
> assuming that can be achieved, I don't really see what the problem is.
> There's a difference between being a "paranoid idiot" and wanting to
> protect users from unnecessary exposure.
See earlier discussion about automatically running crypto tests on boot
which caused Linus to flame. This is more intrusive, and is not something
most developers would want; but it might make sense in production
environment.
^ permalink raw reply
* Re: a problem tcp_v4_err()
From: Eric Dumazet @ 2010-11-12 18:33 UTC (permalink / raw)
To: Alexey Kuznetsov
Cc: Patrick McHardy, David Lamparter, Eric Paris, Hua Zhong, netdev,
linux-kernel, davem, pekkas, jmorris, yoshfuji, paul.moore,
Damian Lukowski
In-Reply-To: <20101112182959.GA20459@ms2.inr.ac.ru>
Le vendredi 12 novembre 2010 à 21:29 +0300, Alexey Kuznetsov a écrit :
> Hello!
>
> On Fri, Nov 12, 2010 at 07:12:58PM +0100, Eric Dumazet wrote:
> > I see socket is locked around line 368,
> >
> > bh_lock_sock(sk);
> > /* If too many ICMPs get dropped on busy
> > * servers this needs to be solved differently.
> > */
> > if (sock_owned_by_user(sk))
> > NET_INC_STATS_BH(net, LINUX_MIB_LOCKDROPPEDICMPS);
> >
> >
> > Hmm, maybe some goto is missing ;)
>
> It is not missing, sock_owned_by_user() is checked later when some operation which
> cannot be done without lock is required. It was done to save error in sk_err_soft even
> when socket is locked.
>
> This code also _understands_ this: look at
>
> } else if (sock_owned_by_user(sk)) {
> /* RTO revert clocked out retransmission,
> * but socket is locked. Will defer. */
> inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
> HZ/20, TCP_RTO_MAX);
>
> but somehow it considers the manipulations with rto/backoff/write_queue as safe.
> Seems, they are not.
Indeed, right you are, I came to same conclusion.
I CC Damian Lukowski in my previous answer (and this one too)
Thanks !
^ permalink raw reply
* Re: [PATCH] rtnetlink: Fix message size calculation for link messages
From: David Miller @ 2010-11-12 18:53 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <4CDCF032.7040802@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 12 Nov 2010 08:43:46 +0100
> On 12.11.2010 02:47, Thomas Graf wrote:
>> nlmsg_total_size() calculates the length of a netlink message
>> including header and alignment. nla_total_size() calculates the
>> space an individual attribute consumes which was meant to be used
>> in this context.
>>
>> Also, ensure to account for the attribute header for the
>> IFLA_INFO_XSTATS attribute as implementations of get_xstats_size()
>> seem to assume that we do so.
>>
>> The addition of two message headers minus the missing attribute
>> header resulted in a calculated message size that was larger than
>> required. Therefore we never risked running out of skb tailroom.
>>
>> Signed-off-by: Thomas Graf <tgraf@infradead.org>
>> Cc: Patrick McHardy <kaber@trash.net>
>
> Looks good to me, thanks Thomas.
>
> Acked-by: Patrick McHardy <kaber@trash.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] netfilter: netfilter fixes
From: David Miller @ 2010-11-12 19:07 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1289575172-7272-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Fri, 12 Nov 2010 16:19:30 +0100
> Hi Dave,
>
> The following two patches fix some netfilter bugs:
>
> - missing parentheses in NF_HOOK_COND, breaking error propagation for
> dropped packets. From Eric Paris.
>
> - incorrect checking for overlapping fragments in IPv6 conntrack
> reassembly. From Shan Wei
>
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git
Pulled, thanks Patrick.
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Christoph Lameter @ 2010-11-12 19:14 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Eric Dumazet, Andrew Morton, linux-kernel, David Miller, netdev,
Arnaldo Carvalho de Melo, Ingo Molnar, Andi Kleen, Nick Piggin
In-Reply-To: <20101105195101.GC15561@linux.vnet.ibm.com>
prefetchw() would be too much overhead?
^ permalink raw reply
* Re: [PATCH] NET: sunrpc, remove unneeded NULL tests
From: J. Bruce Fields @ 2010-11-12 19:14 UTC (permalink / raw)
To: Jiri Slaby
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jirislaby-Re5JQEeQqe8AvxtiuMwx3w, Neil Brown,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, Trond Myklebust
In-Reply-To: <1288180325-20009-1-git-send-email-jslaby-AlSwsSmVLrQ@public.gmane.org>
Sorry for the slow response, this one's for Trond if it hasn't already
been handled.
--b.
On Wed, Oct 27, 2010 at 01:52:05PM +0200, Jiri Slaby wrote:
> Stanse found that req in xprt_reserve_xprt is dereferenced prior its
> test to NULL. If that's the case, the checks are unnecessary, so
> remove them.
>
> The alternative is not to dereference it before the test. The patch
> is to point out the problem, you have to decide.
>
> Signed-off-by: Jiri Slaby <jslaby-AlSwsSmVLrQ@public.gmane.org>
> Cc: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
> Cc: Neil Brown <neilb-l3A5Bk7waGM@public.gmane.org>
> Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> net/sunrpc/xprt.c | 8 +++-----
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
> index 4c8f18a..5355c71 100644
> --- a/net/sunrpc/xprt.c
> +++ b/net/sunrpc/xprt.c
> @@ -202,10 +202,8 @@ int xprt_reserve_xprt(struct rpc_task *task)
> goto out_sleep;
> }
> xprt->snd_task = task;
> - if (req) {
> - req->rq_bytes_sent = 0;
> - req->rq_ntrans++;
> - }
> + req->rq_bytes_sent = 0;
> + req->rq_ntrans++;
> return 1;
>
> out_sleep:
> @@ -213,7 +211,7 @@ out_sleep:
> task->tk_pid, xprt);
> task->tk_timeout = 0;
> task->tk_status = -EAGAIN;
> - if (req && req->rq_ntrans)
> + if (req->rq_ntrans)
> rpc_sleep_on(&xprt->resend, task, NULL);
> else
> rpc_sleep_on(&xprt->sending, task, NULL);
> --
> 1.7.3.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: a problem tcp_v4_err()
From: David Miller @ 2010-11-12 19:22 UTC (permalink / raw)
To: eric.dumazet
Cc: kuznet, kaber, equinox, eparis, hzhong, netdev, linux-kernel,
pekkas, jmorris, yoshfuji, paul.moore, damian
In-Reply-To: <1289586803.3185.275.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 12 Nov 2010 19:33:23 +0100
> I CC Damian Lukowski in my previous answer (and this one too)
Probably the safest fix is this:
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 8f8527d..69ccbc1 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -415,6 +415,9 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
!icsk->icsk_backoff)
break;
+ if (sock_owned_by_user(sk))
+ break;
+
icsk->icsk_backoff--;
inet_csk(sk)->icsk_rto = __tcp_set_rto(tp) <<
icsk->icsk_backoff;
@@ -429,11 +432,6 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
if (remaining) {
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
remaining, TCP_RTO_MAX);
- } else if (sock_owned_by_user(sk)) {
- /* RTO revert clocked out retransmission,
- * but socket is locked. Will defer. */
- inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
- HZ/20, TCP_RTO_MAX);
} else {
/* RTO revert clocked out retransmission.
* Will retransmit now */
^ permalink raw reply related
* Re: [RFC PATCH] network: return errors if we know tcp_connect failed
From: David Miller @ 2010-11-12 19:28 UTC (permalink / raw)
To: kuznet; +Cc: eparis, netdev, linux-kernel, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20101112174620.GA16544@ms2.inr.ac.ru>
From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Date: Fri, 12 Nov 2010 20:46:20 +0300
> The only loophole is ICMP error in the same case as yours. In
> _violation_ of specs linux immediately aborts unestablished connect
> on an icmp error. IMHO that thing which you suggest is correct (of
> course, provided you filter out transient errors and react only to
> EPERM or something like this). It was not done because it was
> expected firewall rule prescribing immediate abort is configured
> with "--reject-with icmp-port-unreachable", otherwise the rule
> orders real blackhole.
The idea to signal on -EPERM might be OK, but if that's also
what things like "-m statistical" and friends end up reporting
then we still cannot do it.
^ permalink raw reply
* Re: [PATCH] dlm: Handle application limited situations properly.
From: David Teigland @ 2010-11-12 20:03 UTC (permalink / raw)
To: David Miller; +Cc: ccaulfie, cluster-devel, netdev, linux-kernel
In-Reply-To: <20101110.215639.189706684.davem@davemloft.net>
On Wed, Nov 10, 2010 at 09:56:39PM -0800, David Miller wrote:
>
> In the normal regime where an application uses non-blocking I/O
> writes on a socket, they will handle -EAGAIN and use poll() to
> wait for send space.
>
> They don't actually sleep on the socket I/O write.
>
> But kernel level RPC layers that do socket I/O operations directly
> and key off of -EAGAIN on the write() to "try again later" don't
> use poll(), they instead have their own sleeping mechanism and
> rely upon ->sk_write_space() to trigger the wakeup.
>
> So they do effectively sleep on the write(), but this mechanism
> alone does not let the socket layers know what's going on.
>
> Therefore they must emulate what would have happened, otherwise
> TCP cannot possibly see that the connection is application window
> size limited.
>
> Handle this, therefore, like SUNRPC by setting SOCK_NOSPACE and
> bumping the ->sk_write_count as needed when we hit the send buffer
> limits.
>
> This should make TCP send buffer size auto-tuning and the
> ->sk_write_space() callback invocations actually happen.
Thanks, pushed to
git://git.kernel.org/pub/scm/linux/kernel/git/teigland/dlm.git#next
^ permalink raw reply
* Re: [PATCH 4/10] Fix leaking of kernel heap addresses in net/
From: Alexey Dobriyan @ 2010-11-12 20:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20101112083315.096dfaa3@nehalam>
On Fri, Nov 12, 2010 at 08:33:15AM -0800, Stephen Hemminger wrote:
> Also, the whole idea needs to be under a config option, so only
> the paranoid idiots turn it on.
Would be fun if something will break because ffff8800bcd498c0
will become something else. :-)
^ permalink raw reply
* Fwd: WARNING: at net/ipv6/ip6_fib.c:1172 fib6_del+0x4f6/0x5a0() 2.6.35.7
From: Alexey Dobriyan @ 2010-11-12 20:21 UTC (permalink / raw)
To: netdev; +Cc: udovdh
----- Forwarded message from Udo van den Heuvel <udovdh@xs4all.nl> -----
From: Udo van den Heuvel <udovdh@xs4all.nl>
To: linux-kernel@vger.kernel.org
Subject: WARNING: at net/ipv6/ip6_fib.c:1172 fib6_del+0x4f6/0x5a0() 2.6.35.7
Date: Thu, 11 Nov 2010 17:56:50 +0100
Hello,
Should apps like NetworkManager cause stuff like in the logs added below?
What happened?
How to fix?
Kind regards,
Udo
------------[ cut here ]------------
WARNING: at net/ipv6/ip6_fib.c:1172 fib6_del+0x4f6/0x5a0()
Hardware name:
Modules linked in: sit tunnel4 nls_utf8 isofs vfat fat usb_storage
vboxnetadp vboxnetflt vboxdrv radeon ttm drm_kms_helper drm fb fbdev
i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect rfcomm sco bridge stp llc
bnep l2cap nfsd nfs_acl auth_rpcgss exportfs eeprom it87 hwmon_vid lockd
sunrpc powernow_k8 mperf ipt_REJECT iptable_filter ipt_MASQUERADE
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
nf_conntrack_netbios_ns ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables x_tables binfmt_misc dm_mirror
dm_region_hash dm_log ppdev snd_hda_codec_atihdmi snd_hda_codec_realtek
pwc snd_seq snd_seq_device videodev parport_pc snd_hda_intel
snd_hda_codec k10temp snd_pcm ohci1394 snd_timer btusb ieee1394 snd
v4l1_compat v4l2_compat_ioctl32 i2c_piix4 usblp evdev sg parport
bluetooth button snd_page_alloc sr_mod cdrom ide_pci_generic atiixp
pata_atiixp ehci_hcd ohci_hcd sata_sil24 floppy [last unloaded:
scsi_wait_scan]
Pid: 19225, comm: NetworkManager Not tainted 2.6.35.7 #10
Call Trace:
[<ffffffff8103e02b>] ? warn_slowpath_common+0x7b/0xc0
[<ffffffff8137b7b6>] ? fib6_del+0x4f6/0x5a0
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff8137a9c0>] ? fib6_prune_clone+0x0/0x20
[<ffffffff8137b8bc>] ? fib6_clean_node+0x5c/0xc0
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137acd6>] ? fib6_walk_continue+0x156/0x170
[<ffffffff8137ad41>] ? fib6_walk+0x51/0xb0
[<ffffffff813a8533>] ? _raw_write_lock_bh+0x13/0x30
[<ffffffff8137b177>] ? fib6_clean_all+0x97/0xe0
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137a8e6>] ? rt6_ifdown+0x26/0xc0
[<ffffffff81373b88>] ? addrconf_ifdown+0x48/0x4e0
[<ffffffff81043cdd>] ? local_bh_enable_ip+0x4d/0xb0
[<ffffffff81374405>] ? addrconf_notify+0xe5/0x910
[<ffffffff8104a013>] ? lock_timer_base+0x33/0x70
[<ffffffff813a84b2>] ? _raw_spin_unlock_irqrestore+0x12/0x40
[<ffffffff8104a8bd>] ? mod_timer+0x14d/0x250
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff8105acf6>] ? notifier_call_chain+0x46/0x70
[<ffffffff812f91d5>] ? __dev_notify_flags+0x65/0x90
[<ffffffff812f923b>] ? dev_change_flags+0x3b/0x70
[<ffffffff81304f09>] ? do_setlink+0x189/0x740
[<ffffffff811c1da0>] ? nla_parse+0x30/0x100
[<ffffffff81305b90>] ? rtnetlink_rcv_msg+0x0/0x270
[<ffffffff81305597>] ? rtnl_setlink+0xd7/0x120
[<ffffffff81305b90>] ? rtnetlink_rcv_msg+0x0/0x270
[<ffffffff813153e9>] ? netlink_rcv_skb+0x89/0xb0
[<ffffffff81305b7f>] ? rtnetlink_rcv+0x1f/0x30
[<ffffffff81314fe5>] ? netlink_unicast+0x2a5/0x2f0
[<ffffffff8131592c>] ? netlink_sendmsg+0x1fc/0x300
[<ffffffff812e559e>] ? sock_sendmsg+0xfe/0x110
[<ffffffff8110e3a9>] ? dquot_file_open+0x19/0x60
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff8108d709>] ? file_read_actor+0x179/0x1b0
[<ffffffff811ae452>] ? cpumask_any_but+0x22/0x40
[<ffffffff8102b27c>] ? flush_tlb_page+0x5c/0xe0
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff810c0972>] ? fget_light+0xb2/0xf0
[<ffffffff812e7946>] ? move_addr_to_kernel+0x46/0x70
[<ffffffff812f185a>] ? verify_iovec+0x6a/0xc0
[<ffffffff812e58bb>] ? sys_sendmsg+0x23b/0x380
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81026829>] ? do_page_fault+0x199/0x3b0
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff810c0972>] ? fget_light+0xb2/0xf0
[<ffffffff8107a9d8>] ? audit_syscall_entry+0x1b8/0x1e0
[<ffffffff810023eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace 286af05228c1bc82 ]---
fib6_clean_node: del failed: rt=ffff880037a84200@98c20d5400000000 err=-2
------------[ cut here ]------------
WARNING: at net/ipv6/ip6_fib.c:1172 fib6_del+0x4f6/0x5a0()
Hardware name:
Modules linked in: sit tunnel4 nls_utf8 isofs vfat fat usb_storage
vboxnetadp vboxnetflt vboxdrv radeon ttm drm_kms_helper drm fb fbdev
i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect rfcomm sco bridge stp llc
bnep l2cap nfsd nfs_acl auth_rpcgss exportfs eeprom it87 hwmon_vid lockd
sunrpc powernow_k8 mperf ipt_REJECT iptable_filter ipt_MASQUERADE
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
nf_conntrack_netbios_ns ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables x_tables binfmt_misc dm_mirror
dm_region_hash dm_log ppdev snd_hda_codec_atihdmi snd_hda_codec_realtek
pwc snd_seq snd_seq_device videodev parport_pc snd_hda_intel
snd_hda_codec k10temp snd_pcm ohci1394 snd_timer btusb ieee1394 snd
v4l1_compat v4l2_compat_ioctl32 i2c_piix4 usblp evdev sg parport
bluetooth button snd_page_alloc sr_mod cdrom ide_pci_generic atiixp
pata_atiixp ehci_hcd ohci_hcd sata_sil24 floppy [last unloaded:
scsi_wait_scan]
Pid: 19225, comm: NetworkManager Tainted: G W 2.6.35.7 #10
Call Trace:
[<ffffffff8103e02b>] ? warn_slowpath_common+0x7b/0xc0
[<ffffffff8137b7b6>] ? fib6_del+0x4f6/0x5a0
[<ffffffff813a5a16>] ? printk+0x40/0x4a
[<ffffffff8137b8bc>] ? fib6_clean_node+0x5c/0xc0
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137acd6>] ? fib6_walk_continue+0x156/0x170
[<ffffffff8137ad41>] ? fib6_walk+0x51/0xb0
[<ffffffff813a8533>] ? _raw_write_lock_bh+0x13/0x30
[<ffffffff8137b177>] ? fib6_clean_all+0x97/0xe0
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137a8e6>] ? rt6_ifdown+0x26/0xc0
[<ffffffff81373b88>] ? addrconf_ifdown+0x48/0x4e0
[<ffffffff81043cdd>] ? local_bh_enable_ip+0x4d/0xb0
[<ffffffff81374405>] ? addrconf_notify+0xe5/0x910
[<ffffffff8104a013>] ? lock_timer_base+0x33/0x70
[<ffffffff813a84b2>] ? _raw_spin_unlock_irqrestore+0x12/0x40
[<ffffffff8104a8bd>] ? mod_timer+0x14d/0x250
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff8105acf6>] ? notifier_call_chain+0x46/0x70
[<ffffffff812f91d5>] ? __dev_notify_flags+0x65/0x90
[<ffffffff812f923b>] ? dev_change_flags+0x3b/0x70
[<ffffffff81304f09>] ? do_setlink+0x189/0x740
[<ffffffff811c1da0>] ? nla_parse+0x30/0x100
[<ffffffff81305b90>] ? rtnetlink_rcv_msg+0x0/0x270
[<ffffffff81305597>] ? rtnl_setlink+0xd7/0x120
[<ffffffff81305b90>] ? rtnetlink_rcv_msg+0x0/0x270
[<ffffffff813153e9>] ? netlink_rcv_skb+0x89/0xb0
[<ffffffff81305b7f>] ? rtnetlink_rcv+0x1f/0x30
[<ffffffff81314fe5>] ? netlink_unicast+0x2a5/0x2f0
[<ffffffff8131592c>] ? netlink_sendmsg+0x1fc/0x300
[<ffffffff812e559e>] ? sock_sendmsg+0xfe/0x110
[<ffffffff8110e3a9>] ? dquot_file_open+0x19/0x60
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff8108d709>] ? file_read_actor+0x179/0x1b0
[<ffffffff811ae452>] ? cpumask_any_but+0x22/0x40
[<ffffffff8102b27c>] ? flush_tlb_page+0x5c/0xe0
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff810c0972>] ? fget_light+0xb2/0xf0
[<ffffffff812e7946>] ? move_addr_to_kernel+0x46/0x70
[<ffffffff812f185a>] ? verify_iovec+0x6a/0xc0
[<ffffffff812e58bb>] ? sys_sendmsg+0x23b/0x380
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81026829>] ? do_page_fault+0x199/0x3b0
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff810c0972>] ? fget_light+0xb2/0xf0
[<ffffffff8107a9d8>] ? audit_syscall_entry+0x1b8/0x1e0
[<ffffffff810023eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace 286af05228c1bc83 ]---
fib6_clean_node: del failed: rt=ffff88012ae4b200@620aa8c000000000 err=-2
r8169 0000:03:00.0: eth0: link up
eth0: no IPv6 routers present
------------[ cut here ]------------
WARNING: at net/ipv6/ip6_fib.c:1172 fib6_del+0x4f6/0x5a0()
Hardware name:
Modules linked in: sit tunnel4 nls_utf8 isofs vfat fat usb_storage
vboxnetadp vboxnetflt vboxdrv radeon ttm drm_kms_helper drm fb fbdev
i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect rfcomm sco bridge stp llc
bnep l2cap nfsd nfs_acl auth_rpcgss exportfs eeprom it87 hwmon_vid lockd
sunrpc powernow_k8 mperf ipt_REJECT iptable_filter ipt_MASQUERADE
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
nf_conntrack_netbios_ns ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables x_tables binfmt_misc dm_mirror
dm_region_hash dm_log ppdev snd_hda_codec_atihdmi snd_hda_codec_realtek
pwc snd_seq snd_seq_device videodev parport_pc snd_hda_intel
snd_hda_codec k10temp snd_pcm ohci1394 snd_timer btusb ieee1394 snd
v4l1_compat v4l2_compat_ioctl32 i2c_piix4 usblp evdev sg parport
bluetooth button snd_page_alloc sr_mod cdrom ide_pci_generic atiixp
pata_atiixp ehci_hcd ohci_hcd sata_sil24 floppy [last unloaded:
scsi_wait_scan]
Pid: 19514, comm: NetworkManager Tainted: G W 2.6.35.7 #10
Call Trace:
[<ffffffff8103e02b>] ? warn_slowpath_common+0x7b/0xc0
[<ffffffff8137b7b6>] ? fib6_del+0x4f6/0x5a0
[<ffffffff810386af>] ? load_balance+0xbf/0x6b0
[<ffffffff8103201f>] ? dequeue_task_fair+0x4f/0x1c0
[<ffffffff8137b8bc>] ? fib6_clean_node+0x5c/0xc0
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137acd6>] ? fib6_walk_continue+0x156/0x170
[<ffffffff8137ad41>] ? fib6_walk+0x51/0xb0
[<ffffffff813a8533>] ? _raw_write_lock_bh+0x13/0x30
[<ffffffff8137b177>] ? fib6_clean_all+0x97/0xe0
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137a8e6>] ? rt6_ifdown+0x26/0xc0
[<ffffffff81373b88>] ? addrconf_ifdown+0x48/0x4e0
[<ffffffff81043cdd>] ? local_bh_enable_ip+0x4d/0xb0
[<ffffffff81374405>] ? addrconf_notify+0xe5/0x910
[<ffffffff8104a013>] ? lock_timer_base+0x33/0x70
[<ffffffff813a84b2>] ? _raw_spin_unlock_irqrestore+0x12/0x40
[<ffffffff8104a8bd>] ? mod_timer+0x14d/0x250
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff8105acf6>] ? notifier_call_chain+0x46/0x70
[<ffffffff812f91d5>] ? __dev_notify_flags+0x65/0x90
[<ffffffff812f923b>] ? dev_change_flags+0x3b/0x70
[<ffffffff81304f09>] ? do_setlink+0x189/0x740
[<ffffffff811c1da0>] ? nla_parse+0x30/0x100
[<ffffffff81305b90>] ? rtnetlink_rcv_msg+0x0/0x270
[<ffffffff81305597>] ? rtnl_setlink+0xd7/0x120
[<ffffffff81305b90>] ? rtnetlink_rcv_msg+0x0/0x270
[<ffffffff813153e9>] ? netlink_rcv_skb+0x89/0xb0
[<ffffffff81305b7f>] ? rtnetlink_rcv+0x1f/0x30
[<ffffffff81314fe5>] ? netlink_unicast+0x2a5/0x2f0
[<ffffffff8131592c>] ? netlink_sendmsg+0x1fc/0x300
[<ffffffff812e559e>] ? sock_sendmsg+0xfe/0x110
[<ffffffff8110e3a9>] ? dquot_file_open+0x19/0x60
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff8108d709>] ? file_read_actor+0x179/0x1b0
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff812e7946>] ? move_addr_to_kernel+0x46/0x70
[<ffffffff812f185a>] ? verify_iovec+0x6a/0xc0
[<ffffffff812e58bb>] ? sys_sendmsg+0x23b/0x380
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035c8f>] ? add_preempt_count+0x5f/0xb0
[<ffffffff81043c7e>] ? local_bh_disable+0xe/0x20
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff810d1d2f>] ? d_kill+0x5f/0x80
[<ffffffff8107a9d8>] ? audit_syscall_entry+0x1b8/0x1e0
[<ffffffff810023eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace 286af05228c1bc84 ]---
fib6_clean_node: del failed: rt=ffff88012ae4b200@620aa8c000000000 err=-2
fib6_clean_node: del failed: rt=ffff8800250edd00@(null) err=-2
fib6_clean_node: del failed: rt=ffff88012d877840@(null) err=-2
------------[ cut here ]------------
WARNING: at net/ipv6/ip6_fib.c:1172 fib6_del+0x4f6/0x5a0()
Hardware name:
Modules linked in: sit tunnel4 nls_utf8 isofs vfat fat usb_storage
vboxnetadp vboxnetflt vboxdrv radeon ttm drm_kms_helper drm fb fbdev
i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect rfcomm sco bridge stp llc
bnep l2cap nfsd nfs_acl auth_rpcgss exportfs eeprom it87 hwmon_vid lockd
sunrpc powernow_k8 mperf ipt_REJECT iptable_filter ipt_MASQUERADE
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
nf_conntrack_netbios_ns ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables x_tables binfmt_misc dm_mirror
dm_region_hash dm_log ppdev snd_hda_codec_atihdmi snd_hda_codec_realtek
pwc snd_seq snd_seq_device videodev parport_pc snd_hda_intel
snd_hda_codec k10temp snd_pcm ohci1394 snd_timer btusb ieee1394 snd
v4l1_compat v4l2_compat_ioctl32 i2c_piix4 usblp evdev sg parport
bluetooth button snd_page_alloc sr_mod cdrom ide_pci_generic atiixp
pata_atiixp ehci_hcd ohci_hcd sata_sil24 floppy [last unloaded:
scsi_wait_scan]
Pid: 19678, comm: ip Tainted: G W 2.6.35.7 #10
Call Trace:
[<ffffffff8103e02b>] ? warn_slowpath_common+0x7b/0xc0
[<ffffffff8137b7b6>] ? fib6_del+0x4f6/0x5a0
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff8137a9c0>] ? fib6_prune_clone+0x0/0x20
[<ffffffff8137b8bc>] ? fib6_clean_node+0x5c/0xc0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137acd6>] ? fib6_walk_continue+0x156/0x170
[<ffffffff8137ad41>] ? fib6_walk+0x51/0xb0
[<ffffffff813a8533>] ? _raw_write_lock_bh+0x13/0x30
[<ffffffff8137b177>] ? fib6_clean_all+0x97/0xe0
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137a8e6>] ? rt6_ifdown+0x26/0xc0
[<ffffffff81373b88>] ? addrconf_ifdown+0x48/0x4e0
[<ffffffff813741f6>] ? inet6_addr_del+0x106/0x130
[<ffffffff81305b90>] ? rtnetlink_rcv_msg+0x0/0x270
[<ffffffff81374285>] ? inet6_rtm_deladdr+0x65/0x70
[<ffffffff813153e9>] ? netlink_rcv_skb+0x89/0xb0
[<ffffffff81305b7f>] ? rtnetlink_rcv+0x1f/0x30
[<ffffffff81314fe5>] ? netlink_unicast+0x2a5/0x2f0
[<ffffffff8131592c>] ? netlink_sendmsg+0x1fc/0x300
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff812e559e>] ? sock_sendmsg+0xfe/0x110
[<ffffffff810a3f2a>] ? __do_fault+0x40a/0x520
[<ffffffff812e6cc8>] ? move_addr_to_user+0x88/0xa0
[<ffffffff812e6e2d>] ? __sys_recvmsg+0x14d/0x290
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff812e5622>] ? sockfd_lookup_light+0x22/0x80
[<ffffffff812e7a8d>] ? sys_sendto+0x11d/0x180
[<ffffffff810ab0ca>] ? vma_link+0xaa/0x110
[<ffffffff810ac5bd>] ? do_brk+0x2fd/0x330
[<ffffffff8107a9d8>] ? audit_syscall_entry+0x1b8/0x1e0
[<ffffffff810023eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace 286af05228c1bc85 ]---
fib6_clean_node: del failed: rt=ffff880028faa340@ffff8800250a6e40 err=-2
------------[ cut here ]------------
WARNING: at net/ipv6/ip6_fib.c:1172 fib6_del+0x4f6/0x5a0()
Hardware name:
Modules linked in: sit tunnel4 nls_utf8 isofs vfat fat usb_storage
vboxnetadp vboxnetflt vboxdrv radeon ttm drm_kms_helper drm fb fbdev
i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect rfcomm sco bridge stp llc
bnep l2cap nfsd nfs_acl auth_rpcgss exportfs eeprom it87 hwmon_vid lockd
sunrpc powernow_k8 mperf ipt_REJECT iptable_filter ipt_MASQUERADE
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
nf_conntrack_netbios_ns ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables x_tables binfmt_misc dm_mirror
dm_region_hash dm_log ppdev snd_hda_codec_atihdmi snd_hda_codec_realtek
pwc snd_seq snd_seq_device videodev parport_pc snd_hda_intel
snd_hda_codec k10temp snd_pcm ohci1394 snd_timer btusb ieee1394 snd
v4l1_compat v4l2_compat_ioctl32 i2c_piix4 usblp evdev sg parport
bluetooth button snd_page_alloc sr_mod cdrom ide_pci_generic atiixp
pata_atiixp ehci_hcd ohci_hcd sata_sil24 floppy [last unloaded:
scsi_wait_scan]
Pid: 19678, comm: ip Tainted: G W 2.6.35.7 #10
Call Trace:
[<ffffffff8103e02b>] ? warn_slowpath_common+0x7b/0xc0
[<ffffffff8137b7b6>] ? fib6_del+0x4f6/0x5a0
[<ffffffff813a5a16>] ? printk+0x40/0x4a
[<ffffffff8137b8bc>] ? fib6_clean_node+0x5c/0xc0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137acd6>] ? fib6_walk_continue+0x156/0x170
[<ffffffff8137ad41>] ? fib6_walk+0x51/0xb0
[<ffffffff813a8533>] ? _raw_write_lock_bh+0x13/0x30
[<ffffffff8137b177>] ? fib6_clean_all+0x97/0xe0
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137a8e6>] ? rt6_ifdown+0x26/0xc0
[<ffffffff81373b88>] ? addrconf_ifdown+0x48/0x4e0
[<ffffffff813741f6>] ? inet6_addr_del+0x106/0x130
[<ffffffff81305b90>] ? rtnetlink_rcv_msg+0x0/0x270
[<ffffffff81374285>] ? inet6_rtm_deladdr+0x65/0x70
[<ffffffff813153e9>] ? netlink_rcv_skb+0x89/0xb0
[<ffffffff81305b7f>] ? rtnetlink_rcv+0x1f/0x30
[<ffffffff81314fe5>] ? netlink_unicast+0x2a5/0x2f0
[<ffffffff8131592c>] ? netlink_sendmsg+0x1fc/0x300
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff812e559e>] ? sock_sendmsg+0xfe/0x110
[<ffffffff810a3f2a>] ? __do_fault+0x40a/0x520
[<ffffffff812e6cc8>] ? move_addr_to_user+0x88/0xa0
[<ffffffff812e6e2d>] ? __sys_recvmsg+0x14d/0x290
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff812e5622>] ? sockfd_lookup_light+0x22/0x80
[<ffffffff812e7a8d>] ? sys_sendto+0x11d/0x180
[<ffffffff810ab0ca>] ? vma_link+0xaa/0x110
[<ffffffff810ac5bd>] ? do_brk+0x2fd/0x330
[<ffffffff8107a9d8>] ? audit_syscall_entry+0x1b8/0x1e0
[<ffffffff810023eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace 286af05228c1bc86 ]---
fib6_clean_node: del failed: rt=ffff8800ce662cc0@0100007f00000000 err=-2
------------[ cut here ]------------
WARNING: at net/ipv6/ip6_fib.c:1172 fib6_del+0x4f6/0x5a0()
Hardware name:
Modules linked in: sit tunnel4 nls_utf8 isofs vfat fat usb_storage
vboxnetadp vboxnetflt vboxdrv radeon ttm drm_kms_helper drm fb fbdev
i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect rfcomm sco bridge stp llc
bnep l2cap nfsd nfs_acl auth_rpcgss exportfs eeprom it87 hwmon_vid lockd
sunrpc powernow_k8 mperf ipt_REJECT iptable_filter ipt_MASQUERADE
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
nf_conntrack_netbios_ns ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables x_tables binfmt_misc dm_mirror
dm_region_hash dm_log ppdev snd_hda_codec_atihdmi snd_hda_codec_realtek
pwc snd_seq snd_seq_device videodev parport_pc snd_hda_intel
snd_hda_codec k10temp snd_pcm ohci1394 snd_timer btusb ieee1394 snd
v4l1_compat v4l2_compat_ioctl32 i2c_piix4 usblp evdev sg parport
bluetooth button snd_page_alloc sr_mod cdrom ide_pci_generic atiixp
pata_atiixp ehci_hcd ohci_hcd sata_sil24 floppy [last unloaded:
scsi_wait_scan]
Pid: 19679, comm: ip Tainted: G W 2.6.35.7 #10
Call Trace:
[<ffffffff8103e02b>] ? warn_slowpath_common+0x7b/0xc0
[<ffffffff8137b7b6>] ? fib6_del+0x4f6/0x5a0
[<ffffffff810386af>] ? load_balance+0xbf/0x6b0
[<ffffffff8103201f>] ? dequeue_task_fair+0x4f/0x1c0
[<ffffffff8137b8bc>] ? fib6_clean_node+0x5c/0xc0
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137acd6>] ? fib6_walk_continue+0x156/0x170
[<ffffffff8137ad41>] ? fib6_walk+0x51/0xb0
[<ffffffff813a8533>] ? _raw_write_lock_bh+0x13/0x30
[<ffffffff8137b177>] ? fib6_clean_all+0x97/0xe0
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137a8e6>] ? rt6_ifdown+0x26/0xc0
[<ffffffff81373b88>] ? addrconf_ifdown+0x48/0x4e0
[<ffffffff81043cdd>] ? local_bh_enable_ip+0x4d/0xb0
[<ffffffff81374405>] ? addrconf_notify+0xe5/0x910
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff8137a9e0>] ? fib6_age+0x0/0x80
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff8105acf6>] ? notifier_call_chain+0x46/0x70
[<ffffffff812f91d5>] ? __dev_notify_flags+0x65/0x90
[<ffffffff812f923b>] ? dev_change_flags+0x3b/0x70
[<ffffffff81304f09>] ? do_setlink+0x189/0x740
[<ffffffff811c1da0>] ? nla_parse+0x30/0x100
[<ffffffff813061e9>] ? rtnl_newlink+0x3e9/0x4f0
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff813a84b2>] ? _raw_spin_unlock_irqrestore+0x12/0x40
[<ffffffff812f28ba>] ? __skb_recv_datagram+0xca/0x280
[<ffffffff81305c15>] ? rtnetlink_rcv_msg+0x85/0x270
[<ffffffff81305b90>] ? rtnetlink_rcv_msg+0x0/0x270
[<ffffffff813153e9>] ? netlink_rcv_skb+0x89/0xb0
[<ffffffff81305b7f>] ? rtnetlink_rcv+0x1f/0x30
[<ffffffff81314fe5>] ? netlink_unicast+0x2a5/0x2f0
[<ffffffff8131592c>] ? netlink_sendmsg+0x1fc/0x300
[<ffffffff812e559e>] ? sock_sendmsg+0xfe/0x110
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff8108e18d>] ? find_get_page+0x6d/0xd0
[<ffffffff8108eb19>] ? filemap_fault+0x99/0x400
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff810a3f2a>] ? __do_fault+0x40a/0x520
[<ffffffff812e7946>] ? move_addr_to_kernel+0x46/0x70
[<ffffffff812f185a>] ? verify_iovec+0x6a/0xc0
[<ffffffff812e58bb>] ? sys_sendmsg+0x23b/0x380
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff81026829>] ? do_page_fault+0x199/0x3b0
[<ffffffff810ab0ca>] ? vma_link+0xaa/0x110
[<ffffffff810ac5bd>] ? do_brk+0x2fd/0x330
[<ffffffff8107a9d8>] ? audit_syscall_entry+0x1b8/0x1e0
[<ffffffff810023eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace 286af05228c1bc87 ]---
fib6_clean_node: del failed: rt=ffff880028faa340@ffff8800250a6e40 err=-2
------------[ cut here ]------------
WARNING: at net/ipv6/ip6_fib.c:1172 fib6_del+0x4f6/0x5a0()
Hardware name:
Modules linked in: sit tunnel4 nls_utf8 isofs vfat fat usb_storage
vboxnetadp vboxnetflt vboxdrv radeon ttm drm_kms_helper drm fb fbdev
i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect rfcomm sco bridge stp llc
bnep l2cap nfsd nfs_acl auth_rpcgss exportfs eeprom it87 hwmon_vid lockd
sunrpc powernow_k8 mperf ipt_REJECT iptable_filter ipt_MASQUERADE
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
nf_conntrack_netbios_ns ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables x_tables binfmt_misc dm_mirror
dm_region_hash dm_log ppdev snd_hda_codec_atihdmi snd_hda_codec_realtek
pwc snd_seq snd_seq_device videodev parport_pc snd_hda_intel
snd_hda_codec k10temp snd_pcm ohci1394 snd_timer btusb ieee1394 snd
v4l1_compat v4l2_compat_ioctl32 i2c_piix4 usblp evdev sg parport
bluetooth button snd_page_alloc sr_mod cdrom ide_pci_generic atiixp
pata_atiixp ehci_hcd ohci_hcd sata_sil24 floppy [last unloaded:
scsi_wait_scan]
Pid: 19679, comm: ip Tainted: G W 2.6.35.7 #10
Call Trace:
[<ffffffff8103e02b>] ? warn_slowpath_common+0x7b/0xc0
[<ffffffff8137b7b6>] ? fib6_del+0x4f6/0x5a0
[<ffffffff810386af>] ? load_balance+0xbf/0x6b0
[<ffffffff813a5a16>] ? printk+0x40/0x4a
[<ffffffff8137b8bc>] ? fib6_clean_node+0x5c/0xc0
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137acd6>] ? fib6_walk_continue+0x156/0x170
[<ffffffff8137ad41>] ? fib6_walk+0x51/0xb0
[<ffffffff813a8533>] ? _raw_write_lock_bh+0x13/0x30
[<ffffffff8137b177>] ? fib6_clean_all+0x97/0xe0
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff81377130>] ? fib6_ifdown+0x0/0x30
[<ffffffff8137a8e6>] ? rt6_ifdown+0x26/0xc0
[<ffffffff81373b88>] ? addrconf_ifdown+0x48/0x4e0
[<ffffffff81043cdd>] ? local_bh_enable_ip+0x4d/0xb0
[<ffffffff81374405>] ? addrconf_notify+0xe5/0x910
[<ffffffff8137b860>] ? fib6_clean_node+0x0/0xc0
[<ffffffff8137a9e0>] ? fib6_age+0x0/0x80
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff8105acf6>] ? notifier_call_chain+0x46/0x70
[<ffffffff812f91d5>] ? __dev_notify_flags+0x65/0x90
[<ffffffff812f923b>] ? dev_change_flags+0x3b/0x70
[<ffffffff81304f09>] ? do_setlink+0x189/0x740
[<ffffffff811c1da0>] ? nla_parse+0x30/0x100
[<ffffffff813061e9>] ? rtnl_newlink+0x3e9/0x4f0
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff813a84b2>] ? _raw_spin_unlock_irqrestore+0x12/0x40
[<ffffffff812f28ba>] ? __skb_recv_datagram+0xca/0x280
[<ffffffff81305c15>] ? rtnetlink_rcv_msg+0x85/0x270
[<ffffffff81305b90>] ? rtnetlink_rcv_msg+0x0/0x270
[<ffffffff813153e9>] ? netlink_rcv_skb+0x89/0xb0
[<ffffffff81305b7f>] ? rtnetlink_rcv+0x1f/0x30
[<ffffffff81314fe5>] ? netlink_unicast+0x2a5/0x2f0
[<ffffffff8131592c>] ? netlink_sendmsg+0x1fc/0x300
[<ffffffff812e559e>] ? sock_sendmsg+0xfe/0x110
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff8108e18d>] ? find_get_page+0x6d/0xd0
[<ffffffff8108eb19>] ? filemap_fault+0x99/0x400
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff810a3f2a>] ? __do_fault+0x40a/0x520
[<ffffffff812e7946>] ? move_addr_to_kernel+0x46/0x70
[<ffffffff812f185a>] ? verify_iovec+0x6a/0xc0
[<ffffffff812e58bb>] ? sys_sendmsg+0x23b/0x380
[<ffffffff81034349>] ? get_parent_ip+0x9/0x20
[<ffffffff81035bff>] ? sub_preempt_count+0x7f/0xb0
[<ffffffff81026829>] ? do_page_fault+0x199/0x3b0
[<ffffffff810ab0ca>] ? vma_link+0xaa/0x110
[<ffffffff810ac5bd>] ? do_brk+0x2fd/0x330
[<ffffffff8107a9d8>] ? audit_syscall_entry+0x1b8/0x1e0
[<ffffffff810023eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace 286af05228c1bc88 ]---
fib6_clean_node: del failed: rt=ffff8800ce662cc0@0100007f00000000 err=-2
fib6_clean_node: del failed: rt=ffff880028faad40@(null) err=-2
lo: Disabled Privacy Extensions
r8169 0000:03:00.0: eth0: link up
usb0: no IPv6 routers present
fib6_clean_node: del failed: rt=ffff880028faa5c0@(null) err=-2
fib6_clean_node: del failed: rt=ffff880028faa5c0@(null) err=-2
fib6_clean_node: del failed: rt=ffff880028faa5c0@(null) err=-2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
^ permalink raw reply
* Re: [PATCH net-2.6 v2 1/3] vlan: Add function to retrieve EtherType from vlan packets.
From: David Miller @ 2010-11-12 20:24 UTC (permalink / raw)
To: jesse; +Cc: netdev, hzheng
In-Reply-To: <1289519279-20641-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Thu, 11 Nov 2010 15:47:57 -0800
> From: Hao Zheng <hzheng@nicira.com>
>
> Depending on how a packet is vlan tagged (i.e. hardware accelerated or
> not), the encapsulated protocol is stored in different locations. This
> provides a consistent method of accessing that protocol, which is needed
> by drivers, security checks, etc.
>
> Signed-off-by: Hao Zheng <hzheng@nicira.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 v2 2/3] bnx2x: Look inside vlan when determining checksum proto.
From: David Miller @ 2010-11-12 20:24 UTC (permalink / raw)
To: jesse; +Cc: netdev, hzheng, eilong
In-Reply-To: <1289519279-20641-2-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Thu, 11 Nov 2010 15:47:58 -0800
> From: Hao Zheng <hzheng@nicira.com>
>
> Currently the skb->protocol field is used to setup checksum
> offloading on transmit for the correct protocol. However, if
> vlan offloading is disabled or otherwise not used, the protocol
> field will be ETH_P_8021Q, not the actual protocol. This will
> cause the checksum to be not computed correctly, even though the
> hardware is capable of looking inside vlan tags. Instead,
> look inside the header if necessary to determine the correct
> protocol type.
>
> To some extent this fixes a regression from 2.6.36 because it
> was previously not possible to disable vlan offloading and this
> error case was not exposed.
>
> Signed-off-by: Hao Zheng <hzheng@nicira.com>
> CC: Eilon Greenstein <eilong@broadcom.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 v2 3/3] ixgbe: Look inside vlan when determining offload protocol.
From: David Miller @ 2010-11-12 20:24 UTC (permalink / raw)
To: jesse
Cc: netdev, hzheng, jeffrey.t.kirsher, alexander.h.duyck,
jesse.brandeburg
In-Reply-To: <1289519279-20641-3-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Thu, 11 Nov 2010 15:47:59 -0800
> From: Hao Zheng <hzheng@nicira.com>
>
> Currently the skb->protocol field is used to setup various
> offloading parameters on transmit for the correct protocol.
> However, if vlan offloading is disabled or otherwise not used,
> the protocol field will be ETH_P_8021Q, not the actual protocol.
> This will cause the offloading to be not performed correctly,
> even though the hardware is capable of looking inside vlan tags.
> Instead, look inside the header if necessary to determine the
> correct protocol type.
>
> To some extent this fixes a regression from 2.6.36 because it
> was previously not possible to disable vlan offloading and this
> error case was not exposed.
>
> Signed-off-by: Hao Zheng <hzheng@nicira.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: Alex Duyck <alexander.h.duyck@intel.com>
> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] ucc_geth: Do not bring the whole IF down when TX failure.
From: David Miller @ 2010-11-12 20:24 UTC (permalink / raw)
To: cbouatmailru; +Cc: Joakim.Tjernlund, linuxppc-dev, netdev
In-Reply-To: <20101112140515.GA28223@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <cbouatmailru@gmail.com>
Date: Fri, 12 Nov 2010 17:05:15 +0300
> On Fri, Nov 12, 2010 at 02:55:08PM +0100, Joakim Tjernlund wrote:
>> ucc_geth_close lacks a cancel_work_sync(&ugeth->timeout_work)
>> to stop any outstanding processing of TX fail. However, one
>> can not call cancel_work_sync without fixing the timeout function
>> otherwise it will deadlock. This patch brings ucc_geth in line with
>> gianfar:
>>
>> Don't bring the interface down and up, just reinit controller HW
>> and PHY.
>>
>> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> Looks sane, thanks!
>
> Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] ucc_geth: Fix deadlock
From: David Miller @ 2010-11-12 20:25 UTC (permalink / raw)
To: cbouatmailru; +Cc: Joakim.Tjernlund, linuxppc-dev, netdev
In-Reply-To: <20101112140947.GB28223@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <cbouatmailru@gmail.com>
Date: Fri, 12 Nov 2010 17:09:47 +0300
> On Fri, Nov 12, 2010 at 02:55:09PM +0100, Joakim Tjernlund wrote:
>> This script:
>> while [ 1==1 ] ; do ifconfig eth0 up; usleep 1950000 ;ifconfig eth0 down; dmesg -c ;done
>> causes in just a second or two:
>> INFO: task ifconfig:572 blocked for more than 120 seconds.
> [...]
>> The reason appears to be ucc_geth_stop meets adjust_link as the
>> PHY reports PHY changes. I belive adjust_link hangs somewhere,
>> holding the PHY lock, because ucc_geth_stop disabled the
>> controller HW.
>> Fix is to stop the PHY before disabling the controller.
>>
>> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> It's unclear where exactly adjust_link() hangs, but the patch
> looks as the right thing overall.
>
> Thanks!
>
> Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-26 0/6] cxgb4vf: a number of bug fixes
From: David Miller @ 2010-11-12 20:27 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <1289502413-9895-1-git-send-email-leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Thu, 11 Nov 2010 11:06:47 -0800
> The following patch set includes a number of bug fixes for the cxgb4vf
> network driver. As always, please toss these in the bin if they're not
> right.
All 6 patches applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH v2] Prevent crashing when parsing bad X.25 facilities
From: David Miller @ 2010-11-12 20:29 UTC (permalink / raw)
To: drosenberg; +Cc: andrew.hendry, netdev
In-Reply-To: <1289570877.3090.274.camel@Dan>
From: Dan Rosenberg <drosenberg@vsecurity.com>
Date: Fri, 12 Nov 2010 09:07:57 -0500
> @@ -149,9 +157,8 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
> break;
> default:
> printk(KERN_DEBUG "X.25: unknown facility %02X,"
> - "length %d, values %02X, %02X, "
> - "%02X, %02X\n",
> - p[0], p[1], p[2], p[3], p[4], p[5]);
> + "length %d\n"
> + p[0], p[1]);
> break;
Thanks for not even compile testing your changes:
net/x25/x25_facilities.c: In function 'x25_parse_facilities':
net/x25/x25_facilities.c:161:6: error: expected ')' before 'p'
net/x25/x25_facilities.c:161:6: warning: too few arguments for format
I find this kind of carelessness extremely amusing coming from someone
who is so big on security theatre.
^ permalink raw reply
* Re: [PATCH 4/10] Fix leaking of kernel heap addresses in net/
From: David Miller @ 2010-11-12 20:37 UTC (permalink / raw)
To: adobriyan; +Cc: shemminger, netdev
In-Reply-To: <20101112201850.GA5625@core2.telecom.by>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Fri, 12 Nov 2010 22:18:50 +0200
> On Fri, Nov 12, 2010 at 08:33:15AM -0800, Stephen Hemminger wrote:
>> Also, the whole idea needs to be under a config option, so only
>> the paranoid idiots turn it on.
>
> Would be fun if something will break because ffff8800bcd498c0
> will become something else. :-)
Actually, this is not even a joke.
Take a look at how we track what sockets a user wants dumped via
the inet_diag netlink facility, the socket pointer is used as
the identification cookie.
I'm sure we'll now get some more security theatre about how we
have to undo that too.
More and more I see this whole idea as extremely rediculious.
If I can write to or read kernel memory, I can look up the
sockets, inodes, and whatever else we're currently exposing
the addresses of. Even without a symbol table, which is
readily available, I can easily find the ksymtab and find the
inode and socket hash table addresses there.
This whole exercise is closing the barn door after the horses have
already escaped, and it's causing all kinds of inconveniences
that we really have no need for.
^ permalink raw reply
* enic build warnings
From: David Miller @ 2010-11-12 20:40 UTC (permalink / raw)
To: vkolluri; +Cc: roprabhu, dwang2, netdev
Please fix these warnings, you cannot pass the address of
a "u64" object where a "dma_addr_t" is expected:
drivers/net/enic/enic_main.c: In function 'enic_set_rsskey':
drivers/net/enic/enic_main.c:2056:16: warning: passing argument 3 of 'pci_alloc_consistent' from incompatible pointer type
include/asm-generic/pci-dma-compat.h:16:1: note: expected 'dma_addr_t *' but argument is of type 'u64 *'
drivers/net/enic/enic_main.c: In function 'enic_set_rsscpu':
drivers/net/enic/enic_main.c:2082:16: warning: passing argument 3 of 'pci_alloc_consistent' from incompatible pointer type
include/asm-generic/pci-dma-compat.h:16:1: note: expected 'dma_addr_t *' but argument is of type 'u64 *'
Thanks.
^ permalink raw reply
* [PATCH v3] Prevent crashing when parsing bad X.25 facilities
From: Dan Rosenberg @ 2010-11-12 20:42 UTC (permalink / raw)
To: andrew.hendry; +Cc: netdev
Now with improved comma support.
On parsing malformed X.25 facilities, decrementing the remaining length
may cause it to underflow. Since the length is an unsigned integer,
this will result in the loop continuing until the kernel crashes.
This patch adds checks to ensure decrementing the remaining length does
not cause it to wrap around.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
---
net/x25/x25_facilities.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/x25/x25_facilities.c b/net/x25/x25_facilities.c
index 3a8c4c4..55187c8 100644
--- a/net/x25/x25_facilities.c
+++ b/net/x25/x25_facilities.c
@@ -61,6 +61,8 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
while (len > 0) {
switch (*p & X25_FAC_CLASS_MASK) {
case X25_FAC_CLASS_A:
+ if (len < 2)
+ return 0;
switch (*p) {
case X25_FAC_REVERSE:
if((p[1] & 0x81) == 0x81) {
@@ -104,6 +106,8 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
len -= 2;
break;
case X25_FAC_CLASS_B:
+ if (len < 3)
+ return 0;
switch (*p) {
case X25_FAC_PACKET_SIZE:
facilities->pacsize_in = p[1];
@@ -125,6 +129,8 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
len -= 3;
break;
case X25_FAC_CLASS_C:
+ if (len < 4)
+ return 0;
printk(KERN_DEBUG "X.25: unknown facility %02X, "
"values %02X, %02X, %02X\n",
p[0], p[1], p[2], p[3]);
@@ -132,6 +138,8 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
len -= 4;
break;
case X25_FAC_CLASS_D:
+ if (len < p[1] + 2)
+ return 0;
switch (*p) {
case X25_FAC_CALLING_AE:
if (p[1] > X25_MAX_DTE_FACIL_LEN || p[1] <= 1)
@@ -149,9 +157,7 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
break;
default:
printk(KERN_DEBUG "X.25: unknown facility %02X,"
- "length %d, values %02X, %02X, "
- "%02X, %02X\n",
- p[0], p[1], p[2], p[3], p[4], p[5]);
+ "length %d\n", p[0], p[1]);
break;
}
len -= p[1] + 2;
^ permalink raw reply related
* Re: [net-next] stmmac: update the driver documentation
From: David Miller @ 2010-11-12 20:43 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1289561852-22833-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 12 Nov 2010 12:37:32 +0100
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] r8169: fix checksum broken
From: David Miller @ 2010-11-12 20:44 UTC (permalink / raw)
To: shanwei; +Cc: romieu, netdev
In-Reply-To: <4CDD13BD.7060109@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Fri, 12 Nov 2010 18:15:25 +0800
> If r8196 received packets with invalid sctp/igmp(not tcp, udp) checksum, r8196 set skb->ip_summed
> wit CHECKSUM_UNNECESSARY. This cause that upper protocol don't check checksum field.
>
> I am not family with r8196 driver. I try to guess the meaning of RxProtoIP and IPFail.
> RxProtoIP stands for received IPv4 packet that upper protocol is not tcp and udp.
> !(opts1 & IPFail) is true means that driver correctly to check checksum in IPv4 header.
>
> If it's right, I think we should not set ip_summed wit CHECKSUM_UNNECESSARY for my sctp packets
> with invalid checksum.
>
> If it's not right, please tell me.
>
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Francois, please review, it looks correct to my eyes.
^ permalink raw reply
* Re: [PATCH v2] Prevent crashing when parsing bad X.25 facilities
From: Dan Rosenberg @ 2010-11-12 20:44 UTC (permalink / raw)
To: David Miller; +Cc: andrew.hendry, netdev
In-Reply-To: <20101112.122946.102556009.davem@davemloft.net>
> I find this kind of carelessness extremely amusing coming from someone
> who is so big on security theatre.
You know what I find amusing? The sheer number of security issues a
single person can find in his spare time. Congratulations on your
attention to detail.
-Dan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox