- 09 Jun, 2009 1 commit
-
-
Eric Dumazet authored
Michael Tokarev reported receiving a large packet could crash a machine with RTL8169 NIC. ( original thread at http://lkml.org/lkml/2009/6/8/192 ) Problem is this driver tells that NIC frames up to 16383 bytes can be received but provides skb to rx ring allocated with smaller sizes (1536 bytes in case standard 1500 bytes MTU is used) When a frame larger than what was allocated by driver is received, dma transfert can occurs past the end of buffer and corrupt kernel memory. Fix is to tell to NIC what is the maximum size a frame can be. This bug is very old, (before git introduction, linux-2.6.10), and should be backported to stable versions. Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Tested-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 02 Jun, 2009 3 commits
-
-
Minoru Usui authored
net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup This patch fixes a bug which unconfigured struct tcf_proto keeps chaining in tc_ctl_tfilter(), and avoids kernel panic in cls_cgroup_classify() when we use cls_cgroup. When we execute 'tc filter add', tcf_proto is allocated, initialized by classifier's init(), and chained. After it's chained, tc_ctl_tfilter() calls classifier's change(). When classifier's change() fails, tc_ctl_tfilter() does not free and keeps tcf_proto. In addition, cls_cgroup is initialized in change() not in init(). It accesses unconfigured struct tcf_proto which is chained before change(), then hits Oops. Signed-off-by: Minoru Usui <usui@mxm.nes.nec.co.jp> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca> Tested-by: Minoru Usui <usui@mxm.nes.nec.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Neil Horman authored
Patch to fix bad length checking in e1000. E1000 by default does two things: 1) Spans rx descriptors for packets that don't fit into 1 skb on recieve 2) Strips the crc from a frame by subtracting 4 bytes from the length prior to doing an skb_put Since the e1000 driver isn't written to support receiving packets that span multiple rx buffers, it checks the End of Packet bit of every frame, and discards it if its not set. This places us in a situation where, if we have a spanning packet, the first part is discarded, but the second part is not (since it is the end of packet, and it passes the EOP bit test). If the second part of the frame is small (4 bytes or less), we subtract 4 from it to remove its crc, underflow the length, and wind up in skb_over_panic, when we try to skb_put a huge number of bytes into the skb. This amounts to a remote DOS attack through careful selection of frame size in relation to interface MTU. The fix for this is already in the e1000e driver, as well as the e1000 sourceforge driver, but no one ever pushed it to e1000. This is lifted straight from e1000e, and prevents small frames from causing the underflow described above Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Tested-by: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ed Swierk authored
Add a phy_power_down parameter to forcedeth: set to 1 to power down the phy and disable the link when an interface goes down; set to 0 to always leave the phy powered up. The phy power state persists across reboots; Windows, some BIOSes, and older versions of Linux don't bother to power up the phy again, forcing users to remove all power to get the interface working (see http://bugzilla.kernel.org/show_bug.cgi?id=13072). Leaving the phy powered on is the safest default behavior. Users accustomed to seeing the link state reflect the interface state and/or wanting to minimize power consumption can set phy_power_down=1 if compatibility with other OSes is not an issue. Signed-off-by: Ed Swierk <eswierk@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 01 Jun, 2009 3 commits
-
-
Maciej W. Rozycki authored
Several EISA device IDs for 3c509 family network cards are missing from the driver, making the cards unusable in their EISA mode. Here's a fix to add them based on the EISA configuration files distributed by 3Com and our eisa.ids database. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
This patch adds me as the maintainer of the CPMAC (AR7) Ethernet driver. Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: David S. Miller <davem@davemloft.net>
- 30 May, 2009 4 commits
-
-
Matt Kraai authored
Signed-off-by: Matt Kraai <kraai@ftbfs.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Greg Kroah-Hartman authored
Gary Lin reports that a new device id needs to be added to the atl1e in order to get some new Asus hardware to work properly. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yevgeny Petrilin authored
When the transmit queue gets full we enable interrupts for TX completions There was a race that we handled the TX queue both from the interrupt context and from the transmit function. Using "spin_trylock_irq()" ensures this doesn't happen. Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 29 May, 2009 5 commits
-
-
John W. Linville authored
http://bugzilla.kernel.org/show_bug.cgi?id=13383Reported-by: Przemyslaw Kulczycki <azrael@autocom.pl> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
http://bugzilla.kernel.org/show_bug.cgi?id=13312 at76_dwork_hw_scan holds a mutex while calling ieee80211_scan_completed, which then calls at76_config which needs the same mutex. This reworks the ordering to not hold the lock while calling ieee80211_scan_completed. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Finn Thain authored
Fix the build for CONFIG_NET_POLL_CONTROLLER that I broke with 217cbfa8 ("mac8390: fix regression caused during net_device_ops conversion"). Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Divy Le Ray authored
Do not call t3_link_fault() under spinlock, as it calls msleep(). Besides, only the access to pi->link_fault needs to be serialized. Also initialize local variables before checking the link status, link state fields might otherwise end up containing garbage. Signed-off-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Divy Le Ray authored
Commit 5e68b772 cxgb3: map entire Rx page, feed map+offset to Rx ring. introduced a regression on platforms defining DECLARE_PCI_UNMAP_ADDR() and related macros as no-ops. Rx descriptors are fed with the a page buffer bus address + page chunk offset. The page buffer bus address is set and retrieved through pci_unamp_addr_set(), pci_unmap_addr(). These functions being meaningless on x86 (if CONFIG_DMA_API_DEBUG is not set). The HW ends up with a bogus bus address. This patch saves the page buffer bus address for all plaftorms. Signed-off-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 27 May, 2009 8 commits
-
-
-
Pablo Neira Ayuso authored
This problem was introduced in 72961ecf since no space was reserved for the new attributes NFULA_HWTYPE, NFULA_HWLEN and NFULA_HWHEADER. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Patrick McHardy <kaber@trash.net>
-
Jesper Dangaard Brouer authored
The function dl_seq_show() returns 1 (equal to SEQ_SKIP) in case a seq_printf() call return -1. It should return -1. This SEQ_SKIP behavior brakes processing the proc file e.g. via a pipe or just through less. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
-
Dave Young authored
The calls to flush_work() are pointless in a single thread workqueue and they are actually causing a lockdep warning. ============================================= [ INFO: possible recursive locking detected ] 2.6.30-rc6-02911-gbb803cfb #16 --------------------------------------------- bluetooth/2518 is trying to acquire lock: (bluetooth){+.+.+.}, at: [<c0130c14>] flush_work+0x28/0xb0 but task is already holding lock: (bluetooth){+.+.+.}, at: [<c0130424>] worker_thread+0x149/0x25e other info that might help us debug this: 2 locks held by bluetooth/2518: #0: (bluetooth){+.+.+.}, at: [<c0130424>] worker_thread+0x149/0x25e #1: (&conn->work_del){+.+...}, at: [<c0130424>] worker_thread+0x149/0x25e stack backtrace: Pid: 2518, comm: bluetooth Not tainted 2.6.30-rc6-02911-gbb803cfb #16 Call Trace: [<c03d64d9>] ? printk+0xf/0x11 [<c0140d96>] __lock_acquire+0x7ce/0xb1b [<c0141173>] lock_acquire+0x90/0xad [<c0130c14>] ? flush_work+0x28/0xb0 [<c0130c2e>] flush_work+0x42/0xb0 [<c0130c14>] ? flush_work+0x28/0xb0 [<f8b84966>] del_conn+0x1c/0x84 [bluetooth] [<c0130469>] worker_thread+0x18e/0x25e [<c0130424>] ? worker_thread+0x149/0x25e [<f8b8494a>] ? del_conn+0x0/0x84 [bluetooth] [<c0133843>] ? autoremove_wake_function+0x0/0x33 [<c01302db>] ? worker_thread+0x0/0x25e [<c013355a>] kthread+0x45/0x6b [<c0133515>] ? kthread+0x0/0x6b [<c01034a7>] kernel_thread_helper+0x7/0x10 Based on a report by Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Tested-by: Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Mike Frysinger authored
The previous commit "convert to net_device_ops" broke the Blackfin MAC driver as it declared the new structure before the function it used: CC drivers/net/bfin_mac.o drivers/net/bfin_mac.c:984: error: ‘bfin_mac_close’ undeclared here (not in a function) make[1]: *** [drivers/net/bfin_mac.o] Error 1 Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alex Chiang authored
Both atl1.c and atl2.c include atlx.h, which defines some modinfo stuff. But atl2.c seems like it doesn't want the modinfo data from atlx.h, as it defines its own. Running modinfo on atl2.ko, we get conflicting information: $ /sbin/modinfo drivers/net/atlx/atl2.ko | egrep "version|description|author" version: 2.2.3 description: Atheros Fast Ethernet Network Driver author: Atheros Corporation <xiong.huang@atheros.com>, Chris Snook <csnook@redhat.com> version: 2.1.3 author: Xiong Huang <xiong.huang@atheros.com>, Chris Snook <csnook@redhat.com>, Jay Cliburn <jcliburn@gmail.com> Move the modinfo data out of atlx.h and into atl1.c to eliminate the confusion: $ /sbin/modinfo drivers/net/atlx/atl1.ko | egrep "version|description|author" version: 2.1.3 author: Xiong Huang <xiong.huang@atheros.com>, Chris Snook <csnook@redhat.com>, Jay Cliburn <jcliburn@gmail.com> description: Atheros L1 Gigabit Ethernet Driver $ /sbin/modinfo drivers/net/atlx/atl2.ko | egrep "version|description|author" version: 2.2.3 description: Atheros Fast Ethernet Network Driver author: Atheros Corporation <xiong.huang@atheros.com>, Chris Snook <csnook@redhat.com> Reported-by: Scott Scriven <scott.scriven@hp.com> Signed-off-by: Alex Chiang <achiang@hp.com> Acked-by: Jay Cliburn <jcliburn@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xiaotian Feng authored
Gianfar interrupt handler uses IEVENT_ERR_MASK to check and handle errors. Babbling RX error (IEVENT_BABR) should be included in IEVENT_ERROR_MASK. Otherwise if BABR is raised, it never gets handled nor cleared, and an interrupt storm results. This has been observed to happen on sending a burst of ethernet frames to a gianfar based board. Signed-off-by: Xiaotian Feng <xiaotian.feng@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Menage authored
Avoid reading the unsynchronized value cs->classid multiple times, since it could change concurrently from non-zero to zero; this would result in the classifier returning a positive result with a bogus (zero) classid. Signed-off-by: Paul Menage <menage@google.com> Reviewed-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 26 May, 2009 4 commits
-
-
-
David Dillow authored
The 8169 chip only generates MSI interrupts when all enabled event sources are quiescent and one or more sources transition to active. If not all of the active events are acknowledged, or a new event becomes active while the existing ones are cleared in the handler, we will not see a new interrupt. The current interrupt handler masks off the Rx and Tx events once the NAPI handler has been scheduled, which opens a race window in which we can get another Rx or Tx event and never ACK'ing it, stopping all activity until the link is reset (ifconfig down/up). Fix this by always ACK'ing all event sources, and loop in the handler until we have all sources quiescent. Signed-off-by: David Dillow <dave@thedillows.org> Tested-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Doug Leith authored
This patch fixes ssthresh accounting issues in tcp_vegas when cwnd decreases Signed-off-by: Doug Leith <doug.leith@nuim.ie> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Finn Thain authored
Changeset ca17584b ("mac8390: update to net_device_ops") broke mac8390 by adding 8390.o to the link. That meant that lib8390.c was included twice, once in mac8390.c and once in 8390.c, subject to different macros. This patch reverts that by avoiding the wrappers in 8390.c. They seem to be of no value since COMPAT_NET_DEV_OPS is going away soon. Tested with a Kinetics EtherPort card. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 25 May, 2009 3 commits
-
-
Pablo Neira Ayuso authored
This patch adds the missing protocol state-change event reporting for DCCP. $ sudo conntrack -E [NEW] dccp 33 240 src=192.168.0.2 dst=192.168.1.2 sport=57040 dport=5001 [UNREPLIED] src=192.168.1.2 dst=192.168.1.100 sport=5001 dport=57040 With this patch: $ sudo conntrack -E [NEW] dccp 33 240 REQUEST src=192.168.0.2 dst=192.168.1.2 sport=57040 dport=5001 [UNREPLIED] src=192.168.1.2 dst=192.168.1.100 sport=5001 dport=57040 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Patrick McHardy <kaber@trash.net>
-
Jozsef Kadlecsik authored
Robert L Mathews discovered that some clients send evil TCP RST segments, which are accepted by netfilter conntrack but discarded by the destination. Thus the conntrack entry is destroyed but the destination retransmits data until timeout. The same technique, i.e. sending properly crafted RST segments, can easily be used to bypass connlimit/connbytes based restrictions (the sample script written by Robert can be found in the netfilter mailing list archives). The patch below adds a new flag and new field to struct ip_ct_tcp_state so that checking RST segments can be made more strict and thus TCP conntrack can catch the invalid ones: the RST segment is accepted only if its sequence number higher than or equal to the highest ack we seen from the other direction. (The last_ack field cannot be reused because it is used to catch resent packets.) Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Signed-off-by: Patrick McHardy <kaber@trash.net>
-
Lennert Buytenhek authored
Since commit 0fd56bb5 ("gianfar: Add support for skb recycling"), gianfar puts skbuffs that are in the rx ring back onto the recycle list as-is in case there was a receive error, but this breaks the following invariant: that all skbuffs on the recycle list have skb->data = skb->head + NET_SKB_PAD. The RXBUF_ALIGNMENT realignment done in gfar_new_skb() will be done twice on skbuffs recycled in this way, causing there not to be enough room in the skb anymore to receive a full packet, eventually leading to an skb_over_panic from gfar_clean_rx_ring() -> skb_put(). Resetting the skb->data pointer to skb->head + NET_SKB_PAD before putting the skb back onto the recycle list restores the mentioned invariant, and should fix this issue. Reported-by: Michael Guntsche <mike@it-loops.com> Tested-by: Michael Guntsche <mike@it-loops.com> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 22 May, 2009 1 commit
-
-
Inaky Perez-Gonzalez authored
When the i2400m is connected to a network, the host interface (USB) cannot be suspended. For that to happen, the device has to have negotiated with the basestation to put the link on IDLE state. If the host tries to put the device in standby while it is connected but not idle, the device resets, as the driver should not do that. To avoid triggering that, when the USB susbsytem requires the driver to autosuspend the device, the driver checks if the device is not yet idle. If it is not, the request is rejected (will be retried again later on after the autosuspend timeout). At some point the device will enter idle and the request will succeed (unless of course, there is network traffic, but at that point, there is no idle neither in the link or the host interface). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
-
- 21 May, 2009 8 commits
-
-
Dan Carpenter authored
rxrpc_alloc_connection() doesn't return an error code on failure, it just returns NULL. IS_ERR(NULL) is false. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Robert Olsson authored
It seems we can fix this by disabling preemption while we re-balance the trie. This is with the CONFIG_CLASSIC_RCU. It's been stress-tested at high loads continuesly taking a full BGP table up/down via iproute -batch. Note. fib_trie is not updated for CONFIG_PREEMPT_RCU Reported-by: Andrei Popa Signed-off-by: Robert Olsson <robert.olsson@its.uu.se> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Westphal authored
typo -- pkt_dev->nflows is for stats only, the number of concurrent flows is stored in cflows. Reported-By: Vladimir Ivashchenko <hazard@francoudi.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Roel Kluin authored
Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jean-Mickael Guerin authored
The use of unspecified protocol in IPv6 initial route prevents quagga to install IPv6 default route: # show ipv6 route S ::/0 [1/0] via fe80::1, eth1_0 K>* ::/0 is directly connected, lo, rej C>* ::1/128 is directly connected, lo C>* fe80::/64 is directly connected, eth1_0 # ip -6 route fe80::/64 dev eth1_0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit -1 ff00::/8 dev eth1_0 metric 256 mtu 1500 advmss 1440 hoplimit -1 unreachable default dev lo proto none metric -1 error -101 hoplimit 255 The attached patch ensures RTPROT_KERNEL to the default initial route and fixes the problem for quagga. This is similar to "ipv6: protocol for address routes" f410a1fb. # show ipv6 route S>* ::/0 [1/0] via fe80::1, eth1_0 C>* ::1/128 is directly connected, lo C>* fe80::/64 is directly connected, eth1_0 # ip -6 route fe80::/64 dev eth1_0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit -1 fe80::/64 dev eth1_0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit -1 ff00::/8 dev eth1_0 metric 256 mtu 1500 advmss 1440 hoplimit -1 default via fe80::1 dev eth1_0 proto zebra metric 1024 mtu 1500 advmss 1440 hoplimit -1 unreachable default dev lo proto kernel metric -1 error -101 hoplimit 255 Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Alexander V. Lukyanov found a regression in 2.6.29 and made a complete analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339 Quoted here because its a perfect one : begin_of_quotation 2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the patch has at least one critical flaw, and another problem. rt_intern_hash calculates rthi pointer, which is later used for new entry insertion. The same loop calculates cand pointer which is used to clean the list. If the pointers are the same, rtable leak occurs, as first the cand is removed then the new entry is appended to it. This leak leads to unregister_netdevice problem (usage count > 0). Another problem of the patch is that it tries to insert the entries in certain order, to facilitate counting of entries distinct by all but QoS parameters. Unfortunately, referencing an existing rtable entry moves it to list beginning, to speed up further lookups, so the carefully built order is destroyed. For the first problem the simplest patch it to set rthi=0 when rthi==cand, but it will also destroy the ordering. end_of_quotation Problematic commit is 1080d709 (net: implement emergency route cache rebulds when gc_elasticity is exceeded) Trying to keep dst_entries ordered is too complex and breaks the fact that order should depend on the frequency of use for garbage collection. A possible fix is to make rt_intern_hash() simpler, and only makes rt_check_expire() a litle bit smarter, being able to cope with an arbitrary entries order. The added loop is running on cache hot data, while cpu is prefetching next object, so should be unnoticied. Reported-and-analyzed-by: Alexander V. Lukyanov <lav@yar.ru> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
rt_check_expire() computes average and standard deviation of chain lengths, but not correclty reset length to 0 at beginning of each chain. This probably gives overflows for sum2 (and sum) on loaded machines instead of meaningful results. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-