- 27 Apr, 2014 30 commits
-
-
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.8 (no dm-cache-metadata.c, dm-era-target.c) ] Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
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:
-
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:
-
Jason Wang authored
commit ca3ba2a2 upstream. This patch bypass the timer_irq_works() check for hyperv guest since: - It was guaranteed to work. - timer_irq_works() may fail sometime due to the lpj calibration were inaccurate in a hyperv guest or a buggy host. In the future, we should get the tsc frequency from hypervisor and use preset lpj instead. [ hpa: I would prefer to not defer things to "the future" in the future... ] Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Acked-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Link: http://lkml.kernel.org/r/1393558229-14755-1-git-send-email-jasowang@redhat.comSigned-off-by:
H. Peter Anvin <hpa@linux.intel.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:
-
Josef Bacik authored
commit 3bbb24b2 upstream. Zach found this deadlock that would happen like this btrfs_end_transaction <- reduce trans->use_count to 0 btrfs_run_delayed_refs btrfs_cow_block find_free_extent btrfs_start_transaction <- increase trans->use_count to 1 allocate chunk btrfs_end_transaction <- decrease trans->use_count to 0 btrfs_run_delayed_refs lock tree block we are cowing above ^^ We need to only decrease trans->use_count if it is above 1, otherwise leave it alone. This will make nested trans be the only ones who decrease their added ref, and will let us get rid of the trans->use_count++ hack if we have to commit the transaction. Thanks, Reported-by:
Zach Brown <zab@redhat.com> Signed-off-by:
Josef Bacik <jbacik@fb.com> Tested-by:
Chris Mason <clm@fb.com> 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> [ kamal: backport to 3.8 (context) ] 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:
-
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:
Mark Brown <broonie@linaro.org> 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 <k.kozlowski@samsung.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> 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:
-
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:
Takashi Iwai <tiwai@suse.de> Signed-off-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:
-
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:
-
Krzysztof Kozlowski authored
commit 65aba1e0 upstream. During probe the sec-core driver allocates dummy I2C device for RTC with i2c_new_dummy() but return value is not checked. 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() or i2c_unregister_device(). If i2c_new_dummy() fails for RTC device, fail also the probe for main MFD driver. Signed-off-by:
-
Yann Droneaud authored
commit 9d194d10 upstream. In case of error while accessing to userspace memory, function nes_create_qp() returns NULL instead of an error code wrapped through ERR_PTR(). But NULL is not expected by ib_uverbs_create_qp(), as it check for error with IS_ERR(). As page 0 is likely not mapped, it is going to trigger an Oops when the kernel will try to dereference NULL pointer to access to struct ib_qp's fields. In some rare cases, page 0 could be mapped by userspace, which could turn this bug to a vulnerability that could be exploited: the function pointers in struct ib_device will be under userspace total control. This was caught when using spatch (aka. coccinelle) to rewrite calls to ib_copy_{from,to}_udata(). Link: https://www.gitorious.org/opteya/ib-hw-nes-create-qp-null Link: https://www.gitorious.org/opteya/coccib/source/75ebf2c1033c64c1d81df13e4ae44ee99c989eba:ib_copy_udata.cocci Link: http://marc.info/?i=cover.1394485254.git.ydroneaud@opteya.comSigned-off-by:
Yann Droneaud <ydroneaud@opteya.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Dennis Dalessandro authored
commit a2cb0eb8 upstream. Guard against a potential buffer overrun. The size to read from the user is passed in, and due to the padding that needs to be taken into account, as well as the place holder for the ICRC it is possible to overflow the 32bit value which would cause more data to be copied from user space than is allocated in the buffer. Reported-by:
Nico Golde <nico@ngolde.de> Reported-by:
Fabian Yamaguchi <fabs@goesec.de> Reviewed-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
-
Alan Stern authored
commit 6aec044c upstream. When a driver doesn't have pre_reset, post_reset, or reset_resume methods, the USB core unbinds that driver when its device undergoes a reset or a reset-resume, and then rebinds it afterward. The existing straightforward implementation can lead to problems, because each interface gets unbound and rebound before the next interface is handled. If a driver claims additional interfaces, the claim may fail because the old binding instance may still own the additional interface when the new instance tries to claim it. This patch fixes the problem by first unbinding all the interfaces that are marked (i.e., their needs_binding flag is set) and then rebinding all of them. The patch also makes the helper functions in driver.c a little more uniform and adjusts some out-of-date comments. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by:
"Poulain, Loic" <loic.poulain@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Kees Cook authored
commit aba37fd9 upstream. This makes sure that the name coming out of configfs cannot be used accidentally as a format string. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
- 17 Apr, 2014 10 commits
-
-
Felix Fietkau authored
commit 3b3e0efb upstream. qi->tqi_readyTime is written directly to registers that expect microseconds as unit instead of TU. When setting the CABQ ready time, cur_conf->beacon_interval is in TU, so convert it to microseconds before passing it to ath9k_hw. This should hopefully fix some Tx DMA issues with buffered multicast frames in AP mode. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Felipe Franciosi authored
commit 368c89d7 upstream. If the buffers are unmapped after completing a request, then stale data might be in the request. Signed-off-by:
Felipe Franciosi <felipe@paradoxo.org> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Felipe Franciosi authored
commit 1044b1bb upstream. We need to set the queue bounce limit during the device initialization to prevent excessive bouncing on 32 bit architectures. Signed-off-by:
-
Stefan Sørensen authored
commit 698b4853 upstream. When an interrupt has become active on the INTC it will stay active until it is acked, even if masked or de-asserted. The INTC_PENDING_IRQn registers are however updated and since these are used by omap_intc_handle_irq to determine which interrupt to handle, it will never see the active interrupt. This will result in a storm of useless interrupts that is only stopped when another higher priority interrupt is asserted. Fix by sending the INTC an acknowledge if we find no interrupts to handle. Signed-off-by:
Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Catalin Marinas authored
commit 71fdb6bf upstream. Special pte mappings are not intended to be executable and do not even have an associated struct page. This patch ensures that we do not call __sync_icache_dcache() on such ptes. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Reported-by:
Steve Capper <Steve.Capper@arm.com> Tested-by:
Laura Abbott <lauraa@codeaurora.org> Tested-by:
Bharat Bhushan <Bharat.Bhushan@freescale.com> Signed-off-by:
-
Catalin Marinas authored
commit de2db743 upstream. pgprot_{dmacoherent,writecombine,noncached} don't need to generate executable mappings with side-effects like __sync_icache_dcache() being called when the mapping is in user space. Signed-off-by:
-
Catalin Marinas authored
commit 4f00130b upstream. This provides better performance compared to Device GRE and also allows unaligned accesses. Such memory is intended to be used with standard RAM (e.g. framebuffers) and not I/O. Signed-off-by:
-
Rusty Russell authored
commit 1f74ef0f upstream. When adding or removing 100G from a balloon: BUG: soft lockup - CPU#0 stuck for 22s! [vballoon:367] We have a wait_event_interruptible(), but the condition is always true (more ballooning to do) so we don't ever sleep. We also have a wait_event() for the host to ack, but that is also always true as QEMU is synchronous for balloon operations. Reported-by:
Gopesh Kumar Chaudhary <gopchaud@in.ibm.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Emmanuel Grumbach authored
commit 82e5a649 upstream. There is a flow in which we send the host command in SYNC mode, but we don't take priv->mutex. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1046495Reviewed-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Herve Codina authored
commit 90445ff6 upstream. Crash detected on sam5d35 and its pmecc nand ecc controller. The problem was a call to chip->ecc.hwctl from nand_write_subpage_hwecc (nand_base.c) when we write a sub page. chip->ecc.hwctl function is not set when we are using PMECC controller. As a workaround, set NAND_NO_SUBPAGE_WRITE for PMECC controller in order to disable sub page access in nand_write_page. Signed-off-by:
Herve Codina <Herve.CODINA@celad.com> Acked-by:
Josh Wu <josh.wu@atmel.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
