- 07 Oct, 2016 40 commits
-
-
Mustafa Ismail authored
commit d41d0910 upstream. Memory allocated for iwqp; iwqp->allocated_buffer is freed twice in the create_qp error path. Correct this by having it freed only once in i40iw_free_qp_resources(). Fixes: d3749841 ("i40iw: add files for iwarp interface") Signed-off-by:
Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by:
Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Shiraz Saleem authored
commit 6c7d46fd upstream. iwdev->mem_resources is incorrectly defined as an unsigned long instead of u8. As a result, the offset into the dynamic allocated structures in i40iw_initialize_hw_resources() is incorrectly calculated and would lead to writing of memory regions outside of the allocated buffer. Fixes: 8e06af71 ("i40iw: add main, hdr, status") Reported-by:
Stefan Assmann <sassmann@redhat.com> Signed-off-by:
-
Mustafa Ismail authored
commit faa739fb upstream. In i40iw_open(), check if interface is already open and return success if it is. Fixes: 8e06af71 ("i40iw: add main, hdr, status") Reported-by:
-
Mustafa Ismail authored
commit 44856be3 upstream. In i40iw_alloc_resource(), ensure that the update to req_resource_num is protected by the lock. Fixes: 8e06af71 ("i40iw: add main, hdr, status") Reported-by:
-
Johannes Berg authored
commit 0b97a484 upstream. The A-MSDU TX code (within TXQs) didn't always check the return value of skb_linearize() properly, resulting in potentially passing a frag- list SKB down to the driver even when it said it can't handle it. Fix that. Fixes: 6e0456b5 ("mac80211: add A-MSDU tx support") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Russell King authored
commit 56beac95 upstream. ucb1x00 has used IRQ probing since it's dawn to find the GPIO interrupt that it's connected to. However, commit 23393d49 ("gpio: kill off set_irq_flags usage") broke this by disabling IRQ probing on GPIO interrupts. Fix this. Fixes: 23393d49 ("gpio: kill off set_irq_flags usage") Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit f4693b08 upstream. We can't assign -EINVAL to a u16. Fixes: 3948f0e0 ('usb: add Freescale QE/CPM USB peripheral controller driver') Acked-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit ff6e58e6 upstream. fw-dbg code return ret but that variable was either 0 or not initialised. Return 0 always. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: 6a951267 ("iwlwifi: mvm: send dbg config hcmds to fw if set in tlv") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Arnd Bergmann authored
commit 5a7d87da upstream. gcc is apparently unablel to track the state of the local 'resp_v2' variable across the kzalloc() function, and warns about the response variable being used without an initialization: drivers/net/wireless/intel/iwlwifi/mvm/nvm.c: In function ‘iwl_mvm_update_mcc’: drivers/net/wireless/intel/iwlwifi/mvm/nvm.c:727:36: warning: ‘mcc_resp_v1’ may be used uninitialized in this function [-Wmaybe-uninitialized] resp_cp->n_channels = mcc_resp_v1->n_channels; drivers/net/wireless/intel/iwlwifi/mvm/nvm.c:721:3: warning: ‘mcc_resp’ may be used uninitialized in this function [-Wmaybe-uninitialized] memcpy(resp_cp, mcc_resp, resp_len); The warning showed up in x86 allmodconfig after my patch to unhide -Wmaybe-uninitialized warnings by default was merged, though it always existed in randconfig builds. I did not catch the warning earlier because I was testing on ARM, which never produced the warning. This rearranges the code in a way that improves readability for both humans and the compiler, and that avoids the warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 6fa52430 ("iwlwifi: mvm: change mcc update API") Signed-off-by:
-
Sara Sharon authored
commit 60dec523 upstream. Restart flow zeroes the rx_ba_sessions counter. Mac80211 asks driver to tear down of the session only afterwards, and as a result driver didn't free the data. Fix it. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Fixes: 10b2b201 ("iwlwifi: mvm: add infrastructure for tracking BA session in driver") Signed-off-by:
-
Sara Sharon authored
commit d5d0689a upstream. This fixes a pretty ancient bug that hasn't manifested itself until now. The scratchbuf for command queue is allocated only for 32 slots but is accessed with the queue write pointer - which can be up to 256. Since the scratch buf size was 16 and there are up to 256 TFDs we never passed a page boundary when accessing the scratch buffer, but when attempting to increase the size of the scratch buffer a panic was quick to follow when trying to access the address resulted in a page boundary. Signed-off-by:
-
Emmanuel Grumbach authored
commit 3edbc7da upstream. This led to a DMA splat. Fixes: a6c4fb44 ("iwlwifi: mvm: Add FW paging mechanism for the UMAC on PCI") Signed-off-by:
-
Golan Ben-Ami authored
commit e7c9bd1c upstream. The TX fifos are arranged consecutively in the SMEM, beginning with the regular fifos, and tailed by the internal fifos. In the current code, while trying to read the internal fifos, we read the fifos beginning with the index zero. By doing this we actually re-read the regular fifos. In order to read the internal fifos, start the reading index from the number of regular fifos configured by the fw. Signed-off-by:
Golan Ben-Ami <golan.ben.ami@intel.com> Fixes: 39654cb3 ("iwlwifi: don't access a nonexistent register upon assert") Signed-off-by:
-
Oren Givon authored
commit 2c4a247e upstream. Fix an issue where nullfunc frames and block ack requests had the same tid as aggregation frames and were queued on a non aggregation queue. The pending frames counter included those frames but the check whether to decrement the pending frames counter relied on the tid status and not on the txq id. The result was an inconsistent state of the pending frames counter followed by a failure to remove the station. This failure triggered SYSASSERT 0x3421. In addition, fix a situation in DQA mode where the number of pending frames turned negative. This was due to the TX queue being on the IWL_EMPTYING_HW_QUEUE_DELBA state and its frames were still decremented. Even though the SYSASSERT issue is fixed when DQA is disabled, the issue is not completely solved when DQA is enabled and should still be fixed. Signed-off-by:
Oren Givon <oren.givon@intel.com> Fixes: cf961e16 ("iwlwifi: mvm: support dqa-mode agg on non-shared queue") Signed-off-by:
-
Sara Sharon authored
commit ecf51424 upstream. Our HW does not support checksum of fragmented packets. Fix code accordingly to checksum those packets in the driver. Signed-off-by:
-
Geert Uytterhoeven authored
commit c3ccf357 upstream. The conversion from a look-up table to a calculation for clock generator parameters forgot to take into account that BRDV x 1/1 is valid only if BRPS is x 1/1 or x 1/2, leading to undefined behavior (e.g. arbitrary clock rates). This limitation is documented for the MSIOF module in all supported SH/R-Mobile and R-Car Gen2/Gen3 ARM SoCs. Tested on r8a7791/koelsch and r8a7795/salvator-x. Fixes: 65d5665b ("spi: sh-msiof: Update calculation of frequency dividing") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Wanpeng Li authored
commit 3d89e547 upstream. Commit: e9532e69 ("sched/cputime: Fix steal time accounting vs. CPU hotplug") ... set rq->prev_* to 0 after a CPU hotplug comes back, in order to fix the case where (after CPU hotplug) steal time is smaller than rq->prev_steal_time. However, this should never happen. Steal time was only smaller because of the KVM-specific bug fixed by the previous patch. Worse, the previous patch triggers a bug on CPU hot-unplug/plug operation: because rq->prev_steal_time is cleared, all of the CPU's past steal time will be accounted again on hot-plug. Since the root cause has been fixed, we can just revert commit e9532e69. Signed-off-by:
Wanpeng Li <wanpeng.li@hotmail.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 'commit e9532e69 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")' Link: http://lkml.kernel.org/r/1465813966-3116-3-git-send-email-wanpeng.li@hotmail.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Michael Walle authored
commit b53893aa upstream. According to the datasheet you should only write 1 to this bit. If it is not set, at least AIN3 will return bad values on newer silicon revisions. Fixes: d84ca5b3 ("hwmon: Add driver for ADT7411 voltage and temperature sensor") Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guenter Roeck authored
commit a6c50912 upstream. nvmem_cell_read() is declared as void * if CONFIG_NVMEM is enabled, and as char * otherwise. This can result in a build warning if CONFIG_NVMEM is not enabled and a caller asigns the result to a type other than char * without using a typecast. Use a consistent declaration to avoid the problem. Fixes: e2a5402e ("nvmem: Add nvmem_device based consumer apis.") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Jon Hunter authored
commit 4f6aa326 upstream. To support UHS modes for Tegra an external regulator must be present to adjust the IO voltage accordingly. Even if the regulator is not present but the host supports the UHS modes and the device supports the UHS modes, then we will attempt to switch to a high-speed mode. Without an external regulator, Tegra will fail to switch to the high-speed mode. It has been found that with some SD cards, that once it has been switch to operate at a high-speed mode, all subsequent commands issues to the card will fail and so it will not be possible to switch back to a non high-speed mode and so the SD card initialisation will fail. The SDHCI core does not require that the host have an external regulator when switching to UHS modes and therefore, the Tegra SDHCI host controller should only advertise the UHS modes as being supported if the regulator for the IO voltage is present. Fortunately, Tegra has a vendor specific register which can be used to control which modes are advertised via the SDHCI_CAPABILITIES register. Hence, if there is no IO voltage regulator available for the Tegra SDHCI host, then don't advertise the UHS modes. Note that if the regulator is not available, we also don't advertise that the SDHCI is compatible with v3.0 of the SDHCI specification because this will read the SDHCI_CAPABILITIES_1 register which will enable other UHS modes. This fixes commit 7ad2ed1d ("mmc: tegra: enable UHS-I modes") which enables UHS mode without checking if the board can support them. Fixes: 7ad2ed1d ("mmc: tegra: enable UHS-I modes") Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Will Deacon authored
commit 8b6a3fe8 upstream. When tearing down an AUX buf for an event via perf_mmap_close(), __perf_event_output_stop() is called on the event's CPU to ensure that trace generation is halted before the process of unmapping and freeing the buffer pages begins. The callback is performed via cpu_function_call(), which ensures that it runs with interrupts disabled and is therefore not preemptible. Unfortunately, the current code grabs the per-cpu context pointer using get_cpu_ptr(), which unnecessarily disables preemption and doesn't pair the call with put_cpu_ptr(), leading to a preempt_count() imbalance and a BUG when freeing the AUX buffer later on: WARNING: CPU: 1 PID: 2249 at kernel/events/ring_buffer.c:539 __rb_free_aux+0x10c/0x120 Modules linked in: [...] Call Trace: [<ffffffff813379dd>] dump_stack+0x4f/0x72 [<ffffffff81059ff6>] __warn+0xc6/0xe0 [<ffffffff8105a0c8>] warn_slowpath_null+0x18/0x20 [<ffffffff8112761c>] __rb_free_aux+0x10c/0x120 [<ffffffff81128163>] rb_free_aux+0x13/0x20 [<ffffffff8112515e>] perf_mmap_close+0x29e/0x2f0 [<ffffffff8111da30>] ? perf_iterate_ctx+0xe0/0xe0 [<ffffffff8115f685>] remove_vma+0x25/0x60 [<ffffffff81161796>] exit_mmap+0x106/0x140 [<ffffffff8105725c>] mmput+0x1c/0xd0 [<ffffffff8105cac3>] do_exit+0x253/0xbf0 [<ffffffff8105e32e>] do_group_exit+0x3e/0xb0 [<ffffffff81068d49>] get_signal+0x249/0x640 [<ffffffff8101c273>] do_signal+0x23/0x640 [<ffffffff81905f42>] ? _raw_write_unlock_irq+0x12/0x30 [<ffffffff81905f69>] ? _raw_spin_unlock_irq+0x9/0x10 [<ffffffff81901896>] ? __schedule+0x2c6/0x710 [<ffffffff810022a4>] exit_to_usermode_loop+0x74/0x90 [<ffffffff81002a56>] prepare_exit_to_usermode+0x26/0x30 [<ffffffff81906d1b>] retint_user+0x8/0x10 This patch uses this_cpu_ptr() instead of get_cpu_ptr(), since preemption is already disabled by the caller. Signed-off-by:
Will Deacon <will.deacon@arm.com> Reviewed-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Fixes: 95ff4ca2 ("perf/core: Free AUX pages in unmap path") Link: http://lkml.kernel.org/r/20160824091905.GA16944@arm.comSigned-off-by:
-
Stefan Wahren authored
commit 75324684 upstream. In case of a IRQ type mismatch in of_pmu_irq_cfg() the device node for interrupt affinity isn't freed. So fix this issue by calling of_node_put(). Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Fixes: fa8ad788 ("arm: perf: factor arm_pmu core out to drivers") Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Boqun Feng authored
commit af06d4f7 upstream. 0day found a boot warning triggered in rcu_perf_writer() on !SMP kernel: WARN_ON(rcu_gp_is_normal() && gp_exp); , the root cause of which is trying to measure expedited grace periods(by setting gp_exp to true by default) when all the grace periods are normal(TINY RCU only has normal grace periods). However, such a mis-setting would only result in failing to measure the performance for a specific kind of grace periods, therefore using a WARN_ON to check this is a little overkilling. We could handle this inside rcuperf module via some error messages to tell users about the mis-settings. Therefore this patch removes the WARN_ON in rcu_perf_writer() and handles those checkings in rcu_perf_init() with plain if() code. Moreover, this patch changes the default value of gp_exp to 1) align with rcutorture tests and 2) make the default setting work for all RCU implementations by default. Suggested-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
Boqun Feng <boqun.feng@gmail.com> Fixes: http://lkml.kernel.org/r/57411b10.mFvG0+AgcrMXGtcj%fengguang.wu@intel.comSigned-off-by:
-
Wolfram Sang authored
commit e35478ea upstream. We can't use a static property for all the changesets, so we now create dynamic ones for each changeset. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Fixes: 50a5ba87 ("i2c: mux: demux-pinctrl: add driver") Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Andy Shevchenko authored
commit 7440926e upstream. Documentation incorrectly refers to struct pinctrl_desc, where no such flag is available. Replace the name of the struct. Fixes: commit 8c4c2016 ("pinctrl: move strict option to pinmux_ops") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Masahiro Yamada authored
commit 10ef8277 upstream. Without this, reading the "pins" in the debugfs causes kernel BUG. Fixes: 6e908892 ("pinctrl: UniPhier: add UniPhier pinctrl core support") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Heinrich Schuchardt authored
commit cd956722 upstream. In function i40e_debug_aq parameter desc is assumed to be possibly NULL. Do not dereference it before checking the value. Fixes: f905dd62 ("i40e/i40evf: add max buf len to aq debug print helper") Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Heinrich Schuchardt authored
commit 3fdbda44 upstream. Variable adapter is incorrectly initialized. Fixes: bf00dc22 ("mwifiex: AMSDU Rx frame handling in AP mode") Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Roger Quadros authored
commit d248220f upstream. Since commit 6ce0d200 ("ARM: dma: Use dma_pfn_offset for dma address translation"), dma_to_pfn() already returns the PFN with the physical memory start offset so we don't need to add it again. This fixes USB mass storage lock-up problem on systems that can't do DMA over the entire physical memory range (e.g.) Keystone 2 systems with 4GB RAM can only do DMA over the first 2GB. [K2E-EVM]. What happens there is that without this patch SCSI layer sets a wrong bounce buffer limit in scsi_calculate_bounce_limit() for the USB mass storage device. dma_max_pfn() evaluates to 0x8fffff and bounce_limit is set to 0x8fffff000 whereas maximum DMA'ble physical memory on Keystone 2 is 0x87fffffff. This results in non DMA'ble pages being given to the USB controller and hence the lock-up. NOTE: in the above case, USB-SCSI-device's dma_pfn_offset was showing as 0. This should have really been 0x780000 as on K2e, LOWMEM_START is 0x80000000 and HIGHMEM_START is 0x800000000. DMA zone is 2GB so dma_max_pfn should be 0x87ffff. The incorrect dma_pfn_offset for the USB storage device is because USB devices are not correctly inheriting the dma_pfn_offset from the USB host controller. This will be fixed by a separate patch. Fixes: 6ce0d200 ("ARM: dma: Use dma_pfn_offset for dma address translation") Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Olof Johansson <olof@lixom.net> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Reported-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Robin Murphy authored
commit ba6dea4f upstream. Whilst MPIDR values themselves are less than 32 bits, it is still perfectly valid for a DT to have #address-cells > 1 in the CPUs node, resulting in the "reg" property having leading zero cell(s). In that situation, the big-endian nature of the data conspires with the current behaviour of only reading the first cell to cause the kernel to think all CPUs have ID 0, and become resoundingly unhappy as a consequence. Take the full property length into account when parsing CPUs so as to be correct under any circumstances. Cc: Russell King <linux@armlinux.org.uk> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Alex Deucher authored
commit 670bb4fd upstream. Add clock quirks for Jet parts. Reviewed-by:
Sonny Jiang <sonny.jiang@amd.com> Tested-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Ilia Mirkin authored
commit 666ca3d8 upstream. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
David Herrmann authored
commit 90fd68dc upstream. The udl damage handler is supposed to render 'height' lines, but its iterator has an obvious typo that makes it miss most lines if the rectangle does not cover 0/0. Fix the damage handler to correctly render all lines. This is a fallout from: commit e3758824 Author: Noralf Trønnes <noralf@tronnes.org> Date: Thu Apr 28 17:18:37 2016 +0200 drm/udl: Use drm_fb_helper deferred_io support Tested-by:
poma <poma@gmail.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Andy Lutomirski authored
commit 05fb3c19 upstream. Otherwise arch_task_struct_size == 0 and we die. While we're at it, set X86_FEATURE_ALWAYS, too. Reported-by:
David Saggiorato <david@saggiorato.net> Tested-by:
Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave@sr71.net> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: aaeb5c01c5b ("x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86") Link: http://lkml.kernel.org/r/8de723afbf0811071185039f9088733188b606c9.1475103911.git.luto@kernel.orgSigned-off-by:
-
Andy Lutomirski authored
commit e1bfc11c upstream. cr4_init_shadow() will panic on 486-like machines without CR4. Fix it using __read_cr4_safe(). Reported-by: david@saggiorato.net Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 1e02ce4c ("x86: Store a per-cpu shadow copy of CR4") Link: http://lkml.kernel.org/r/43a20f81fb504013bf613913dc25574b45336a61.1475091074.git.luto@kernel.orgSigned-off-by:
-
Sergei Miroshnichenko authored
commit 9abefcb1 upstream. A timer was used to restart after the bus-off state, leading to a relatively large can_restart() executed in an interrupt context, which in turn sets up pinctrl. When this happens during system boot, there is a high probability of grabbing the pinctrl_list_mutex, which is locked already by the probe() of other device, making the kernel suspect a deadlock condition [1]. To resolve this issue, the restart_timer is replaced by a delayed work. [1] https://github.com/victronenergy/venus/issues/24Signed-off-by:
Sergei Miroshnichenko <sergeimir@emcraft.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
zhong jiang authored
commit 5b398e41 upstream. I hit the following hung task when runing a OOM LTP test case with 4.1 kernel. Call trace: [<ffffffc000086a88>] __switch_to+0x74/0x8c [<ffffffc000a1bae0>] __schedule+0x23c/0x7bc [<ffffffc000a1c09c>] schedule+0x3c/0x94 [<ffffffc000a1eb84>] rwsem_down_write_failed+0x214/0x350 [<ffffffc000a1e32c>] down_write+0x64/0x80 [<ffffffc00021f794>] __ksm_exit+0x90/0x19c [<ffffffc0000be650>] mmput+0x118/0x11c [<ffffffc0000c3ec4>] do_exit+0x2dc/0xa74 [<ffffffc0000c46f8>] do_group_exit+0x4c/0xe4 [<ffffffc0000d0f34>] get_signal+0x444/0x5e0 [<ffffffc000089fcc>] do_signal+0x1d8/0x450 [<ffffffc00008a35c>] do_notify_resume+0x70/0x78 The oom victim cannot terminate because it needs to take mmap_sem for write while the lock is held by ksmd for read which loops in the page allocator ksm_do_scan scan_get_next_rmap_item down_read get_next_rmap_item alloc_rmap_item #ksmd will loop permanently. There is no way forward because the oom victim cannot release any memory in 4.1 based kernel. Since 4.6 we have the oom reaper which would solve this problem because it would release the memory asynchronously. Nevertheless we can relax alloc_rmap_item requirements and use __GFP_NORETRY because the allocation failure is acceptable as ksm_do_scan would just retry later after the lock got dropped. Such a patch would be also easy to backport to older stable kernels which do not have oom_reaper. While we are at it add GFP_NOWARN so the admin doesn't have to be alarmed by the allocation failure. Link: http://lkml.kernel.org/r/1474165570-44398-1-git-send-email-zhongjiang@huawei.comSigned-off-by:
zhong jiang <zhongjiang@huawei.com> Suggested-by:
Hugh Dickins <hughd@google.com> Suggested-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Karl Beldan authored
commit f6d7c1b5 upstream. This fixes subpage writes when using 4-bit HW ECC. There has been numerous reports about ECC errors with devices using this driver for a while. Also the 4-bit ECC has been reported as broken with subpages in [1] and with 16 bits NANDs in the driver and in mach* board files both in mainline and in the vendor BSPs. What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to try reinitializing the ECC engine: - R/W on whole pages properly generates/checks RS code - try writing the 1st subpage only of a blank page, the subpage is well written and the RS code properly generated, re-reading the same page the HW detects some ECC error, reading the same page again no ECC error is detected Note that the ECC engine is already reinitialized in the 1-bit case. Tested on my LCDK with UBI+UBIFS using subpages. This could potentially get rid of the issue workarounded in [1]. [1] 28c015a9 ("mtd: davinci-nand: disable subpage write for keystone-nand") Fixes: 6a4123e5 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage") Signed-off-by:
Karl Beldan <kbeldan@baylibre.com> Acked-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Dmitry Vyukov authored
commit e436fd61 upstream. be7635e7 ("arch, ftrace: for KASAN put hard/soft IRQ entries into separate sections") added .softirqentry.text section, but it was not added to recordmcount. So functions in the section are untracable. Add the section to scripts/recordmcount.c and scripts/recordmcount.pl. Fixes: be7635e7 ("arch, ftrace: for KASAN put hard/soft IRQ entries into separate sections") Link: http://lkml.kernel.org/r/1474902626-73468-1-git-send-email-dvyukov@google.comSigned-off-by:
Dmitry Vyukov <dvyukov@google.com> Acked-by:
Steve Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Tejun Heo authored
commit 9157056d upstream. On the v2 hierarchy, "cgroup.subtree_control" rejects controller enables if the cgroup has processes in it. The enforcement of this logic assumes that the cgroup wouldn't have any css_sets associated with it if there are no tasks in the cgroup, which is no longer true since a79a908f ("cgroup: introduce cgroup namespaces"). When a cgroup namespace is created, it pins the css_set of the creating task to use it as the root css_set of the namespace. This extra reference stays as long as the namespace is around and makes "cgroup.subtree_control" think that the namespace root cgroup is not empty even when it is and thus reject controller enables. Fix it by making cgroup_subtree_control() walk and test emptiness of each css_set instead of testing whether the list_head is empty. While at it, update the comment of cgroup_task_count() to indicate that the returned value may be higher than the number of tasks, which has always been true due to temporary references and doesn't break anything. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Evgeny Vereshchagin <evvers@ya.ru> Cc: Serge E. Hallyn <serge.hallyn@ubuntu.com> Cc: Aditya Kali <adityakali@google.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Fixes: a79a908f ("cgroup: introduce cgroup namespaces") Link: https://github.com/systemd/systemd/pull/3589#issuecomment-249089541Signed-off-by:
-
