aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/qlcnic/qlcnic.h (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2010-10-30isdn: mISDN: socket: fix information leak to userlandKulikov Vasiliy1-0/+2
Structure mISDN_devinfo is copied to userland with the field "name" that has the last elements unitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov <segooon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30netdev: can: Change mail address of Hans J. KochHans J. Koch1-1/+1
My old mail address doesn't exist anymore. This changes all occurrences to my new address. Signed-off-by: Hans J. Koch <hjk@hansjkoch.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30pcnet_cs: add new_idKen Kawasaki1-0/+1
pcnet_cs: add new_id: "corega Ether CF-TD" 10Base-T PCMCIA card. Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30net: Truncate recvfrom and sendto length to INT_MAX.Linus Torvalds1-0/+4
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30RDS: Let rds_message_alloc_sgs() return NULLAndy Grover3-0/+17
Even with the previous fix, we still are reading the iovecs once to determine SGs needed, and then again later on. Preallocating space for sg lists as part of rds_message seemed like a good idea but it might be better to not do this. While working to redo that code, this patch attempts to protect against userspace rewriting the rds_iovec array between the first and second accesses. The consequences of this would be either a too-small or too-large sg list array. Too large is not an issue. This patch changes all callers of message_alloc_sgs to handle running out of preallocated sgs, and fail gracefully. Signed-off-by: Andy Grover <andy.grover@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30RDS: Copy rds_iovecs into kernel memory instead of rereading from userspaceAndy Grover1-39/+65
Change rds_rdma_pages to take a passed-in rds_iovec array instead of doing copy_from_user itself. Change rds_cmsg_rdma_args to copy rds_iovec array once only. This eliminates the possibility of userspace changing it after our sanity checks. Implement stack-based storage for small numbers of iovecs, based on net/socket.c, to save an alloc in the extremely common case. Although this patch reduces iovec copies in cmsg_rdma_args to 1, we still do another one in rds_rdma_extra_size. Getting rid of that one will be trickier, so it'll be a separate patch. Signed-off-by: Andy Grover <andy.grover@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30RDS: Clean up error handling in rds_cmsg_rdma_argsAndy Grover1-3/+2
We don't need to set ret = 0 at the end -- it's initialized to 0. Also, don't increment s_send_rdma stat if we're exiting with an error. Signed-off-by: Andy Grover <andy.grover@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30RDS: Return -EINVAL if rds_rdma_pages returns an errorAndy Grover1-1/+3
rds_cmsg_rdma_args would still return success even if rds_rdma_pages returned an error (or overflowed). Signed-off-by: Andy Grover <andy.grover@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30net: fix rds_iovec page count overflowLinus Torvalds1-0/+7
As reported by Thomas Pollet, the rdma page counting can overflow. We get the rdma sizes in 64-bit unsigned entities, but then limit it to UINT_MAX bytes and shift them down to pages (so with a possible "+1" for an unaligned address). So each individual page count fits comfortably in an 'unsigned int' (not even close to overflowing into signed), but as they are added up, they might end up resulting in a signed return value. Which would be wrong. Catch the case of tot_pages turning negative, and return the appropriate error code. Reported-by: Thomas Pollet <thomas.pollet@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andy Grover <andy.grover@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30can: pch_can: fix section mismatch warning by using a whitelisted nameMarc Kleine-Budde1-3/+3
This patch fixes the following section mismatch warning: WARNING: drivers/net/can/pch_can.o(.data+0x18): Section mismatch in reference from the variable pch_can_pcidev to the variable .devinit.rodata:pch_pci_tbl The variable pch_can_pcidev references the variable __devinitconst pch_pci_tbl This is actually a false positive which is fixed by giving the offending variable a whitelisted name, it's renamed to "pch_can_pci_driver". This makes sense because the variable is of the type "struct pci_driver". Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30can: pch_can: fix sparse warningMarc Kleine-Budde1-2/+2
This patch fixes the following sparse warning: drivers/net/can/pch_can.c:231:26: warning: incorrect type in argument 1 (different address spaces) drivers/net/can/pch_can.c:231:26: expected unsigned int [usertype] *addr drivers/net/can/pch_can.c:231:26: got unsigned int [noderef] <asn:2>*<noident> Let pch_can_bit_{set,clear} first parameter be a void __iomem pointer. Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30netxen_nic: Fix the tx queue manipulation bug in netxen_nic_probeDenis Kirjanov1-1/+0
We should not stop the egress queue during probe because it is wrong. Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30ip_gre: fix fallback tunnel setupEric Dumazet1-3/+3
Before making the fallback tunnel visible to lookups, we should make sure it is completely setup, once ipgre_tunnel_init() had been called and tstats per_cpu pointer allocated. move rcu_assign_pointer(ign->tunnels_wc[0], tunnel); from ipgre_fb_tunnel_init() to ipgre_init_net() Based on a patch from Pavel Emelyanov Reported-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30vmxnet: trivial annotation of protocol constantHarvey Harrison1-1/+1
Noticed by sparse: drivers/net/vmxnet3/vmxnet3_drv.c:876:38: warning: cast from restricted __be16 drivers/net/vmxnet3/vmxnet3_drv.c:876:38: warning: cast from restricted __be16 drivers/net/vmxnet3/vmxnet3_drv.c:876:24: warning: restricted __be16 degrades to integer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30vmxnet3: remove unnecessary byteswapping in BAR writing macrosHarvey Harrison1-4/+4
readl/writel swap to little-endian internally. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-30ipv6/udp: report SndbufErrors and RcvbufErrorsEric Dumazet1-0/+4
commit a18135eb9389 (Add UDP_MIB_{SND,RCV}BUFERRORS handling.) forgot to make the necessary changes in net/ipv6/proc.c to report additional counters in /proc/net/snmp6 Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-29phy/marvell: rename 88ec048 to 88e1318s and fix mscr1 addrCyril Chemparathy2-10/+10
The marvell 88ec048's official part number is 88e1318s. This patch renames definitions in the driver to reflect this. In addition, a minor bug fix has been added to write back the MSCR1 register value properly. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-29b43: Fix warning at drivers/mmc/core/core.c:237 in mmc_wait_for_cmdLarry Finger1-0/+2
On module removal, the sdio version of b43 generates the following warning: [ 851.560519] ------------[ cut here ]------------ [ 851.560531] WARNING: at drivers/mmc/core/core.c:237 mmc_wait_for_cmd+0x88/0x90() [ 851.560534] Hardware name: 20552PG [ 851.560536] Modules linked in: b43(-) ssb mmc_block binfmt_misc rfcomm sco bnep ppdev l2cap ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp kvm_intel kvm arc4 iwlagn snd_hda_codec_conexant snd_hda_intel snd_hda_codec iwlcore snd_hwdep snd_pcm thinkpad_acpi mac80211 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq r852 joydev snd_timer sm_common pcmcia nand snd_seq_device cfg80211 sdhci_pci btusb psmouse tpm_tis yenta_socket nand_ids lp snd pcmcia_rsrc nand_ecc bluetooth sdhci tpm pcmcia_core parport mtd snd_page_alloc serio_raw tpm_bios soundcore nvram led_class sha256_generic aes_i586 aes_generic dm_crypt i915 drm_kms_helper drm ahci intel_agp i2c_algo_bit intel_gtt e1000e libahci video agpgart output [ 851.560620] Pid: 2504, comm: rmmod Not tainted 2.6.36-titan0+ #1 [ 851.560622] Call Trace: [ 851.560631] [<c014a102>] warn_slowpath_common+0x72/0xa0 [ 851.560636] [<c04d94c8>] ? mmc_wait_for_cmd+0x88/0x90 [ 851.560641] [<c04d94c8>] ? mmc_wait_for_cmd+0x88/0x90 [ 851.560645] [<c014a152>] warn_slowpath_null+0x22/0x30 [ 851.560649] [<c04d94c8>] mmc_wait_for_cmd+0x88/0x90 [ 851.560655] [<c0401585>] ? device_release+0x25/0x80 [ 851.560660] [<c04df210>] mmc_io_rw_direct_host+0xa0/0x150 [ 851.560665] [<c04df370>] mmc_io_rw_direct+0x30/0x40 [ 851.560669] [<c04e06e7>] sdio_disable_func+0x37/0xa0 [ 851.560683] [<f8dfcb80>] b43_sdio_remove+0x30/0x50 [b43] [ 851.560687] [<c04df8cc>] sdio_bus_remove+0x1c/0x60 [ 851.560692] [<c016d39f>] ? blocking_notifier_call_chain+0x1f/0x30 [ 851.560697] [<c0404991>] __device_release_driver+0x51/0xb0 [ 851.560701] [<c0404a7f>] driver_detach+0x8f/0xa0 [ 851.560705] [<c0403c83>] bus_remove_driver+0x63/0xa0 [ 851.560709] [<c0405039>] driver_unregister+0x49/0x80 [ 851.560713] [<c0405039>] ? driver_unregister+0x49/0x80 [ 851.560718] [<c04dfad7>] sdio_unregister_driver+0x17/0x20 [ 851.560727] [<f8dfcb42>] b43_sdio_exit+0x12/0x20 [b43] [ 851.560734] [<f8dfe76f>] b43_exit+0x17/0x3c [b43] [ 851.560740] [<c017fb8d>] sys_delete_module+0x13d/0x200 [ 851.560747] [<c01fd7d2>] ? do_munmap+0x212/0x300 [ 851.560752] [<c010311f>] sysenter_do_call+0x12/0x28 [ 851.560757] ---[ end trace 31e14488072d2f7d ]--- [ 851.560759] ------------[ cut here ]------------ The warning is caused by b43 not claiming the device before calling sdio_disable_func(). Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: Arnd Hannemann <arnd@arndnet.de> Tested-by: Arnd Hannemann <arnd@arndnet.de> Cc: Stable <stable@kernel.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-29mac80211: fix failure to check kmalloc return value in key_key_readJesper Juhl1-1/+5
I noticed two small issues in mac80211/debugfs_key.c::key_key_read while reading through the code. Patch below. The key_key_read() function returns ssize_t and the value that's actually returned is the return value of simple_read_from_buffer() which also returns ssize_t, so let's hold the return value in a ssize_t local variable rather than a int one. Also, memory is allocated dynamically with kmalloc() which can fail, but the return value of kmalloc() is not checked, so we may end up operating on a null pointer further on. So check for a NULL return and bail out with -ENOMEM in that case. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-29libertas: Fix sd8686 firmware reloadPaul Fox1-3/+29
For the SD8686, we cannot rely on the scratch register to read the firmware load status, because the same register is used for storing RX packet length. Broaden the check to account for this. The module can now be unloaded/reloaded successfully. Based on the implementation from libertas_tf. Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Steve deRosier <steve@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-29ath9k: Fix incorrect access of rate flags in RCMohammed Shafi Shajakhan1-1/+1
The index variable to access the rate flags should be obtained from the inner loop counter which corresponds to the rate table structure.This fixes the invalid rate selection i.e when the supported basic rate is invalid on a particular band and also the following warning message. Thanks to Raj for finding this out. Call Trace: [<ffffffff8104ee4a>] warn_slowpath_common+0x7a/0xb0 [<ffffffff8104ee95>] warn_slowpath_null+0x15/0x20 [<ffffffffa0583c45>] ath_get_rate+0x595/0x5b0 [ath9k] [<ffffffff811a0636>] ? cpumask_next_and+0x36/0x50 [<ffffffffa0405186>] rate_control_get_rate+0x86/0x160 [mac80211] [<ffffffffa040dfac>] invoke_tx_handlers+0x81c/0x12d0 [mac80211] [<ffffffffa040eae9>] ieee80211_tx+0x89/0x2b0 [mac80211] [<ffffffff812891bc>] ? pskb_expand_head+0x1cc/0x1f0 [<ffffffffa040edc5>] ieee80211_xmit+0xb5/0x1c0 [mac80211] [<ffffffffa041026f>] ieee80211_tx_skb+0x4f/0x60 [mac80211] [<ffffffffa03fe016>] ieee80211_send_nullfunc+0x46/0x60 [mac80211] [<ffffffffa03f91d7>] ieee80211_offchannel_stop_station+0x107/0x150 [mac80211] [<ffffffff812891bc>] ? pskb_expand_head+0x1cc/0x1f0 [<ffffffffa040edc5>] ieee80211_xmit+0xb5/0x1c0 [mac80211] [<ffffffffa041026f>] ieee80211_tx_skb+0x4f/0x60 [mac80211] [<ffffffffa03fe016>] ieee80211_send_nullfunc+0x46/0x60 [mac80211] [<ffffffffa03f91d7>] ieee80211_offchannel_stop_station+0x107/0x150 [mac80211] [<ffffffffa03f8896>] ieee80211_scan_work+0x146/0x600 [mac80211] [<ffffffff8133a375>] ? schedule+0x2f5/0x8e0 [<ffffffffa03f8750>] ? ieee80211_scan_work+0x0/0x600 [mac80211] [<ffffffff81064fcf>] process_one_work+0x10f/0x380 [<ffffffff81066bc2>] worker_thread+0x162/0x340 [<ffffffff81066a60>] ? worker_thread+0x0/0x340 Cc: stable@kernel.org Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-28netfilter: xt_socket: Make tproto signed in socket_mt6_v1().David S. Miller1-4/+3
Otherwise error indications from ipv6_find_hdr() won't be noticed. This required making the protocol argument to extract_icmp6_fields() signed too. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28stmmac: enable/disable rx/tx in the core with a single write.avisconti1-30/+10
This patch enables and disables the rx and tx bits in the MAC control reg by using a single write operation. This also solves a possible problem (spotted on SPEAr platforms) at 10Mbps where two consecutive writes to a MAC control register can take more than 4 phy_clk cycles. Signed-off-by: Armando Visconti <armando.visconti@st.com> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28net: atarilance - flags should be unsigned longGeert Uytterhoeven1-1/+1
drivers/net/atarilance.c: In function ‘addr_accessible’: drivers/net/atarilance.c:413: warning: comparison of distinct pointer types lacks a cast drivers/net/atarilance.c:450: warning: comparison of distinct pointer types lacks a cast Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28netxen: fix kdumpRajesh Borundia2-15/+7
Reset the whole hw instead of freeing hw resources consumed by each pci function. Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28pktgen: Limit how much data we copy onto the stack.Nelson Elhage1-3/+4
A program that accidentally writes too much data to the pktgen file can overflow the kernel stack and oops the machine. This is only triggerable by root, so there's no security issue, but it's still an unfortunate bug. printk() won't print more than 1024 bytes in a single call, anyways, so let's just never copy more than that much data. We're on a fairly shallow stack, so that should be safe even with CONFIG_4KSTACKS. Signed-off-by: Nelson Elhage <nelhage@ksplice.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28net: Limit socket I/O iovec total length to INT_MAX.David S. Miller3-16/+16
This helps protect us from overflow issues down in the individual protocol sendmsg/recvmsg handlers. Once we hit INT_MAX we truncate out the rest of the iovec by setting the iov_len members to zero. This works because: 1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial writes are allowed and the application will just continue with another write to send the rest of the data. 2) For datagram oriented sockets, where there must be a one-to-one correspondance between write() calls and packets on the wire, INT_MAX is going to be far larger than the packet size limit the protocol is going to check for and signal with -EMSGSIZE. Based upon a patch by Linus Torvalds. Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28USB: gadget: fix ethernet gadget crash in gether_setupDmitry Artamonow1-1/+1
Crash is triggered by commit e6484930d7 ("net: allocate tx queues in register_netdevice"), which moved tx netqueue creation into register_netdev. So now calling netif_stop_queue() before register_netdev causes an oops. Move netif_stop_queue() after net device registration to fix crash. Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28fib: Fix fib zone and its hash leak on namespace stopPavel Emelyanov4-1/+26
When we stop a namespace we flush the table and free one, but the added fn_zone-s (and their hashes if grown) are leaked. Need to free. Tries releases all its stuff in the flushing code. Shame on us - this bug exists since the very first make-fib-per-net patches in 2.6.27 :( Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28cxgb3: Fix panic in free_tx_desc()Krishna Kumar1-1/+3
I got a few of these panics (on 2.6.36-rc7) when running high number of netperf sessions: BUG: unable to handle kernel paging request at 0000100000000000 IP: [<ffffffff813125f0>] skb_release_data+0xa0/0xd0 Oops: 0000 [#1] SMP Pid: 2155, comm: vhost-2115 Not tainted 2.6.36-rc7-ORG #1 49Y6512 /System x3650 M2 -[7947AC1]- RIP: 0010:[<ffffffff813125f0>] [<ffffffff813125f0>] skb_release_data+0xa0/0xd0 RSP: 0018:ffff880001803738 EFLAGS: 00010206 RAX: ffff880179b0fc00 RBX: ffff880178b441c0 RCX: 0000000000000000 RSP: 0018:ffff880001803738 EFLAGS: 00010206 RAX: ffff880179b0fc00 RBX: ffff880178b441c0 RCX: 0000000000000000 RDX: ffff880179b0fd40 RSI: 0000000000000000 RDI: 0000100000000000 RBP: ffff880001803748 R08: 0000000000000001 R09: ffff88017f117000 R10: ffff88017b990608 R11: ffff88017f117090 R12: ffff880178b441c0 R13: ffff88017f117090 R14: 0000000000000000 R15: ffff880178b441c0 FS: 0000000000000000(0000) GS:ffff880001800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000100000000000 CR3: 000000017ea64000 CR4: 00000000000026e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process vhost-2115 (pid: 2155, threadinfo ffff88017d872000, task ffff88017e954680) Stack: ffff880178b441c0 0000000000000007 ffff880001803768 ffffffff81312119 <0> 0000000000000000 0000000000000002 ffff880001803778 ffffffff813121f9 <0> ffff880001803818 ffffffffa012d14c ffffffffa02de076 ffff880001803700 Call Trace: <IRQ> [<ffffffff81312119>] __kfree_skb+0x19/0xa0 [<ffffffff813121f9>] kfree_skb+0x19/0x40 [<ffffffffa012d14c>] free_tx_desc+0x2fc/0x350 [cxgb3] [<ffffffffa02de076>] ? vhost_poll_wakeup+0x16/0x20 [vhost_net] [<ffffffffa01323db>] t3_eth_xmit+0x28b/0x380 [cxgb3] [<ffffffff8131ce47>] dev_hard_start_xmit+0x377/0x5a0 [<ffffffff81335a4a>] sch_direct_xmit+0xfa/0x1d0 [<ffffffff8131d1a9>] dev_queue_xmit+0x139/0x450 [<ffffffff81326225>] neigh_resolve_output+0x125/0x340 [<ffffffff8135a77c>] ip_finish_output+0x14c/0x320 [<ffffffff8135a9fe>] ip_output+0xae/0xc0 [<ffffffff8135620f>] ip_forward_finish+0x3f/0x50 [<ffffffff8135641f>] ip_forward+0x1ff/0x400 [<ffffffff81354789>] ip_rcv_finish+0x119/0x3e0 [<ffffffff81354c7d>] ip_rcv+0x22d/0x300 [<ffffffff8131a95b>] __netif_receive_skb+0x29b/0x570 [<ffffffff8131ba70>] ? netif_receive_skb+0x0/0x80 [<ffffffff8131bae8>] netif_receive_skb+0x78/0x80 [<ffffffffa02a96d8>] br_handle_frame_finish+0x198/0x260 [bridge] [<ffffffffa02aebc8>] br_nf_pre_routing_finish+0x238/0x380 [bridge] [<ffffffff813424bc>] ? nf_hook_slow+0x6c/0x100 [<ffffffffa02ae990>] ? br_nf_pre_routing_finish+0x0/0x380 [bridge] [<ffffffffa02afb08>] br_nf_pre_routing+0x698/0x7a0 [bridge] [<ffffffff81342414>] nf_iterate+0x64/0xa0 [<ffffffffa02a9540>] ? br_handle_frame_finish+0x0/0x260 [bridge] [<ffffffff813424bc>] nf_hook_slow+0x6c/0x100 [<ffffffffa02a9540>] ? br_handle_frame_finish+0x0/0x260 [bridge] [<ffffffffa02a9931>] br_handle_frame+0x191/0x240 [bridge] [<ffffffffa02a97a0>] ? br_handle_frame+0x0/0x240 [bridge] [<ffffffff8131a863>] __netif_receive_skb+0x1a3/0x570 [<ffffffff812ef3f6>] ? dma_issue_pending_all+0x76/0xa0 [<ffffffff8131ad32>] process_backlog+0x102/0x200 [<ffffffff8131c2d0>] net_rx_action+0x100/0x220 [<ffffffff810548ef>] __do_softirq+0xaf/0x140 [<ffffffff8100bcdc>] call_softirq+0x1c/0x30 [<ffffffff8100dfc5>] ? do_softirq+0x65/0xa0 [<ffffffff8131c6b8>] netif_rx_ni+0x28/0x30 [<ffffffffa02c305d>] tun_sendmsg+0x2cd/0x4b0 [tun] [<ffffffffa02e01af>] handle_tx+0x1df/0x340 [vhost_net] [<ffffffffa02e0340>] handle_tx_kick+0x10/0x20 [vhost_net] [<ffffffffa02de29b>] vhost_worker+0xbb/0x130 [vhost_net] [<ffffffffa02de1e0>] ? vhost_worker+0x0/0x130 [vhost_net] [<ffffffffa02de1e0>] ? vhost_worker+0x0/0x130 [vhost_net] [<ffffffff81069686>] kthread+0x96/0xa0 [<ffffffff8100bbe4>] kernel_thread_helper+0x4/0x10 [<ffffffff810695f0>] ? kthread+0x0/0xa0 [<ffffffff8100bbe0>] ? kernel_thread_helper+0x0/0x10 Code: 8b 94 24 d0 00 00 00 49 8b 84 24 d8 00 00 00 48 8d 14 10 0f b7 0a 39 d9 7f d1 48 8b 7a 10 48 85 ff 74 20 48 c7 42 10 00 00 00 00 <48> 8b 1f e8 e8 fb ff ff 48 85 db 48 89 df 75 f0 49 8b 84 24 d8 Patch below fixes the panic. cxgb4 and cxgb4vf already have this fix. Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28cxgb3: fix crash due to manipulating queues before registrationNishanth Aravamudan1-1/+1
Along the same lines as "cxgb4: fix crash due to manipulating queues before registration" (8f6d9f40476895571df039b6f1f5230ec7faebad), before commit "net: allocate tx queues in register_netdevice" netif_tx_stop_all_queues and related functions could be used between device allocation and registration but now only after registration. cxgb4 has such a call before registration and crashes now. Move it after register_netdev. Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Cc: eric.dumazet@gmail.com Cc: sonnyrao@us.ibm.com Cc: Divy Le Ray <divy@chelsio.com> Cc: Dimitris Michailidis <dm@chelsio.com> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Tested-by: Nishanth Aravamudan <nacc@us.ibm.com> Acked-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-288390: Don't oops on starting dev queuePavel Emelyanov1-1/+0
The __NS8390_init tries to start the device queue before the device is registered. This results in an oops (snipped): [ 2.865493] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 2.866106] IP: [<ffffffffa000602a>] netif_start_queue+0xb/0x12 [8390] [ 2.881267] Call Trace: [ 2.881437] [<ffffffffa000624d>] __NS8390_init+0x102/0x15a [8390] [ 2.881999] [<ffffffffa00062ae>] NS8390_init+0x9/0xb [8390] [ 2.882237] [<ffffffffa000d820>] ne2k_pci_init_one+0x297/0x354 [ne2k_pci] [ 2.882955] [<ffffffff811c7a0e>] local_pci_probe+0x12/0x16 [ 2.883308] [<ffffffff811c85ad>] pci_device_probe+0xc3/0xef [ 2.884049] [<ffffffff8129218d>] driver_probe_device+0xbe/0x14b [ 2.884937] [<ffffffff81292260>] __driver_attach+0x46/0x62 [ 2.885170] [<ffffffff81291788>] bus_for_each_dev+0x49/0x78 [ 2.885781] [<ffffffff81291fbb>] driver_attach+0x1c/0x1e [ 2.886089] [<ffffffff812912ab>] bus_add_driver+0xba/0x227 [ 2.886330] [<ffffffff8129259a>] driver_register+0x9e/0x115 [ 2.886933] [<ffffffff811c8815>] __pci_register_driver+0x50/0xac [ 2.887785] [<ffffffffa001102c>] ne2k_pci_init+0x2c/0x2e [ne2k_pci] [ 2.888093] [<ffffffff81000212>] do_one_initcall+0x7c/0x130 [ 2.888693] [<ffffffff8106d74f>] sys_init_module+0x99/0x1da [ 2.888946] [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b This happens because the netif_start_queue sets respective bit on the dev->_tx array which is not yet allocated. As far as I understand the code removing the netif_start_queue from __NS8390_init is OK, since queue will be started later on device open. Plz, correct me if I'm wrong. Found in the Dave's current tree, so he's in Cc. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28dccp ccid-2: Stop pollingGerrit Renker2-8/+20
This updates CCID-2 to use the CCID dequeuing mechanism, converting from previous continuous-polling to a now event-driven mechanism. Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28dccp: Refine the wait-for-ccid mechanismGerrit Renker4-54/+89
This extends the existing wait-for-ccid routine so that it may be used with different types of CCID, addressing the following problems: 1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for example has a full TX queue and becomes network-limited just as the application wants to close, then waiting for CCID-2 to become unblocked could lead to an indefinite delay (i.e., application "hangs"). 2) Since each TX CCID in turn uses a feedback mechanism, there may be changes in its sending policy while the queue is being drained. This can lead to further delays during which the application will not be able to terminate. 3) The minimum wait time for CCID-3/4 can be expected to be the queue length times the current inter-packet delay. For example if tx_qlen=100 and a delay of 15 ms is used for each packet, then the application would have to wait for a minimum of 1.5 seconds before being allowed to exit. 4) There is no way for the user/application to control this behaviour. It would be good to use the timeout argument of dccp_close() as an upper bound. Then the maximum time that an application is willing to wait for its CCIDs to can be set via the SO_LINGER option. These problems are addressed by giving the CCID a grace period of up to the `timeout' value. The wait-for-ccid function is, as before, used when the application (a) has read all the data in its receive buffer and (b) if SO_LINGER was set with a non-zero linger time, or (c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ state (client application closes after receiving CloseReq). In addition, there is a catch-all case of __skb_queue_purge() after waiting for the CCID. This is necessary since the write queue may still have data when (a) the host has been passively-closed, (b) abnormal termination (unread data, zero linger time), (c) wait-for-ccid could not finish within the given time limit. Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28dccp: Extend CCID packet dequeueing interfaceGerrit Renker3-58/+89
This extends the packet dequeuing interface of dccp_write_xmit() to allow 1. CCIDs to take care of timing when the next packet may be sent; 2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds). The main purpose is to take CCID-2 out of its polling mode (when it is network- limited, it tries every millisecond to send, without interruption). The mode of operation for (2) is as follows: * new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(), * ccid_hc_tx_send_packet() detects that it may not send (e.g. window full), * it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER', * dccp_write_xmit() returns without further action; * after some time the wait-condition for CCID becomes true, * that CCID schedules the tasklet, * tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(), * since the wait-condition is now true, ccid_hc_tx_packet() returns "send now", * packet is sent, and possibly more (since dccp_write_xmit() loops). Code reuse: the taskled function calls dccp_write_xmit(), the timer function reduces to a wrapper around the same code. Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28dccp: Return-value convention of hc_tx_send_packet()Gerrit Renker2-9/+37
This patch reorganises the return value convention of the CCID TX sending function, to permit more flexible schemes, as required by subsequent patches. Currently the convention is * values < 0 mean error, * a value == 0 means "send now", and * a value x > 0 means "send in x milliseconds". The patch provides symbolic constants and a function to interpret return values. In addition, it caps the maximum positive return value to 0xFFFF milliseconds, corresponding to 65.535 seconds. This is possible since in CCID-3/4 the maximum possible inter-packet gap is fixed at t_mbi = 64 sec. Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28igbvf: fix panic on loadEmil Tantilov1-4/+4
Introduced by commit:e6484930d7c73d324bccda7d43d131088da697b9 net: allocate tx queues in register_netdevice Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Acked-by: Greg Rose <greg.v.rose@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28ixgb: call pci_disable_device in ixgb_removeEmil Tantilov1-0/+1
ixgb fails to work after reload on recent kernels: rmmod ixgb (dev->current_state = PCI_UNKNOWN) modprobe ixgb (pci_enable_device will bail leaving current_state to PCI_UNKNOWN) ifup eth0 do_IRQ: 2.82 No irq handler for vector (irq -1) The issue was exposed by commit fcd097f31a6ee207cc0c3da9cccd2a86d4334785 PCI: MSI: Remove unsafe and unnecessary hardware access which avoids HW writes for power states != PCI_D0 CC: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28ixgbe: DCB, fix TX hang occurring in stress condition with PFCJohn Fastabend5-10/+54
The DCB credits refill quantum _must_ be greater than half the max packet size. This is needed to guarantee that TX DMA operations are not attempted during a pause state. Additionally, the min IFG must be set correctly for DCB mode. If a DMA operation is requested unexpectedly during the pause state the HW data store may be corrupted leading to a DMA hang. The DMA hang requires a reset to correct. This fixes the HW configuration to avoid this condition. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28e1000e: Add check for reset flags before displaying reset messageCarolyn Wyborny1-2/+5
Some parts need to execute resets during normal operation. This flag check ensures that those parts reset without needlessly alarming the user. Other unexpected resets by other parts will dump debug info and message the reset action to the user, as originally intended. Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Acked-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28e1000e: reset PHY after errors detectedCarolyn Wyborny3-0/+63
Some errors can be induced in the PHY via environmental testing (specifically extreme temperature changes and electro static discharge testing), and in the case of the PHY hanging due to this input, this detects the problem and resets to continue. This issue only applies to 82574 silicon. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28pch_gbe: Select MII.David S. Miller1-0/+1
Reported-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27igb: Fix unused variable warning.Jesse Gross1-1/+0
Commit eab6d18d "vlan: Don't check for vlan group before vlan_tx_tag_present" removed the need for the adapter variable in igb_xmit_frame_ring_adv(). This removes the variable as well to avoid the compiler warning. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Jesse Gross <jesse@nicira.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27ehea: Fixing statisticsBreno Leitao2-6/+28
(Applied over Eric's "ehea: fix use after free" patch) Currently ehea stats are broken. The bytes counters are got from the hardware, while the packets counters are got from the device driver. Also, the device driver counters are resetted during the the down process, and the hardware aren't, causing some weird numbers. This patch just consolidates the packets and bytes on the device driver. Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27bonding: Fix lockdep warning after bond_vlan_rx_register()Jarek Poplawski1-2/+2
Fix lockdep warning: [ 52.991402] ====================================================== [ 52.991511] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] [ 52.991569] 2.6.36-04573-g4b60626-dirty #65 [ 52.991622] ------------------------------------------------------ [ 52.991696] ip/4842 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: [ 52.991758] (&bond->lock){++++..}, at: [<efe4d300>] bond_set_multicast_list+0x60/0x2c0 [bonding] [ 52.991966] [ 52.991967] and this task is already holding: [ 52.992008] (&bonding_netdev_addr_lock_key){+.....}, at: [<c04e5530>] dev_mc_sync+0x50/0xa0 [ 52.992008] which would create a new lock dependency: [ 52.992008] (&bonding_netdev_addr_lock_key){+.....} -> (&bond->lock){++++..} [ 52.992008] [ 52.992008] but this new dependency connects a SOFTIRQ-irq-safe lock: [ 52.992008] (&(&mc->mca_lock)->rlock){+.-...} [ 52.992008] ... which became SOFTIRQ-irq-safe at: [ 52.992008] [<c0272beb>] __lock_acquire+0x96b/0x1960 [ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0 [ 52.992008] [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50 [ 52.992008] [<c0584e40>] mld_ifc_timer_expire+0xf0/0x280 [ 52.992008] [<c024cee6>] run_timer_softirq+0x146/0x310 [ 52.992008] [<c024591d>] __do_softirq+0xad/0x1c0 [ 52.992008] [ 52.992008] to a SOFTIRQ-irq-unsafe lock: [ 52.992008] (&bond->lock){++++..} [ 52.992008] ... which became SOFTIRQ-irq-unsafe at: [ 52.992008] ... [<c0272c3b>] __lock_acquire+0x9bb/0x1960 [ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0 [ 52.992008] [<c05f36b8>] _raw_write_lock+0x38/0x50 [ 52.992008] [<efe4cbe4>] bond_vlan_rx_register+0x24/0x70 [bonding] [ 52.992008] [<c0598010>] register_vlan_dev+0xc0/0x280 [ 52.992008] [<c0599f3a>] vlan_newlink+0xaa/0xd0 [ 52.992008] [<c04ed4b4>] rtnl_newlink+0x404/0x490 [ 52.992008] [<c04ece35>] rtnetlink_rcv_msg+0x1e5/0x220 [ 52.992008] [<c050424e>] netlink_rcv_skb+0x8e/0xb0 [ 52.992008] [<c04ecbac>] rtnetlink_rcv+0x1c/0x30 [ 52.992008] [<c0503bfb>] netlink_unicast+0x24b/0x290 [ 52.992008] [<c0503e37>] netlink_sendmsg+0x1f7/0x310 [ 52.992008] [<c04cd41c>] sock_sendmsg+0xac/0xe0 [ 52.992008] [<c04ceb80>] sys_sendmsg+0x130/0x230 [ 52.992008] [<c04cf04e>] sys_socketcall+0xde/0x280 [ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36 [ 52.992008] [ 52.992008] other info that might help us debug this: ... [ Full info at netdev: Wed, 27 Oct 2010 12:24:30 +0200 Subject: [BUG net-2.6 vlan/bonding] lockdep splats ] Use BH variant of write_lock(&bond->lock) (as elsewhere in bond_main) to prevent this dependency. Fixes commit f35188faa0fbabefac476536994f4b6f3677380f [v2.6.36] Reported-by: Eric Dumazet <eric.dumazet@gmail.com> Tested-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: Jay Vosburgh <fubar@us.ibm.com>
2010-10-27tunnels: Fix tunnels change rcu protectionPavel Emelyanov4-0/+4
After making rcu protection for tunnels (ipip, gre, sit and ip6) a bug was introduced into the SIOCCHGTUNNEL code. The tunnel is first unlinked, then addresses change, then it is linked back probably into another bucket. But while changing the parms, the hash table is unlocked to readers and they can lookup the improper tunnel. Respective commits are b7285b79 (ipip: get rid of ipip_lock), 1507850b (gre: get rid of ipgre_lock), 3a43be3c (sit: get rid of ipip6_lock) and 94767632 (ip6tnl: get rid of ip6_tnl_lock). The quick fix is to wait for quiescent state to pass after unlinking, but if it is inappropriate I can invent something better, just let me know. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27ath5k: Fix double free on hw attach error pathJones Desougi1-9/+8
If ath5k_hw_attach fails it will free sc->ah (local variable ah) before returning. However, when it reports failure the caller (ath5k_pci_probe) will also free sc->ah. Let the caller handle the deallocation, it does so on further errors as well. Signed-off-by: Jones Desougi <jones.desougi@27m.se> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-27mac80211: Fix scan_ies_len to include DS ParamsJouni Malinen1-2/+3
Commit 651b52254fc061f02d965524e71de4333a009a5a added DS Parameter Set information into Probe Request frames that are transmitted on 2.4 GHz band, but it failed to increment local->scan_ies_len to cover this new information. This variable needs to be updated to match the maximum IE data length so that the extra buffer need gets reduced from the driver limit. Signed-off-by: Jouni Malinen <j@w1.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-27ath9k_htc: Set proper firmware offset for Netgear WNDA3200Rajkumar Manoharan1-2/+8
Netgear WNDA3200 device uses ar7010 firmware but it is failed to set correct firmware offset on firmware download which causes device initialization failure. Cc: stable@kernel.org Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-27ath9k: fix tx aggregation flush on AR9003Felix Fietkau1-9/+9
Completing aggregate frames can lead to new buffers being pushed into the tid queues due to software retransmission. When the tx queues are being drained, all pending aggregates must be completed before the tid queues get drained, otherwise buffers might be leaked. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.