- 13 Apr, 2008 2 commits
-
-
Pavel Emelyanov authored
The ax25_uid_free call walks the ax25_uid_list and releases entries from it. The problem is that after the fisrt call to hlist_del_init the hlist_for_each_entry (which hides behind the ax25_uid_for_each) will consider the current position to be the last and will return. Thus, the whole list will be left not freed. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sergei Shtylyov authored
The driver stores the PCI resource addresses into 'unsigned long' variable before calling ioremap_nocache() on them. This warrants kernel oops when the registers are accessed on PPC 44x platforms which (being 32-bit) have PCI memory space mapped beyond 4 GB. The arch/ppc/ kernel has a fixup in ioremap() that creates an illusion that the PCI memory resource is mapped below 4 GB, but arch/powerpc/ code got rid of this trick, having instead CONFIG_RESOURCES_64BIT enabled. [ Bump driver version and release date -DaveM ] Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 12 Apr, 2008 10 commits
-
-
Krzysztof Halasa authored
PPP support in generic HDLC in Linux 2.6.25 is broken and will cause a kernel panic when a device configured in PPP mode is activated. It will be replaced by new PPP implementation after Linux 2.6.25 is released. This affects only PPP support in generic HDLC (mostly Hitachi SCA and SCA-II based drivers, wanxl, and few others). Standalone syncppp and async PPP support are not affected. Signed-off-by:
Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Thomas Klein authored
This patch fixes two weaknesses in send/receive packet handling which may lead to kernel panics during DLPAR memory add operations. Signed-off-by:
Thomas Klein <tklein@de.ibm.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Stephen Hemminger authored
Add missing sysfs device association. Compile tested only -ENOHW. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=10380Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Cc: Cesar Eduardo Barros <cesarb@cesarb.net> Cc: <tom@sharkbay.at> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Sonic Zhang authored
http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3956Signed-off-by:
Sonic Zhang <sonic.zhang@analog.com> Signed-off-by:
Bryan Wu <cooloney@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Ayaz Abdulla authored
This critical patch fixes a mac address issue recently introduced. If the device's mac address was in correct order and the flag NVREG_TRANSMITPOLL_MAC_ADDR_REV was set, during nv_remove the flag would get cleared. During next load, the mac address would get reversed because the flag is missing. As it has been indicated previously, the flag is cleared across a low power transition. Therefore, the driver should set the mac address back into the reversed order when clearing the flag. Also, the driver should set back the flag after a low power transition to protect against kexec command calling nv_probe a second time. Signed-off-by:
Ayaz Abdulla <aabdulla@nvidia.com> Cc: "Yinghai Lu" <yhlu.kernel@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Atsushi Nemoto authored
It seems no good reason to use comma here. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Atsushi Nemoto authored
Call phy_disconnect() on remove routine. Otherwise the phy timer causes a kernel crash when unloading. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Joakim Tjernlund authored
The new Fixed PHY method, fixed-link property, isn't impl. for ucc_geth which makes fixed PHYs non functional. Add support for the new method to restore the Fixed PHY functionality. Signed-off-by:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by:
Li Yang <leoli@freescale.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Laurent Pinchart authored
fs_enet_close() calls napi_disable() unconditionally. This patch skips the call when use_napi isn't set. Signed-off-by:
Laurent Pinchart <laurentp@cse-semaphore.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Stephen Hemminger authored
Any usage of sky2 on new Yukon Supreme would cause a NULL dereference. The chip is very new, so the support is still untested; vendor has not sent any eval hardware. Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
- 11 Apr, 2008 1 commit
-
-
Daniel Lezcano authored
Copy the network namespace from the socket to the timewait socket. Signed-off-by:
Daniel Lezcano <dlezcano@fr.ibm.com> Acked-by:
Mark Lord <mlord@pobox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 10 Apr, 2008 1 commit
-
-
David S. Miller authored
This fixes kernel bugzilla 10371. As reported by M.Piechaczek@osmosys.tv, if we try to grab a char sized socket option value, as in: unsigned char ttl = 255; socklen_t len = sizeof(ttl); setsockopt(socket, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, &len); getsockopt(socket, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, &len); The ttl returned will be wrong on big-endian, and on both little- endian and big-endian the next three bytes in userspace are written with garbage. It's because of this test in do_ip_getsockopt(): if (len < sizeof(int) && len > 0 && val>=0 && val<255) { It should allow a 'val' of 255 to pass here, but it doesn't so it copies a full 'int' back to userspace. On little-endian that will write the correct value into the location but it spams on the next three bytes in userspace. On big endian it writes the wrong value into the location and spams the next three bytes. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 09 Apr, 2008 9 commits
-
-
Eliezer Tamir authored
Fixed bug: Wrong register was written to when bringing the chip out of reset. [ Bump driver version and release date -DaveM ] Signed-off-by:
Eliezer Tamir <eliezert@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jan Engelhardt authored
Without this patch, the generic L3 tracker would kick in if nf_conntrack_ipv4 was not loaded before nf_nat, which would lead to translation problems with ICMP errors. NAT does not make sense without IPv4 connection tracking anyway, so just add a call to need_ipv4_conntrack(). Signed-off-by:
Jan Engelhardt <jengelh@computergmbh.de> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
Shifts larger than the data type are undefined, don't try to shift an u32 by 32. Also remove some special-casing of bitmasks divisible by 32. Based on patch by Jan Engelhardt <jengelh@computergmbh.de>. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
Commit df9dcb45 ([IPSEC]: Fix inter address family IPsec tunnel handling) broke openswan by removing the selector initialization for tunnel mode in case it is uninitialized. This patch restores the initialization, fixing openswan, but probably breaking inter-family tunnels again (unknown since the patch author disappeared). The correct thing for inter-family tunnels is probably to simply initialize the selector family explicitly. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daniel Wagner authored
The layer above will free the skb in an error case. Signed-off-by:
Daniel Wagner <wagi@monom.org> Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This fixes assignment of the interrupt vectors on the SSB MIPS core. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
This fixes the TPS flag handling for the SSB pcicore driver. This fixes interrupts on some devices. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Vladimir Koutny authored
When associating to a b-only AP where there is no ERP IE, short preamble mode is left at previous state (probably also protection mode). In this case, disable protection and use short preamble mode as specified in capability field. The same is done if capability field is changed on-the-fly. Signed-off-by:
Vladimir Koutny <vlado@ksp.sk> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 08 Apr, 2008 10 commits
-
-
David S. Miller authored
If print_mac() is used inside of a pr_debug() the compiler can't see that the call is redundant so still performs it even of pr_debug() ends up being a nop. So don't use print_mac() in such cases in hot code paths, use MAC_FMT et al. instead. As noted by Joe Perches, pr_debug() could be modified to handle this better, but that is a change to an interface used by the entire kernel and thus needs to be validated carefully. This here is thus the less risky fix for 2.6.25 Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ilpo Järvinen authored
MTU probe can cause some remedies for FRTO because the normal packet ordering may be violated allowing FRTO to make a wrong decision (it might not be that serious threat for anything though). Thus it's safer to not run FRTO while MTU probe is underway. It seems that the basic FRTO variant should also look for an skb at probe_seq.start to check if that's retransmitted one but I didn't implement it now (plain seqno in window check isn't robust against wraparounds). Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ilpo Järvinen authored
This fixes Bugzilla #10384 tcp_simple_retransmit does L increment without any checking whatsoever for overflowing S+L when Reno is in use. The simplest scenario I can currently think of is rather complex in practice (there might be some more straightforward cases though). Ie., if mss is reduced during mtu probing, it may end up marking everything lost and if some duplicate ACKs arrived prior to that sacked_out will be non-zero as well, leading to S+L > packets_out, tcp_clean_rtx_queue on the next cumulative ACK or tcp_fastretrans_alert on the next duplicate ACK will fix the S counter. More straightforward (but questionable) solution would be to just call tcp_reset_reno_sack() in tcp_simple_retransmit but it would negatively impact the probe's retransmission, ie., the retransmissions would not occur if some duplicate ACKs had arrived. So I had to add reno sacked_out reseting to CA_Loss state when the first cumulative ACK arrives (this stale sacked_out might actually be the explanation for the reports of left_out overflows in kernel prior to 2.6.23 and S+L overflow reports of 2.6.24). However, this alone won't be enough to fix kernel before 2.6.24 because it is building on top of the commit 1b6d427b ([TCP]: Reduce sacked_out with reno when purging write_queue) to keep the sacked_out from overflowing. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Reported-by:
Alessandro Suardi <alessandro.suardi@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ilpo Järvinen authored
Fixes a long-standing bug which makes NewReno recovery crippled. With GSO the whole head skb was marked as LOST which is in violation of NewReno procedure that only wants to mark one packet and ended up breaking our TCP code by causing counter overflow because our code was built on top of assumption about valid NewReno procedure. This manifested as triggering a WARN_ON for the overflow in a number of places. It seems relatively safe alternative to just do nothing if tcp_fragment fails due to oom because another duplicate ACK is likely to be received soon and the fragmentation will be retried. Special thanks goes to Soeren Sonnenburg <kernel@nn7.de> who was lucky enough to be able to reproduce this so that the warning for the overflow was hit. It's not as easy task as it seems even if this bug happens quite often because the amount of outstanding data is pretty significant for the mismarkings to lead to an overflow. Because it's very late in 2.6.25-rc cycle (if this even makes in time), I didn't want to touch anything with SACK enabled here. Fragmenting might be useful for it as well but it's more or less a policy decision rather than mandatory fix. Thus there's no need to rush and we can postpone considering tcp_fragment with SACK for 2.6.26. In 2.6.24 and earlier, this very same bug existed but the effect is slightly different because of a small changes in the if conditions that fit to the patch's context. With them nothing got lost marker and thus no retransmissions happened. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ilpo Järvinen authored
The fast retransmission can be forced locally to the rfc3517 branch in tcp_update_scoreboard instead of making such fragile constructs deeper in tcp_mark_head_lost. This is necessary for the next patch which must not have loopholes for cnt > packets check. As one can notice, readability got some improvements too because of this :-). Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Johannes Berg authored
This fixes the STA AID setting and actually makes hostapd/mac80211 work properly in presence of power-saving stations. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Stefano Brivio authored
This fixes an hard crash which happened upon driver loading on bcm4303 rev. 2 devices. Signed-off-by:
Stefano Brivio <stefano.brivio@polimi.it> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Abhijeet Kolekar authored
This patch enables the IWL4965_HT flag (n-band) in Kconfig. Removed the "depends on n" from Kconfig for config IWL4965_HT Signed-off-by:
Abhijeet Kolekar <abhijeet.kolekar@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Daniel Drake authored
Commit bada339b enforces that all interfaces have a valid MAC address before they are brought up. ipw2200 does not assign a MAC address to it's radiotap interface, meaning that the radiotap interface cannot be brought up in 2.6.24. https://bugs.gentoo.org/show_bug.cgi?id=215714 Fix this by copying the MAC address from the real interface. Signed-off-by:
Daniel Drake <dsd@gentoo.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Holger Schurig authored
After moving lbs_find_best_network_ssid() from scan.c to assoc.c gcc was able to deduce that new_mode might stay uninitialized. Signed-off-by:
Holger Schurig <hs4233@mail.mn-solutions.de> Acked-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 04 Apr, 2008 6 commits
-
-
David S. Miller authored
-
Al Viro authored
a) if you initialize something with le32_to_cpu(...), then |= it with host-endian and feed to cpu_to_le32(), it's most definitely *not* __le32. As sparse would've told you... b) the whole sequence is |= cpu_to_le32(host-endian constant) Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jeff Garzik <jeff@garzik.org>
-
Adrian Bunk authored
My previous section fix only turned one section problem into another section problem. This patch fixes it for real. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
Jeff Garzik <jeff@garzik.org>
-
Harvey Harrison authored
The other if blocks don't redeclare temp, remove the redeclaration in the final if() block. drivers/net/phy/marvell.c:214:7: warning: symbol 'temp' shadows an earlier one drivers/net/phy/marvell.c:160:6: originally declared here Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org>
-
Pavel Emelyanov authored
These entries are allocated in vlan_dev_set_egress_priority, but are never released and leaks on vlan device removal. Drop these in vlan's ->uninit callback - after the device is brought down and everyone is notified about it is going to be unregistered. Found during testing vlan netnsization patchset. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Acked-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Matt Carlson authored
The 5784 B step and newer chips require the PHY DSPs to be fine-tuned based on one-time programmable values stored in the chip. This is essential to achieve optimal PHY operations especially when using long cables. We also need to properly handle the 10Mbit RX bit in the CPMU_CTRL register during PHY reset. Update version to 3.89. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 03 Apr, 2008 1 commit
-
-
Andi Kleen authored
- Let it update the state of all CPUs. The network stack goes into pains to feed the current IP addresses in, but it is not very effective if that is only done for some random CPU instead of all. So change it to feed bits into all CPUs. I decided to do that lockless because well somewhat random results are ok. v2: Drop rename so that this patch doesn't depend on x86 maintainers Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-