- 17 Nov, 2012 19 commits
-
-
Johannes Berg authored
commit 9b395bc3 upstream. A number of places in the mesh code don't check that the frame data is present and in the skb header when trying to access. Add those checks and the necessary pskb_may_pull() calls. This prevents accessing data that doesn't actually exist. To do this, export ieee80211_get_mesh_hdrlen() to be able to use it in mac80211. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johannes Berg authored
commit 4a4f1a58 upstream. Due to pskb_may_pull() checking the skb length, all non-management frames are checked on input whether their 802.11 header is fully present. Also add that check for management frames and remove a check that is now duplicate. This prevents accessing skb data beyond the frame end. Signed-off-by:
-
Dave Airlie authored
commit 3916e1d7 upstream. When buffer sharing with the i915 and using a 1680x1050 monitor, the i915 gives is a 6912 buffer for the 6720 width, the code doesn't render this properly as it uses one value to set the base address for reading from the vmap and for where to start on the device. This fixes it by calculating the values correctly for the device and for the pixmap. No idea how I haven't seen this before now. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Egbert Eich authored
commit 83325d07 upstream. An uninitialized variable led to broken load detection. Signed-off-by:
Egbert Eich <eich@suse.de> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Javier Cardona authored
commit f7fbf70e upstream. Per IEEE Std. 802.11-2012, Sec 8.2.4.4.1, the sequence Control field is not present in control frames. We noticed this problem when processing Block Ack Requests. Signed-off-by:
Javier Cardona <javier@cozybit.com> Signed-off-by:
Javier Lopez <jlopex@cozybit.com> Signed-off-by:
-
Javier Cardona authored
commit 555cb715 upstream. Doing otherwise is wrong, and may wreak havoc on the mpp tables, specially if the frame is encrypted. Reported-by:
Chaoxing Lin <Chaoxing.Lin@ultra-3eti.com> Signed-off-by:
-
Johannes Berg authored
commit 9690fb16 upstream. Instead of the current whitelist which accepts duplicates only for the quiet and vendor IEs, use a blacklist of all IEs (that we currently parse) that can't be duplicated. This avoids detecting a beacon as corrupt in the future when new IEs are added that can be duplicated. Signed-off-by:
Paul Stewart <pstew@chromium.org> Signed-off-by:
-
Johannes Berg authored
commit 7dd111e8 upstream. The mesh header can have address extension by a 4th or a 5th and 6th address, but never both. Drop such frames in 802.11 -> 802.3 conversion along with any frames that have the wrong extension. Reviewed-by:
-
Felix Fietkau authored
commit c4a9fafc upstream. No driver initializes chan->max_antenna_gain to something sensible, and the only place where it is being used right now is inside ath9k. This leads to ath9k potentially using less tx power than it can use, which can decrease performance/range in some rare cases. Rather than going through every single driver, this patch initializes chan->orig_mag in wiphy_register(), ignoring whatever value the driver left in there. If a driver for some reason wishes to limit it independent from regulatory rulesets, it can do so internally. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Steve Hodgson authored
commit ab74b3d6 upstream. This patch changes core_tmr_abort_task() to use spin_lock -> spin_unlock around se_cmd->t_state_lock while spin_lock_irqsave is held via se_sess->sess_cmd_lock. Signed-off-by:
Steve Hodgson <steve@purestorage.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Roland Dreier authored
commit d5627acb upstream. The sleeping code in iscsi_target_tx_thread() is susceptible to the classic missed wakeup race: - TX thread finishes handle_immediate_queue() and handle_response_queue(), thinks both queues are empty. - Another thread adds a queue entry and does wake_up_process(), which does nothing because the TX thread is still awake. - TX thread does schedule_timeout() and sleeps forever. In practice this can kill an iSCSI connection if for example an initiator does single-threaded writes and the target misses the wakeup window when queueing an R2T; in this case the connection will be stuck until the initiator loses patience and does some task management operation (or kills the connection entirely). Fix this by converting to wait_event_interruptible(), which does not suffer from this sort of race. Signed-off-by:
-
Roland Dreier authored
commit 3e03989b upstream. The expression (max_sectors * block_size) might overflow a u32 (indeed, since iblock sets max_hw_sectors to UINT_MAX, it is guaranteed to overflow and end up with a much-too-small result in many common cases). Fix this by doing an equivalent calculation that doesn't require multiplication. While we're touching this code, avoid splitting a printk format across two lines and use pr_info(...) instead of printk(KERN_INFO ...). Signed-off-by:
-
Roland Dreier authored
commit 0d0f9dfb upstream. If the call to core_dev_release_virtual_lun0() fails, then nothing sets ret to anything other than 0, so even though everything is torn down and freed, target_core_init_configfs() will seem to succeed and the module will be loaded. Fix this by passing the return value on up the chain. Signed-off-by:
-
Stanislaw Gruszka authored
commit bf7e1abe upstream. Some hardware has correct (!= 0xff) value of tssi_bounds[4] in the EEPROM, but step is equal to 0xff. This results on ridiculous delta calculations and completely broke TX power settings. Reported-and-tested-by:
Pavel Lucik <pavel.lucik@gmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Sven Eckelmann authored
commit 6fe7cc71 upstream. The ath9k xmit functions for AMPDUs can send frames as non-aggregate in case only one frame is currently available. The client will then answer using a normal Ack instead of a BlockAck. This acknowledgement has no TID stored and therefore the hardware is not able to provide us the corresponding TID. The TID set by the hardware in the tx status descriptor has to be seen as undefined and not as a valid TID value for normal acknowledgements. Doing otherwise results in a massive amount of retransmissions and stalls of connections. Users may experience low bandwidth and complete connection stalls in environments with transfers using multiple TIDs. This regression was introduced in b11b160d ("ath9k: validate the TID in the tx status information"). Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Acked-by:
-
Felix Fietkau authored
commit 8c6e3093 upstream. bf->bf_next is only while buffers are chained as part of an A-MPDU in the tx queue. When a tid queue is flushed (e.g. on tearing down an aggregation session), frames can be enqueued again as normal transmission, without bf_next being cleared. This can lead to the old pointer being dereferenced again later. This patch might fix crashes and "Failed to stop TX DMA!" messages. Signed-off-by:
-
Rolf Eike Beer authored
commit 32ed1911 upstream. The tsc40 driver announces it supports the pressure event, but will never send one. The announcement will cause tslib to wait for such events and sending all touch events with a pressure of 0. Removing the announcement will make tslib fall back to emulating the pressure on touch events so everything works as expected. Signed-off-by:
Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit 95a7d768 upstream. As Mukesh explained it, the MMUEXT_TLB_FLUSH_ALL allows the hypervisor to do a TLB flush on all active vCPUs. If instead we were using the generic one (which ends up being xen_flush_tlb) we end up making the MMUEXT_TLB_FLUSH_LOCAL hypercall. But before we make that hypercall the kernel will IPI all of the vCPUs (even those that were asleep from the hypervisor perspective). The end result is that we needlessly wake them up and do a TLB flush when we can just let the hypervisor do it correctly. This patch gives around 50% speed improvement when migrating idle guest's from one host to another. Oracle-bug: 14630170 Tested-by:
Jingjie Jiang <jingjie.jiang@oracle.com> Suggested-by:
Mukesh Rathor <mukesh.rathor@oracle.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
David Vrabel authored
commit a67baeb7 upstream. map->kmap_ops allocated in gntdev_alloc_map() wasn't freed by gntdev_put_map(). Add a gntdev_free_map() helper function to free everything allocated by gntdev_alloc_map(). Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
-
- 05 Nov, 2012 13 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This reverts commit baa526f4, which is commit 308b3afb upstream. To quote Colin Cross: This patch breaks Exynos5 spi on 3.4.17. The patch with the bug that this patch was supposed to address went in to 3.6 and not 3.4, so this patch causes a driver name mismatch when applied to 3.4. Cc: Colin Cross <ccross@google.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Ben Skeggs authored
This is to prevent nouveau from taking over the console on headless boards such as Tesla. Backport of upstream commit: e412e95aSigned-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Ben Skeggs authored
Backport of fixes from upstream commit: 9430738dSigned-off-by:
-
Ben Skeggs authored
commit cee59f15 upstream. Signed-off-by:
-
Jiri Slaby authored
commit 3ccc60f9 upstream. Microsoft Digital Media Keyboard 3000 has two interfaces, and the second one has a report descriptor with a bug. The second collection says: 05 01 -- global; usage page -- 01 -- Generic Desktop Controls 09 80 -- local; usage -- 80 -- System Control a1 01 -- main; collection -- 01 -- application 85 03 -- global; report ID -- 03 19 00 -- local; Usage Minimum -- 00 29 ff -- local; Usage Maximum -- ff 15 00 -- global; Logical Minimum -- 0 26 ff 00 -- global; Logical Maximum -- ff 81 00 -- main; input c0 -- main; End Collection I.e. it makes us think that there are all kinds of usages of system control. That the keyboard is a not only a keyboard, but also a joystick, mouse, gamepad, keypad, etc. The same as for the Wireless Desktop Receiver, this should be Physical Min/Max. So fix that appropriately. References: https://bugzilla.novell.com/show_bug.cgi?id=776834Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Nicholas Bellinger authored
commit e13d5fef upstream. Fabric drivers currently expect to internally release se_cmd in the event of a TMR failure during target_submit_tmr(), which means the immediate call to transport_generic_free_cmd() after TFO->queue_tm_rsp() from within target_complete_tmr_failure() workqueue context is wrong. This is done as some fabrics expect TMR operations to be acknowledged before releasing the descriptor, so the assumption that core is releasing se_cmd associated TMR memory is incorrect. This fixes a OOPs where transport_generic_free_cmd() was being called more than once. This bug was originally observed with tcm_qla2xxx fabric ports. Signed-off-by:
-
Larry Finger authored
commit f89ff644 upstream. When b43 fails to find firmware when loaded, a subsequent unload will oops due to calling ieee80211_unregister_hw() when the corresponding register call was never made. Commit 2d838bb6 fixed the same problem for b43legacy. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Tested-by:
Markus Kanet <dvmailing@gmx.eu> Cc: Markus Kanet <dvmailing@gmx.eu> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
commit 238ab784 upstream. If blk_init_queue fails, we do not call put_disk on the current dr (dr is decremented first in the error handling loop). Reviewed-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
NeilBrown authored
commit 02b898f2 upstream. setup_conf in raid1.c uses conf->raid_disks before assigning a value. It is used when including 'Replacement' devices. The consequence is that assembling an array which contains a replacement will misbehave and either not include the replacement, or not include the device being replaced. Though this doesn't lead directly to data corruption, it could lead to reduced data safety. So use mddev->raid_disks, which is initialised, instead. Bug was introduced by commit c19d5798 md/raid1: recognise replacements when assembling arrays. in 3.3, so fix is suitable for 3.3.y thru 3.6.y. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Mathias Nyman authored
commit ad2fab36 upstream. gpios requested with invalid numbers, or gpios requested from userspace via sysfs should not try to be deferred on failure. Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit d79550a7 upstream. ->last_ier is an unsigned long but the high bits can't be used int the original code because the shift wraps. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Eric Sandeen authored
commit ffb5387e upstream. commit 119c0d44 changed ext4_new_inode() such that the inode bitmap was being modified outside a transaction, which could lead to corruption, and was discovered when journal_checksum found a bad checksum in the journal during log replay. Nix ran into this when using the journal_async_commit mount option, which enables journal checksumming. The ensuing journal replay failures due to the bad checksums led to filesystem corruption reported as the now infamous "Apparent serious progressive ext4 data corruption bug" [ Changed by tytso to only call ext4_journal_get_write_access() only when we're fairly certain that we're going to allocate the inode. ] I've tested this by mounting with journal_checksum and running fsstress then dropping power; I've also tested by hacking DM to create snapshots w/o first quiescing, which allows me to test journal replay repeatedly w/o actually power-cycling the box. Without the patch I hit a journal checksum error every time. With this fix it survives many iterations. Reported-by:
Nix <nix@esperi.org.uk> Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
- 31 Oct, 2012 8 commits
-
-
Greg Kroah-Hartman authored
-
Sjoerd Simons authored
commit 9756fe38 upstream. This box claims to have an LVDS interface but doesn't actually have one. Signed-off-by:
Sjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Yinghai Lu authored
commit 1f2ff682 upstream. We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time. Also memblock has page aligned range for ram, so we could avoid mapping partial pages. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.comAcked-by:
Jacob Shin <jacob.shin@amd.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Ian Abbott authored
commit aaeb61a9 upstream. `pc236_detach()` is called by the comedi core if it attempted to attach a device and failed. `pc236_detach()` calls `pc236_intr_disable()` if the comedi device private data pointer (`devpriv`) is non-null. This test is insufficient as `pc236_intr_disable()` accesses hardware registers and the attach routine may have failed before it has saved their I/O base addresses. Fix it by checking `dev->iobase` is non-zero before calling `pc236_intr_disable()` as that means the I/O base addresses have been saved and the hardware registers can be accessed. It also implies the comedi device private data pointer is valid, so there is no need to check it. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Olof Johansson authored
commit 5189c2a7 upstream. When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off efi_enabled once setup is done. Beyond setup, it is normally used to determine if runtime services are available and we will have none. This will resolve issues stemming from efivars modprobe panicking on a 32/64-bit setup, as well as some reboot issues on similar setups. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45991Reported-by:
Marko Kohtala <marko.kohtala@gmail.com> Reported-by:
Maxim Kammerer <mk@dee.su> Signed-off-by:
Olof Johansson <olof@lixom.net> Acked-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
Josh Triplett authored
commit 78510792 upstream. Some new ACPI 5.0 tables reference resources stored in boot services memory, so keep that memory around until we have ACPI and can extract data from it. Signed-off-by:
Josh Triplett <josh@joshtriplett.org> Link: http://lkml.kernel.org/r/baaa6d44bdc4eb0c58e5d1b4ccd2c729f854ac55.1348876882.git.josh@joshtriplett.orgSigned-off-by:
-
Yinghai Lu authored
commit f82f64dd upstream. Commit 844ab6f9 x86, mm: Find_early_table_space based on ranges that are actually being mapped added back some lines back wrongly that has been removed in commit 7b16bbf9 Revert "x86/mm: Fix the size calculation of mapping tables" remove them again. Signed-off-by:
-
Jacob Shin authored
commit 844ab6f9 upstream. Current logic finds enough space for direct mapping page tables from 0 to end. Instead, we only need to find enough space to cover mr[0].start to mr[nr_range].end -- the range that is actually being mapped by init_memory_mapping() This is needed after 1bbbbe77, to address the panic reported here: https://lkml.org/lkml/2012/10/20/160 https://lkml.org/lkml/2012/10/21/157Signed-off-by:
Tom Rini <trini@ti.com> Signed-off-by:
-
