summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* tcp: Fix recvmsg MSG_PEEK influence of blocking behavior.David S. Miller2008-11-051-2/+1
| | | | | | | | | | | Vito Caputo noticed that tcp_recvmsg() returns immediately from partial reads when MSG_PEEK is used. In particular, this means that SO_RCVLOWAT is not respected. Simply remove the test. And this matches the behavior of several other systems, including BSD. Signed-off-by: David S. Miller <davem@davemloft.net>
* netfilter: netns ct: walk netns list under RTNLAlexey Dobriyan2008-11-052-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | netns list (just list) is under RTNL. But helper and proto unregistration happen during rmmod when RTNL is not held, and that's how it was tested: modprobe/rmmod vs clone(CLONE_NEWNET)/exit. BUG: unable to handle kernel paging request at 0000000000100100 <=== IP: [<ffffffffa009890f>] nf_conntrack_l4proto_unregister+0x96/0xae [nf_conntrack] PGD 15e300067 PUD 15e1d8067 PMD 0 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file: /sys/kernel/uevent_seqnum CPU 0 Modules linked in: nf_conntrack_proto_sctp(-) nf_conntrack_proto_dccp(-) af_packet iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 sr_mod cdrom [last unloaded: nf_conntrack_proto_sctp] Pid: 16758, comm: rmmod Not tainted 2.6.28-rc2-netns-xfrm #3 RIP: 0010:[<ffffffffa009890f>] [<ffffffffa009890f>] nf_conntrack_l4proto_unregister+0x96/0xae [nf_conntrack] RSP: 0018:ffff88015dc1fec8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 00000000001000f8 RCX: 0000000000000000 RDX: ffffffffa009575c RSI: 0000000000000003 RDI: ffffffffa00956b5 RBP: ffff88015dc1fed8 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88015dc1fe48 R12: ffffffffa0458f60 R13: 0000000000000880 R14: 00007fff4c361d30 R15: 0000000000000880 FS: 00007f624435a6f0(0000) GS:ffffffff80521580(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000100100 CR3: 0000000168969000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process rmmod (pid: 16758, threadinfo ffff88015dc1e000, task ffff880179864218) Stack: ffffffffa0459100 0000000000000000 ffff88015dc1fee8 ffffffffa0457934 ffff88015dc1ff78 ffffffff80253fef 746e6e6f635f666e 6f72705f6b636172 00707463735f6f74 ffffffff8024cb30 00000000023b8010 0000000000000000 Call Trace: [<ffffffffa0457934>] nf_conntrack_proto_sctp_fini+0x10/0x1e [nf_conntrack_proto_sctp] [<ffffffff80253fef>] sys_delete_module+0x19f/0x1fe [<ffffffff8024cb30>] ? trace_hardirqs_on_caller+0xf0/0x114 [<ffffffff803ea9b2>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8020b52b>] system_call_fastpath+0x16/0x1b Code: 13 35 e0 e8 c4 6c 1a e0 48 8b 1d 6d c6 46 e0 eb 16 48 89 df 4c 89 e2 48 c7 c6 fc 85 09 a0 e8 61 cd ff ff 48 8b 5b 08 48 83 eb 08 <48> 8b 43 08 0f 18 08 48 8d 43 08 48 3d 60 4f 50 80 75 d3 5b 41 RIP [<ffffffffa009890f>] nf_conntrack_l4proto_unregister+0x96/0xae [nf_conntrack] RSP <ffff88015dc1fec8> CR2: 0000000000100100 ---[ end trace bde8ac82debf7192 ]--- Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* ipv6: fix run pending DAD when interface becomes readyBenjamin Thery2008-11-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With some net devices types, an IPv6 address configured while the interface was down can stay 'tentative' forever, even after the interface is set up. In some case, pending IPv6 DADs are not executed when the device becomes ready. I observed this while doing some tests with kvm. If I assign an IPv6 address to my interface eth0 (kvm driver rtl8139) when it is still down then the address is flagged tentative (IFA_F_TENTATIVE). Then, I set eth0 up, and to my surprise, the address stays 'tentative', no DAD is executed and the address can't be pinged. I also observed the same behaviour, without kvm, with virtual interfaces types macvlan and veth. Some easy steps to reproduce the issue with macvlan: 1. ip link add link eth0 type macvlan 2. ip -6 addr add 2003::ab32/64 dev macvlan0 3. ip addr show dev macvlan0 ... inet6 2003::ab32/64 scope global tentative ... 4. ip link set macvlan0 up 5. ip addr show dev macvlan0 ... inet6 2003::ab32/64 scope global tentative ... Address is still tentative I think there's a bug in net/ipv6/addrconf.c, addrconf_notify(): addrconf_dad_run() is not always run when the interface is flagged IF_READY. Currently it is only run when receiving NETDEV_CHANGE event. Looks like some (virtual) devices doesn't send this event when becoming up. For both NETDEV_UP and NETDEV_CHANGE events, when the interface becomes ready, run_pending should be set to 1. Patch below. 'run_pending = 1' could be moved below the if/else block but it makes the code less readable. Signed-off-by: Benjamin Thery <benjamin.thery@bull.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* net/9p: fix printk format warningsRandy Dunlap2008-11-051-11/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix printk format warnings in net/9p. Built cleanly on 7 arches. net/9p/client.c:820: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64' net/9p/client.c:820: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64' net/9p/client.c:867: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64' net/9p/client.c:867: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64' net/9p/client.c:932: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64' net/9p/client.c:932: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'u64' net/9p/client.c:982: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64' net/9p/client.c:982: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64' net/9p/client.c:1025: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64' net/9p/client.c:1025: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64' net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'u64' net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 12 has type 'u64' net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 8 has type 'u64' net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 13 has type 'u64' net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'u64' net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 12 has type 'u64' net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 8 has type 'u64' net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 13 has type 'u64' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: fix packet socket delivery in rx irq handlerPatrick McHardy2008-11-043-13/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The changes to deliver hardware accelerated VLAN packets to packet sockets (commit bc1d0411) caused a warning for non-NAPI drivers. The __vlan_hwaccel_rx() function is called directly from the drivers RX function, for non-NAPI drivers that means its still in RX IRQ context: [ 27.779463] ------------[ cut here ]------------ [ 27.779509] WARNING: at kernel/softirq.c:136 local_bh_enable+0x37/0x81() ... [ 27.782520] [<c0264755>] netif_nit_deliver+0x5b/0x75 [ 27.782590] [<c02bba83>] __vlan_hwaccel_rx+0x79/0x162 [ 27.782664] [<f8851c1d>] atl1_intr+0x9a9/0xa7c [atl1] [ 27.782738] [<c0155b17>] handle_IRQ_event+0x23/0x51 [ 27.782808] [<c015692e>] handle_edge_irq+0xc2/0x102 [ 27.782878] [<c0105fd5>] do_IRQ+0x4d/0x64 Split hardware accelerated VLAN reception into two parts to fix this: - __vlan_hwaccel_rx just stores the VLAN TCI and performs the VLAN device lookup, then calls netif_receive_skb()/netif_rx() - vlan_hwaccel_do_receive(), which is invoked by netif_receive_skb() in softirq context, performs the real reception and delivery to packet sockets. Reported-and-tested-by: Ramon Casellas <ramon.casellas@cttc.es> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* xfrm: Have af-specific init_tempsel() initialize family field of temporary ↵Andreas Steffen2008-11-042-0/+2
| | | | | | | | | | | | | | | | selector While adding MIGRATE support to strongSwan, Andreas Steffen noticed that the selectors provided in XFRM_MSG_ACQUIRE have their family field uninitialized (those in MIGRATE do have their family set). Looking at the code, this is because the af-specific init_tempsel() (called via afinfo->init_tempsel() in xfrm_init_tempsel()) do not set the value. Reported-by: Andreas Steffen <andreas.steffen@strongswan.org> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
* xfrm: Fix xfrm_policy_gc_lock handling.Alexey Dobriyan2008-11-031-2/+2
| | | | | | | | | | | | From: Alexey Dobriyan <adobriyan@gmail.com> Based upon a lockdep trace by Simon Arlott. xfrm_policy_kill() can be called from both BH and non-BH contexts, so we have to grab xfrm_policy_gc_lock with BH disabling. Signed-off-by: David S. Miller <davem@davemloft.net>
* niu: Use pci_ioremap_bar().David S. Miller2008-11-031-5/+1
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* bnx2x: Version UpdateEilon Greenstein2008-11-031-2/+2
| | | | | | | Updating the version Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnx2x: Calling netif_carrier_off at the end of the probeEilon Greenstein2008-11-031-2/+2
| | | | | | | | | netif_carrier_off was called too early at the probe. In case of failure or simply bad timing, this can cause a fatal error since linkwatch_event might run too soon. Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnx2x: PCI configuration bug on big-endianEilon Greenstein2008-11-031-4/+5
| | | | | | | | | | The current code read nothing but zeros on big-endian (wrong part of the 32bits). This caused poor performance on big-endian machines. Though this issue did not cause the system to crash, the performance is significantly better with the fix so I view it as critical bug fix. Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnx2x: Removing the PMF indication when unloadingEilon Greenstein2008-11-031-0/+2
| | | | | | | | | | When the PMF flag is set, the driver can access the HW freely. When the driver is unloaded, it should not access the HW. The problem caused fatal errors when "ethtool -i" was called after the calling instance was unloaded and another instance was already loaded Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* mv643xx_eth: fix SMI bus access timeoutsLennert Buytenhek2008-11-031-3/+6
| | | | | | | | | | | | | | | | | | | | The mv643xx_eth mii bus implementation uses wait_event_timeout() to wait for SMI completion interrupts. If wait_event_timeout() would return zero, mv643xx_eth would conclude that the SMI access timed out, but this is not necessarily true -- wait_event_timeout() can also return zero in the case where the SMI completion interrupt did happen in time but where it took longer than the requested timeout for the process performing the SMI access to be scheduled again. This would lead to occasional SMI access timeouts when the system would be under heavy load. The fix is to ignore the return value of wait_event_timeout(), and to re-check the SMI done bit after wait_event_timeout() returns to determine whether or not the SMI access timed out. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* net: kconfig cleanupJeff Kirsher2008-11-031-3/+15
| | | | | | | | The bool kconfig option added to ixgbe and myri10ge for DCA is ambigous, so this patch adds a description to the kconfig option. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* fs_enet: fix pollingAlexey Dobriyan2008-11-031-2/+4
| | | | | | | | 1. compile fix for irqreturn_t type change 2. restore ->poll_controller after CONFIG_PPC_CPM_NEW_BINDING transition Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* XFRM: copy_to_user_kmaddress() reports local address twiceArnaud Ebalard2008-11-031-1/+1
| | | | | | | | | | | | | | | | | | | While adding support for MIGRATE/KMADDRESS in strongSwan (as specified in draft-ebalard-mext-pfkey-enhanced-migrate-00), Andreas Steffen noticed that XFRMA_KMADDRESS attribute passed to userland contains the local address twice (remote provides local address instead of remote one). This bug in copy_to_user_kmaddress() affects only key managers that use native XFRM interface (key managers that use PF_KEY are not affected). For the record, the bug was in the initial changeset I posted which added support for KMADDRESS (13c1d18931ebb5cf407cb348ef2cd6284d68902d 'xfrm: MIGRATE enhancements (draft-ebalard-mext-pfkey-enhanced-migrate)'). Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Reported-by: Andreas Steffen <andreas.steffen@strongswan.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* SMC91x: Fix compilation on some platforms.David S. Miller2008-11-031-0/+2
| | | | | | | | | | | | | This reverts 51ac3beffd4afaea4350526cf01fe74aaff25eff ('SMC91x: delete unused local variable "lp"') and adds __maybe_unused markers to these (potentially) unused variables. The issue is that in some configurations SMC_IO_SHIFT evaluates to '(lp->io_shift)', but in some others it's plain '0'. Based upon a build failure report from Manuel Lauss. Signed-off-by: David S. Miller <davem@davemloft.net>
* udp: Fix the SNMP counter of UDP_MIB_INERRORSWei Yongjun2008-11-021-2/+8
| | | | | | | | | | UDP packets received in udpv6_recvmsg() are not only IPv6 UDP packets, but also have IPv4 UDP packets, so when do the counter of UDP_MIB_INERRORS in udpv6_recvmsg(), we should check whether the packet is a IPv6 UDP packet or a IPv4 UDP packet. Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* udp: Fix the SNMP counter of UDP_MIB_INDATAGRAMSWei Yongjun2008-11-021-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | If UDP echo is sent to xinetd/echo-dgram, the UDP reply will be received at the sender. But the SNMP counter of UDP_MIB_INDATAGRAMS will be not increased, UDP6_MIB_INDATAGRAMS will be increased instead. Endpoint A Endpoint B UDP Echo request -----------> (IPv4, Dst port=7) <---------- UDP Echo Reply (IPv4, Src port=7) This bug is come from this patch cb75994ec311b2cd50e5205efdcc0696abd6675d. It do counter UDP[6]_MIB_INDATAGRAMS until udp[v6]_recvmsg. Because xinetd used IPv6 socket to receive UDP messages, thus, when received UDP packet, the UDP6_MIB_INDATAGRAMS will be increased in function udpv6_recvmsg() even if the packet is a IPv4 UDP packet. This patch fixed the problem. Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* drivers/net/smc911x.c: Fix lockdep warning on xmit.Will Newton2008-11-021-1/+1
| | | | | | | | | | | | | | | | | | | | dev_kfree_skb should not be called with irqs disabled, use dev_kfree_skb_irq instead. The warning caused looks like this: ====================================================== [ INFO: hard-safe -> hard-unsafe lock order detected ] 2.6.28-rc1 #273 ------------------------------------------------------ swapper/0 [HC0[0]:SC1[2]:HE0:SE0] is trying to acquire: (clock-AF_INET){-..+}, at: [<4015c17c>] _sock_def_write_space+0x28/0xd8 and this task is already holding: (&lp->lock){++..}, at: [<4013f230>] _smc911x_hard_start_xmit+0x30/0x4b8 which would create a new lock dependency: (&lp->lock){++..} -> (clock-AF_INET){-..+} Signed-off-by: Will Newton <will.newton@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* af_unix: netns: fix problem of return valueJianjun Kong2008-11-011-1/+1
| | | | | | | | | | fix problem of return value net/unix/af_unix.c: unix_net_init() when error appears, it should return 'error', not always return 0. Signed-off-by: Jianjun Kong <jianjun@zeuux.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* IRDA: remove double inclusion of module.hAlexander Beregalov2008-11-012-2/+0
| | | | | Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* udp: multicast packets need to check namespaceEric Dumazet2008-11-012-9/+11
| | | | | | | | Current UDP multicast delivery is not namespace aware. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Acked-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: add documentation for skb recyclingStephen Hemminger2008-11-011-0/+12
| | | | | | | | | | | | | Commit 04a4bb55bcf35b63d40fd2725e58599ff8310dd7 ("net: add skb_recycle_check() to enable netdriver skb recycling") added a method for network drivers to recycle skbuffs, but while use of this mechanism was documented in the commit message, it should really have been added as a docbook comment as well -- this patch does that. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* key: fix setkey(8) policy set breakageAlexey Dobriyan2008-10-311-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Steps to reproduce: #/usr/sbin/setkey -f flush; spdflush; add 192.168.0.42 192.168.0.1 ah 24500 -A hmac-md5 "1234567890123456"; add 192.168.0.42 192.168.0.1 esp 24501 -E 3des-cbc "123456789012123456789012"; spdadd 192.168.0.42 192.168.0.1 any -P out ipsec esp/transport//require ah/transport//require; setkey: invalid keymsg length Policy dump will bail out with the same message after that. -recv(4, "\2\16\0\0\32\0\3\0\0\0\0\0\37\r\0\0\3\0\5\0\377 \0\0\2\0\0\0\300\250\0*\0"..., 32768, 0) = 208 +recv(4, "\2\16\0\0\36\0\3\0\0\0\0\0H\t\0\0\3\0\5\0\377 \0\0\2\0\0\0\300\250\0*\0"..., 32768, 0) = 208 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bpa10x: free sk_buff with kfree_skbIlpo Järvinen2008-10-311-2/+2
| | | | | | | | | | Inspired by Sergio Luis' similar patches, I finally found a case which is trivial enough that spatch won't choke on it. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* xfrm: do not leak ESRCH to user spacefernando@oss.ntt.co2008-10-311-0/+2
| | | | | | | | | | | | | | | | I noticed that, under certain conditions, ESRCH can be leaked from the xfrm layer to user space through sys_connect. In particular, this seems to happen reliably when the kernel fails to resolve a template either because the AF_KEY receive buffer being used by racoon is full or because the SA entry we are trying to use is in XFRM_STATE_EXPIRED state. However, since this could be a transient issue it could be argued that EAGAIN would be more appropriate. Besides this error code is not even documented in the man page for sys_connect (as of man-pages 3.07). Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: Really remove all of LOOPBACK_TSO code.David S. Miller2008-10-311-9/+0
| | | | | | | | | As noticed by Saikiran Madugula, commit 7447ef63cf2dfdc444f4c72ae13f604350b2e25f ("loopback: Remove rest of LOOPBACK_TSO code.") got rid of emulate_large_send_offload() but didn't get rid of the call site as well. Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of git://git.infradead.org/users/pcmoore/lblnet-2.6David S. Miller2008-10-304-4/+29
|\
| * netlabel: Fix compilation warnings in net/netlabel/netlabel_addrlist.cManish Katiyar2008-10-302-0/+24
| | | | | | | | | | | | | | Enable netlabel auditing functions only when CONFIG_AUDIT is set Signed-off-by: Manish Katiyar <mkatiyar@gmail.com> Signed-off-by: Paul Moore <paul.moore@hp.com>
| * netlabel: Fix compiler warnings in netlabel_mgmt.cPaul Moore2008-10-291-1/+1
| | | | | | | | | | | | | | | | | | | | Fix the compiler warnings below, thanks to Andrew Morton for finding them. net/netlabel/netlabel_mgmt.c: In function `netlbl_mgmt_listentry': net/netlabel/netlabel_mgmt.c:268: warning: 'ret_val' might be used uninitialized in this function Signed-off-by: Paul Moore <paul.moore@hp.com>
| * cipso: unsigned buf_len cannot be negativeroel kluin2008-10-291-3/+4
| | | | | | | | | | | | | | unsigned buf_len cannot be negative Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Paul Moore <paul.moore@hp.com>
* | netfilter: nf_conntrack_proto_gre: switch to register_pernet_gen_subsys()Alexey Dobriyan2008-10-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | register_pernet_gen_device() can't be used is nf_conntrack_pptp module is also used (compiled in or loaded). Right now, proto_gre_net_exit() is called before nf_conntrack_pptp_net_exit(). The former shutdowns and frees GRE piece of netns, however the latter absolutely needs it to flush keymap. Oops is inevitable. Switch to shiny new register_pernet_gen_subsys() to get correct ordering in netns ops list. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | netns: add register_pernet_gen_subsys/unregister_pernet_gen_subsysAlexey Dobriyan2008-10-302-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | netns ops which are registered with register_pernet_gen_device() are shutdown strictly before those which are registered with register_pernet_subsys(). Sometimes this leads to opposite (read: buggy) shutdown ordering between two modules. Add register_pernet_gen_subsys()/unregister_pernet_gen_subsys() for modules which aren't elite enough for entry in struct net, and which can't use register_pernet_gen_device(). PPTP conntracking module is such one. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: delete excess kernel-doc notationRandy Dunlap2008-10-303-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | Remove excess kernel-doc function parameters from networking header & driver files: Warning(include/net/sock.h:946): Excess function parameter or struct member 'sk' description in 'sk_filter_release' Warning(include/linux/netdevice.h:1545): Excess function parameter or struct member 'cpu' description in 'netif_tx_lock' Warning(drivers/net/wan/z85230.c:712): Excess function parameter or struct member 'regs' description in 'z8530_interrupt' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'davem-fixes' of ↵David S. Miller2008-10-3013-37/+127
|\ \ | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
| * | gianfar: Don't reset TBI<->SerDes link if it's already upTrent Piepho2008-10-311-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The link may be up already via the chip's reset strapping, or though action of U-Boot, or from the last time the interface was brought up. Resetting the link causes it to go down for several seconds. This can significantly increase the time from power-on to DHCP completion and a device being accessible to the network. Signed-off-by: Trent Piepho <tpiepho@freescale.com> Acked-by: Andy Fleming <afleming@freescale.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | gianfar: Fix race in TBI/SerDes configurationTrent Piepho2008-10-315-1/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The init_phy() function attaches to the PHY, then configures the SerDes<->TBI link (in SGMII mode). The TBI is on the MDIO bus with the PHY (sort of) and is accessed via the gianfar's MDIO registers, using the functions gfar_local_mdio_read/write(), which don't do any locking. The previously attached PHY will start a work-queue on a timer, and probably an irq handler as well, which will talk to the PHY and thus use the MDIO bus. This uses phy_read/write(), which have locking, but not against the gfar_local_mdio versions. The result is that PHY code will try to use the MDIO bus at the same time as the SerDes setup code, corrupting the transfers. Setting up the SerDes before attaching to the PHY will insure that there is no race between the SerDes code and *our* PHY, but doesn't fix everything. Typically the PHYs for all gianfar devices are on the same MDIO bus, which is associated with the first gianfar device. This means that the first gianfar's SerDes code could corrupt the MDIO transfers for a different gianfar's PHY. The lock used by phy_read/write() is contained in the mii_bus structure, which is pointed to by the PHY. This is difficult to access from the gianfar drivers, as there is no link between a gianfar device and the mii_bus which shares the same MDIO registers. As far as the device layer and drivers are concerned they are two unrelated devices (which happen to share registers). Generally all gianfar devices' PHYs will be on the bus associated with the first gianfar. But this might not be the case, so simply locking the gianfar's PHY's mii bus might not lock the mii bus that the SerDes setup code is going to use. We solve this by having the code that creates the gianfar platform device look in the device tree for an mdio device that shares the gianfar's registers. If one is found the ID of its platform device is saved in the gianfar's platform data. A new function in the gianfar mii code, gfar_get_miibus(), can use the bus ID to search through the platform devices for a gianfar_mdio device with the right ID. The platform device's driver data is the mii_bus structure, which the SerDes setup code can use to lock the current bus. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Andy Fleming <afleming@freescale.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | at91_ether: request/free GPIO for PHY interruptDavid Brownell2008-10-311-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | When the at91_ether driver is using a GPIO for its PHY interrupt, be sure to request (and later, if needed, free) that GPIO. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | amd8111e: fix dma_free_coherent contextChunbo Luo2008-10-311-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Acoording commit aa24886e379d2b641c5117e178b15ce1d5d366ba, dma_free_coherent() need irqs enabled. This patch fix following warning messages: WARNING: at linux/arch/x86/kernel/pci-dma.c:376 dma_free_coherent+0xaa/0xb0() Call Trace: [<ffffffff8023f80f>] warn_on_slowpath+0x5f/0x90 [<ffffffff80496ffa>] ? __kfree_skb+0x3a/0xa0 [<ffffffff802a4723>] ? discard_slab+0x23/0x40 [<ffffffff8021274a>] dma_free_coherent+0xaa/0xb0 [<ffffffff8043668f>] amd8111e_close+0x10f/0x1b0 [<ffffffff8049f3ae>] dev_close+0x5e/0xb0 [<ffffffff8049efa1>] dev_change_flags+0xa1/0x1e0 [<ffffffff806b2171>] ic_close_devs+0x36/0x4e [<ffffffff806b29ee>] ip_auto_config+0x581/0x10f3 [<ffffffff803a6e19>] ? kobject_add+0x69/0x90 [<ffffffff803a698a>] ? kobject_get+0x1a/0x30 [<ffffffff803a785b>] ? kobject_uevent+0xb/0x10 [<ffffffff803a6c62>] ? kset_register+0x52/0x60 [<ffffffff803a6f9b>] ? kset_create_and_add+0x6b/0xa0 [<ffffffff804e2e74>] ? tcp_ca_find+0x24/0x50 [<ffffffff806b246d>] ? ip_auto_config+0x0/0x10f3 [<ffffffff8020903c>] _stext+0x3c/0x150 [<ffffffff802772d3>] ? register_irq_proc+0xd3/0xf0 [<ffffffff802f0000>] ? mb_cache_create+0x80/0x1f0 [<ffffffff80688693>] kernel_init+0x141/0x1b8 [<ffffffff80688552>] ? kernel_init+0x0/0x1b8 [<ffffffff8020d609>] child_rip+0xa/0x11 [<ffffffff80688552>] ? kernel_init+0x0/0x1b8 [<ffffffff80688552>] ? kernel_init+0x0/0x1b8 [<ffffffff8020d5ff>] ? child_rip+0x0/0x11 Signed-off-by: Chunbo Luo <chunbo.luo@windriver.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | atl1: fix vlan tag regressionJay Cliburn2008-10-312-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 401c0aabec4b97320f962a0161a846d230a6f7aa introduced a regression in the atl1 driver by storing the VLAN tag in the wrong TX descriptor field. This patch causes the VLAN tag to be stored in its proper location. Tested-by: Ramon Casellas <ramon.casellas@cttc.es> Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net> Cc: stable@kernel.org Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | SMC91x: delete unused local variable "lp"Mike Frysinger2008-10-311-2/+0
| | | | | | | | | | | | | | | Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | myri10ge: fix stop/go mmio orderingBrice Goglin2008-10-311-1/+3
| | | | | | | | | | | | | | | | | | | | | Use mmiowb() to ensure "stop" and "go" commands are sent in order on ia64. Signed-off-by: Brice Goglin <brice@myri.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | bonding: fix panic when taking bond interface down before removing moduleAndy Gospodarek2008-10-311-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A panic was discovered with bonding when using mode 5 or 6 and trying to remove the slaves from the bond after the interface was taken down. When calling 'ifconfig bond0 down' the following happens: bond_close() bond_alb_deinitialize() tlb_deinitialize() kfree(bond_info->tx_hashtbl) bond_info->tx_hashtbl = NULL Unfortunately if there are still slaves in the bond, when removing the module the following happens: bonding_exit() bond_free_all() bond_release_all() bond_alb_deinit_slave() tlb_clear_slave() tx_hash_table = BOND_ALB_INFO(bond).tx_hashtbl u32 next_index = tx_hash_table[index].next As you might guess we panic when trying to access a few entries into the table that no longer exists. I experimented with several options (like moving the calls to tlb_deinitialize somewhere else), but it really makes the most sense to be part of the bond_close routine. It also didn't seem logical move tlb_clear_slave around too much, so the simplest option seems to add a check in tlb_clear_slave to make sure we haven't already wiped the tx_hashtbl away before searching for all the non-existent hash-table entries that used to point to the slave as the output interface. Signed-off-by: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | bonding: Clean up resource leaksJay Vosburgh2008-10-311-18/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch reworks the resource free logic performed at the time a bonding device is released. This (a) closes two resource leaks, one for workqueues and one for multicast lists, and (b) improves commonality of code between the "destroy one" and "destroy all" paths by performing final free activity via destructor instead of explicitly (and differently) in each path. "Sean E. Millichamp" <sean@bruenor.org> reported the workqueue leak, and included a different patch. Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | bonding: fix miimon failure counterJay Vosburgh2008-10-311-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the rework of the mii monitor for: commit f0c76d61779b153dbfb955db3f144c62d02173c2 Author: Jay Vosburgh <fubar@us.ibm.com> Date: Wed Jul 2 18:21:58 2008 -0700 bonding: refactor mii monitor I left out the increment of the link failure counter. This patch corrects that omission. Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* | | Merge branch 'master' of ↵David S. Miller2008-10-309-25/+19
|\ \ \ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
| * | | ath5k: add self to MAINTAINERSBob Copeland2008-10-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I might as well be on the official list for ath5k. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | ath5k: honor FIF_BCN_PRBRESP_PROMISC in STA modeBob Copeland2008-10-291-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were setting RX_FILTER_BEACON even after entering STA mode, which leads to a lot of unnecessary wakeups. This should fix the bug "Ath5k driver has too many interrupts per second at idle" at http://bugzilla.kernel.org/show_bug.cgi?id=11749. Signed-off-by: Bob Copeland <me@bobcopeland.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | ath5k: Fix reset sequence for AR5212 in general and RF5111 in particularElias Oltmanns2008-10-292-15/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take care to handle register 0xa228 exactly as in the HAL released by Atheros. This change is required to make ath5k work again on my system since commit 2203d6be (ath5k: Misc hw_reset updates), thus fixing a regression in 2.6.27 and therefore hopefully eligible for inclusion into a stable release. v2: Only overwrite initial register values on later revisions of AR5212 chips. v3: Use standard macros to manipulate the register. Signed-off-by: Elias Oltmanns <eo@nebensachen.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
OpenPOWER on IntegriCloud