- 03 Oct, 2011 40 commits
-
-
Dave Hansen authored
commit eb4866d0 upstream. We need to teach the numa_maps code about transparent huge pages. The first step is to teach gather_stats() that the pte it is dealing with might represent more than one page. Note that will we use this in a moment for transparent huge pages since they have use a single pmd_t which _acts_ as a "surrogate" for a bunch of smaller pte_t's. I'm a _bit_ unhappy that this interface counts in hugetlbfs page sizes for hugetlbfs pages and PAGE_SIZE for normal pages. That means that to figure out how many _bytes_ "dirty=1" means, you must first know the hugetlbfs page size. That's easier said than done especially if you don't have visibility in to the mount. But, that's probably a discussion for another day especially since it would change behavior to fix it. But, just in case anyone wonders why this patch only passes a '1' in the hugetlb case... Signed-off-by:
Dave Hansen <dave@linux.vnet.ibm.com> Acked-by:
Hugh Dickins <hughd@google.com> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Larry Finger authored
commit d331eb51 upstream. Using gcc 4.4.5 on a Powerbook G4 with a PPC cpu, a complicated if statement results in incorrect flow, whereas the equivalent switch statement works correctly. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Lasse Collin authored
commit 9c1f8594 upstream. xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by:
Lasse Collin <lasse.collin@tukaani.org> Signed-off-by:
-
Jesse Brandeburg authored
commit b811ce91 upstream. It seems that at least one PPC machine would occasionally give a (valid) 0 as the return value from dma_map, this caused the ixgbe code to not work correctly. A fix is pending in the PPC tree to not return 0 from dma map, but we can also fix the driver to make sure we don't mess up in other arches as well. This patch is applicable to all current stable kernels. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=683611Reported-by:
Neil Horman <nhorman@redhat.com> Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Tested-by:
Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Manual Munz authored
commit 8c23516f upstream. In ad-hoc mode, driver b43 does not issue beacons. Signed-off-by:
Manual Munz <freifunk@somakoma.de> Tested-by:
-
Carsten Emde authored
commit 6c4867f6 upstream. When no floppy is found the module code can be released while a timer function is pending or about to be executed. CPU0 CPU1 floppy_init() timer_softirq() spin_lock_irq(&base->lock); detach_timer(); spin_unlock_irq(&base->lock); -> Interrupt del_timer(); return -ENODEV; module_cleanup(); <- EOI call_timer_fn(); OOPS Use del_timer_sync() to prevent this. Signed-off-by:
Carsten Emde <C.Emde@osadl.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Nicolas Pitre authored
commit 72cc2056 upstream. Commit 980f9f60 "ARM: orion: Consolidate SPI initialization." broke it by overwriting the SPI0 registration. Signed-off-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Steve French authored
commit c9c7fa00 upstream. Both these options are started with "rw" - that's why the first one isn't switched on even if it is specified. Fix this by adding a length check for "rw" option check. Signed-off-by:
Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Jeff Layton authored
commit 9438fabb upstream. The name_len variable in CIFSFindNext is a signed int that gets set to the resume_name_len in the cifs_search_info. The resume_name_len however is unsigned and for some infolevels is populated directly from a 32 bit value sent by the server. If the server sends a very large value for this, then that value could look negative when converted to a signed int. That would make that value pass the PATH_MAX check later in CIFSFindNext. The name_len would then be used as a length value for a memcpy. It would then be treated as unsigned again, and the memcpy scribbles over a ton of memory. Fix this by making the name_len an unsigned value in CIFSFindNext. Reported-by:
Darren Lavender <dcl@hppine99.gbr.hp.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
-
Takashi Iwai authored
commit 8974bd51 upstream. When the system has only the headphone and the line-out jacks without speakers, the current auto-mute code doesn't work. It's because the spec->automute_lines flag is wrongly referred in update_speakers(). This flag must be meaningless when spec->automute_hp_lo isn't set, thus they should be always coupled. The patch fixes the problem and add a comment to indicate the relationship briefly. BugLink: http://bugs.launchpad.net/bugs/851697Reported-by:
David Henningsson <david.henningsson@canonical.com> Tested-By:
Jayne Han <jayne.han@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Johannes Berg authored
commit 282cdb32 upstream. If the command queue is constantly busy, which can happen in P2P, the hangcheck timer will frequently find a command in it and will eventually reset the device because nothing sets the timestamp for this queue when commands are processed. Fix this by setting the timestamp when a command completes. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Sarah Sharp authored
commit 44f4c3ed upstream. Sometimes, when a USB 3.0 device is disconnected, the Intel Panther Point xHCI host controller will report a link state change with the state set to "SS.Inactive". This causes the xHCI host controller to issue a warm port reset, which doesn't finish before the USB core times out while waiting for it to complete. When the warm port reset does complete, and the xHC gives back a port status change event, the xHCI driver kicks khubd. However, it fails to set the bit indicating there is a change event for that port because the logic in xhci-hub.c doesn't check for the warm port reset bit. After that, the warm port status change bit is never cleared by the USB core, and the xHC stops reporting port status change bits. (The xHCI spec says it shouldn't report more port events until all change bits are cleared.) This means any port changes when a new device is connected will never be reported, and the port will seem "dead" until the xHCI driver is unloaded and reloaded, or the computer is rebooted. Fix this by making the xHCI driver set the port change bit when a warm port reset change bit is set. A better solution would be to make the USB core handle warm port reset in differently, merging the current code with the standard port reset code that does an incremental backoff on the timeout, and tries to complete the port reset two more times before giving up. That more complicated fix will be merged next window, and this fix will be backported to stable. This should be backported to kernels as old as 3.0, since that was the first kernel with commit a11496eb ("xHCI: warm reset support"). Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Alex Deucher authored
commit 003cefe0 upstream. The BO blit code inconsistenly handled the page size. This wasn't an issue on system with 4k pages since the GPU's page size is 4k as well. Switch the driver blit callbacks to take num pages in GPU page units. Fixes lemote mipsel systems using AMD rs780/rs880 chipsets. v2: incorporate suggestions from Michel. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Ming Lei authored
commit f39aa30d upstream. This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719 . An O2Micro PCI Express FireWire controller, "FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:11f7] (rev 05)" which is a combination device together with an SDHCI controller and some sort of storage controller, misses SBP-2 status writes from an attached FireWire HDD. This problem goes away if MSI is disabled for this FireWire controller. The device reportedly does not require QUIRK_CYCLE_TIMER. Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Anton Blanchard authored
commit 91aae1e5 upstream. Commit b9367bf3 (net: ibmveth: convert to hw_features) reversed a check in ibmveth_set_csum_offload that results in checksum offload never being enabled. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Anton Blanchard authored
commit b93da27f upstream. descs[].fields.address is 32bit which truncates any dma mapping errors so dma_mapping_error() fails to catch it. Use a dma_addr_t to do the comparison. With this patch I was able to transfer many gigabytes of data with IOMMU fault injection set at 10% probability. Signed-off-by:
-
Brian King authored
commit 33a48ab1 upstream. Commit 6e8ab30e (ibmveth: Add scatter-gather support) introduced a DMA mapping API inconsistency resulting in dma_unmap_page getting called on memory mapped via dma_map_single. This was seen when CONFIG_DMA_API_DEBUG was enabled. Fix up this API usage inconsistency. Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Acked-by:
-
Arjan van de Ven authored
commit 763437a9 upstream. wait_for_avail() in pcm_lib.c has a race in it (observed in practice by an Intel validation group). The function is supposed to return once space in the buffer has become available, or if some timeout happens. The entity that creates space (irq handler of sound driver and some such) will do a wake up on a waitqueue that this function registers for. However there are two races in the existing code 1) If space became available between the caller noticing there was no space and this function actually sleeping, the wakeup is missed and the timeout condition will happen instead 2) If a wakeup happened but not sufficient space became available, the code will loop again and wait for more space. However, if the second wake comes in prior to hitting the schedule_timeout_interruptible(), it will be missed, and potentially you'll wait out until the timeout happens. The fix consists of using more careful setting of the current state (so that if a wakeup happens in the main loop window, the schedule_timeout() falls through) and by checking for available space prior to going into the schedule_timeout() loop, but after being on the waitqueue and having the state set to interruptible. [tiwai: the following changes have been added to Arjan's original patch: - merged akpm's fix for waitqueue adding order into a single patch - reduction of duplicated code of avail check ] Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
Thomas Tuttle authored
commit fa2563e4 upstream. Take cwq->gcwq->lock to avoid racing between drain_workqueue checking to make sure the workqueues are empty and cwq_dec_nr_in_flight decrementing and then incrementing nr_active when it activates a delayed work. We discovered this when a corner case in one of our drivers resulted in us trying to destroy a workqueue in which the remaining work would always requeue itself again in the same workqueue. We would hit this race condition and trip the BUG_ON on workqueue.c:3080. Signed-off-by:
Thomas Tuttle <ttuttle@chromium.org> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Naga Chumbalkar authored
commit e71f5cc4 upstream. per_cpu(processors, n) can be NULL, resulting in: Loading CPUFreq modules[ 437.661360] BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0434314>] pcc_cpufreq_cpu_init+0x74/0x220 [pcc_cpufreq] It's better to avoid the oops by failing the driver, and allowing the system to boot. Signed-off-by:
Naga Chumbalkar <nagananda.chumbalkar@hp.com> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Len Brown <lenb@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit 7a5caabd upstream. Fix regression introduced by commit 5ada28bf ("led-class: always implement blinking") which broke sysfs delay handling by not storing the updated value. Consequently it was only possible to set one of the delays through the sysfs interface as the other delay was automatically restored to it's default value. Reading the parameters always gave the defaults. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Acked-by:
Florian Fainelli <florian@openwrt.org> Acked-by:
Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by:
-
David Vrabel authored
commit 461ae488 upstream. Xen backend drivers (e.g., blkback and netback) would sometimes fail to map grant pages into the vmalloc address space allocated with alloc_vm_area(). The GNTTABOP_map_grant_ref would fail because Xen could not find the page (in the L2 table) containing the PTEs it needed to update. (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 netback and blkback were making the hypercall from a kernel thread where task->active_mm != &init_mm and alloc_vm_area() was only updating the page tables for init_mm. The usual method of deferring the update to the page tables of other processes (i.e., after taking a fault) doesn't work as a fault cannot occur during the hypercall. This would work on some systems depending on what else was using vmalloc. Fix this by reverting ef691947 ("vmalloc: remove vmalloc_sync_all() from alloc_vm_area()") and add a comment to explain why it's needed. Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Ian Campbell <Ian.Campbell@citrix.com> Cc: Keir Fraser <keir.xen@gmail.com> Signed-off-by:
-
Al Viro authored
commit 1d2ef590 upstream. We used to get the victim pinned by dentry_unhash() prior to commit 64252c75 ("vfs: remove dget() from dentry_unhash()") and ->rmdir() and ->rename() instances relied on that; most of them don't care, but ones that used d_delete() themselves do. As the result, we are getting rmdir() oopses on NFS now. Just grab the reference before locking the victim and drop it explicitly after unlocking, same as vfs_rename_other() does. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Tested-by:
Simon Kirby <sim@hostway.ca> Signed-off-by:
-
Michel Dänzer authored
commit 87463ff8 upstream. Apparently this doesn't always work reliably, e.g. at resume time. Just initialize to 0, so the ring is considered empty. Tested with hibernation on Sumo and Cayman cards. Should fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ . Signed-off-by:
-
David Henningsson authored
commit 2e1210bc upstream. This patch fixes "Surround Speaker Playback Volume" being cut off. (Commit b4dabfc4 was probably meant to fix this, but it fixed only the "Switch" name, not the "Volume" name.) Signed-off-by:
-
Thomas Gleixner authored
commit 477694e7 upstream. Mark this lowlevel IRQ handler as non-threaded. This prevents a boot crash when "threadirqs" is on the kernel commandline. Also the interrupt handler is handling hardware critical events which should not be delayed into a thread. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Johannes Berg authored
commit 4bae7d97 upstream. Since my commit 34e89507 ("mac80211: allow station add/remove to sleep") there is a race in mac80211 when it clears the TIM bit because a sleeping station disconnected, the spinlock isn't held around the relevant code any more. Use the right API to acquire the spinlock correctly. Signed-off-by:
-
George authored
commit bac2555c upstream. The driver fails to clear encryption keys making it impossible to switch connections. Signed-off-by:
George <george0505@realtek.com> Signed-off-by:
-
George authored
commit 3401dc6e upstream. The driver fails to connect to 802.11n-enabled APs. The patch fixes Bug #42262. Signed-off-by:
-
Geert Uytterhoeven authored
commit ed585a65 upstream. If an irq_chip provides .irq_shutdown(), but neither of .irq_disable() or .irq_mask(), free_irq() crashes when jumping to NULL. Fix this by only trying .irq_disable() and .irq_mask() if there's no .irq_shutdown() provided. This revives the symmetry with irq_startup(), which tries .irq_startup(), .irq_enable(), and irq_unmask(), and makes it consistent with the comment for irq_chip.irq_shutdown() in <linux/irq.h>, which says: * @irq_shutdown: shut down the interrupt (defaults to ->disable if NULL) This is also how __free_irq() behaved before the big overhaul, cfr. e.g. 3b56f058 ("genirq: Remove bogus conditional"), where the core interrupt code always overrode .irq_shutdown() to .irq_disable() if .irq_shutdown() was NULL. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-m68k@lists.linux-m68k.org Link: http://lkml.kernel.org/r/1315742394-16036-2-git-send-email-geert@linux-m68k.orgSigned-off-by:
-
Anand Gadiyar authored
commit e600cffe upstream. This code section seems to have been accidentally copy pasted. It causes incorrect bits to be set up in the TLL_CHANNEL_CONF register and prevents the TLL mode from working correctly. Signed-off-by:
Anand Gadiyar <gadiyar@ti.com> Cc: Keshava Munegowda <keshava_mgowda@ti.com> Acked-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Johan Hovold authored
commit fa948761 upstream. Fix regression introduced by commit a2974732 (TPS65911: Add new irq definitions) which caused irq_num to be incorrectly set for tps65910. Signed-off-by:
Graeme Gregory <gg@slimlogic.co.uk> Signed-off-by:
-
Mark Brown authored
commit 8efcc57d upstream. This needs to be an out of band value for the register and on this device registers are 16 bit so we must shift left one to the 17th bit. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit c5d2e650 upstream. Fix the codec_name field of the dai_link to match the actual device name of the codec. Otherwise the card won't be instantiated. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
Mark Brown authored
commit 747da0f8 upstream. We need to report the entire jack state to the core jack code, not just the bits that were being updated by the caller, otherwise the status reported by other detection methods will be omitted from the state seen by userspace. Signed-off-by:
-
Jeff Kirsher authored
commit e2faeec2 upstream. The checksum field in the EEPROM on HPPA is really not a checksum but a signature (0x16d6). So allow 0x16d6 as the matching checksum on HPPA systems. This issue is present on longterm/stable kernels, I have verified that this patch is applicable back to at least 2.6.32.y kernels. v2- changed ifdef to use CONFIG_PARISC instead of __hppa__ CC: Guy Martin <gmsoft@tuxicoman.be> CC: Rolf Eike Beer <eike-kernel@sf-tec.de> CC: Matt Turner <mattst88@gmail.com> Reported-by:
Mikulas Patocka <mikulas@artax.kerlin.mff.cuni.cz> Signed-off-by:
-
Felix Fietkau authored
commit 0e4660cb upstream. ADC calibrations cannot run on 5 GHz with fast clock enabled. They need to be disabled, otherwise they'll hang and IQ mismatch calibration will not be run either. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Reported-by:
Adrian Chadd <adrian@freebsd.org> Signed-off-by:
-
Len Brown authored
commit b33c25d6 upstream. This limit is a workaround for AML that sleeps too long, but the workaround didn't work b/c of a typo. https://bugzilla.kernel.org/show_bug.cgi?id=13195Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit 7c251012 upstream. When trying to connect to 5GHz we can provide negative index to mac80211 what trigger BUG_ON. Reason of iwl-3945-rs malfunction on 5GHz is unknown and needs further investigation. For now, to do not trigger a bug, correct value and just print WARNING. Address bug: https://bugzilla.redhat.com/show_bug.cgi?id=730653Reported-and-tested-by:
Jan Teichmann <jan.teichmann@gmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Andrew Vasquez authored
commit 58b48576 upstream. Transitioning to a LOOP_UPDATE loop-state could cause the driver to miss normal link/target processing. LOOP_UPDATE is a crufty artifact leftover from at time the driver performed it's own internal command-queuing. Safely remove this state. Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
