- 01 May, 2014 40 commits
-
-
Benjamin LaHaise authored
commit fa8a53c3 upstream. As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues exist in the aio ring page migration support. As a result, for example, we have the following problem: thread 1 | thread 2 | aio_migratepage() | |-> take ctx->completion_lock | |-> migrate_page_copy(new, old) | | *NOW*, ctx->ring_pages[idx] == old | | | *NOW*, ctx->ring_pages[idx] == old | aio_read_events_ring() | |-> ring = kmap_atomic(ctx->ring_pages[0]) | |-> ring->head = head; *HERE, write to the old ring page* | |-> kunmap_atomic(ring); | |-> ctx->ring_pages[idx] = new | | *BUT NOW*, the content of | | ring_pages[idx] is old. | |-> release ctx->completion_lock | As above, the new ring page will not be updated. Fix this issue, as well as prevent races in aio_ring_setup() by holding the ring_lock mutex during kioctx setup and page migration. This avoids the overhead of taking another spinlock in aio_read_events_ring() as Tang's and Gu's original fix did, pushing the overhead into the migration code. Note that to handle the nesting of ring_lock inside of mmap_sem, the migratepage operation uses mutex_trylock(). Page migration is not a 100% critical operation in this case, so the ocassional failure can be tolerated. This issue was reported by Sasha Levin. Based on feedback from Linus, avoid the extra taking of ctx->completion_lock. Instead, make page migration fully serialised by mapping->private_lock, and have aio_free_ring() simply disconnect the kioctx from the mapping by calling put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the error handling logic in aio_migratepage(), and should improve robustness. v4: always do mutex_unlock() in cases when kioctx setup fails. Reported-by:
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reported-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Cc: Tang Chen <tangchen@cn.fujitsu.com> Cc: Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Joe Thornber authored
commit 5a32083d upstream. In theory copying the space map root can fail, but in practice it never does because we're careful to check what size buffer is needed. But make certain we're able to copy the space map roots before locking the superblock. Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> [ kamal: backport to 3.13-stable (dropped dm-era-target.c changes) ] Signed-off-by:
-
Joe Thornber authored
commit a9d45396 upstream. The persistent-data library used by dm-thin, dm-cache, etc is transactional. If anything goes wrong, such as an io error when writing new metadata or a power failure, then we roll back to the last transaction. Atomicity when committing a transaction is achieved by: a) Never overwriting data from the previous transaction. b) Writing the superblock last, after all other metadata has hit the disk. This commit and the following commit ("dm: take care to copy the space map roots before locking the superblock") fix a bug associated with (b). When committing it was possible for the superblock to still be written in spite of an io error occurring during the preceeding metadata flush. With these commits we're careful not to take the write lock out on the superblock until after the metadata flush has completed. Change the transaction manager's semantics for dm_tm_commit() to assume all data has been flushed _before_ the single superblock that is passed in. As a prerequisite, split the block manager's block unlocking and flushing by simplifying dm_bm_flush_and_unlock() to dm_bm_flush(). Now the unlocking must be done separately. This issue was discovered by forcing io errors at the crucial time using dm-flakey. Signed-off-by:
-
Mike Snitzer authored
commit d132cc6d upstream. If the discard block size is larger than the cache block size we will not properly quiesce IO to a region that is about to be discarded. This results in a race between a cache migration where no copy is needed, and a write to an adjacent cache block that's within the same large discard block. Workaround this by limiting the discard_block_size to cache_block_size. Also limit the max_discard_sectors to cache_block_size. A more comprehensive fix that introduces range locking support in the bio_prison and proper quiescing of a discard range that spans multiple cache blocks is already in development. Reported-by:
Morgan Mears <Morgan.Mears@netapp.com> Signed-off-by:
Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
commit 9f67f189 upstream. Looks like this bug has been here since these write counts were introduced, not sure why it was just noticed now. Thanks also to Jan Kara for pointing out the problem. Reported-by:
Matthew Rahtz <mrahtz@rapitasystems.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
commit a11fcce1 upstream. If the entire operation fails then there's nothing to encode. Signed-off-by:
-
J. Bruce Fields authored
commit 04819bf6 upstream. This fixes an ommission from 18032ca0 "NFSD: Server implementation of MAC Labeling", which increased the size of the setattr error reply without increasing COMPOUND_ERR_SLACK_SPACE. Signed-off-by:
-
J. Bruce Fields authored
commit 4c69d585 upstream. Signed-off-by:
-
J. Bruce Fields authored
commit de3997a7 upstream. This was an omission from 8c18f205 "nfsd41: SUPPATTR_EXCLCREAT attribute". Cc: Benny Halevy <bhalevy@primarydata.com> Signed-off-by:
-
Marek Vasut authored
commit a585f87c upstream. The scenario here is that someone calls enable_irq_wake() from somewhere in the code. This will result in the lockdep producing a backtrace as can be seen below. In my case, this problem is triggered when using the wl1271 (TI WlCore) driver found in drivers/net/wireless/ti/ . The problem cause is rather obvious from the backtrace, but let's outline the dependency. enable_irq_wake() grabs the IRQ buslock in irq_set_irq_wake(), which in turns calls mxs_gpio_set_wake_irq() . But mxs_gpio_set_wake_irq() calls enable_irq_wake() again on the one-level-higher IRQ , thus it tries to grab the IRQ buslock again in irq_set_irq_wake() . Because the spinlock in irq_set_irq_wake()->irq_get_desc_buslock()->__irq_get_desc_lock() is not marked as recursive, lockdep will spew the stuff below. We know we can safely re-enter the lock, so use IRQ_GC_INIT_NESTED_LOCK to fix the spew. ============================================= [ INFO: possible recursive locking detected ] 3.10.33-00012-gf06b763-dirty #61 Not tainted --------------------------------------------- kworker/0:1/18 is trying to acquire lock: (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88 but task is already holding lock: (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by kworker/0:1/18: #0: (events){.+.+.+}, at: [<c0036308>] process_one_work+0x134/0x4a4 #1: ((&fw_work->work)){+.+.+.}, at: [<c0036308>] process_one_work+0x134/0x4a4 #2: (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88 stack backtrace: CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.10.33-00012-gf06b763-dirty #61 Workqueue: events request_firmware_work_func [<c0013eb4>] (unwind_backtrace+0x0/0xf0) from [<c0011c74>] (show_stack+0x10/0x14) [<c0011c74>] (show_stack+0x10/0x14) from [<c005bb08>] (__lock_acquire+0x140c/0x1a64) [<c005bb08>] (__lock_acquire+0x140c/0x1a64) from [<c005c6a8>] (lock_acquire+0x9c/0x104) [<c005c6a8>] (lock_acquire+0x9c/0x104) from [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58) [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c00685f0>] (__irq_get_desc_lock+0x48/0x88) [<c00685f0>] (__irq_get_desc_lock+0x48/0x88) from [<c0068e78>] (irq_set_irq_wake+0x20/0xf4) [<c0068e78>] (irq_set_irq_wake+0x20/0xf4) from [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24) [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24) from [<c0068cf4>] (set_irq_wake_real+0x30/0x44) [<c0068cf4>] (set_irq_wake_real+0x30/0x44) from [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4) [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4) from [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c) [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c) from [<c02be5e8>] (request_firmware_work_func+0x38/0x58) [<c02be5e8>] (request_firmware_work_func+0x38/0x58) from [<c0036394>] (process_one_work+0x1c0/0x4a4) [<c0036394>] (process_one_work+0x1c0/0x4a4) from [<c0036a4c>] (worker_thread+0x138/0x394) [<c0036a4c>] (worker_thread+0x138/0x394) from [<c003cb74>] (kthread+0xa4/0xb0) [<c003cb74>] (kthread+0xa4/0xb0) from [<c000ee00>] (ret_from_fork+0x14/0x34) wlcore: loaded Signed-off-by:
Marek Vasut <marex@denx.de> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Anton Blanchard authored
commit 7505258c upstream. I noticed KVM is broken when KVM in-kernel XICS emulation (CONFIG_KVM_XICS) is disabled. The problem was introduced in 48eaef05 (KVM: PPC: Book3S HV: use xics_wake_cpu only when defined). It used CONFIG_KVM_XICS to wrap xics_wake_cpu, where CONFIG_PPC_ICP_NATIVE should have been used. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Paul Mackerras <paulus@samba.org> Acked-by:
Scott Wood <scottwood@freescale.com> Signed-off-by:
-
Hui Wang authored
commit a870593b upstream. When we plug a 3-ring headset on the Dell machines (VID: 0x10ec0255, SID: 0x10280632; VID: 0x10ec0293, SID: 0x1028062c; VID: 0x10ec0293, SID: 0x1028062e), the headset mic can't be detected, after apply this patch, the headset mic can work well. BugLink: https://bugs.launchpad.net/bugs/1297581 Cc: David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Uwe Kleine-König authored
commit 12f6dd86 upstream. Wolfram Sang pointed out that "efm32,$device" is non-standard. So use the common scheme and prefix device with "efm32-". The old compatible string is left in place until arch/arm/boot/dts/efm32* is fixed. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 238e1405 upstream. If parent device does not have of_node set the s2mps11_clk_parse_dt() returned NULL. This NULL was later passed to of_clk_add_provider() which dereferenced it in pr_debug() call. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Mike Turquette <mturquette@linaro.org> Signed-off-by:
-
Anton Blanchard authored
commit 422b9b96 upstream. I noticed this when testing setarch. No, we don't magically support a big endian userspace on a little endian kernel. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Chris Wilson authored
commit df6f783a upstream. On non-LLC platforms, when changing the cache level of an object, we may need to unbind it so that prefetching across page boundaries does not cross into a different memory domain. This requires us to unbind conflicting vma, but we did so iterating over the objects vma in an unsafe manner (as the list was being modified as we iterated). The regression was introduced in commit 3089c6f2 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 31 17:00:03 2013 -0700 drm/i915: make caching operate on all address spaces apparently as far back as v3.12-rc1, but it has only just begun to trigger real world bug reports. Reported-and-tested-by:
Nikolay Martynov <mar.kolya@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76384Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Guenter Roeck authored
commit 204747c9 upstream. On PXT and COMe-cPC2 boards it is observed that the hardware mutex is acquired but not being released during initialization. This can result in a hang-up during boot if the driver is built into the kernel. Releasing the mutex twice if it was acquired fixes the problem. Subsequent request/release cycles work as expected, so the fix is only needed during initialization. Reviewed-by:
Michael Brunner <michael.brunner@kontron.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Richard Guy Briggs authored
commit c92cdeb4 upstream. sys_getppid() returns the parent pid of the current process in its own pid namespace. Since audit filters are based in the init pid namespace, a process could avoid a filter or trigger an unintended one by being in an alternate pid namespace or log meaningless information. Switch to task_ppid_nr() for PPIDs to anchor all audit filters in the init_pid_ns. (informed by ebiederman's 6c621b7e) Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
-
Richard Guy Briggs authored
commit 2f2ad101 upstream. When being refactored from audit_log_start() to audit_log_task_info(), in commit e23eb920 the tty and ses fields in the log output got transposed. Restore to original order to avoid breaking search tools. Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
Richard Guy Briggs authored
commit ad36d282 upstream. Added the functions task_ppid_nr_ns() and task_ppid_nr() to abstract the lookup of the PPID (real_parent's pid_t) of a process, including rcu locking, in the arbitrary and init_pid_ns. This provides an alternative to sys_getppid(), which is relative to the child process' pid namespace. (informed by ebiederman's 6c621b7e) Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Michael Braun authored
commit 112c44b2 upstream. commit de74a1d9 "mac80211: fix WPA with VLAN on AP side with ps-sta" fixed an issue where queued multicast packets would be sent out encrypted with the key of an other bss. commit "7cbf9d01" "mac80211: fix oops on mesh PS broadcast forwarding" essentially reverted it, because vif.type cannot be AP_VLAN due to the check to vif.type in ieee80211_get_buffered_bc before. As the later commit intended to fix the MESH case, fix it by checking for IFTYPE_AP instead of IFTYPE_AP_VLAN. Fixes: 7cbf9d01 ("mac80211: fix oops on mesh PS broadcast forwarding") Signed-off-by:
Michael Braun <michael-dev@fami-braun.de> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 1a1cb744 upstream. Since Stanislaw's patch removing the quiescing code, mac80211 had a race regarding suspend vs. authentication: as cfg80211 doesn't track authentication attempts, it can't abort them. Therefore the attempts may be kept running while suspending, which can lead to all kinds of issues, in at least some cases causing an error in iwlmvm firmware. Fix this by aborting the authentication attempt when suspending. Fixes: 12e7f517 ("mac80211: cleanup generic suspend/resume procedures") Signed-off-by:
-
Johannes Berg authored
commit d2722f8b upstream. The bss struct might be freed in ieee80211_rx_bss_put(), so we shouldn't use it afterwards. Fixes: 817cee76 ("mac80211: track AP's beacon rate and give it to the driver") Signed-off-by:
-
Brian Austin authored
commit 7272e051 upstream. The shift values for the ADC,PCM, and Analog kcontrols were wrong causing wrong values for the SOC_DOUBLE_R_SX_TLV macros Fixed the TLV for aout_tlv to show -102dB correctly Fixes: 1d99f243 (ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV) Reported-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
Brian Austin <brian.austin@cirrus.com> Signed-off-by:
-
James Hogan authored
commit 15505679 upstream. Previously a reserved instruction exception while in guest code would cause a KVM internal error if kvm_mips_handle_ri() didn't recognise the instruction (including a RDHWR from an unrecognised hardware register). However the guest OS should really have the opportunity to catch the exception so that it can take the appropriate actions such as sending a SIGILL to the guest user process or emulating the instruction itself. Therefore in these cases emulate a guest RI exception and only return EMULATE_FAIL if that fails, being careful to revert the PC first in case the exception occurred in a branch delay slot in which case the PC will already point to the branch target. Also turn the printk messages relating to these cases into kvm_debug messages so that they aren't usually visible. This allows crashme to run in the guest without killing the entire VM. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Gleb Natapov <gleb@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Sanjay Lal <sanjayl@kymasys.com> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 483e2dfd upstream. Fixes: 4aab3fad ("mfd: tps65910: Move interrupt implementation code to mfd file") tps65910_irq_init() sets 'tps65910->chip_irq' before calling regmap_add_irq_chip(). If the regmap_add_irq_chip() call fails in memory allocation of regmap_irq_chip_data members then: 1. The 'tps65910->chip_irq' will still hold some value 2. 'tps65910->irq_data' will be pointing to already freed memory (because regmap_add_irq_chip() will free it on error) This results in invalid memory access during driver remove because the tps65910_irq_exit() tests whether 'tps65910->chip_irq' is not zero. Signed-off-by:
-
Krzysztof Kozlowski authored
commit 141050cf upstream. During probe the driver allocates two dummy I2C devices for subchips in function pm800_pages_init(). Additionally this function allocates regmaps for these subchips. If any of these steps fail then these dummy I2C devices are not freed and resources leak. On pm800_pages_init() fail the driver must call pm800_pages_exit() to unregister dummy I2C devices. Signed-off-by:
-
Krzysztof Kozlowski authored
commit ad09dd6a upstream. During probe the driver allocates dummy I2C devices for MUIC and haptic with i2c_new_dummy() but it does not check the return value of this calls. In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later used by devm_regmap_init_i2c() and i2c_unregister_device(). If i2c_new_dummy() fails for MUIC or haptic devices, fail also the probe for main MFD driver. Signed-off-by:
-
Krzysztof Kozlowski authored
commit 159ce52a upstream. During probe the driver allocates dummy I2C device for companion chip with i2c_new_dummy() but it does not check the return value of this call. In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later used by regmap_init_i2c(). If i2c_new_dummy() fails for companion device, fail also the probe for main MFD driver. Signed-off-by:
-
Krzysztof Kozlowski authored
commit a7ab1c8b upstream. During probe the driver allocates dummy I2C device for companion chip and then allocates a regmap for it. If regmap_init_i2c() fails then the I2C driver (allocated with i2c_new_dummy()) is not freed and this resource leaks. Signed-off-by:
-
Krzysztof Kozlowski authored
commit 96cf3ded upstream. During probe the driver allocates dummy I2C devices for RTC and ADC with i2c_new_dummy() but it does not check the return value of this calls. In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later used by i2c_unregister_device(). If i2c_new_dummy() fails for RTC or ADC devices, fail also the probe for main MFD driver. Signed-off-by:
-
Krzysztof Kozlowski authored
commit ed26f87b upstream. During probe the driver allocates dummy I2C device for RTC with i2c_new_dummy() but it does not check the return value of this call. In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later used by i2c_unregister_device(). If i2c_new_dummy() fails for RTC device, fail also the probe for main MFD driver. Signed-off-by:
-
Krzysztof Kozlowski authored
commit b9e183a1 upstream. During probe the driver allocates dummy I2C device for RTC with i2c_new_dummy() but it does not check the return value of this call. In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later used by i2c_unregister_device(). If i2c_new_dummy() fails for RTC device, fail also the probe for main MFD driver. Signed-off-by:
-
Krzysztof Kozlowski authored
commit 97dc4ed3 upstream. During probe the driver allocates dummy I2C devices for RTC, haptic and MUIC with i2c_new_dummy() but it does not check the return value of this calls. In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later used by i2c_unregister_device(). If i2c_new_dummy() fails for RTC, haptic or MUIC devices, fail also the probe for main MFD driver. Signed-off-by:
-
Linus Walleij authored
commit a6e6e660 upstream. It is currently not possible to select the SA1100 or Vexpress drivers in the MFD subsystem, because the menu for the entire subsystem ends before these options are presented. Move the main menu closing and the endif for HAS_IOMEM to the end of the file so these are selectable again. Signed-off-by:
-
Steven Rostedt authored
commit 9297ebf2 upstream. The TP_printk() should never dereference any pointers, because the ring buffer can be read at some unknown time in the future. If a device no longer exists, it can cause a kernel oops. This also makes this event useless when saving the ring buffer in userspaces tools such as perf and trace-cmd. The i915_gem_evict_vm dereferences the vm pointer which may also not exist when the ring buffer is read sometime in the future. Link: http://lkml.kernel.org/r/1395095198-20034-3-git-send-email-artagnon@gmail.comReported-by:
Ramkumar Ramachandra <artagnon@gmail.com> Fixes: bcccff84 "drm/i915: trace vm eviction instead of everything" Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> [danvet: Try to make it actually compile] Signed-off-by:
-
Brian Austin authored
commit d31a33dd upstream. The mask bits values were wrong for the SOC_VALUE_ENUM_SINGLE for the PCM/ADC Swap controls Reported-by:
-
Brian Austin authored
commit 1555b652 upstream. The mask bits values were wrong for the SOC_VALUE_ENUM_SINGLE for the mono mix controls. Reported-by:
-
Emmanuel Grumbach authored
commit a82dda6c upstream. The current firmware advertises support for uAPSD, but critical bugs force us to disable the feature. When a fixed firmware will be available, we will be able to re-enable uAPSD. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Charles Keepax authored
commit a35ff286 upstream. Both 5102 and 8997 have the regulator capable of supplying 1.8V, and the voltage step from the 5110 regulator is different from what is specified in the default description. This patch updates the default regulator description to match 5110 and selects the 1.8V capable description for 8997. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
