- 09 Dec, 2011 37 commits
-
-
Greg Kroah-Hartman authored
This reverts commit 11b8fc6a, which was commit f09ee045 upstream. Koen Kooi <koen@dominion.thruhere.net> reports that this shouldn't have been applied to the 3.0 kernel as it isn't relevant there, only 3.1. Reported-by:
Koen Kooi <koen@dominion.thruhere.net> Cc: Thomas Weber <weber@corscience.de> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jean Delvare authored
This is for stable kernel branch 3.0 only. Previous and later versions have different code paths and are not affected by this bug. If the CPU microcode is too old, the coretemp driver won't work. But instead of failing gracefully, it currently oops. Check for NULL platform device data to avoid this. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Durgadoss R <durgadoss.r@intel.com> Acked-by:
Guenter Roeck <guenter.roeck@ericsson.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 2a1e0fd1 upstream. When a packet is supposed to sent be as an a-MPDU, mac80211 sets IEEE80211_TX_CTL_AMPDU to let the driver know. On the other hand, mac80211 configures the driver for aggregration with the ampdu_action callback. There is race between these two mechanisms since the following scenario can occur when the BA agreement is torn down: Tx softIRQ drv configuration ========== ================= check OPERATIONAL bit Set the TX_CTL_AMPDU bit in the packet clear OPERATIONAL bit stop Tx AGG Pass Tx packet to the driver. In that case the driver would get a packet with TX_CTL_AMPDU set although it has already been notified that the BA session has been torn down. To fix this, we need to synchronize all the Qdisc activity after we cleared the OPERATIONAL bit. After that step, all the following packets will be buffered until the driver reports it is ready to get new packets for this RA / TID. This buffering allows not to run into another race that would send packets with TX_CTL_AMPDU unset while the driver hasn't been requested to tear down the BA session yet. This race occurs in practice and iwlwifi complains with a WARN_ON when it happens. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Johannes Berg authored
commit 24f50a9d upstream. Nikolay noticed (by code review) that mac80211 can attempt to stop an aggregation session while it is already being stopped. So to fix it, check whether stop is already being done and bail out if so. Also move setting the STOPPING state into the lock so things are properly atomic. Reported-by:
Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
commit de3584bd upstream. By the time userspace returns with a response to the regulatory domain request, the wiphy causing the request might have gone away. If this is so, reject the update but mark the request as having been processed anyway. Cc: Luis R. Rodriguez <lrodriguez@qca.qualcomm.com> Signed-off-by:
-
Eliad Peller authored
commit e007b857 upstream. MAC addresses have a fixed length. The current policy allows passing < ETH_ALEN bytes, which might result in reading beyond the buffer. Signed-off-by:
Eliad Peller <eliad@wizery.com> Signed-off-by:
-
Gertjan van Wingerde authored
commit 68fa64ef upstream. Fix __le32 to __le16 conversion of the first word of an 8-word block of EEPROM read via the efuse method. Reported-and-tested-by:
Ingvar Hagelund <ingvar@redpill-linpro.com> Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Helmut Schaa <helmut.schaa@googlemail.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Michael Büsch authored
commit 2d161817 upstream. priv->work must not be synced while priv->mutex is locked, because the mutex is taken in the work handler. Move cancel_work_sync down to after the device shutdown code. This is safe, because the work handler checks fw_state and bails out early in case of a race. Signed-off-by:
Michael Buesch <m@bues.ch> Acked-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Michael Büsch authored
commit 32d3a392 upstream. The tx_lock is not initialized properly. Add spin_lock_init(). Signed-off-by:
-
Jeff Ohlstein authored
commit 27c9cd7e upstream. __remove_hrtimer() attempts to reprogram the clockevent device when the timer being removed is the next to expire. However, __remove_hrtimer() reprograms the clockevent *before* removing the timer from the timerqueue and thus when hrtimer_force_reprogram() finds the next timer to expire it finds the timer we're trying to remove. This is especially noticeable when the system switches to NOHz mode and the system tick is removed. The timer tick is removed from the system but the clockevent is programmed to wakeup in another HZ anyway. Silence the extra wakeup by removing the timer from the timerqueue before calling hrtimer_force_reprogram() so that we actually program the clockevent for the next timer to expire. This was broken by 998adc3d "hrtimers: Convert hrtimers to use timerlist infrastructure". Signed-off-by:
Jeff Ohlstein <johlstei@codeaurora.org> Link: http://lkml.kernel.org/r/1321660030-8520-1-git-send-email-johlstei@codeaurora.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Hector Palacios authored
commit d004e024 upstream. ktime_get and ktime_get_ts were calling timekeeping_get_ns() but later they were not calling arch_gettimeoffset() so architectures using this mechanism returned 0 ns when calling these functions. This happened for example when running Busybox's ping which calls syscall(__NR_clock_gettime, CLOCK_MONOTONIC, ts) which eventually calls ktime_get. As a result the returned ping travel time was zero. Signed-off-by:
Hector Palacios <hector.palacios@digi.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Michal Hocko authored
commit 884a45d9 upstream. 2d3cbf8b (cgroup_freezer: update_freezer_state() does incorrect state transitions) removed is_task_frozen_enough and replaced it with a simple frozen call. This, however, breaks freezing for a group with stopped tasks because those cannot be frozen and so the group remains in CGROUP_FREEZING state (update_if_frozen doesn't count stopped tasks) and never reaches CGROUP_FROZEN. Let's add is_task_frozen_enough back and use it at the original locations (update_if_frozen and try_to_freeze_cgroup). Semantically we consider stopped tasks as frozen enough so we should consider both cases when testing frozen tasks. Testcase: mkdir /dev/freezer mount -t cgroup -o freezer none /dev/freezer mkdir /dev/freezer/foo sleep 1h & pid=$! kill -STOP $pid echo $pid > /dev/freezer/foo/tasks echo FROZEN > /dev/freezer/foo/freezer.state while true do cat /dev/freezer/foo/freezer.state [ "`cat /dev/freezer/foo/freezer.state`" = "FROZEN" ] && break sleep 1 done echo OK Signed-off-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Li Zefan <lizf@cn.fujitsu.com> Cc: Tomasz Buchert <tomasz.buchert@inria.fr> Cc: Paul Menage <paul@paulmenage.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Tejun Heo <htejun@gmail.com> Signed-off-by:
-
Edward Donovan authored
commit 52553ddf upstream. Commit fa27271b("genirq: Fixup poll handling") introduced a regression that broke irqfixup/irqpoll for some hardware configurations. Amidst reorganizing 'try_one_irq', that patch removed a test that checked for 'action->handler' returning IRQ_HANDLED, before acting on the interrupt. Restoring this test back returns the functionality lost since 2.6.39. In the current set of tests, after 'action' is set, it must precede '!action->next' to take effect. With this and my previous patch to irq/spurious.c, c75d720f, all IRQ regressions that I have encountered are fixed. Signed-off-by:
Edward Donovan <edward.donovan@numble.net> Reported-and-tested-by:
Rogério Brito <rbrito@ime.usp.br> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Trond Myklebust authored
commit 24ca9a84 upstream. By returning '0' instead of 'EAGAIN' when the tests in xs_nospace() fail to find evidence of socket congestion, we are making the RPC engine believe that the message was incorrectly sent and so it disconnects the socket instead of just retrying. The bug appears to have been introduced by commit 5e3771ce (SUNRPC: Ensure that xs_nospace return values are propagated). Reported-by:
Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Tested-by:
-
Mark Brown authored
commit ed3e80c4 upstream. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Timo Juhani Lindfors authored
commit 2391a0e0 upstream. This patch makes it possible to set DAI mode to its currently applied value even if codec is active. This is necessary to allow aplay -t raw -r 44100 -f S16_LE -c 2 < /dev/urandom & alsactl store -f backup.state alsactl restore -f backup.state to work without returning errors. This patch is based on a patch sent by Klaus Kurzmann <mok@fluxnetz.de>. Signed-off-by:
Timo Juhani Lindfors <timo.lindfors@iki.fi> Signed-off-by:
-
Timur Tabi authored
commit 0f768a72 upstream. Commit 6992f533 ("sysfs: Use one lockdep class per sysfs attribute") requires 'struct attribute' objects to be initialized with sysfs_attr_init(). Signed-off-by:
Timur Tabi <timur@freescale.com> Signed-off-by:
-
Tim Blechmann authored
commit a2987855 upstream. commit 6175ddf0 optimized the mem*io functions that have been used to send commands to the device. these optimizations somehow corrupted the communication with the lx6464es, that resulted the device to be unusable with kernels after 2.6.33. this patch emulates the memcpy_*_io functions via a loop to avoid these problems. Signed-off-by:
Tim Blechmann <tim@klingt.org> LKML-Reference: <4ECB5257.4040600@ladisch.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Will Deacon authored
commit 11ed0ba1 upstream. This patch implements a workaround for PL310 erratum 769419. On revisions of the PL310 prior to r3p2, the Store Buffer does not automatically drain. This can cause normal, non-cacheable writes to be retained when the memory system is idle, leading to suboptimal I/O performance for drivers using coherent DMA. This patch adds an optional wmb() call to the cpu_idle loop. On systems with an outer cache, this causes an explicit flush of the store buffer. Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Tested-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Ming Lei authored
commit a8a6565c upstream. This patch selects ARM_AMBA if OMAP3_EMU is defined because OC_ETM depends on ARM_AMBA, so fix the link failure[1]. [1], arch/arm/kernel/built-in.o: In function `etm_remove': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:609: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etb_remove': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:409: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etm_init': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:640: undefined reference to `amba_driver_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:646: undefined reference to `amba_driver_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:648: undefined reference to `amba_driver_unregister' arch/arm/kernel/built-in.o: In function `etm_probe': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:545: undefined reference to `amba_request_regions' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:595: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etb_probe': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:347: undefined reference to `amba_request_regions' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:392: undefined reference to `amba_release_regions' arch/arm/mach-omap2/built-in.o: In function `emu_init': /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:62: undefined reference to `amba_device_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:63: undefined reference to `amba_device_register' make: *** [.tmp_vmlinux1] Error 1 making modules Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Felipe Balbi authored
commit 5a4f1844 upstream. Fix a bug which has been on this driver since it was added by the original commit 984aa6db which would never clear IRQSTATUS bits. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Kevin Hilman <khilman@ti.com> Signed-off-by:
-
Wolfram Sang authored
commit c2735391 upstream. reg | (1 << clk->enable_shift) always evaluates to true. Switch it to & which makes much more sense. Same fix as 13be9f00 (ARM i.MX28: fix bit operation) at a different location. Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Shawn Guo <shawn.guo@freescale.com> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Haojian Zhuang authored
commit c0a39151 upstream. Since CONFIG_USB_GADGET_PXA27X and other macros are renamed to CONFIG_USB_PXA27X. Update them in arch/arm/mach-pxa and arch/arm/configs to keep consistent. Signed-off-by:
Haojian Zhuang <haojian.zhuang@marvell.com> Acked-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Daniel Drake authored
commit a3283969 upstream. While the OLPC display appears to be able to handle either positive or negative sync, the Display Controller only recognises positive sync. This brings viafb (for XO-1.5) in line with lxfb (for XO-1) and fixes a recent regression where the XO-1.5 DCON could no longer be frozen. Thanks to Florian Tobias Schandinat for helping identify the fix. Test case: from a vt, echo 1 > /sys/devices/platform/dcon/freeze should cause the current screen contents to freeze, rather than garbage being displayed. Signed-off-by:
Daniel Drake <dsd@laptop.org> Signed-off-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by:
-
Alex Deucher authored
commit 6c47e5c2 upstream. Fixes i2c test failures when i2c_algo_bit.bit_test=1. The hw doesn't actually require a mask, so just set it to the default mask bits for r1xx-r4xx radeon ddc. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Bjorn Helgaas authored
commit 4cac2eb1 upstream. Previously we claimed device ID 0x7450, regardless of the vendor, which is clearly wrong. Now we'll claim that device ID only for AMD. I suspect this was just a typo in the original code, but it's possible this change will break shpchp on non-7450 AMD bridges. If so, we'll have to fix them as we find them. Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863Reported-by:
Ralf Jung <ralfjung-e@gmx.de> Cc: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jesse Barnes authored
commit cb0e0931 upstream. CB tuning is needed to handle potential process variations that might cause clock jitter for certain PLL settings. However, we were setting it incorrectly since we were using the wrong M value as a check (M1 when we needed to use the whole M value). Fix it up, making my HDMI attached display a little prettier (used to have occasional dots crawl across the display). Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Timo Aaltonen <timo@canonical.com> Signed-off-by:
-
Ben Skeggs authored
commit ff02b13f upstream. Fixes an information leak to userspace, we were handing out un-zeroed pages for any newly created TTM_PL_TT buffer. Reported-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Tested-by:
-
Eric Anholt authored
commit 9ca1d10d upstream. Unlike the previous one, I don't have known testcases it fixes. I'd rather not go through the same debug cycle on whatever testcases those might be. Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Eric Anholt authored
commit 406478dc upstream. Fixes rendering failures in Unigine Tropics and Sanctuary and the mesa "fire" demo. Signed-off-by:
-
Daniel Vetter authored
commit 775d17b6 upstream. So don't forget to restore them on resume and dump them into the error state. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Alex Deucher authored
commit d724502a upstream. Fixes i2c test failures when i2c_algo_bit.bit_test=1. The hw doesn't actually require a mask, so just set it to the default mask bits for r1xx-r4xx radeon ddc. I missed this part the first time through. Signed-off-by:
-
Xi Wang authored
commit a5cd3351 upstream. There is a potential integer overflow in drm_mode_dirtyfb_ioctl() if userspace passes in a large num_clips. The call to kmalloc would allocate a small buffer, and the call to fb->funcs->dirty may result in a memory corruption. Reported-by:
Haogang Chen <haogangchen@gmail.com> Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
-
Phil Sutter authored
commit 27425286 upstream. This was broken by commit 7759995c (yes, myself). The basic problem here is since the digest state is only saved after the last chunk, the state array is only valid when handling the first chunk of the next buffer. Broken since linux-3.0. Signed-off-by:
Phil Sutter <phil.sutter@viprinet.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Tyler Hicks authored
commit 0f751e64 upstream. From mhalcrow's original commit message: Characters with ASCII values greater than the size of filename_rev_map[] are valid filename characters. ecryptfs_decode_from_filename() will access kernel memory beyond that array, and ecryptfs_parse_tag_70_packet() will then decrypt those characters. The attacker, using the FNEK of the crafted file, can then re-encrypt the characters to reveal the kernel memory past the end of the filename_rev_map[] array. I expect low security impact since this array is statically allocated in the text area, and the amount of memory past the array that is accessible is limited by the largest possible ASCII filename character. This patch solves the issue reported by mhalcrow but with an implementation suggested by Linus to simply extend the length of filename_rev_map[] to 256. Characters greater than 0x7A are mapped to 0x00, which is how invalid characters less than 0x7A were previously being handled. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Reported-by:
Michael Halcrow <mhalcrow@google.com> Signed-off-by:
-
Jeffrey (Sheng-Hui) Chu authored
commit cc6bcf7d upstream. The wrong bits were put on the wire, fix that. This fixes kernel bug #42562. Signed-off-by:
Sheng-Hui J. Chu <jeffchu@broadcom.com> Signed-off-by:
-
Tyler Hicks authored
commit 32001d6f upstream. Dirty pages weren't being written back when an mmap'ed eCryptfs file was closed before the mapping was unmapped. Since f_ops->flush() is not called by the munmap() path, the lower file was simply being released. This patch flushes the eCryptfs file in the vm_ops->close() path. https://launchpad.net/bugs/870326Signed-off-by:
-
- 28 Nov, 2011 2 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This reverts commit 317451c1. Cc: Matthieu Castet <matthieu.castet@parrot.com> Cc: Thomas Poussevin <thomas.poussevin@parrot.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
- 26 Nov, 2011 1 commit
-
-
Greg Kroah-Hartman authored
-
