- 14 May, 2020 40 commits
-
-
Daniel Borkmann authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b4e76f7e upstream. Dan Carpenter reported [1] a static checker warning that ctx->offsets[] may be accessed off by one from build_body(), since it's allocated with fp->len * sizeof(*ctx.offsets) as length. The cBPF arm and ppc code doesn't have this issue as claimed, so only mips seems to be affected and should like most other JITs allocate with fp->len + 1. A few number of JITs (x86, sparc, arm64) handle this differently, where they only require fp->len array elements. [1] http://www.spinics.net/lists/mips/msg64193.html Fixes: c6610de3 ("MIPS: net: Add BPF JIT") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: Alexei Starovoitov <ast@kernel.org> Cc: ast@kernel.org Cc: linux-mips@linux-mips.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13814/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 008d0cf1 upstream. It should be >= ARRAY_SIZE() instead of > ARRAY_SIZE(). Fixes: 64b139f9 ('MIPS: OCTEON: irq: add CIB and other fixes') Signed-off-by:
David Daney <david.daney@cavium.com> Cc: Rob Herring <robh@kernel.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-mips@linux-mips.org Cc: kernel-janitors@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13813/Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0758b116 upstream. The protected_writeback_scache_line() function is used by local_r4k_flush_cache_sigtramp() to flush an FPU delay slot emulation trampoline on the userland stack from the caches so it is visible to subsequent instruction fetches. Commit de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing functions") updated some protected_ cache flush functions to use EVA CACHEE instructions via protected_cachee_op(), and commit 83fd4344 ("MIPS: r4kcache: Add EVA case for protected_writeback_dcache_line") did the same thing for protected_writeback_dcache_line(), but protected_writeback_scache_line() never got updated. Lets fix that now to flush the right user address from the secondary cache rather than some arbitrary kernel unmapped address. This issue was spotted through code inspection, and it seems unlikely to be possible to hit this in practice. It theoretically affect EVA kernels on EVA capable cores with an L2 cache, where the icache fetches straight from RAM (cpu_icache_snoops_remote_store == 0), running a hard float userland with FPU disabled (nofpu). That both Malta and Boston platforms override cpu_icache_snoops_remote_store to 1 suggests that all MIPS cores fetch instructions into icache straight from L2 rather than RAM. Fixes: de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing functions") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13800/Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 826e99be upstream. When a CPU is disabled via CPU hotplug, cpu_foreign_map is not updated. This could result in cache management SMP calls being sent to offline CPUs instead of online siblings in the same core. Add a call to calculate_cpu_foreign_map() in the various MIPS cpu disable callbacks after set_cpu_online(). All cases are updated for consistency and to keep cpu_foreign_map strictly up to date, not just those which may support hardware multithreading. Fixes: cccf34e9 ("MIPS: c-r4k: Fix cache flushing for MT cores") Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 66ffc50c upstream. The MIPS KVM dynamic translation is meant to translate "MFC0 rt, ErrCtl" instructions into "ADD rt, zero, zero" to zero the destination register, however the rt register number was copied into rt of the ADD instruction encoding, which is the 2nd source operand. This results in "ADD zero, zero, rt" which is a no-op, so only the first execution of each such MFC0 from ErrCtl will actually read 0. Fix the shift to put the rt from the MFC0 encoding into the rd field of the ADD. Fixes: 50c83085 ("KVM/MIPS32: Binary patching of select privileged instructions.") Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit fd716fca upstream. Fix perf hardware performance counter event numbers for I6400. This core does not follow the performance event numbering scheme of previous MIPS cores. All performance counters (both odd and even) are capable of counting any of the available events. Fixes: 4e88a862 ("MIPS: Add cases for CPU_I6400") Signed-off-by:
-
Paul Burton authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ac149698 upstream. The conditions for branching when emulating the BC1EQZ & BC1NEZ instructions were backwards, leading to each of those instructions being treated as the other. Fix this by reversing the conditions, and clear up the code a little for readability & checkpatch. Fixes: c8a34581 ("MIPS: Emulate the BC1{EQ,NE}Z FPU instructions") Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Reviewed-by:
-
Paul Burton authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 93583e17 upstream. The conditions for branching when emulating the BC1EQZ & BC1NEZ instructions were backwards, leading to each of those instructions being treated as the other. Fix this by reversing the conditions, and clear up the code a little for readability & checkpatch. Fixes: c909ca71 ("MIPS: math-emu: Emulate missing BC1{EQ,NE}Z instructions") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 80fa40ac upstream. The CPU actually runs at 1405Mhz which gives us a 175625000 Hz MIPS timer frequency (CPU frequency / 8). Fixes: e4c7d009 ("MIPS: BMIPS: Add BCM7435 dtsi") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Cc: linux-mips@linux-mips.org Cc: john@phrozen.org Cc: cernekee@gmail.com Cc: jaedon.shin@gmail.com Patchwork: https://patchwork.linux-mips.org/patch/13132/Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 14bc2414 upstream. The hardware page table walker (HTW) configuration is broken on XPA kernels where XPA couldn't be enabled (either nohtw or the hardware doesn't support it). This is because the PWSize.PTEW field (PTE width) was only set to 8 bytes (an extra shift of 1) in config_htw_params() if PageGrain.ELPA (enable large physical addressing) is set. On an XPA kernel though the size of PTEs is fixed at 8 bytes regardless of whether XPA could actually be enabled. Fix the initialisation of this field based on sizeof(pte_t) instead. Fixes: c5b36783 ("MIPS: Add support for XPA.") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 37808d62 upstream. Just to ease debugging of multiplatform kernel, make sure we print "Broadcom BMIPS5200" for the BMIPS5200 implementation instead of Broadcom BMIPS5000. Fixes: 68e6a783 ("MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit f675843d upstream. local_r4k___flush_cache_all() is missing a special check for BMIPS5000 processors, we need to blast the S-cache, just like other MTI processors since we have an inclusive cache. We also need an additional __sync() to make sure this is completed. Fixes: d74b0172 ("MIPS: BMIPS: Add special cache handling in c-r4k.c") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 73c4ca04 upstream. BMIPS5000 and BMIPS5200 processor have no D cache aliases, and this is properly handled by the per-CPU override added at the end of r4k_cache_init(), the problem is that the output of probe_pcache() disagrees with that, since this is too late: Primary instruction cache 32kB, VIPT, 4-way, linesize 64 bytes. Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes With the change moved earlier, we now have a consistent output with the settings we are intending to have: Primary instruction cache 32kB, VIPT, 4-way, linesize 64 bytes. Primary data cache 32kB, 4-way, VIPT, no aliases, linesize 32 bytes Fixes: d74b0172 ("MIPS: BMIPS: Add special cache handling in c-r4k.c") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c130d2fd upstream. BMIPS5000 and BMIPS52000 processors have their I-cache filling from the D-cache. Since BMIPS_GENERIC does not provide (yet) a cpu-feature-overrides.h file, this was not set anywhere, so make sure the R4K cache detection takes care of that. Fixes: d74b0172 ("MIPS: BMIPS: Add special cache handling in c-r4k.c") Signed-off-by:
-
Matt Redfearn authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit a400bed6 upstream. Commit d218af78 ("MIPS: scall: Always run the seccomp syscall filters") modified the syscall code to always call the seccomp filters, but missed the case where a filter may redirect the syscall, as revealed by the seccomp_bpf self test. The syscall path now restores the syscall from the stack after the filter rather than saving it locally. Syscall number checking and syscall function table lookup is done after the filter may have run such that redirected syscalls are also checked, and executed. The regular path of syscall number checking and pointer lookup is also made more consistent between ABIs with scall64-64.S being the reference. With this patch in place, the seccomp_bpf self test now passes TRACE_syscall.syscall_redirected and TRACE_syscall.syscall_dropped on all MIPS ABIs. Fixes: d218af78 ("MIPS: scall: Always run the seccomp syscall filters") Signed-off-by:
Matt Redfearn <matt.redfearn@imgtec.com> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Eric B Munson <emunson@akamai.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: IMG-MIPSLinuxKerneldevelopers@imgtec.com Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12916/Signed-off-by:
-
Paul Burton authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6609ccdc upstream. When CONFIG_MIPS_CPS_NS16550 is enabled, some register state is dumped to the UART when an exception is taken via the BEV on secondary cores. EJTAG exceptions are architecturally expected to be handled by the BEV even when Status.BEV is 0. This effectively means that if userland executes an sdbbp instruction on a secondary core then the kernel dumps register state to the UART even though the exception is perfectly normal & expected. Prevent this by simply not dumping information to the UART for EJTAG exceptions. Fixes: 609cf6f2 ("MIPS: CPS: Early debug using an ns16550-compatible UART") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit cbbda6e7 upstream. BMIPS5000 have a PrID value of 0x5A00 and BMIPS5200 have a PrID value of 0x5B00, which, masked with 0x5A00, returns 0x5A00. Update all conditionals on the PrID to cover both variants since we are going to need this to enable BMIPS5200 SMP. The existing check, masking with 0xFF00 would not cover BMIPS5200 at all. Fixes: 68e6a783 ("MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)") Fixes: 6465460c ("MIPS: BMIPS: change compile time checks to runtime checks") Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 555fae60 upstream. The cp0_tcstatus member of struct pt_regs was removed along with the rest of SMTC in v3.16, commit b633648c ("MIPS: MT: Remove SMTC support"), however recent uprobes support in v4.3 added back a reference to it in the regoffset_table[] in ptrace.c. Remove it. Signed-off-by:
-
Jaedon Shin authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 2549cc96 upstream. Change the CONFIG_MIPS_CMDLINE_EXTEND to CONFIG_MIPS_CMDLINE_DTB_EXTEND to resolve the EXTEND_WITH_PROM macro. Signed-off-by:
Jaedon Shin <jaedon.shin@gmail.com> Fixes: 2024972e ("MIPS: Make the kernel arguments from dtb available") Reviewed-by:
Alexander Sverdlin <alexander.svedlin@gmail.com> Cc: Jonas Gorski <jogo@openwrt.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Aaro Koskinen <aaro.koskinen@nokia.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11909/Signed-off-by:
-
Felipe Balbi authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 23fd537c upstream. Always unmap all SG entries as required by DMA API Fixes: a698908d ("usb: gadget: add generic map/unmap request utilities") Cc: <stable@vger.kernel.org> # v3.4+ Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Iago Abal authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 1d23d16a upstream. The above commit reordered spin_lock/unlock and now `&dev->lock' is acquired (rather than released) before calling `dev->driver->disconnect', `dev->driver->setup', `dev->driver->suspend', `usb_gadget_giveback_request', and `usb_gadget_udc_reset'. But this *may* not be the right way to fix the problem pointed by d3cb25a1. Note that the other usb/gadget/udc drivers do release the lock before calling these functions. There are also inconsistencies within pch_udc.c, where `dev->driver->disconnect' is called while holding `&dev->lock' in lines 613 and 1184, but not in line 2739. Finally, commit d3cb25a1 may have introduced several potential deadlocks. For instance, EBA (https://github.com/models-team/eba) reports: Double lock in drivers/usb/gadget/udc/pch_udc.c first at 2791: spin_lock(& dev->lock); [pch_udc_isr] second at 2694: spin_lock(& dev->lock); [pch_udc_svc_cfg_interrupt] after calling from 2793: pch_udc_dev_isr(dev, dev_intr); after calling from 2724: pch_udc_svc_cfg_interrupt(dev); Similarly, other potential deadlocks are 2791 -> 2793 -> 2721 -> 2657; and 2791 -> 2793 -> 2711 -> 2573 -> 1499 -> 1480. Fixes: d3cb25a1 ("usb: gadget: udc: fix spin_lock in pch_udc") Signed-off-by:
Iago Abal <mail@iagoabal.eu> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6b968737 upstream. It seems there are leftovers of some assignments which are not used anymore. Compiler even warns us about: drivers/usb/gadget/udc/pch_udc.c:2022:22: warning: variable ‘dev’ set \ but not used [-Wunused-but-set-variable] drivers/usb/gadget/udc/pch_udc.c:2639:9: warning: variable ‘ret’ set \ but not used [-Wunused-but-set-variable] Remove them and shut compiler about. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Krzysztof Opasiak authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0561f77e upstream. Correct attribute name is port_num not num. Fixes: ea6bd6b1 ("usb-gadget/f_acm: use per-attribute show and store methods") Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Ben Hutchings authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c3f46348 upstream. There's no net_device stashed in skb->cb, there's a net_device * there. To make it *really* clear, also change the write of the dev pointer into skb->cb from a memcpy() to an assignment. Fixes: 3fe56324 ("staging: rtl8192u: r8192U_core.c: Cleaning up ...") Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 85e9b88a upstream. ret should be changed to release allocated struct qxl_release Cc: stable@vger.kernel.org Fixes: 8002db63 ("qxl: convert qxl driver to proper use for reservations") Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Link: http://patchwork.freedesktop.org/patch/msgid/22cfd55f-07c8-95d0-a2f7-191b7153c3d4@virtuozzo.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 933db733 upstream. qxl_release should not be accesses after qxl_push_*_ring_release() calls: userspace driver can process submitted command quickly, move qxl_release into release_ring, generate interrupt and trigger garbage collector. It can lead to crashes in qxl driver or trigger memory corruption in some kmalloc-192 slab object Gerd Hoffmann proposes to swap the qxl_release_fence_buffer_objects() + qxl_push_{cursor,command}_ring_release() calls to close that race window. cc: stable@vger.kernel.org Fixes: f64122c1 ("drm: add new QXL driver. (v1.4)") Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ce0c58d9 upstream. This patch corrects some information in mwifiex_pcie_card_reg() structure for 8997 chipset Fixes: 6d85ef00 ("mwifiex: add support for 8997 chipset") Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Shengzhen Li <szli@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1878246Signed-off-by:
-
Paul Moore authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit fb739741 upstream. Fix the SELinux netlink_send hook to properly handle multiple netlink messages in a single sk_buff; each message is parsed and subject to SELinux access control. Prior to this patch, SELinux only inspected the first message in the sk_buff. Cc: stable@vger.kernel.org Reported-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Stephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Olivier Matz authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 59e3e4b5 upstream. As it was done in commit 8f659a03 ("net: ipv4: fix for a race condition in raw_sendmsg") and commit 20b50d79 ("net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()") for ipv4, copy the value of inet->hdrincl in a local variable, to avoid introducing a race condition in the next commit. Signed-off-by:
Olivier Matz <olivier.matz@6wind.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Lars-Peter Clausen authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 99548591 upstream. When registering a ASoC card the driver data of the parent device is set to point to the card. This driver data is used in the snd_soc_suspend()/resume() callbacks. The imx-spdif driver overwrites the driver data with custom data which causes snd_soc_suspend() to crash. Since the custom driver is not used anywhere simply deleting the line which sets the custom driver data fixes the issue. Fixes: 43ac9469 ("ASoC: imx-spdif: add snd_soc_pm_ops for spdif machine driver") Tested-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Stuart Henderson authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 6bb74514 upstream. With the introduction of WM8960_SYSCLK_AUTO mode, WM8960_SYSCLK_PLL mode was made unusable. Ensure we're not PLL mode before trying to use MCLK. Fixes: 3176bf2d ("ASoC: wm8960: update pll and clock setting function") Signed-off-by:
Stuart Henderson <stuart.henderson@cirrus.com> Reviewed-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
Rasmus Villemoes authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 76a56367 upstream. Ironically, 7d4020c3 ("[media] exynos4-is: fix some warnings when compiling on arm64") fixed some format string bugs but introduced a new one. buf_index is a simple int, so it should be printed with %d, not %pad (which is correctly used for dma_addr_t). Fixes: 7d4020c3 ("[media] exynos4-is: fix some warnings when compiling on arm64") Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Peter Zijlstra authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit e01d8718 upstream. When calling intel_alt_er() with .idx != EXTRA_REG_RSP_* we will not initialize alt_idx and then use this uninitialized value to index an array. When that is not fatal, it can result in an infinite loop in its caller __intel_shared_reg_get_constraints(), with IRQs disabled. Alternative error modes are random memory corruption due to the cpuc->shared_regs->regs[] array overrun, which manifest in either get_constraints or put_constraints doing weird stuff. Only took 6 hours of painful debugging to find this. Neither GCC nor Smatch warnings flagged this bug. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Fixes: ae3f011f ("perf/x86/intel: Fix SLM MSR_OFFCORE_RSP1 valid_mask") Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Madhavan Srinivasan authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 370f06c8 upstream. Commit 7a786832 ("powerpc/perf: Add an explict flag indicating presence of SLOT field") introduced the PPMU_HAS_SSLOT flag to remove the assumption that MMCRA[SLOT] was present when PPMU_ALT_SIPR was not set. That commit's changelog also mentions that Power8 does not support MMCRA[SLOT]. However when the Power8 PMU support was merged, it errnoeously included the PPMU_HAS_SSLOT flag. So remove PPMU_HAS_SSLOT from the Power8 flags. mpe: On systems where MMCRA[SLOT] exists, the field occupies bits 37:39 (IBM numbering). On Power8 bit 37 is reserved, and 38:39 overlap with the high bits of the Threshold Event Counter Mantissa. I am not aware of any published events which use the threshold counting mechanism, which would cause the mantissa bits to be set. So in practice this bug is unlikely to trigger. Fixes: e05b9b9e ("powerpc/perf: Power8 PMU support") Signed-off-by:
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Jiri Olsa authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 0805909f upstream. Set correct width for unresolved mem_dcacheline addr. Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Fixes: 9b32ba71 ("perf tools: Add dcacheline sort") Link: http://lkml.kernel.org/r/1453290995-18485-3-git-send-email-jolsa@kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 08c6e8cc upstream. This is effectively reapplies the commit b0898fda ("i2c: designware-pci: use IRQF_COND_SUSPEND flag") after the commit d80d1341 ("i2c: designware: Move common probe code into i2c_dw_probe()"). Original message as follows. The mentioned flag fixes a warning on Intel Edison board since one of the I2C controller shares IRQ line with watchdog timer. Fixes: d80d1341 (i2c: designware: Move common probe code into i2c_dw_probe()) Signed-off-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit b9f96020 upstream. Under some circumstances, i.e. when test is still running and about to time out and user runs, for example, grep -H . /sys/module/dmatest/parameters/* the iterations parameter is not respected and test is going on and on until user gives echo 0 > /sys/module/dmatest/parameters/run This is not what expected. The history of this bug is interesting. I though that the commit 2d88ce76 ("dmatest: add a 'wait' parameter") is a culprit, but looking closer to the code I think it simple revealed the broken logic from the day one, i.e. in the commit 0a2ff57d ("dmaengine: dmatest: add a maximum number of test iterations") which adds iterations parameter. So, to the point, the conditional of checking the thread to be stopped being first part of conjunction logic prevents to check iterations. Thus, we have to always check both conditions to be able to stop after given iterations. Since it wasn't visible before second commit appeared, I add a respective Fixes tag. Fixes: 2d88ce76 ("dmatest: add a 'wait' parameter") Cc: Dan Williams <dan.j.williams@intel.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20200424161147.16895-1-andriy.shevchenko@linux.intel.comSigned-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Andreas Gruenbacher authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 7648f939 upstream. nfs3_set_acl keeps track of the acl it allocated locally to determine if an acl needs to be released at the end. This results in a memory leak when the function allocates an acl as well as a default acl. Fix by releasing acls that differ from the acl originally passed into nfs3_set_acl. Fixes: b7fa0554 ("[PATCH] NFS: Add support for NFSv3 ACLs") Reported-by:
Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 5ce00760 upstream. gcc-10 points out a few instances of suspicious integer arithmetic leading to value truncation: sound/isa/opti9xx/opti92x-ad1848.c: In function 'snd_opti9xx_configure': sound/isa/opti9xx/opti92x-ad1848.c:322:43: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_opti9xx_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow] 322 | (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask))) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/opti92x-ad1848.c:351:3: note: in expansion of macro 'snd_opti9xx_write_mask' 351 | snd_opti9xx_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff); | ^~~~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/miro.c: In function 'snd_miro_configure': sound/isa/opti9xx/miro.c:873:40: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_miro_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow] 873 | (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask))) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/miro.c:1010:3: note: in expansion of macro 'snd_miro_write_mask' 1010 | snd_miro_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff); | ^~~~~~~~~~~~~~~~~~~ These are all harmless here as only the low 8 bit are passed down anyway. Change the macros to inline functions to make the code more readable and also avoid the warning. Strictly speaking those functions also need locking to make the read/write pair atomic, but it seems unlikely that anyone would still run into that issue. Fixes: 1841f613 ("[ALSA] Add snd-miro driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200429190216.85919-1-arnd@arndb.deSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
