- 09 6月, 2009 13 次提交
-
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
With the hope that these can be used to eliminate direct references to the frag list implementation. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Furthermore, it twiddles with the details of SKB list handling directly, which we're trying to eliminate. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 08 6月, 2009 27 次提交
-
-
由 Maciej W. Rozycki 提交于
A driver overhaul on 29 Feb 2000 (!) broke locking around fiddling with the tx descriptor ring in start_xmit(); a follow-on "fix" removed the broken remnants altogether. Here's a patch to restore proper locking in the function -- the complement in the interrupt handler has been correct all the time. This *may* have been the reason for the occasional confusion of the chip -- triggering a tx timeout followed by a chip reset sequence -- seen on R4k-based DECstations with the onboard Ethernet interface. Another theory is the confusion is due to an unindentified problem -- perhaps a silicon erratum -- associated with the variation of the MT ASIC used to interface the R4k CPU to the rest of the system on these computers; with its aggressive write-back buffering the design is particularly weakly ordered when it comes to MMIO (in the absence of ordering barriers uncached reads are allowed to bypass earlier uncached writes, even if to the same location), which may trigger all kinds of corner cases in peripheral hardware as well as software. Either way this piece of code is buggy. Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tilman Schmidt 提交于
Clarify calling context and return codes of callback methods, and add a description of the _cmsg structure and helper functions. Impact: documentation Signed-off-by: NTilman Schmidt <tilman@imap.cc> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tilman Schmidt 提交于
The dereferencing of the private pointer cmsg->m in capi_cmsg2str() may cause an Oops in case of an error, which is particularly inconvenient as that function is typically used to format an error message. Add a NULL pointer check to avoid this. Impact: error handling improvement Signed-off-by: NTilman Schmidt <tilman@imap.cc> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tilman Schmidt 提交于
Add kerneldoc comments for the exported funtions in capiutil.c. Impact: documentation Signed-off-by: NTilman Schmidt <tilman@imap.cc> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tilman Schmidt 提交于
Change the name of the Kernel CAPI exported function capi_ctr_reseted() to something representing its purpose better. Impact: renaming, no functional change Signed-off-by: NTilman Schmidt <tilman@imap.cc> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric W. Biederman 提交于
It is possible for tun_chr_close to race with dellink on the a tun device. In which case if __tun_get runs before dellink but dellink runs before tun_chr_close calls unregister_netdevice we will attempt to unregister the netdevice after it is already gone. The two cases are already serialized on the rtnl_lock, so I have gone for the cheap simple fix of moving rtnl_lock to cover __tun_get in tun_chr_close. Eliminating the possibility of the tun device being unregistered between __tun_get and unregister_netdevice in tun_chr_close. Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com> Tested-by: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andre Detsch 提交于
BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state)) was being hit during e100 EEH recovery. The problem source was a napi_enable call being made during e100_io_error_detected. Napi should remain disabled after e100_down, and only be reenabled when the interface is recovered. This patch also updates e100_io_error_detected in order to make it similar to the current versions of the error_detected callback in drivers such as e1000e and ixgbe. Signed-off-by: NAndre Detsch <adetsch@br.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Figo.zhang 提交于
vfree() does its own 'NULL' check, so no need for check before calling it. Signed-off-by: NFigo.zhang <figo1802@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yevgeny Petrilin 提交于
If mlx4_create_eq() would fail for one of EQ's assigned for completion handling, the code would try to free the same EQ we failed to create. The crash was found by Christoph Lameter Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sridhar Samudrala 提交于
Use the right structure while incrementing the offset in tun_get_user. Signed-off-by: NSridhar Samudrala <sri@us.ibm.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sridhar Samudrala 提交于
Increment the iovec base by the offset passed in for the initial copy_to_user() in memcpy_to_iovecend(). Signed-off-by: NSridhar Samudrala <sri@us.ibm.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sridhar Samudrala 提交于
I am working on enabling UFO between KVM guests using virtio-net and i have some patches that i got working with 2.6.30-rc8. When i wanted to try them with net-next-2.6, i noticed that virtio-net is not working with that tree. After some debugging, it turned out to be several bugs in the recent patches to fix aio with tun driver, specifically the following 2 commits. http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=0a1ec07a67bd8b0033dace237249654d015efa21 http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=6f26c9a7555e5bcca3560919db9b852015077dae Fix the call to memcpy_from_iovecend() in skb_copy_datagram_from_iovec to pass the right iovec offset. Signed-off-by: NSridhar Samudrala <sri@us.ibm.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric Dumazet 提交于
skb_dma_unmap() is quite expensive for small packets, because we use two different cache lines from skb_shared_info. One to access nr_frags, one to access dma_maps[0] Instead of dma_maps being an array of MAX_SKB_FRAGS + 1 elements, let dma_head alone in a new dma_head field, close to nr_frags, to reduce cache lines misses. Tested on my dev machine (bnx2 & tg3 adapters), nice speedup ! Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric Dumazet 提交于
Get rid of num_dma_maps in struct skb_shared_info, as it seems unused. Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tobias Klauser 提交于
Remove the private definition of TRUE/FALSE and use the ones from linux/stddef.h. Also remove the definition of BOOL which is not referenced inside the driver anyway. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Paulius Zaleckas 提交于
Signed-off-by: NPaulius Zaleckas <paulius.zaleckas@teltonika.lt> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Richard Röjfors 提交于
This is a driver for the Micrel KS8842 ethernet switch. The supplied code is for driving the KS8842 through the Timberdale FPGA on the Russellville board, a development board for Intel Atom CPU in the automotive area. Signed-off-by: NRichard Röjfors <richard.rojfors.ext@mocean-labs.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Herbert Xu 提交于
On Thu, Jun 04, 2009 at 09:06:00PM +1000, Herbert Xu wrote: > > tun: Optimise handling of bogus gso->hdr_len > > As all current versions of virtio_net generate a value for the > header length that's too small, we should optimise this so that > we don't copy it twice. This can be done by ensuring that it is > at least as large as the place where we'll write the checksum. > > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> With this applied we can strengthen the partial checksum check: In skb_partial_csum_set we check to see if the checksum offset is within the packet. However, we really should check that it is within the skb head as that's the only bit we can modify without copying. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Acked-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Herbert Xu 提交于
As all current versions of virtio_net generate a value for the header length that's too small, we should optimise this so that we don't copy it twice. This can be done by ensuring that it is at least as large as the place where we'll write the checksum. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Herbert Xu 提交于
Through a bug in the tun driver, I noticed that virtio_net is producing bogus hdr_len values. In particular, it only includes the IP header in the linear area, and excludes the entire TCP header. This causes the TCP header to be copied twice for each packet. (The bug omitted the second copy :) This patch corrects this. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Riccardo Ghetta 提交于
Fixes an initialization error; the chip negotiates gigabit, but the driver mistakenly handled it as 100Mb. Changes based on both SiS own GPL driver and forcedeth. Hopefully should fix http://bugzilla.kernel.org/show_bug.cgi?id=9735 http://bugzilla.kernel.org/show_bug.cgi?id=11149Signed-off-by: NRiccardo Ghetta <birrachiara@tin.it> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Riccardo Ghetta 提交于
Signed-off-by: NRiccardo Ghetta <birrachiara@tin.it> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Riccardo Ghetta 提交于
Signed-off-by: NRiccardo Ghetta <birrachiara@tin.it> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Riccardo Ghetta 提交于
Corrected dma sync handling on small packets. Should fix http://bugzilla.kernel.org/show_bug.cgi?id=11509 Note: While this bug was reported only on x86_64, it could have affected any architecture. Signed-off-by: NRiccardo Ghetta <birrachiara@tin.it> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ron Mercer 提交于
Some firmware mailbox commands require the firmware to communicate with the FCoE driver running on another PCI function. This can potentially take several seconds. This wait is done in process context only. Signed-off-by: NRon Mercer <ron.mercer@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ron Mercer 提交于
There are 8 banks of 'sub-registers' each of which are accessed through address/data register pair. An example would be reading flash or the xgmac. Accessing these require the driver to wait for a ready bit before writing the address and then accessing the data. This patch increases the timeout to 100us to prevent timeouts that have been seen on some platforms. These register are accessed in process context only. Signed-off-by: NRon Mercer <ron.mercer@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ron Mercer 提交于
Since an FCoE function shares a port with this NIC function, the jumbo settings must always be in place. This patch causes the hardware to be set up for jumbo if it is not already done. Signed-off-by: NRon Mercer <ron.mercer@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-