- 10 8月, 2010 8 次提交
-
-
由 Jarek Poplawski 提交于
pkt_sched: Add some basic qdisc class ops verification. Was: [PATCH] sfq: add dummy bind/unbind handles Verify in register_qdisc() some basic qdisc class handlers are present. Signed-off-by: NJarek Poplawski <jarkao2@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jarek Poplawski 提交于
pkt_sched: sch_sfq: Add dummy unbind_tcf and put handles. Was: [PATCH] sfq: add dummy bind/unbind handles Add dummy .unbind_tcf and .put qdisc class ops for easier verification. (All other schedulers have it like this.) Signed-off-by: NJarek Poplawski <jarkao2@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
qlcnic_pci_info structs are 128 bytes so an array of 8 uses 1024 bytes. That's a lot if you run with 4K stacks. I allocated them with kcalloc() instead. Signed-off-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
In the original code we allocated memory conditionally and freed it in the error handling unconditionally. It turns out that this function is only called during initialization and "adapter->npars" and "adapter->eswitch" are always NULL at the start of the function. I removed those checks. Also since I was cleaning things, I changed the error handling for qlcnic_get_pci_info() and pulled everything in an indent level. Signed-off-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Randy Dunlap 提交于
Fix phy.c kernel-doc notation: Warning(drivers/net/phy/phy.c:313): No description found for parameter 'ifr' Warning(drivers/net/phy/phy.c:313): Excess function parameter 'mii_data' description in 'phy_mii_ioctl' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Randy Dunlap 提交于
Add missing kernel-doc notation to struct sock: Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_pid' Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_cred' Warning(include/net/sock.h:324): No description found for parameter 'sk_classid' Warning(include/net/sock.h:324): Excess struct/union/enum/typedef member 'sk_peercred' description in 'sock' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Randy Dunlap 提交于
Fix etherdevice.h parameter name typo in kernel-doc: Warning(include/linux/etherdevice.h:138): No description found for parameter 'hwaddr' Warning(include/linux/etherdevice.h:138): Excess function parameter 'addr' description in 'dev_hw_addr_random' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
drivers/net/wan/farsync.c: In function 'fst_intr_rx': drivers/net/wan/farsync.c:1312: warning: cast to pointer from integer of different size drivers/net/wan/farsync.c: In function 'do_bottom_half_tx': drivers/net/wan/farsync.c:1407: warning: cast to pointer from integer of different size The "skb" and "mem" arguments being passed here are DMA addresses being programmed into the hardware registers, so pass them as the type that they actually are. And use the correct printf formatting in debug logging statements for these things to match the type change. Reported-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 8月, 2010 4 次提交
-
-
由 Jeff Kirsher 提交于
Adds documentation for the igbvf (igb virtual function driver). v2: - Removed trailing white space - Removed Ethtool version info Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jeff Kirsher 提交于
Add documentation for the igb networking driver. v2: - Removed trailing white space - Removed Ethtool version info - Removed LRO kernel version info Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jeff Kirsher 提交于
Based on patches from Sonny Rao and Milton Miller... Combined the patches to fix up clean_tx_irq and clean_rx_irq. The PowerPC architecture does not require loads to independent bytes to be ordered without adding an explicit barrier. In ixgbe_clean_rx_irq we load the status bit then load the packet data. With packet split disabled if these loads go out of order we get a stale packet, but we will notice the bad sequence numbers and drop it. The problem occurs with packet split enabled where the TCP/IP header and data are in different descriptors. If the reads go out of order we may have data that doesn't match the TCP/IP header. Since we use hardware checksumming this bad data is never verified and it makes it all the way to the application. This bug was found during stress testing and adding this barrier has been shown to fix it. The bug can manifest as a data integrity issue (bad payload data) or as a BUG in skb_pull(). This was a nasty bug to hunt down, if people agree with the fix I think it's a candidate for stable. Previously Submitted to e1000-devel only for ixgbe http://marc.info/?l=e1000-devel&m=126593062701537&w=3 We've now seen this problem hit with other device drivers (e1000e mostly) So I'm resubmitting with fixes for other Intel Device Drivers with similar issues. CC: Milton Miller <miltonm@bga.com> CC: Anton Blanchard <anton@samba.org> CC: Sonny Rao <sonnyrao@us.ibm.com> CC: stable <stable@kernel.org> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 John Fastabend 提交于
Building ixgbe without DCB_CONFIG and FCOE_CONFIG will cause a build error. This resolves the build error by wrapping the fcoe.up in CONFIG_IXGBE_DCB ifdefs. Also frames were being priority VLAN tagged even without DCB enabled. This fixes this so that 8021Q priority tags are only added with DCB actually enabled. Reported-by: Ndivya <dipraksh@linux.vnet.ibm.com> Reported-by: NJon Mason <jon.mason@exar.com> Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com> Tested-by: NStephen Ko <stephen.s.ko@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 08 8月, 2010 7 次提交
-
-
由 Amit Kumar Salecha 提交于
Signed-off-by: NAmit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
I moved the kfree(cb) below the dereferences. Signed-off-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
We should unlock here. This is the only place where we return from the function with the lock held. The caller isn't expecting it. Signed-off-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David Woodhouse 提交于
We were seeing faults in the solos-pci receive tasklet when packets arrived for a VCC which was currently being closed: [18842.727906] EIP: [<e082f490>] br2684_push+0x19/0x234 [br2684] SS:ESP 0068:dfb89d14 [18845.090712] [<c13ecff3>] ? do_page_fault+0x0/0x2e1 [18845.120042] [<e082f490>] ? br2684_push+0x19/0x234 [br2684] [18845.153530] [<e084fa13>] solos_bh+0x28b/0x7c8 [solos_pci] [18845.186488] [<e084f711>] ? solos_irq+0x2d/0x51 [solos_pci] [18845.219960] [<c100387b>] ? handle_irq+0x3b/0x48 [18845.247732] [<c10265cb>] ? irq_exit+0x34/0x57 [18845.274437] [<c1025720>] tasklet_action+0x42/0x69 [18845.303247] [<c102643f>] __do_softirq+0x8e/0x129 [18845.331540] [<c10264ff>] do_softirq+0x25/0x2a [18845.358274] [<c102664c>] _local_bh_enable_ip+0x5e/0x6a [18845.389677] [<c102666d>] local_bh_enable+0xb/0xe [18845.417944] [<e08490a8>] ppp_unregister_channel+0x32/0xbb [ppp_generic] [18845.458193] [<e08731ad>] pppox_unbind_sock+0x18/0x1f [pppox] This patch uses an RCU-inspired approach to fix it. In the RX tasklet's find_vcc() function we first refuse to use a VCC which already has the ATM_VF_READY bit cleared. And in the VCC close function, we synchronise with the tasklet to ensure that it can't still be using the VCC before we continue and allow the VCC to be destroyed. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Tested-by: NNathan Williams <nathan@traverse.com.au> Cc: stable@kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jarek Poplawski 提交于
Since there was added ->tcf_chain() method without ->bind_tcf() to sch_sfq class options, there is oops when a filter is added with the classid parameter. Fixes commit 7d2681a6 netdev thread: null pointer at cls_api.c Signed-off-by: NJarek Poplawski <jarkao2@gmail.com> Reported-by: NFranchoze Eric <franchoze@yandex.ru> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Changli Gao 提交于
Although netif_rx() isn't expected to be called in process context with preemption enabled, it'd better handle this case. And this is why get_cpu() is used in the non-RPS #ifdef branch. If tree RCU is selected, rcu_read_lock() won't disable preemption, so preempt_disable() should be called explictly. Signed-off-by: NChangli Gao <xiaosuo@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dmitry Popov 提交于
tcp_parse_md5sig_option doesn't check md5sig option (TCPOPT_MD5SIG) length, but tcp_v[46]_inbound_md5_hash assume that it's at least 16 bytes long. Signed-off-by: NDmitry Popov <dp@highloadlab.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 07 8月, 2010 3 次提交
-
-
由 Johannes Berg 提交于
spin_is_locked() can return zero on some (UP?) configurations because locks don't exist, and that causes an endless amount of warnings. Use lockdep_assert_held() instead, which has two advantages: 1) it verifies the current task is holding the lock or mutex 2) it compiles away completely when lockdep is not enabled Cc: stable@kernel.org [2.6.34+, maybe only parts of patch] Reported-by: NThomas Meyer <thomas@m3y3r.de> Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
The TX tracing code copies with the wrong length, which will typically copy too little data. Fix this by using the correct length variable. Cc: stable@kernel.org [2.6.32+] Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
- 06 8月, 2010 9 次提交
-
-
由 Dan Carpenter 提交于
The main motivation of this patch changing strcpy() to strlcpy(). We strcpy() to copy a 48 byte buffers into a 49 byte buffers. So at best the last byte has leaked information, or maybe there is an overflow? Anyway, this patch closes the information leaks by zeroing the memory and the calls to strlcpy() prevent overflows. Signed-off-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jarek Poplawski 提交于
The netpoll_rx_on() check in __napi_gro_receive() skips part of the "common" GRO_NORMAL path, especially "pull:" in dev_gro_receive(), where at least eth header should be copied for entirely paged skbs. Signed-off-by: NJarek Poplawski <jarkao2@gmail.com> Acked-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Christian Samsel 提交于
With turned on hspa modem (Dell 5530 internal card) and activated usb auto suspend, my system gets up 100 "usbnet_resume has delayed data" per minute. I didnt noticed any pathological behaviour, so just drop this message. if any objections, please at least change it to _DEBUG. Signed-off-by: NChristian Samsel <christian.samsel@rwth-aachen.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 John W. Linville 提交于
ieee80211_beacon_get can return NULL... Signed-off-by: NJohn W. Linville <linville@tuxdriver.com> Cc: stable@kernel.org
-
由 Sujith 提交于
So long. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Dan Williams 提交于
Fix this leftover TODO from the cfg80211 conversion by doing a scan if cfg80211 didn't pass in the BSSID for us. Since the scan code uses so much of the cfg80211_scan_request structure to build up the firmware command, we just fake one when the scan request is triggered internally. But we need to make sure that internal 'fake' cfg82011 scan request does not get back to cfg82011 via cfg80211_scan_done(). Signed-off-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Dan Williams 提交于
Some APs get pissy if you don't send the firmware the extended rates in the association request's rates TLV. Found this on a Linksys WRT54G v2; it denies association with status code 18 unless you add the extended rates too. The old driver did this, but it got lost in the cfg80211 conversion. Signed-off-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Dan Williams 提交于
Let's actually check the right field in the command response; and if there aren't any reported BSSes, exit early with success. Signed-off-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 8月, 2010 9 次提交
-
-
由 Rusty Russell 提交于
I often use "ethtool -i" command to check what driver controls the ehternet device. But because current virtio_net driver doesn't support "ethtool -i", it becomes the following: # ethtool -i eth3 Cannot get driver information: Operation not supported This patch simply adds the "ethtool -i" support. The following is the result when using the virtio_net driver with my patch applied to. # ethtool -i eth3 driver: virtio_net version: N/A firmware-version: N/A bus-info: virtio0 Personally, "-i" is one of the most frequently-used option, and most network drivers support "ethtool -i", so I think virtio_net also should do. Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (use ARRAY_SIZE) Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 stephen hemminger 提交于
The PPP channel ops structure should be const. Cleanup the declarations to use standard C99 format. Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David Howells 提交于
RxRPC can potentially deadlock as rxrpc_resend_time_expired() wants to get call->state_lock so that it can alter the state of an RxRPC call. However, its caller (call_timer_fn()) has an apparent lock on the timer struct. The problem is that rxrpc_resend_time_expired() isn't permitted to lock call->state_lock as this could cause a deadlock against rxrpc_send_abort() as that takes state_lock and then attempts to delete the resend timer by calling del_timer_sync(). The deadlock can occur because del_timer_sync() will sit there forever waiting for rxrpc_resend_time_expired() to return, but the latter may then wait for call->state_lock, which rxrpc_send_abort() holds around del_timer_sync()... This leads to a warning appearing in the kernel log that looks something like the attached. It should be sufficient to simply dispense with the locks. It doesn't matter if we set the resend timer expired event bit and queue the event processor whilst we're changing state to one where the resend timer is irrelevant as the event can just be ignored by the processor thereafter. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.35-rc3-cachefs+ #115 ------------------------------------------------------- swapper/0 is trying to acquire lock: (&call->state_lock){++--..}, at: [<ffffffffa00200d4>] rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc] but task is already holding lock: (&call->resend_timer){+.-...}, at: [<ffffffff8103b675>] run_timer_softirq+0x182/0x2a5 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&call->resend_timer){+.-...}: [<ffffffff810560bc>] __lock_acquire+0x889/0x8fa [<ffffffff81056184>] lock_acquire+0x57/0x6d [<ffffffff8103bb9c>] del_timer_sync+0x3c/0x86 [<ffffffffa002bb7a>] rxrpc_send_abort+0x50/0x97 [af_rxrpc] [<ffffffffa002bdd9>] rxrpc_kernel_abort_call+0xa1/0xdd [af_rxrpc] [<ffffffffa0061588>] afs_deliver_to_call+0x129/0x368 [kafs] [<ffffffffa006181b>] afs_process_async_call+0x54/0xff [kafs] [<ffffffff8104261d>] worker_thread+0x1ef/0x2e2 [<ffffffff81045f47>] kthread+0x7a/0x82 [<ffffffff81002cd4>] kernel_thread_helper+0x4/0x10 -> #0 (&call->state_lock){++--..}: [<ffffffff81055237>] validate_chain+0x727/0xd23 [<ffffffff810560bc>] __lock_acquire+0x889/0x8fa [<ffffffff81056184>] lock_acquire+0x57/0x6d [<ffffffff813e6b69>] _raw_read_lock_bh+0x34/0x43 [<ffffffffa00200d4>] rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc] [<ffffffff8103b6e6>] run_timer_softirq+0x1f3/0x2a5 [<ffffffff81036828>] __do_softirq+0xa2/0x13e [<ffffffff81002dcc>] call_softirq+0x1c/0x28 [<ffffffff810049f0>] do_softirq+0x38/0x80 [<ffffffff810361a2>] irq_exit+0x45/0x47 [<ffffffff81018fb3>] smp_apic_timer_interrupt+0x88/0x96 [<ffffffff81002893>] apic_timer_interrupt+0x13/0x20 [<ffffffff810011ac>] cpu_idle+0x4d/0x83 [<ffffffff813e06f3>] start_secondary+0x1bd/0x1c1 other info that might help us debug this: 1 lock held by swapper/0: #0: (&call->resend_timer){+.-...}, at: [<ffffffff8103b675>] run_timer_softirq+0x182/0x2a5 stack backtrace: Pid: 0, comm: swapper Not tainted 2.6.35-rc3-cachefs+ #115 Call Trace: <IRQ> [<ffffffff81054414>] print_circular_bug+0xae/0xbd [<ffffffff81055237>] validate_chain+0x727/0xd23 [<ffffffff810560bc>] __lock_acquire+0x889/0x8fa [<ffffffff810539a7>] ? mark_lock+0x42f/0x51f [<ffffffff81056184>] lock_acquire+0x57/0x6d [<ffffffffa00200d4>] ? rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc] [<ffffffff813e6b69>] _raw_read_lock_bh+0x34/0x43 [<ffffffffa00200d4>] ? rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc] [<ffffffffa00200d4>] rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc] [<ffffffff8103b6e6>] run_timer_softirq+0x1f3/0x2a5 [<ffffffff8103b675>] ? run_timer_softirq+0x182/0x2a5 [<ffffffffa002007e>] ? rxrpc_resend_time_expired+0x0/0x96 [af_rxrpc] [<ffffffff810367ef>] ? __do_softirq+0x69/0x13e [<ffffffff81036828>] __do_softirq+0xa2/0x13e [<ffffffff81002dcc>] call_softirq+0x1c/0x28 [<ffffffff810049f0>] do_softirq+0x38/0x80 [<ffffffff810361a2>] irq_exit+0x45/0x47 [<ffffffff81018fb3>] smp_apic_timer_interrupt+0x88/0x96 [<ffffffff81002893>] apic_timer_interrupt+0x13/0x20 <EOI> [<ffffffff81049de1>] ? __atomic_notifier_call_chain+0x0/0x86 [<ffffffff8100955b>] ? mwait_idle+0x6e/0x78 [<ffffffff81009552>] ? mwait_idle+0x65/0x78 [<ffffffff810011ac>] cpu_idle+0x4d/0x83 [<ffffffff813e06f3>] start_secondary+0x1bd/0x1c1 Signed-off-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Changli Gao 提交于
The packet length should be checked before the packet data is dereferenced. Signed-off-by: NChangli Gao <xiaosuo@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Changli Gao 提交于
The packet length should be checked before the packet data is dereferenced. Signed-off-by: NChangli Gao <xiaosuo@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Changli Gao 提交于
The packet length should be checked before the packet data is dereferenced. Signed-off-by: NChangli Gao <xiaosuo@gmail.com> Acked-by: NPatrick McHardy <kaber@trash.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Changli Gao 提交于
Signed-off-by: NChangli Gao <xiaosuo@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Changli Gao 提交于
On the TX path, skb->data points to the ethernet header, not the network header. So when validating the packet length for accessing we should take the ethernet header into account. Signed-off-by: NChangli Gao <xiaosuo@gmail.com> Acked-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Joe Perches 提交于
Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-