- Apr 16, 2008
-
-
Ivo van Doorn authored
Add the tree entry for rt2x00 to inform people about the rt2x00.git tree. Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
I have been acting as the maintainer since the rfkill introduction, so lets make it official by adding a rfkill entry in the MAINTAINERS file. Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Carlos Corbacho authored
rfkill_switch_all() is supposed to only switch all the interfaces of a given type, but does not actually do this; instead, it just switches everything currently in the same state. Add the necessary type check in. (This fixes a bug I've been seeing while developing an rfkill laptop driver, with both bluetooth and wireless simultaneously changing state after only pressing either KEY_WLAN or KEY_BLUETOOTH). Signed-off-by:
Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This fixes b43legacy for the SSB DMA API change. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Cc: Stefano Brivio <stefano.brivio@polimi.it> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This fixes DMA on architectures where DMA is nontrivial, like PPC64. We must use the host-device's (PCI) struct device for any DMA operation instead of the SSB device. For this we add a new struct device pointer to the SSB device structure that will always point to the right device for DMAing. Without this patch b43 and b44 drivers won't work on complex-DMA architectures, that for example need dev->archdata for DMA operations. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Reinette Chatre authored
Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Stefano Brivio authored
This allows for the correct initial values to be uploaded to bcm4303 devices. It should be correct, but I can't reliably test this as I suspect there's something going wrong with an hardware rfkill switch on my laptop. Please test. Signed-off-by:
Stefano Brivio <stefano.brivio@polimi.it> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Herton Ronaldo Krzesinski authored
This adds missing priv->vif assignments after "mac80211: don't use interface indices in drivers" change. As rtl8180, rtl8187 also needs priv->vif to be set, as without this an oops can happen in rtl8187_tx function (priv->vif is passed to ieee80211_rts_duration). Signed-off-by:
Herton Ronaldo Krzesinski <herton@mandriva.com.br> Acked-by:
Pavel Roskin <proski@gnu.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- Apr 15, 2008
-
-
Oliver Hartkopp authored
The struct sockaddr_can has been simplified in the code review process. This patch updates this simplification also in the associated documentation in can.txt . Signed-off-by:
Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Paul Bolle authored
https://www.isdn4linux.de/mailman/listinfo/isdn4linux: "To prevent spamming, you have to subscribe first. Mails from non-members are silently ignored!" Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vitaliy Gusev authored
tcp_prune_queue() doesn't prune an out-of-order queue at all. Therefore sk_rmem_schedule() can fail but the out-of-order queue isn't pruned . This can lead to tcp deadlock state if the next two conditions are held: 1. There are a sequence hole between last received in order segment and segments enqueued to the out-of-order queue. 2. Size of all segments in the out-of-order queue is more than tcp_mem[2]. Signed-off-by:
Vitaliy Gusev <vgusev@openvz.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jarek Poplawski authored
TC_H_MAJ(parentid) for root classes is the same as for ingress, and if ingress qdisc is created qdisc_lookup() returns its pointer (without ingress NULL is returned). After this all qdisc_lookups give the same, and we get endless loop. (I don't know how this could hide for so long - it should trigger with every leaf class deleted if it's qdisc isn't empty.) After this fix qdisc_lookup() is omitted both for ingress and root parents, but looking for root is only wasting a little time here... Many thanks to Enrico Demarin for finding a test for catching this bug, which probably bothered quite a lot of admins. Reported-by:
Enrico Demarin <enrico@superclick.com>,> Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Acked-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Apr 14, 2008
-
-
Patrick McHardy authored
The bridge netfilter code attaches a fake dst_entry with a pointer to a fake net_device structure to skbs it passes up to IPv4 netfilter. This leads to crashes when the skb is passed to __ip_route_output_key when dereferencing the namespace pointer. Since bridging can currently only operate in the init_net namespace, the easiest fix for now is to initialize the nd_net pointer of the fake net_device struct to &init_net. Should fix bugzilla 10323: http://bugzilla.kernel.org/show_bug.cgi?id=10323 Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
Consider we are putting a clusterip_config entry with the "entries" count == 1, and on the other CPU there's a clusterip_config_find_get in progress: CPU1: CPU2: clusterip_config_entry_put: clusterip_config_find_get: if (atomic_dec_and_test(&c->entries)) { /* true */ read_lock_bh(&clusterip_lock); c = __clusterip_config_find(clusterip); /* found - it's still in list */ ... atomic_inc(&c->entries); read_unlock_bh(&clusterip_lock); write_lock_bh(&clusterip_lock); list_del(&c->list); write_unlock_bh(&clusterip_lock); ... dev_put(c->dev); Oops! We have an entry returned by the clusterip_config_find_get, which is a) not in list b) has a stale dev pointer. The problems will happen when the CPU2 will release the entry - it will remove it from the list for the 2nd time, thus spoiling it, and will put a stale dev pointer. The fix is to make atomic_dec_and_test under the clusterip_lock. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
Patrick McHardy <kaber@trash.net>
-
YOSHIFUJI Hideaki authored
As far as I can remember, I was going to disable privacy extensions on all "tunnel" interfaces. Disable it on ip6-ip6 interface as well. Also, just remove ifdefs for SIT for simplicity. Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
YOSHIFUJI Hideaki authored
Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
YOSHIFUJI Hideaki authored
Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
YOSHIFUJI Hideaki authored
struct ipv6_opt_hdr is the common structure for IPv6 extension headers, and it is common to increment the pointer to get the real content. On the other hand, since the structure consists only of 1-byte next-header field and 1-byte length field, size of that structure depends on architecture; 2 or 4. Add "packed" attribute to get 2. Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Fixes kernel bugzilla 10437 Based almost entirely upon a patch by Dmitry Butskoy. When deciding what raw sockets to deliver the ICMPv6 to, we should use the addresses in the ICMPv6 quoted IPV6 header, not the top-level one. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
Paul Bolle wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9923 would have been much easier to > track down if eth_validate_addr() would somehow complain aloud if an address > is invalid. Shouldn't it make at least some noise? I guess it should return -EADDRNOTAVAIL similar to eth_mac_addr() when validation fails. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Paul Bolle authored
Commit bada339b (Validate device addr prior to interface-up) caused a regression in the ISDN network code, see: http://bugzilla.kernel.org/show_bug.cgi?id=9923 The trivial fix is to remove the pointer to eth_validate_addr() in the net_device struct in isdn_net_init(). Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ben Hutchings authored
The kernel-doc comment for skb_segment is clearly wrong. This states what it actually does. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Problem spotted by Andrew Brampton Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Apr 13, 2008
-
-
Rusty Russell authored
If the user gives a packet under 14 bytes, we'll end up reading off the end of the skb (not oopsing, just reading off the end). Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Acked-by:
Max Krasnyanskiy <maxk@qualcomm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Rusty Russell authored
There's no reason for this to be in the header, and it just hurts recompile time. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Acked-by:
Max Krasnyanskiy <maxk@qualcomm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
All IP addresses that are present in a system are duplicated on struct sctp_sockaddr_entry. They are linked in the global list called sctp_local_addr_list. And this struct unions IPv4 and IPv6 addresses. So, there can be rare case, when a sockaddr_in.sin_addr coincides with the corresponding part of the sockaddr_in6 and the notifier for IPv4 will carry away an IPv6 entry. The fix is to check the family before comparing the addresses. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vlad Yasevich authored
Fix 3 warnings about discarding const qualifiers: net/sctp/ulpevent.c:862: warning: passing argument 1 of 'sctp_event2skb' discards qualifiers from pointer target type net/sctp/sm_statefuns.c:4393: warning: passing argument 1 of 'SCTP_ASOC' discards qualifiers from pointer target type net/sctp/socket.c:5874: warning: passing argument 1 of 'cmsg_nxthdr' discards qualifiers from pointer target type Signed-off-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Gui Jianfeng authored
When receiving an error length INIT-ACK during COOKIE-WAIT, a 0-vtag ABORT will be responsed. This action violates the protocol apparently. This patch achieves the following things. 1 If the INIT-ACK contains all the fixed parameters, use init-tag recorded from INIT-ACK as vtag. 2 If the INIT-ACK doesn't contain all the fixed parameters, just reflect its vtag. Signed-off-by:
Gui Jianfeng <guijianfeng@cn.fujitsu.com> Signed-off-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wei Yongjun authored
RFC 4890 has the following text: The HMAC algorithm based on SHA-1 MUST be supported and included in the HMAC-ALGO parameter. As a result, we need to check in sctp_verify_param() that HMAC_SHA1 is present in the list. If not, we should probably treat this as a protocol violation. It should also be a protocol violation if the HMAC parameter is empty. Signed-off-by:
Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jarek Poplawski authored
Deleting of nonroot hnodes mostly doesn't work in u32_delete(): refcnt == 1 is expected, but such hnodes' refcnts are initialized with 0 and charged only with "link" nodes. Now they'll start with 1 like usual. Thanks to Patrick McHardy for an improving suggestion. Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Acked-by:
Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
dev_queue_xmit() and the other IP output functions expect to get a skb with clear or properly initialized skb->cb. Unlike TCP and UDP, the dccp_skb_cb doesn't contain a struct inet_skb_parm at the beginning, so the DCCP-specific data is interpreted by the IP output functions. This can cause false negatives for the conditional POST_ROUTING hook invocation, making the packet bypass the hook. Add a inet_skb_parm/inet6_skb_parm union to the beginning of dccp_skb_cb to avoid clashes. Also add a BUILD_BUG_ON to make sure it fits in the cb. [ Combined with patch from Gerrit Renker to remove two now unnecessary memsets of IPCB(skb)->opt ] Signed-off-by:
Patrick McHardy <kaber@trash.net> Acked-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
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>
-
- Apr 12, 2008
-
-
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=10380 Signed-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=3956 Signed-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>
-