- 13 5月, 2008 20 次提交
-
-
由 Pavel Roskin 提交于
Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Masakazu Mokuno 提交于
This fixes the bug that the I/O buffer is not freed at the driver removal. Signed-off-by: NMasakazu Mokuno <mokuno@sm.sony.co.jp> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
Some APs refuse association if the supported rates contained in the association request do not match its own supported rates. This patch introduces a new function which builds the intersection between the AP's supported rates and the client's supported rates to work around such problems. The same approach is already used in ipw2200 for example. Signed-off-by: NHelmut Schaa <hschaa@suse.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Emmanuel Grumbach 提交于
This patch fixes a bug in RX path, the frequency was wrongly set in the ieee80211_rx_status. This bug led to an empty scan list in A band. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NTomas Winkler <tomas.winkler@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
zd_mac_tx_to_dev() could potentially free the skb, or hand it off to mac80211 which might free it. Hence, this code needs to get the usb pointer out of skb->cb before handing it off to that function. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Pavel Emelyanov 提交于
Calling synchronize_rcu() under write-lock-ed pathtbl_resize_lock may result in this warning (and other side effects). It looks safe just dropping this lock before calling synchronize_rcu. Signed-off-by: NPavel Emelyanov <xemul@openvz.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Pavel Emelyanov 提交于
The new_node kmallocation is not checked for success, so add this check. BTW, it also happens under the read_lock. Signed-off-by: NPavel Emelyanov <xemul@openvz.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Pavel Emelyanov 提交于
The mesh_path_add() read-locks the pathtbl_resize_lock and calls kmalloc with GFP_KERNEL mask. Fix it and move the endadd2 label lower. It should be _before_ the if() beyond, but it makes no sense for it being there, so I move it right after this if(). Signed-off-by: NPavel Emelyanov <xemul@openvz.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Patrick McHardy 提交于
Signed-off-by: NPatrick McHardy <kaber@trash.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis Carlos Cobo 提交于
Without this patch, if xmit_skb is null but net_ratelimit() returns 0 we would go to the else branch and access the null xmit_skb. Pointed out by Johannes Berg. Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis Carlos Cobo 提交于
This should have been updated at the same time we were transitioning from 3 byte to 4 byte mesh sequence number. Pointed out by Johannes Berg. Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
mac80211 should set the IEEE80211_TX_CTL_DO_NOT_ENCRYPT flag in tx_control structure to inform drivers not to encrypt the beacon. Drivers that only check for that flag before accessing the hw_key field, will otherwise cause a NULL pointer dereference since that field is not configured for beacons. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
When, for some reason, the rt2x00pci module fails to allocate DMA memory for the queues, it tries to undo the complete initialization of the PCI device, including freeing of the irq. This results in the following error in dmesg, as the irq hadn't been requested yet: [ 78.123456] Trying to free already-free IRQ 17 Fix this by implementing proper error handling code, instead of just using the full uninitialization function. Signed-off-by: NGertjan van Wingerde <gwingerde@kpnplanet.nl> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
During initialization the initialize() callback function in rt2x00pci and rt2x00usb will cleanup the mess they made. rt2x00lib shouldn't call uninitialize because the callback function already cleaned up _and_ the DEVICE_INITIALIZED isn't set which causes the rt2x00lib_uninitialize() to halt directly anyway. All that is required to be cleaned up by rt2x00lib is the queue, and that can be done by calling rt2x00queue_uninitialize() directly. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
rt2x00pci allocates DMA for descriptor and data, rt61pci doesn't use this for the beacon, but it can use the descriptor part as temporary buffer instead of using pskb_expand_head(). Using this temporary buffer is obviously much better then reallocating the skb buffer... At the same time we can set the data length for the beacon queue at 0, to make sure no DMA is allocated for data (but just for the descriptor). Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Zhu Yi 提交于
Make iwl4965_lq_sta->drv available even without CONFIG_MAC80211_DEBUGFS. Signed-off-by: NYi Zhu <yi.zhu@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Under certain circumstances (in AP mode) the debugfs function that is supposed to add the default key symlink can encounter a NULL default_key pointer. This patch makes it handle that situtation gracefully. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
Reported by Daniel Marjamäki <danielm77@spray.se> here: http://bugzilla.kernel.org/show_bug.cgi?id=10588Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Steven Rostedt 提交于
A file in the net/mac80211 directory uses "int" for flags. This can cause hard to find bugs on some architectures. This patch converts the flags to use "long" instead. This bug was discovered by doing an allyesconfig make on the -rt kernel where checks are done to ensure all flags are of size sizeof(long). Signed-off-by: NSteven Rostedt <srostedt@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This fixes a regression introduced by commit 7b463ced (prism54: set carrier flags correctly) which causes the device to come up without a carrier in AP-mode. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 5月, 2008 3 次提交
-
-
由 Wei Yongjun 提交于
If socket is create by AF_INET type, add IPv6 address to asoc will cause kernel panic while packet is transmitted on that transport. This patch add address type check before process paramaters of ASCONF chunk. If peer is not support this address type, return with error invald parameter. Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Wei Yongjun 提交于
If socket is create by PF_INET type, it can not used IPv6 address to send/recv DATA, So we can not used IPv6 address even if peer tell us it support IPv6 address. This patch fix to only enabled peer IPv6 address support on PF_INET6 socket. Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Matheos Worku 提交于
Determine the number of physical ports from the card's VPD data. Previous fix failed on Maramba platform which doesn't have the "board-model" property. This fix uses the "model" property which exists on all cards and Neptune based motherboards. cstyle cleanup included. Signed-off-by: NMatheos Worku <matheos.worku@sun.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 5月, 2008 2 次提交
-
-
由 David S. Miller 提交于
Noticed by Paul Marks <paul@pmarks.net>. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Allan Stephens 提交于
This patch increases the headroom TIPC reserves in each sk_buff to accommodate the largest possible link level device header. Signed-off-by: NAllan Stephens <allan.stephens@windriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 08 5月, 2008 9 次提交
-
-
由 Ben Hutchings 提交于
dev_open() and dev_close() must be called holding the RTNL, since they call device functions and netdevice notifiers that are promised the RTNL. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Oliver Hartkopp 提交于
The tx packet counting and the local loopback of CAN frames should only happen in the case that the CAN frame has been enqueued to the netdevice tx queue successfully. Thanks to Andre Naujoks <nautsch@gmail.com> for reporting this issue. Signed-off-by: NOliver Hartkopp <oliver@hartkopp.net> Signed-off-by: NUrs Thuermann <urs@isnogud.escape.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
-
由 Pavel Emelyanov 提交于
When a net namespace is destroyed, some devices (those, not killed on ns stop explicitly) are moved back to init_net. The problem, is that this net_ns change has one point of failure - the __dev_alloc_name() may be called if a name collision occurs (and this is easy to trigger). This allocator performs a likely-to-fail GFP_ATOMIC allocation to find a suitable number. Other possible conditions that may cause error (for device being ns local or not registered) are always false in this case. So, when this call fails, the device is unregistered. But this is *not* the right thing to do, since after this the device may be released (and kfree-ed) improperly. E. g. bridges require more actions (sysfs update, timer disarming, etc.), some other devices want to remove their private areas from lists, etc. I. e. arbitrary use-after-free cases may occur. The proposed fix is the following: since the only reason for the dev_change_net_namespace to fail is the name generation, we may give it a unique fall-back name w/o %d-s in it - the dev<ifindex> one, since ifindexes are still unique. So make this change, raise the failure-case printk loglevel to EMERG and replace the unregister_netdevice call with BUG(). [ Use snprintf() -DaveM ] Signed-off-by: NPavel Emelyanov <xemul@openvz.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Patrick McHardy 提交于
When conntrack and DCCP/SCTP protocols are enabled, chances are good that people also want DCCP/SCTP conntrack and NAT support. Signed-off-by: NPatrick McHardy <kaber@trash.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Patrick McHardy 提交于
Some Inovaphone PBXs exhibit very stange behaviour: when dialing for example "123", the device sends INVITE requests for "1", "12" and "123" back to back. The first requests will elicit error responses from the receiver, causing the SIP helper to flush the RTP expectations even though we might still see a positive response. Note the sequence number of the last INVITE request that contained a media description and only flush the expectations when receiving a negative response for that sequence number. Signed-off-by: NPatrick McHardy <kaber@trash.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Patrick McHardy 提交于
As noticed by Ben Greear, macvlan crashes the kernel when unloading the module. The reason is that it tries to clean up the macvlan_port pointer on the macvlan device itself instead of the underlying device. A non-NULL pointer is taken as indication that the macvlan_handle_frame_hook is valid, when receiving the next packet on the underlying device it tries to call the NULL hook and crashes. Clean up the macvlan_port on the correct device to fix this. Signed-off-by; Patrick McHardy <kaber@trash.net> Tested-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 J.H.M. Dassen (Ray) 提交于
RFC 1122 does not have a section 3.1.2.2. The requirement to silently discard datagrams with a bad checksum is in section 3.2.1.2 instead. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=10611Signed-off-by: NJ.H.M. Dassen (Ray) <jdassen@debian.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ilpo Järvinen 提交于
Note: there's actually another bug in FRTO's SACK variant, which is the causing failure in NewReno case because of the error that's fixed here. I'll fix the SACK case separately (it's a separate bug really, though related, but in order to fix that I need to audit tp->snd_nxt usage a bit). There were two places where SACK variant of FRTO is getting incorrectly used even if SACK wasn't negotiated by the TCP flow. This leads to incorrect setting of frto_highmark with NewReno if a previous recovery was interrupted by another RTO. An eventual fallback to conventional recovery then incorrectly considers one or couple of segments as forward transmissions though they weren't, which then are not LOST marked during fallback making them "non-retransmittable" until the next RTO. In a bad case, those segments are really lost and are the only one left in the window. Thus TCP needs another RTO to continue. The next FRTO, however, could again repeat the same events making the progress of the TCP flow extremely slow. In order for these events to occur at all, FRTO must occur again in FRTOs step 3 while the key segments must be lost as well, which is not too likely in practice. It seems to most frequently with some small devices such as network printers that *seem* to accept TCP segments only in-order. In cases were key segments weren't lost, things get automatically resolved because those wrongly marked segments don't need to be retransmitted in order to continue. I found a reproducer after digging up relevant reports (few reports in total, none at netdev or lkml I know of), some cases seemed to indicate middlebox issues which seems now to be a false assumption some people had made. Bugzilla #10063 _might_ be related. Damon L. Chesser <damon@damtek.com> had a reproducable case and was kind enough to tcpdump it for me. With the tcpdump log it was quite trivial to figure out. Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 07 5月, 2008 6 次提交
-
-
由 Kok, Auke 提交于
On a read error, e1000e might have returned uninitialized block of eeprom data back to userspace. The convention is that 0xff is "empty", so mark the entire eeprom as empty in case of an error. Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 Joakim Tjernlund 提交于
Commit 9fb1e350, ucc_geth: use rx-clock-name and tx-clock-name device tree properties Introduced a typo that made the driver use the RX clock as TX clock, causing massive TX errors. Signed-off-by: NJoakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 Alan Cox 提交于
Otherwise theoretically at least CAP_NET_ADMIN Reload new firmware Wait.. Firmware patches kernel So it should be CAY_SYS_RAWIO - not that I suspect this is in fact a credible attack vector! Signed-off-by: NAlan Cox <alan@redhat.com> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 Don Fry 提交于
Delete the non-napi code from the driver and Kconfig. Tested x86_64. Apply at next open opportunity. Signed-off-by: NDon Fry <pcnet32@verizon.net> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 Scott Wood 提交于
There are more memory leaks in the !PPC_CPM_NEW_BINDING case, but that code will disappear soon along with arch/ppc. Reported by Daniel Marjamki <danielm77@spray.se> at http://bugzilla.kernel.org/show_bug.cgi?id=10591Signed-off-by: NScott Wood <scottwood@freescale.com> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 Bruce Robson 提交于
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=10577 I was unable to access a computer containing an Intel EtherExpress 16 network card using IPv6. I traced this to failure of neighbour discovery. When I used an "ip -6 neigh add" command, on the computer attempting access, to insert a binding between the IPv6 address of the computer with the Intel EtherExpress 16 network card and the card's ethernet address, I was able to access that computer using IPv6. Neighbour discovery requires working multicast. The driver sources file eexpress.c contains an approximately 30 line function eexp_setup_filter used when loading multicast addresses. I found 3 problems in this function 1) It wrote the number of multicast addresses to the card instead of the number of bytes in the multicast addresses. 2) When loading multiple multicast addresses it loaded the first one provided multiple times instead of loading each one once. 3) The setting of pointer 'data' from 'dmi->dmi_addr' occured before the test for the error situation of 'dmi' being NULL. Correcting these problems allows the computer with the Intel EtherExpress 16 network card to found by IPv6 neighbour discovery. p.s. There is some information on the Intel EtherExpress 16 at http://www.intel.com/support/etherexpress/vintage/sb/cs-013500.htm Datasheet for the Intel 82586 ethernet controller used by the card http://www.datasheetcatalog.com/datasheets_pdf/8/2/5/8/82586.shtmlSigned-off-by: NBruce Robson <bns_robson@hotmail.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-