- 24 Mar, 2016 4 commits
-
-
Peter Zijlstra authored
[ Upstream commit 28a967c3 ] Because event_sched_out() checks event->pending_disable _before_ actually disabling the event, it can happen that the event fires after it checks but before it gets disabled. This would leave event->pending_disable set and the queued irq_work will try and process it. However, if the event trigger was during schedule(), the event might have been de-scheduled by the time the irq_work runs, and perf_event_disable_local() will fail. Fix this by checking event->pending_disable _after_ we call event->pmu->del(). This depends on the latter being a compiler barrier, such that the compiler does not lift the load and re-creates the problem. Tested-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
He Kuang <hekuang@huawei.com> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Peter Zijlstra authored
[ Upstream commit 13005627 ] In case of: err_file: fput(event_file), we'll end up calling perf_release() which in turn will free the event. Do not then free the event _again_. Tested-by:
-
Yang Shi authored
[ Upstream commit cf0a2543 ] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 in_atomic(): 1, irqs_disabled(): 128, pid: 383, name: sh Preemption disabled at:[<ffff800000124c18>] kgdb_cpu_enter+0x158/0x6b8 CPU: 3 PID: 383 Comm: sh Tainted: G W 4.1.13-rt13 #2 Hardware name: Freescale Layerscape 2085a RDB Board (DT) Call trace: [<ffff8000000885e8>] dump_backtrace+0x0/0x128 [<ffff800000088734>] show_stack+0x24/0x30 [<ffff80000079a7c4>] dump_stack+0x80/0xa0 [<ffff8000000bd324>] ___might_sleep+0x18c/0x1a0 [<ffff8000007a20ac>] __rt_spin_lock+0x2c/0x40 [<ffff8000007a2268>] rt_read_lock+0x40/0x58 [<ffff800000085328>] single_step_handler+0x38/0xd8 [<ffff800000082368>] do_debug_exception+0x58/0xb8 Exception stack(0xffff80834a1e7c80 to 0xffff80834a1e7da0) 7c80: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7e40 ffff8083 001bfcc4 ffff8000 7ca0: f2000400 00000000 00000000 00000000 4a1e7d80 ffff8083 0049501c ffff8000 7cc0: 00005402 00000000 00aaa210 ffff8000 4a1e7ea0 ffff8083 000833f4 ffff8000 7ce0: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7ea0 ffff8083 001bfcc0 ffff8000 7d00: 4a0fc400 ffff8083 00005402 00000000 4a1e7d40 ffff8083 00490324 ffff8000 7d20: ffffff9c 00000000 92c23ba0 0000ffff 000a0000 00000000 00000000 00000000 7d40: 00000008 00000000 00080000 00000000 92c23b8b 0000ffff 92c23b8e 0000ffff 7d60: 00000038 00000000 00001cb2 00000000 00000005 00000000 92d7b498 0000ffff 7d80: 01010101 01010101 92be9000 0000ffff 00000000 00000000 00000030 00000000 [<ffff8000000833f4>] el1_dbg+0x18/0x6c This issue is similar with 62c6c61a("arm64: replace read_lock to rcu lock in call_break_hook"), but comes to single_step_handler. This also solves kgdbts boot test silent hang issue on 4.4 -rt kernel. Signed-off-by:
Yang Shi <yang.shi@linaro.org> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Yang Shi authored
[ Upstream commit 62c6c61a ] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 in_atomic(): 0, irqs_disabled(): 128, pid: 342, name: perf 1 lock held by perf/342: #0: (break_hook_lock){+.+...}, at: [<ffffffc0000851ac>] call_break_hook+0x34/0xd0 irq event stamp: 62224 hardirqs last enabled at (62223): [<ffffffc00010b7bc>] __call_rcu.constprop.59+0x104/0x270 hardirqs last disabled at (62224): [<ffffffc0000fbe20>] vprintk_emit+0x68/0x640 softirqs last enabled at (0): [<ffffffc000097928>] copy_process.part.8+0x428/0x17f8 softirqs last disabled at (0): [< (null)>] (null) CPU: 0 PID: 342 Comm: perf Not tainted 4.1.6-rt5 #4 Hardware name: linux,dummy-virt (DT) Call trace: [<ffffffc000089968>] dump_backtrace+0x0/0x128 [<ffffffc000089ab0>] show_stack+0x20/0x30 [<ffffffc0007030d0>] dump_stack+0x7c/0xa0 [<ffffffc0000c878c>] ___might_sleep+0x174/0x260 [<ffffffc000708ac8>] __rt_spin_lock+0x28/0x40 [<ffffffc000708db0>] rt_read_lock+0x60/0x80 [<ffffffc0000851a8>] call_break_hook+0x30/0xd0 [<ffffffc000085a70>] brk_handler+0x30/0x98 [<ffffffc000082248>] do_debug_exception+0x50/0xb8 Exception stack(0xffffffc00514fe30 to 0xffffffc00514ff50) fe20: 00000000 00000000 c1594680 0000007f fe40: ffffffff ffffffff 92063940 0000007f 0550dcd8 ffffffc0 00000000 00000000 fe60: 0514fe70 ffffffc0 000be1f8 ffffffc0 0514feb0 ffffffc0 0008948c ffffffc0 fe80: 00000004 00000000 0514fed0 ffffffc0 ffffffff ffffffff 9282a948 0000007f fea0: 00000000 00000000 9282b708 0000007f c1592820 0000007f 00083914 ffffffc0 fec0: 00000000 00000000 00000010 00000000 00000064 00000000 00000001 00000000 fee0: 005101e0 00000000 c1594680 0000007f c1594740 0000007f ffffffd8 ffffff80 ff00: 00000000 00000000 00000000 00000000 c1594770 0000007f c1594770 0000007f ff20: 00665e10 00000000 7f7f7f7f 7f7f7f7f 01010101 01010101 00000000 00000000 ff40: 928e4cc0 0000007f 91ff11e8 0000007f call_break_hook is called in atomic context (hard irq disabled), so replace the sleepable lock to rcu lock, replace relevant list operations to rcu version and call synchronize_rcu() in unregister_break_hook(). And, replace write lock to spinlock in {un}register_break_hook. Signed-off-by:
-
- 23 Mar, 2016 4 commits
-
-
Jan Kara authored
When doing delayed allocation, update of on-disk inode size is postponed until IO submission time. However hole punch or zero range fallocate calls can end up discarding the tail page cache page and thus on-disk inode size would never be properly updated. Make sure the on-disk inode size is updated before truncating page cache. Signed-off-by:
Jan Kara <jack@suse.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reviewed-by:
Mingming Cao <mingming.cao@oracle.com> Signed-off-by:
-
Jan Kara authored
Current code implementing FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_INSERT_RANGE is prone to races with buffered writes and page faults. If buffered write or write via mmap manages to squeeze between filemap_write_and_wait_range() and truncate_pagecache() in the fallocate implementations, the written data is simply discarded by truncate_pagecache() although it should have been shifted. Fix the problem by moving filemap_write_and_wait_range() call inside i_mutex and i_mmap_sem. That way we are protected against races with both buffered writes and page faults. Signed-off-by:
-
Jan Kara authored
Currently ext4_alloc_file_blocks() was handling protection against unlocked DIO. However we now need to sometimes call it under i_mmap_sem and sometimes not and DIO protection ranks above it (although strictly speaking this cannot currently create any deadlocks). Also ext4_zero_range() was actually getting & releasing unlocked DIO protection twice in some cases. Luckily it didn't introduce any real bug but it was a land mine waiting to be stepped on. So move DIO protection out from ext4_alloc_file_blocks() into the two callsites. Signed-off-by:
-
Jan Kara authored
Currently, page faults and hole punching are completely unsynchronized. This can result in page fault faulting in a page into a range that we are punching after truncate_pagecache_range() has been called and thus we can end up with a page mapped to disk blocks that will be shortly freed. Filesystem corruption will shortly follow. Note that the same race is avoided for truncate by checking page fault offset against i_size but there isn't similar mechanism available for punching holes. Fix the problem by creating new rw semaphore i_mmap_sem in inode and grab it for writing over truncate, hole punching, and other functions removing blocks from extent tree and for read over page faults. We cannot easily use i_data_sem for this since that ranks below transaction start and we need something ranking above it so that it can be held over the whole truncate / hole punching operation. Also remove various workarounds we had in the code to reduce race window when page fault could have created pages with stale mapping information. Signed-off-by:
-
- 22 Mar, 2016 26 commits
-
-
Hauke Mehrtens authored
[ Upstream commit 588bad2e ] commit 7a50e468 upstream. The MIPS_GIC_IPI should only be selected when MIPS_GIC is also selected, otherwise it results in a compile error. smp-gic.c uses some functions from include/linux/irqchip/mips-gic.h like plat_ipi_call_int_xlate() which are only added to the header file when MIPS_GIC is set. The Lantiq SoC does not use the GIC, but supports SMP. The calls top the functions from smp-gic.c are already protected by some #ifdefs The first part of this was introduced in commit 72e20142 ("MIPS: Move GIC IPI functions out of smp-cmp.c") Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12774/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Markos Chandras authored
[ Upstream commit 5676319c ] R6 does not support the MIPS MT ASE and the CMP/SMP options so restrict them in order to prevent users from selecting incompatible SMP configuration for R6 cores. We also disable the CPS/SMP option because its support hasn't been added to the CPS code yet. Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10637/Signed-off-by:
-
Markos Chandras authored
[ Upstream commit 1c885357 ] This reverts commit 6ca716f2. SMP/CPS is now supported on 64bit cores. Cc: <stable@vger.kernel.org> # 4.1 Reviewed-by:
Paul Burton <paul.burton@imgtec.com> Signed-off-by:
-
James Hogan authored
[ Upstream commit 4b7b1ef2 ] The ld-version.sh script fails on some versions of awk with the following error, resulting in build failures for MIPS: awk: scripts/ld-version.sh: line 4: regular expression compile failed (missing '(') This is due to the regular expression ".*)", meant to strip off the beginning of the ld version string up to the close bracket, however brackets have a meaning in regular expressions, so lets escape it so that awk doesn't expect a corresponding open bracket. Fixes: ccbef167 ("Kbuild, lto: add ld-version and ld-ifversion ...") Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
James Hogan <james.hogan@imgtec.com> Tested-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Cc: Michal Marek <mmarek@suse.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-mips@linux-mips.org Cc: linux-kbuild@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 4.4.x- Patchwork: https://patchwork.linux-mips.org/patch/12838/Signed-off-by:
-
Ludovic Desroches authored
[ Upstream commit 25c5e962 ] When computing the residue we need two pieces of information: the current descriptor and the remaining data of the current descriptor. To get that information, we need to read consecutively two registers but we can't do it in an atomic way. For that reason, we have to check manually that current descriptor has not changed. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Suggested-by:
Cyrille Pitchen <cyrille.pitchen@atmel.com> Reported-by:
David Engraf <david.engraf@sysgo.com> Tested-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Paolo Bonzini authored
[ Upstream commit 844a5fe2 ] Yes, all of these are needed. :) This is admittedly a bit odd, but kvm-unit-tests access.flat tests this if you run it with "-cpu host" and of course ept=0. KVM runs the guest with CR0.WP=1, so it must handle supervisor writes specially when pte.u=1/pte.w=0/CR0.WP=0. Such writes cause a fault when U=1 and W=0 in the SPTE, but they must succeed because CR0.WP=0. When KVM gets the fault, it sets U=0 and W=1 in the shadow PTE and restarts execution. This will still cause a user write to fault, while supervisor writes will succeed. User reads will fault spuriously now, and KVM will then flip U and W again in the SPTE (U=1, W=0). User reads will be enabled and supervisor writes disabled, going back to the originary situation where supervisor writes fault spuriously. When SMEP is in effect, however, U=0 will enable kernel execution of this page. To avoid this, KVM also sets NX=1 in the shadow PTE together with U=0. If the guest has not enabled NX, the result is a continuous stream of page faults due to the NX bit being reserved. The fix is to force EFER.NX=1 even if the CPU is taking care of the EFER switch. (All machines with SMEP have the CPU_LOAD_IA32_EFER vm-entry control, so they do not use user-return notifiers for EFER---if they did, EFER.NX would be forced to the same value as the host). There is another bug in the reserved bit check, which I've split to a separate patch for easier application to stable kernels. Cc: stable@vger.kernel.org Cc: Andy Lutomirski <luto@amacapital.net> Reviewed-by:
Xiao Guangrong <guangrong.xiao@linux.intel.com> Fixes: f6577a5fSigned-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Martin Schwidefsky authored
[ Upstream commit 3446c13b ] The fork of a process with four page table levels is broken since git commit 6252d702 "[S390] dynamic page tables." All new mm contexts are created with three page table levels and an asce limit of 4TB. If the parent has four levels dup_mmap will add vmas to the new context which are outside of the asce limit. The subsequent call to copy_page_range will walk the three level page table structure of the new process with non-zero pgd and pud indexes. This leads to memory clobbers as the pgd_index *and* the pud_index is added to the mm->pgd pointer without a pgd_deref in between. The init_new_context() function is selecting the number of page table levels for a new context. The function is used by mm_init() which in turn is called by dup_mm() and mm_alloc(). These two are used by fork() and exec(). The init_new_context() function can distinguish the two cases by looking at mm->context.asce_limit, for fork() the mm struct has been copied and the number of page table levels may not change. For exec() the mm_alloc() function set the new mm structure to zero, in this case a three-level page table is created as the temporary stack space is located at STACK_TOP_MAX = 4TB. This fixes CVE-2016-2143. Reported-by:
Marcin Kościelnicki <koriakin@0x04.net> Reviewed-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Cc: stable@vger.kernel.org Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
[ Upstream commit dc17147d ] Commit f3775549 ("tracepoints: Do not trace when cpu is offline") added a check to make sure that tracepoints only get called when the cpu is online, as it uses rcu_read_lock_sched() for protection. Commit 3a630178 ("tracing: generate RCU warnings even when tracepoints are disabled") added lockdep checks (including rcu checks) for events that are not enabled to catch possible RCU issues that would only be triggered if a trace event was enabled. Commit f3775549 only stopped the warnings when the trace event was enabled but did not prevent warnings if the trace event was called when disabled. To fix this, the cpu online check is moved to where the condition is added to the trace event. This will place the cpu online check in all places that it may be used now and in the future. Cc: stable@vger.kernel.org # v3.18+ Fixes: f3775549 ("tracepoints: Do not trace when cpu is offline") Fixes: 3a630178 ("tracing: generate RCU warnings even when tracepoints are disabled") Reported-by:
Sudeep Holla <sudeep.holla@arm.com> Tested-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Alex Deucher authored
[ Upstream commit d74e766e ] This reverts commit 39d42750. This caused a regression on some older hardware. bug: https://bugzilla.kernel.org/show_bug.cgi?id=113891Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Alex Deucher authored
[ Upstream commit c8213a63 ] When I fixed the dp rate selection in: 092c96a8 drm/radeon: fix dp link rate selection (v2) I accidently dropped the special handling for NUTMEG DP bridge chips. They require a fixed link rate. Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Ken Wang <Qingqing.Wang@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Tested-by:
Ken Moffat <zarniwhoop@ntlworld.com> Signed-off-by:
-
Alex Deucher authored
[ Upstream commit 092c96a8 ] Need to properly handle the max link rate in the dpcd. This prevents some cases where 5.4 Ghz is selected when it shouldn't be. v2: simplify logic, add array bounds check Reviewed-by:
Tom St Denis <tom.stdenis@amd.com> Signed-off-by:
-
Alex Deucher authored
[ Upstream commit 0c3a8840 ] Signed-off-by:
-
Radim Krčmář authored
[ Upstream commit 7099e2e1 ] Linux guests on Haswell (and also SandyBridge and Broadwell, at least) would crash if you decided to run a host command that uses PEBS, like perf record -e 'cpu/mem-stores/pp' -a This happens because KVM is using VMX MSR switching to disable PEBS, but SDM [2015-12] 18.4.4.4 Re-configuring PEBS Facilities explains why it isn't safe: When software needs to reconfigure PEBS facilities, it should allow a quiescent period between stopping the prior event counting and setting up a new PEBS event. The quiescent period is to allow any latent residual PEBS records to complete its capture at their previously specified buffer address (provided by IA32_DS_AREA). There might not be a quiescent period after the MSR switch, so a CPU ends up using host's MSR_IA32_DS_AREA to access an area in guest's memory. (Or MSR switching is just buggy on some models.) The guest can learn something about the host this way: If the guest doesn't map address pointed by MSR_IA32_DS_AREA, it results in #PF where we leak host's MSR_IA32_DS_AREA through CR2. After that, a malicious guest can map and configure memory where MSR_IA32_DS_AREA is pointing and can therefore get an output from host's tracing. This is not a critical leak as the host must initiate with PEBS tracing and I have not been able to get a record from more than one instruction before vmentry in vmx_vcpu_run() (that place has most registers already overwritten with guest's). We could disable PEBS just few instructions before vmentry, but disabling it earlier shouldn't affect host tracing too much. We also don't need to switch MSR_IA32_PEBS_ENABLE on VMENTRY, but that optimization isn't worth its code, IMO. (If you are implementing PEBS for guests, be sure to handle the case where both host and guest enable PEBS, because this patch doesn't.) Fixes: 26a4f3c0 ("perf/x86: disable PEBS on a guest entry.") Cc: <stable@vger.kernel.org> Reported-by:
Jiří Olša <jolsa@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Al Viro authored
[ Upstream commit f9381284 ] d_instantiate(new_dentry, old_inode) is absolutely wrong thing to do - it will oops if new_dentry used to be positive, for starters. What we need is d_invalidate() the target and be done with that. Cc: stable@vger.kernel.org # v3.18+ Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
[ Upstream commit 803c0012 ] Failing to allocate an inode for child means that cache for *parent* is incompletely populated. So it's parent directory inode ('dir') that needs NCPI_DIR_CACHE flag removed, *not* the child inode ('inode', which is what we'd failed to allocate in the first place). Fucked-up-in: commit 5e993e25 ("ncpfs: get rid of d_validate() nonsense") Fucked-up-by:
-
Paul Mackerras authored
[ Upstream commit ccec4456 ] Thomas Huth discovered that a guest could cause a hard hang of a host CPU by setting the Instruction Authority Mask Register (IAMR) to a suitable value. It turns out that this is because when the code was added to context-switch the new special-purpose registers (SPRs) that were added in POWER8, we forgot to add code to ensure that they were restored to a sane value on guest exit. This adds code to set those registers where a bad value could compromise the execution of the host kernel to a suitable neutral value on guest exit. Cc: stable@vger.kernel.org # v3.14+ Fixes: b005255eReported-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Mugunthan V N authored
[ Upstream commit 0f514e69 ] Errata id: i877 Description: ------------ The RGMII 1000 Mbps Transmit timing is based on the output clock (rgmiin_txc) being driven relative to the rising edge of an internal clock and the output control/data (rgmiin_txctl/txd) being driven relative to the falling edge of an internal clock source. If the internal clock source is allowed to be static low (i.e., disabled) for an extended period of time then when the clock is actually enabled the timing delta between the rising edge and falling edge can change over the lifetime of the device. This can result in the device switching characteristics degrading over time, and eventually failing to meet the Data Manual Delay Time/Skew specs. To maintain RGMII 1000 Mbps IO Timings, SW should minimize the duration that the Ethernet internal clock source is disabled. Note that the device reset state for the Ethernet clock is "disabled". Other RGMII modes (10 Mbps, 100Mbps) are not affected Workaround: ----------- If the SoC Ethernet interface(s) are used in RGMII mode at 1000 Mbps, SW should minimize the time the Ethernet internal clock source is disabled to a maximum of 200 hours in a device life cycle. This is done by enabling the clock as early as possible in IPL (QNX) or SPL/u-boot (Linux/Android) by setting the register CM_GMAC_CLKSTCTRL[1:0]CLKTRCTRL = 0x2:SW_WKUP. So, do not allow to gate the cpsw clocks using ti,no-idle property in cpsw node assuming 1000 Mbps is being used all the time. If someone does not need 1000 Mbps and wants to gate clocks to cpsw, this property needs to be deleted in their respective board files. Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Lokesh Vutla authored
[ Upstream commit 6327a31a ] commit 2e18f5a1 upstream. Introduce a dt property, ti,no-idle, that prevents an IP to idle at any point. This is to handle Errata i877, which tells that GMAC clocks cannot be disabled. Acked-by:
Roger Quadros <rogerq@ti.com> Tested-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
Dave Gerlach <d-gerlach@ti.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit c12ba8ce ] Some module needs more than one functional clock in order to be accessible, like the McASPs found in DRA7xx family. This flag will indicate that the opt_clks need to be handled at the same time as the main_clk for the given hwmod, ensuring that all needed clocks are enabled before we try to access the module's address space. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Nicholas Bellinger authored
[ Upstream commit 7f54ab5f ] This patch fixes a recent ABORT_TASK regression associated with commit febe562c, where a left-over target_put_sess_cmd() would still be called when __target_check_io_state() detected a command has already been completed, and explicit ABORT must be avoided. Note commit febe562c dropped the local kref_get_unless_zero() check in core_tmr_abort_task(), but did not drop this extra corresponding target_put_sess_cmd() in the failure path. So go ahead and drop this now bogus target_put_sess_cmd(), and avoid this potential use-after-free. Reported-by:
Dan Lane <dracodan@gmail.com> Cc: Quinn Tran <quinn.tran@qlogic.com> Cc: Himanshu Madhani <himanshu.madhani@qlogic.com> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Andy Grover <agrover@redhat.com> Cc: Mike Christie <mchristi@redhat.com> Cc: stable@vger.kernel.org # 3.14+ Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Konstantin Khlebnikov authored
[ Upstream commit b81de061 ] Overlayfs must update uid/gid after chown, otherwise functions like inode_owner_or_capable() will check user against stale uid. Catched by xfstests generic/087, it chowns file and calls utimes. Signed-off-by:
Konstantin Khlebnikov <koct9i@gmail.com> Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Konstantin Khlebnikov authored
[ Upstream commit 45d11738 ] After rename file dentry still holds reference to lower dentry from previous location. This doesn't matter for data access because data comes from upper dentry. But this stale lower dentry taints dentry at new location and turns it into non-pure upper. Such file leaves visible whiteout entry after remove in directory which shouldn't have whiteouts at all. Overlayfs already tracks pureness of file location in oe->opaque. This patch just uses that for detecting actual path type. Comment from Vivek Goyal's patch: Here are the details of the problem. Do following. $ mkdir upper lower work merged upper/dir/ $ touch lower/test $ sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir= work merged $ mv merged/test merged/dir/ $ rm merged/dir/test $ ls -l merged/dir/ /usr/bin/ls: cannot access merged/dir/test: No such file or directory total 0 c????????? ? ? ? ? ? test Basic problem seems to be that once a file has been unlinked, a whiteout has been left behind which was not needed and hence it becomes visible. Whiteout is visible because parent dir is of not type MERGE, hence od->is_real is set during ovl_dir_open(). And that means ovl_iterate() passes on iterate handling directly to underlying fs. Underlying fs does not know/filter whiteouts so it becomes visible to user. Why did we leave a whiteout to begin with when we should not have. ovl_do_remove() checks for OVL_TYPE_PURE_UPPER() and does not leave whiteout if file is pure upper. In this case file is not found to be pure upper hence whiteout is left. So why file was not PURE_UPPER in this case? I think because dentry is still carrying some leftover state which was valid before rename. For example, od->numlower was set to 1 as it was a lower file. After rename, this state is not valid anymore as there is no such file in lower. Signed-off-by:
Viktor Stanchev <me@viktorstanchev.com> Suggested-by:
Vivek Goyal <vgoyal@redhat.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=109611Acked-by:
-
Rui Wang authored
[ Upstream commit ce9113bb ] ovl_remove_upper() should do d_drop() only after it successfully removes the dir, otherwise a subsequent getcwd() system call will fail, breaking userspace programs. This is to fix: https://bugzilla.kernel.org/show_bug.cgi?id=110491Signed-off-by:
Rui Wang <rui.y.wang@intel.com> Reviewed-by:
-
Jouni Malinen authored
[ Upstream commit 1ec7bae8 ] Public Action frames use special rules for how the BSSID field (Address 3) is set. A wildcard BSSID is used in cases where the transmitter and recipient are not members of the same BSS. As such, we need to accept Public Action frames with wildcard BSSID. Commit db8e1732 ("mac80211: ignore frames between TDLS peers when operating as AP") added a rule that drops Action frames to TDLS-peers based on an Action frame having different DA (Address 1) and BSSID (Address 3) values. This is not correct since it misses the possibility of BSSID being a wildcard BSSID in which case the Address 1 would not necessarily match. Fix this by allowing mac80211 to accept wildcard BSSID in an Action frame when in AP mode. Fixes: db8e1732 ("mac80211: ignore frames between TDLS peers when operating as AP") Cc: stable@vger.kernel.org Signed-off-by:
Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
[ Upstream commit 9acc54be ] Just like for CCMP we need to check that for GCMP the fragments have PNs that increment by one; the spec was updated to fix this security issue and now has the following text: The receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not incrementing in steps of 1. Adapt the code for CCMP to work for GCMP as well, luckily the relevant fields already alias each other so no code duplication is needed (just check the aliasing with BUILD_BUG_ON.) Cc: stable@vger.kernel.org Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 15c66570 ] The firmware ctls like "DSP1 Firmware" in wm_adsp codec driver are enum, while the current driver accesses wrongly via value.integer.value[]. They have to be via value.enumerated.item[] instead. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
- 18 Mar, 2016 6 commits
-
-
Takashi Iwai authored
[ Upstream commit 8019c0b3 ] The DRC Mode like "AIF1DRC1 Mode" and EQ Mode like "AIF1.1 EQ Mode" in wm8994 codec driver are enum ctls, while the current driver accesses wrongly via value.integer.value[]. They have to be via value.enumerated.item[] instead. Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit d0784829 ] "MBC Mode", "VSS Mode", "VSS HPF Mode" and "Enhanced EQ Mode" ctls in wm8958 codec driver are enum, while the current driver accesses wrongly via value.integer.value[]. They have to be via value.enumerated.item[] instead. Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 741338f9 ] snd_soc_dapm_dai_link_get() and _put() access the associated ctl values as value.integer.value[]. However, this is an enum ctl, and it has to be accessed via value.enumerated.item[]. The former is long while the latter is unsigned int, so they don't align. Fixes: c6615082 ('ASoC: dapm: add code to configure dai link parameters') Cc: <stable@vger.kernel.org> Signed-off-by:
-
Maximilain Schneider authored
[ Upstream commit e9a2d81b ] gs_destroy_candev() erroneously calls kfree() on a struct gs_can *, which is allocated through alloc_candev() and should instead be freed using free_candev() alone. The inappropriate use of kfree() causes the kernel to hang when gs_destroy_candev() is called. Only the struct gs_usb * which is allocated through kzalloc() should be freed using kfree() when the device is disconnected. Signed-off-by:
Maximilian Schneider <max@schneidersoft.net> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Felix Fietkau authored
[ Upstream commit 7a36b930 ] The value 5000 was put here with the addition of the timeout field to ieee80211_start_tx_ba_session. It was originally added in mac80211 to save resources for drivers like iwlwifi, which only supports a limited number of concurrent aggregation sessions. Since iwlwifi does not use minstrel_ht and other drivers don't need this, 0 is a better default - especially since there have been recent reports of aggregation setup related issues reproduced with ath9k. This should improve stability without causing any adverse effects. Cc: stable@vger.kernel.org Acked-by:
Avery Pennarun <apenwarr@gmail.com> Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Charles Keepax authored
[ Upstream commit 316fa9e0 ] Lockdep warns of a potential lock inversion, i2s->lock is held numerous times whilst we are under the substream lock (snd_pcm_stream_lock). If we use the IRQ unsafe spin lock calls, you can also end up locking snd_pcm_stream_lock whilst under i2s->lock (if an IRQ happens whilst we are holding i2s->lock). This could result in deadlock. [ 18.147001] CPU0 CPU1 [ 18.151509] ---- ---- [ 18.156022] lock(&(&pri_dai->spinlock)->rlock); [ 18.160701] local_irq_disable(); [ 18.166622] lock(&(&substream->self_group.lock)->rlock); [ 18.174595] lock(&(&pri_dai->spinlock)->rlock); [ 18.181806] <Interrupt> [ 18.184408] lock(&(&substream->self_group.lock)->rlock); [ 18.190045] [ 18.190045] *** DEADLOCK *** This patch changes to using the irq safe spinlock calls, to avoid this issue. Fixes: ce8bcdbb ("ASoC: samsung: i2s: Protect more registers with a spinlock") Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Tested-by:
Anand Moon <linux.amoon@gmail.com> Signed-off-by:
-
