- 07 Oct, 2016 40 commits
-
-
Daniel Borkmann authored
commit dbb50887 upstream. During an audit for sk_filter(), we found that rx_busy_skb handling in l2cap_sock_recv_cb() and l2cap_sock_recvmsg() looks not quite as intended. The assumption from commit e328140f ("Bluetooth: Use event-driven approach for handling ERTM receive buffer") is that errors returned from sock_queue_rcv_skb() are due to receive buffer shortage. However, nothing should prevent doing a setsockopt() with SO_ATTACH_FILTER on the socket, that could drop some of the incoming skbs when handled in sock_queue_rcv_skb(). In that case sock_queue_rcv_skb() will return with -EPERM, propagated from sk_filter() and if in L2CAP_MODE_ERTM mode, wrong assumption was that we failed due to receive buffer being full. From that point onwards, due to the to-be-dropped skb being held in rx_busy_skb, we cannot make any forward progress as rx_busy_skb is never cleared from l2cap_sock_recvmsg(), due to the filter drop verdict over and over coming from sk_filter(). Meanwhile, in l2cap_sock_recv_cb() all new incoming skbs are being dropped due to rx_busy_skb being occupied. Instead, just use __sock_queue_rcv_skb() where an error really tells that there's a receive buffer issue. Split the sk_filter() and enable it for non-segmented modes at queuing time since at this point in time the skb has already been through the ERTM state machine and it has been acked, so dropping is not allowed. Instead, for ERTM and streaming mode, call sk_filter() in l2cap_data_rcv() so the packet can be dropped before the state machine sees it. Fixes: e328140f ("Bluetooth: Use event-driven approach for handling ERTM receive buffer") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nicolas Iooss authored
commit ae6c33ba upstream. Commit bbeddf52 ("printk: move braille console support into separate braille.[ch] files") moved the parsing of braille-related options into _braille_console_setup(), changing the type of variable str from char* to char**. In this commit, memcmp(str, "brl,", 4) was correctly updated to memcmp(*str, "brl,", 4) but not memcmp(str, "brl=", 4). Update the code to make "brl=" option work again and replace memcmp() with strncmp() to make the compiler able to detect such an issue. Fixes: bbeddf52 ("printk: move braille console support into separate braille.[ch] files") Link: http://lkml.kernel.org/r/20160823165700.28952-1-nicolas.iooss_linux@m4x.orgSigned-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Cc: Joe Perches <joe@perches.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Marcin Nowakowski authored
commit ca86c9ef upstream. arch_uprobe_pre_xol needs to emulate a branch if a branch instruction has been replaced with a breakpoint, but in fact an uninitialised local variable was passed to the emulator routine instead of the original instruction Signed-off-by:
Marcin Nowakowski <marcin.nowakowski@imgtec.com> Fixes: 40e084a5 ('MIPS: Add uprobes support.') Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14300/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Paul Burton authored
commit 305723ab upstream. Malta boards used with CPU emulators feature a switch to disable use of an IOCU. Software has to check this switch & ignore any present IOCU if the switch is closed. The read used to do this was unsafe for 64 bit kernels, as it simply casted the address 0xbf403000 to a pointer & dereferenced it. Whilst in a 32 bit kernel this would access kseg1, in a 64 bit kernel this attempts to access xuseg & results in an address error exception. Fix by accessing a correctly formed ckseg1 address generated using the CKSEG1ADDR macro. Whilst modifying this code, define the name of the register and the bit we care about within it, which indicates whether PCI DMA is routed to the IOCU or straight to DRAM. The code previously checked that bit 0 was also set, but the least significant 7 bits of the CONFIG_GEN0 register contain the value of the MReqInfo signal provided to the IOCU OCP bus, so singling out bit 0 makes little sense & that part of the check is dropped. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Fixes: b6d92b4a ("MIPS: Add option to disable software I/O coherency.") Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14187/Signed-off-by:
-
Marcin Nowakowski authored
commit db06068a upstream. arch_uretprobe_hijack_return_addr should replace the return address for a call with a trampoline address. Signed-off-by:
-
Marcin Nowakowski authored
commit ddabfa5c upstream. Generic kernel code implements a weak version of set_orig_insn that moves cached 'insn' from arch_uprobe to the original code location when the trap is removed. MIPS variant used arch_uprobe->orig_inst which was never initialised properly, so this code only inserted a nop instead of the original instruction. With that change orig_inst can also be safely removed. Signed-off-by:
-
Will Deacon authored
commit 3a402a70 upstream. When TIF_SINGLESTEP is set for a task, the single-step state machine is enabled and we must take care not to reset it to the active-not-pending state if it is already in the active-pending state. Unfortunately, that's exactly what user_enable_single_step does, by unconditionally setting the SS bit in the SPSR for the current task. This causes failures in the GDB testsuite, where GDB ends up missing expected step traps if the instruction being stepped generates another trap, e.g. PTRACE_EVENT_FORK from an SVC instruction. This patch fixes the problem by preserving the current state of the stepping state machine when TIF_SINGLESTEP is set on the current thread. Cc: <stable@vger.kernel.org> Reported-by:
Yao Qi <yao.qi@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Srinivas Ramana authored
commit 117e5e9c upstream. If the bootloader uses the long descriptor format and jumps to kernel decompressor code, TTBCR may not be in a right state. Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use TTBR0 for translation table walks. The commit dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N. Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to indicate the use of TTBR0 and the correct base address width. Fixes: dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") Acked-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Srinivas Ramana <sramana@codeaurora.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
James Morse authored
commit 727653d6 upstream. gic_raise_softirq() walks the list of cpus using for_each_cpu(), it calls gic_compute_target_list() which advances the iterator by the number of CPUs in the cluster. If gic_compute_target_list() reaches the last CPU it leaves the iterator pointing at the last CPU. This means the next time round the for_each_cpu() loop cpumask_next() will be called with an invalid CPU. This triggers a warning when built with CONFIG_DEBUG_PER_CPU_MAPS: [ 3.077738] GICv3: CPU1: found redistributor 1 region 0:0x000000002f120000 [ 3.077943] CPU1: Booted secondary processor [410fd0f0] [ 3.078542] ------------[ cut here ]------------ [ 3.078746] WARNING: CPU: 1 PID: 0 at ../include/linux/cpumask.h:121 gic_raise_softirq+0x12c/0x170 [ 3.078812] Modules linked in: [ 3.078869] [ 3.078930] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-rc5+ #5188 [ 3.078994] Hardware name: Foundation-v8A (DT) [ 3.079059] task: ffff80087a1a0080 task.stack: ffff80087a19c000 [ 3.079145] PC is at gic_raise_softirq+0x12c/0x170 [ 3.079226] LR is at gic_raise_softirq+0xa4/0x170 [ 3.079296] pc : [<ffff0000083ead24>] lr : [<ffff0000083eac9c>] pstate: 200001c9 [ 3.081139] Call trace: [ 3.081202] Exception stack(0xffff80087a19fbe0 to 0xffff80087a19fd10) [ 3.082269] [<ffff0000083ead24>] gic_raise_softirq+0x12c/0x170 [ 3.082354] [<ffff00000808e614>] smp_send_reschedule+0x34/0x40 [ 3.082433] [<ffff0000080e80a0>] resched_curr+0x50/0x88 [ 3.082512] [<ffff0000080e89d0>] check_preempt_curr+0x60/0xd0 [ 3.082593] [<ffff0000080e8a60>] ttwu_do_wakeup+0x20/0xe8 [ 3.082672] [<ffff0000080e8bb8>] ttwu_do_activate+0x90/0xc0 [ 3.082753] [<ffff0000080ea9a4>] try_to_wake_up+0x224/0x370 [ 3.082836] [<ffff0000080eabc8>] default_wake_function+0x10/0x18 [ 3.082920] [<ffff000008103134>] __wake_up_common+0x5c/0xa0 [ 3.083003] [<ffff0000081031f4>] __wake_up_locked+0x14/0x20 [ 3.083086] [<ffff000008103f80>] complete+0x40/0x60 [ 3.083168] [<ffff00000808df7c>] secondary_start_kernel+0x15c/0x1d0 [ 3.083240] [<00000000808911a4>] 0x808911a4 [ 3.113401] Detected PIPT I-cache on CPU2 Avoid updating the iterator if the next call to cpumask_next() would cause the for_each_cpu() loop to exit. There is no change to gic_raise_softirq()'s behaviour, (cpumask_next()s eventual call to _find_next_bit() will return early as start >= nbits), this patch just silences the warning. Fixes: 021f6537 ("irqchip: gic-v3: Initial support for GICv3") Signed-off-by:
James Morse <james.morse@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1474306155-3303-1-git-send-email-james.morse@arm.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Linus Lüssing authored
commit 1e5d343b upstream. The skb_reserve() call only reserved headroom for the mac header, but not the elp packet header itself. Fixing this by using skb_put()'ing towards the skb tail instead of skb_push()'ing towards the skb head. Fixes: d6f94d91 ("batman-adv: ELP - adding basic infrastructure") Signed-off-by:
Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by:
Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Sven Eckelmann authored
commit 93652344 upstream. batadv_find_router dereferences last_bonding_candidate from orig_node without making sure that it has a valid reference. This reference has to be retrieved by increasing the reference counter while holding neigh_list_lock. The lock is required to avoid that batadv_last_bonding_replace removes the current last_bonding_candidate, reduces the reference counter and maybe destroys the object in this process. Fixes: f3b3d901 ("batman-adv: add bonding again") Signed-off-by:
-
Shiraz Saleem authored
commit b71121b4 upstream. Device notifications are not received after the first interface is closed; since there is an unregister for notifications on every interface close. Correct this by unregistering for device notifications only when the last interface is closed. Also, make all operations on the i40iw_notifiers_registered atomic as it can be read/modified concurrently. Fixes: 8e06af71 ("i40iw: add main, hdr, status") 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:
-
Mustafa Ismail authored
commit 866e0f4d upstream. Update iwqp->hw_iwarp_state to reflect the new state of the CQP modify QP operation. This avoids reissuing a CQP operation to modify a QP to a state that it is already in. Fixes: 4e9042e6 ("i40iw: add hw and utils files") Reported-by:
Stefan Assmann <sassmann@redhat.com> Signed-off-by:
-
Tatyana Nikolova authored
commit 07c72d7d upstream. Send a zero length last streaming mode message for loopback connections to synchronize between accepting QP and connecting QP. This avoids data transfer to start on the accepting QP before the connecting QP is in RTS. Also remove function i40iw_loopback_nop() as it is no longer used. Fixes: f27b4746 ("i40iw: add connection management code") Signed-off-by:
Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by:
-
Shiraz Saleem authored
commit 5dfd5e5e upstream. Add NULL check for pdata and pdata->addr before the memcpy in i40iw_form_cm_frame(). This fixes a NULL pointer de-reference which occurs when the MPA private data pointer is NULL. Also only copy pdata->size bytes in the memcpy to prevent reading past the length of the private data buffer provided by upper layer. Fixes: f27b4746 ("i40iw: add connection management code") Reported-by:
-
Mustafa Ismail authored
commit 433c5813 upstream. iwpbl->iwmr points to the structure that contains iwpbl, which is iwmr. Setting this to NULL would result in writing to freed memory. So just free iwmr, and return. Fixes: d3749841 ("i40iw: add files for iwarp interface") Reported-by:
-
Mustafa Ismail authored
commit 7eaf8313 upstream. In i40iw_free_virt_mem(), do not set mem->va to NULL after freeing it as mem->va is a self-referencing pointer to mem. Fixes: 4e9042e6 ("i40iw: add hw and utils files") Reported-by:
-
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:
-
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:
-
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:
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:
-
