- 14 May, 2020 40 commits
-
-
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 <f.fainelli@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13012/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>
-
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:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12341/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:
James Hogan <james.hogan@imgtec.com> Fixes: 40e084a5 ("MIPS: Add uprobes support.") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11920/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:
-
Sean Christopherson authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 5cbf3264 upstream. Use follow_pfn() to get the PFN of a PFNMAP VMA instead of assuming that vma->vm_pgoff holds the base PFN of the VMA. This fixes a bug where attempting to do VFIO_IOMMU_MAP_DMA on an arbitrary PFNMAP'd region of memory calculates garbage for the PFN. Hilariously, this only got detected because the first "PFN" calculated by vaddr_get_pfn() is PFN 0 (vma->vm_pgoff==0), and iommu_iova_to_phys() uses PA==0 as an error, which triggers a WARN in vfio_unmap_unpin() because the translation "failed". PFN 0 is now unconditionally reserved on x86 in order to mitigate L1TF, which causes is_invalid_reserved_pfn() to return true and in turns results in vaddr_get_pfn() returning success for PFN 0. Eventually the bogus calculation runs into PFNs that aren't reserved and leads to failure in vfio_pin_map_dma(). The subsequent call to vfio_remove_dma() attempts to unmap PFN 0 and WARNs. WARNING: CPU: 8 PID: 5130 at drivers/vfio/vfio_iommu_type1.c:750 vfio_unmap_unpin+0x2e1/0x310 [vfio_iommu_type1] Modules linked in: vfio_pci vfio_virqfd vfio_iommu_type1 vfio ... CPU: 8 PID: 5130 Comm: sgx Tainted: G W 5.6.0-rc5-705d787c7fee-vfio+ #3 Hardware name: Intel Corporation Mehlow UP Server Platform/Moss Beach Server, BIOS CNLSE2R1.D00.X119.B49.1803010910 03/01/2018 RIP: 0010:vfio_unmap_unpin+0x2e1/0x310 [vfio_iommu_type1] Code: <0f> 0b 49 81 c5 00 10 00 00 e9 c5 fe ff ff bb 00 10 00 00 e9 3d fe RSP: 0018:ffffbeb5039ebda8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff9a55cbf8d480 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff9a52b771c200 RBP: 0000000000000000 R08: 0000000000000040 R09: 00000000fffffff2 R10: 0000000000000001 R11: ffff9a51fa896000 R12: 0000000184010000 R13: 0000000184000000 R14: 0000000000010000 R15: ffff9a55cb66ea08 FS: 00007f15d3830b40(0000) GS:ffff9a55d5600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000561cf39429e0 CR3: 000000084f75f005 CR4: 00000000003626e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vfio_remove_dma+0x17/0x70 [vfio_iommu_type1] vfio_iommu_type1_ioctl+0x9e3/0xa7b [vfio_iommu_type1] ksys_ioctl+0x92/0xb0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x4c/0x180 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f15d04c75d7 Code: <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48 Fixes: 73fa0d10 ("vfio: Type1 IOMMU implementation") Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Alaa Hleihel authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit c08cfb2d upstream. Initialize ib_spec on the stack before using it, otherwise we will have garbage values that will break creating default rules with invalid parsing error. Fixes: a37a1a42 ("IB/mlx4: Add mechanism to support flow steering over IB links") Link: https://lore.kernel.org/r/20200413132235.930642-1-leon@kernel.orgSigned-off-by:
Alaa Hleihel <alaa@mellanox.com> Reviewed-by:
Maor Gottlieb <maorg@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Kai-Heng Feng authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit a9b760b0 upstream. Transitioned power state logged at the end of setting ACPI power. However, D3cold won't be in the message because state can only be D3hot at most. Use target_state to corretly report when power state is D3cold. Cc: All applicable <stable@vger.kernel.org> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 4285de07 upstream. The checks of the plugin buffer overflow in the previous fix by commit f2ecf903 ("ALSA: pcm: oss: Avoid plugin buffer overflow") are put in the wrong places mistakenly, which leads to the expected (repeated) sound when the rate plugin is involved. Fix in the right places. Also, at those right places, the zero check is needed for the termination node, so added there as well, and let's get it done, finally. Fixes: f2ecf903 ("ALSA: pcm: oss: Avoid plugin buffer overflow") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200424193350.19678-1-tiwai@suse.deSigned-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit a65aa9c3 upstream. Cc: stable@vger.kernel.org Fixes: 8002db63 ("qxl: convert qxl driver to proper use for reservations") Signed-off-by:
-
Theodore Ts'o authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit 191ce178 upstream. The check for special (reserved) inode number checks in __ext4_iget() was broken by commit 8a363970: ("ext4: avoid declaring fs inconsistent due to invalid file handles"). This was caused by a botched reversal of the sense of the flag now known as EXT4_IGET_SPECIAL (when it was previously named EXT4_IGET_NORMAL). Fix the logic appropriately. Fixes: 8a363970 ("ext4: avoid declaring fs inconsistent...") Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@kernel.org Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1878098Signed-off-by:
-
Al Viro authored
BugLink: https://bugs.launchpad.net/bugs/1878098 commit b0d3869c upstream. ... to protect the modification of mp->m_count done by it. Most of the places that modify that thing also have namespace_lock held, but not all of them can do so, so we really need mount_lock here. Kudos to Piotr Krysiuk <piotras@gmail.com>, who'd spotted a related bug in pivot_root(2) (fixed unnoticed in 5.3); search for other similar turds has caught out this one. Cc: stable@kernel.org Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Piotr Krysiuk <piotras@gmail.com> Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1878098 commit fbbbbd2f upstream. There are two cases where u32 variables n and err are being checked for less than zero error values, the checks is always false because the variables are not signed. Fix this by making the variables ints. Addresses-Coverity: ("Unsigned compared against 0") Fixes: 345c0dbf ("ext4: protect journal inode's blocks using block_validity") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Ashwin H <ashwinh@vmware.com> Signed-off-by:
-
Theodore Ts'o authored
BugLink: https://bugs.launchpad.net/bugs/1878098 commit 170417c8 upstream. Commit 345c0dbf ("ext4: protect journal inode's blocks using block_validity") failed to add an exception for the journal inode in ext4_check_blockref(), which is the function used by ext4_get_branch() for indirect blocks. This caused attempts to read from the ext3-style journals to fail with: [ 848.968550] EXT4-fs error (device sdb7): ext4_get_branch:171: inode #8: block 30343695: comm jbd2/sdb7-8: invalid block Fix this by adding the missing exception check. Fixes: 345c0dbf ("ext4: protect journal inode's blocks using block_validity") Reported-by:
Arthur Marsh <arthur.marsh@internode.on.net> Signed-off-by:
-
Theodore Ts'o authored
BugLink: https://bugs.launchpad.net/bugs/1878098 commit 0a944e8a upstream. Since the journal inode is already checked when we added it to the block validity's system zone, if we check it again, we'll just trigger a failure. This was causing failures like this: [ 53.897001] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 53.931430] jbd2_journal_bmap: journal block not found at offset 49 on sda-8 [ 53.938480] Aborting journal on device sda-8. ... but only if the system was under enough memory pressure that logical->physical mapping for the journal inode gets pushed out of the extent cache. (This is why it wasn't noticed earlier.) Fixes: 345c0dbf ("ext4: protect journal inode's blocks using block_validity") Reported-by:
Dan Rue <dan.rue@linaro.org> Signed-off-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by:
-
