* 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
* Re: [PATCH v3] Prevent crashing when parsing bad X.25 facilities
From: David Miller @ 2010-11-12 20:45 UTC (permalink / raw)
To: drosenberg; +Cc: andrew.hendry, netdev
In-Reply-To: <1289594548.3090.334.camel@Dan>
From: Dan Rosenberg <drosenberg@vsecurity.com>
Date: Fri, 12 Nov 2010 15:42:28 -0500
> 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>
Applied.
^ permalink raw reply
* Re: [PATCH v2] Prevent crashing when parsing bad X.25 facilities
From: David Miller @ 2010-11-12 20:50 UTC (permalink / raw)
To: drosenberg; +Cc: andrew.hendry, netdev
In-Reply-To: <1289594665.3090.336.camel@Dan>
From: Dan Rosenberg <drosenberg@vsecurity.com>
Date: Fri, 12 Nov 2010 15:44:25 -0500
>
>> 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.
I do not even agree that, for example, pointer exposure is a real
issue. It still remains a matter of opinion.
And much of your claims and boasting is based upon that opinion.
So don't pass it off saliently or indirectly as fact.
^ permalink raw reply
* Re: [net-2.6 PATCH] nete zero kobject in rx_queue_release
From: David Miller @ 2010-11-12 21:08 UTC (permalink / raw)
To: john.r.fastabend; +Cc: netdev, eric.dumazet, therbert
In-Reply-To: <20101111201341.4418.16400.stgit@jf-dev1-dcblab>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Thu, 11 Nov 2010 12:13:41 -0800
> netif_set_real_num_rx_queues() can decrement and increment
> the number of rx queues. For example ixgbe does this as
> features and offloads are toggled. Presumably this could
> also happen across down/up on most devices if the available
> resources changed (cpu offlined).
>
> The kobject needs to be zero'd in this case so that the
> state is not preserved across kobject_put()/kobject_init_and_add().
>
> This resolves the following error report.
...
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
I think it's probably better to clear the entire netdev_rx_queue
object rather than just the embedded kobject.
Otherwise we leave dangling rps_map, rps_flow_table, etc. pointers.
In fact, it's more tricky than this, because notice that your
patch will memset() free'd memory in the case where the
first->count drops to zero and we execute the kfree().
So we'll need something like:
if (atomic_dec_and_test(&first->count))
kfree(first);
else
/* clear everything except queue->first */
or, alternatively:
--------------------
map = rcu_dereference_raw(queue->rps_map);
if (map) {
call_rcu(&map->rcu, rps_map_release);
rcu_assign_pointer(queue->rps_map, NULL);
}
flow_table = rcu_dereference_raw(queue->rps_flow_table);
if (flow_table) {
call_rcu(&flow_table->rcu, rps_dev_flow_table_release);
rcu_assign_pointer(queue->rps_flow_table, NULL);
}
if (atomic_dec_and_test(&first->count))
kfree(first);
else
memset(kobj);
--------------------
Something like that.
^ permalink raw reply
* Re: [RFC PATCH] network: return errors if we know tcp_connect failed
From: David Lamparter @ 2010-11-12 21:16 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Lamparter, Eric Dumazet, Eric Paris, Hua Zhong, netdev,
linux-kernel, davem, kuznet, pekkas, jmorris, yoshfuji,
paul.moore
In-Reply-To: <4CDD7145.8070606@trash.net>
On Fri, Nov 12, 2010 at 05:54:29PM +0100, Patrick McHardy wrote:
> Am 12.11.2010 17:35, schrieb David Lamparter:
> > On Fri, Nov 12, 2010 at 05:15:32PM +0100, Eric Dumazet wrote:
> >> Le vendredi 12 novembre 2010 à 11:08 -0500, Eric Paris a écrit :
> >>
> >>> 2) What should the generic TCP code (tcp_connect()) do if the skb failed
> >>> to send. Should it return error codes back up the stack somehow or
> >>> should they continue to be ignored? Obviously continuing to just ignore
> >>> information we have doesn't make me happy (otherwise I wouldn't have
> >>> started scratching this itch). But the point about ENOBUFS is well
> >>> taken. Maybe I should make tcp_connect(), or the caller to
> >>> tcp_connect() more intelligent about specific error codes?
> >>>
> >>> I'm looking for a path forward. If SELinux is rejecting the SYN packets
> >>> on connect() I want to pass that info to userspace rather than just
> >>> hanging. What's the best way to accomplish that?
> >>>
> >>
> >> Eric, if you can differentiate a permanent reject, instead of a
> >> temporary one (congestion, or rate limiting, or ENOBUF, or ...), then
> >> yes, you could make tcp_connect() report to user the permanent error,
> >> and ignore the temporary one.
>
> Indeed. We could even make the NF_DROP return value configurable
> by encoding it in the verdict.
> There is no NF_REJECT.
Ah, sorry, not at home in netfilter, coming from an user perspective here.
> Returning NF_DROP results in -EPERM getting reported back. As Eric
> noticed, this is ignored for SYN packets.
Hrm. But how do you silently drop packets? This seems counterintuitive
or even buggy to me; or at least the netfilter DROP target shouldn't use
this kind of error-reporting drop.
As food for thought I'd like to pose the following rule:
iptables -A OUTPUT -m statistic --mode nth --every 5 -j DROP
which should, to my understanding, still allow the connect to complete,
even if the first SYN got (silently!...) dropped.
Also, i'm *very* sure i was able to trigger a "permission denied" from
either firewall or route rules; weirdly enough i can't get that on my
2.6.35.7 router... (poking older boxes to reproduce it right now)
Just for reference some test results: (heavily cropped)
TL;DR: only tcp-reset and route prohibit work immediately.
+ telnet 74.125.43.105 80
Connected to 74.125.43.105.
+ iptables -I OUTPUT -p tcp -d 74.125.43.105 --dport 80 -j REJECT
# default w/o reject-with is icmp-port-unreachable
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: Connection refused
real 0m3.014s
+ iptables -I OUTPUT -p tcp -d 74.125.43.105 --dport 80 -j REJECT --reject-with tcp-reset
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: Connection refused
real 0m0.007s
+ iptables -I OUTPUT -p tcp -d 74.125.43.105 --dport 80 -j REJECT --reject-with host-prohib
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: No route to host
real 0m3.010s
+ iptables -I OUTPUT -p tcp -d 74.125.43.105 --dport 80 -j REJECT --reject-with admin-prohib
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: No route to host
real 0m3.009s
+ iptables -I OUTPUT -p tcp -d 74.125.43.105 --dport 80 -j REJECT --reject-with net-prohib
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: Network is unreachable
real 0m3.011s
+ iptables -F OUTPUT
+ ip route add prohibit 74.125.43.105
+ ip route flush cache
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: Network is unreachable
real 0m0.007s
-David
^ permalink raw reply
* Re: [RFC PATCH] network: return errors if we know tcp_connect failed
From: David Miller @ 2010-11-12 21:18 UTC (permalink / raw)
To: equinox
Cc: kaber, eric.dumazet, eparis, hzhong, netdev, linux-kernel, kuznet,
pekkas, jmorris, yoshfuji, paul.moore
In-Reply-To: <20101112211627.GC122902@jupiter.n2.diac24.net>
From: David Lamparter <equinox@diac24.net>
Date: Fri, 12 Nov 2010 22:16:27 +0100
> As food for thought I'd like to pose the following rule:
> iptables -A OUTPUT -m statistic --mode nth --every 5 -j DROP
> which should, to my understanding, still allow the connect to complete,
> even if the first SYN got (silently!...) dropped.
Yes, I agree and this is pretty much the point I tried to make
earlier.
^ permalink raw reply
* Re: a problem tcp_v4_err()
From: Eric Dumazet @ 2010-11-12 21:18 UTC (permalink / raw)
To: David Miller
Cc: kuznet, kaber, equinox, eparis, hzhong, netdev, linux-kernel,
pekkas, jmorris, yoshfuji, paul.moore, damian
In-Reply-To: <20101112.112224.112610807.davem@davemloft.net>
Le vendredi 12 novembre 2010 à 11:22 -0800, David Miller a écrit :
> 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 */
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next-2.6 V2] igmp: RCU conversion of in_dev->mc_list
From: David Miller @ 2010-11-12 21:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiyou.wangcong, cypher.w, linux-kernel, netdev
In-Reply-To: <1289576810.3185.261.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 12 Nov 2010 16:46:50 +0100
> [PATCH net-next-2.6 V2] igmp: RCU conversion of in_dev->mc_list
>
> in_dev->mc_list is protected by one rwlock (in_dev->mc_list_lock).
>
> This can easily be converted to a RCU protection.
>
> Writers hold RTNL, so mc_list_lock is removed, not replaced by a
> spinlock.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
This looks good to me, so I've applied it to net-next-2.6
We have enough time there to fix any fallout or revert if
necessary.
^ permalink raw reply
* Re: [PATCH] net: Kconfig whitespace cleanup
From: David Miller @ 2010-11-12 21:21 UTC (permalink / raw)
To: phdm; +Cc: netdev
In-Reply-To: <1289514681-3940-1-git-send-email-phdm@macqel.be>
From: Philippe De Muyter <phdm@macqel.be>
Date: Thu, 11 Nov 2010 23:31:21 +0100
> Many lines in Kconfig start withe 8 spaces instead of a TAB, and even
> sometimes with 7 spaces. Replace 10 or 9 spaces, or TAB + 1 space,
> by TAB + 2 spaces, and 8 or 7 spaces by TAB.
>
> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox