summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-07-07LoongArch: Fix section mismatch warningTiezhu Yang1-1/+0
init_numa_memory() is annotated __init and not used by any module, thus don't export it. Remove not needed EXPORT_SYMBOL for init_numa_memory() to fix the following section mismatch warning: MODPOST vmlinux.symvers WARNING: modpost: vmlinux.o(___ksymtab+init_numa_memory+0x0): Section mismatch in reference from the variable __ksymtab_init_numa_memory to the function .init.text:init_numa_memory() The symbol init_numa_memory is exported and annotated __init Fix this by removing the __init annotation of init_numa_memory or drop the export. This is build on Linux 5.19-rc4. Fixes: d4b6f1562a3c ("LoongArch: Add Non-Uniform Memory Access (NUMA) support") Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2022-07-07LoongArch: Fix build errors for tinyconfigHuacai Chen2-0/+2
Building loongarch:tinyconfig fails with the following error. ./arch/loongarch/include/asm/page.h: In function 'pfn_valid': ./arch/loongarch/include/asm/page.h:42:32: error: 'PHYS_OFFSET' undeclared Add the missing include file and fix succeeding vdso errors. Fixes: 09cfefb7fa70 ("LoongArch: Add memory management") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2022-07-07LoongArch: Remove obsolete mentions of vcsrQi Hu4-14/+0
The `vcsr` only exists in the old hardware design, it isn't used in any shipped hardware from Loongson-3A5000 on. Both scalar FP and LSX/LASX instructions use the `fcsr` as their control and status registers now. For example, the RM control bit in fcsr0 is shared by FP, LSX and LASX instructions. Particularly, fcsr16 to fcsr31 are reserved for LSX/LASX now, access to these registers has no visible effect if LSX/LASX is enabled, and will cause SXD/ASXD exceptions if LSX/LASX is not enabled. So, mentions of vcsr are obsolete in the first place (it was just used for debugging), let's remove them. Reviewed-by: WANG Xuerui <git@xen0n.name> Signed-off-by: Qi Hu <huqi@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2022-07-07LoongArch: Drop these obsolete selects in KconfigLukas Bulwahn1-4/+0
Commit fa96b57c1490 ("LoongArch: Add build infrastructure") adds the new file arch/loongarch/Kconfig. As the work on LoongArch was probably quite some time under development, various config symbols have changed and disappeared from the time of initial writing of the Kconfig file and its inclusion in the repository. The following four commits: commit c126a53c2760 ("arch: remove GENERIC_FIND_FIRST_BIT entirely") commit 140c8180eb7c ("arch: remove HAVE_COPY_THREAD_TLS") commit aca52c398389 ("mm: remove CONFIG_HAVE_MEMBLOCK") commit 3f08a302f533 ("mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option") remove the mentioned config symbol, and enable the intended setup by default without configuration. Drop these obsolete selects in loongarch's Kconfig. Reviewed-by: WANG Xuerui <git@xen0n.name> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2022-07-07fbcon: Use fbcon_info_from_console() in fbcon_modechange_possible()Helge Deller1-1/+1
Use the fbcon_info_from_console() wrapper which was added to kernel v5.19 with commit 409d6c95f9c6 ("fbcon: Introduce wrapper for console->fb_info lookup"). Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
2022-07-07fbmem: Check virtual screen sizes in fb_set_var()Helge Deller1-0/+10
Verify that the fbdev or drm driver correctly adjusted the virtual screen sizes. On failure report the failing driver and reject the screen size change. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: stable@vger.kernel.org # v5.4+
2022-07-07fbcon: Prevent that screen size is smaller than font sizeHelge Deller3-1/+35
We need to prevent that users configure a screen size which is smaller than the currently selected font size. Otherwise rendering chars on the screen will access memory outside the graphics memory region. This patch adds a new function fbcon_modechange_possible() which implements this check and which later may be extended with other checks if necessary. The new function is called from the FBIOPUT_VSCREENINFO ioctl handler in fbmem.c, which will return -EINVAL if userspace asked for a too small screen size. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: stable@vger.kernel.org # v5.4+
2022-07-07fbcon: Disallow setting font bigger than screen sizeHelge Deller1-0/+5
Prevent that users set a font size which is bigger than the physical screen. It's unlikely this may happen (because screens are usually much larger than the fonts and each font char is limited to 32x32 pixels), but it may happen on smaller screens/LCD displays. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: stable@vger.kernel.org # v4.14+
2022-07-06Merge branch 'wireguard-patches-for-5-19-rc6'Jakub Kicinski13-134/+157
Jason A. Donenfeld says: ==================== wireguard patches for 5.19-rc6 1) A few small fixups to the selftests, per usual. Of particular note is a fix for a test flake that occurred on especially fast systems that boot in less than a second. 2) An addition during this cycle of some s390 crypto interacted with the way wireguard selects dependencies, resulting in linker errors reported by the kernel test robot. So Vladis sent in a patch for that, which also required a small preparatory fix moving some Kconfig symbols around. ==================== Link: https://lore.kernel.org/r/20220707003157.526645-1-Jason@zx2c4.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-06wireguard: Kconfig: select CRYPTO_CHACHA_S390Vladis Dronov1-0/+1
Select the new implementation of CHACHA20 for S390 when available. It is faster than the generic software implementation, but also prevents some linker errors in certain situations. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/linux-kernel/202207030630.6SZVkrWf-lkp@intel.com/ Signed-off-by: Vladis Dronov <vdronov@redhat.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-06crypto: s390 - do not depend on CRYPTO_HW for SIMD implementationsJason A. Donenfeld2-115/+114
Various accelerated software implementation Kconfig values for S390 were mistakenly placed into drivers/crypto/Kconfig, even though they're mainly just SIMD code and live in arch/s390/crypto/ like usual. This gives them the very unusual dependency on CRYPTO_HW, which leads to problems elsewhere. This patch fixes the issue by moving the Kconfig values for non-hardware drivers into the usual place in crypto/Kconfig. Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-06wireguard: selftests: use microvm on x86Jason A. Donenfeld3-8/+16
This makes for faster tests, faster compile time, and allows us to ditch ACPI finally. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-06wireguard: selftests: always call kernel makefileJason A. Donenfeld1-3/+2
These selftests are used for much more extensive changes than just the wireguard source files. So always call the kernel's build file, which will do something or nothing after checking the whole tree, per usual. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-06wireguard: selftests: use virt machine on m68kJason A. Donenfeld2-8/+6
This should be a bit more stable hopefully. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-06wireguard: selftests: set fake real time in initJason A. Donenfeld8-0/+18
Not all platforms have an RTC, and rather than trying to force one into each, it's much easier to just set a fixed time. This is necessary because WireGuard's latest handshakes parameter is returned in wallclock time, and if the system time isn't set, and the system is really fast, then this returns 0, which trips the test. Turning this on requires setting CONFIG_COMPAT_32BIT_TIME=y, as musl doesn't support settimeofday without it. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-06r8169: fix accessing unset transport headerHeiner Kallweit1-6/+4
66e4c8d95008 ("net: warn if transport header was not set") added a check that triggers a warning in r8169, see [0]. The commit referenced in the Fixes tag refers to the change from which the patch applies cleanly, there's nothing wrong with this commit. It seems the actual issue (not bug, because the warning is harmless here) was introduced with bdfa4ed68187 ("r8169: use Giant Send"). [0] https://bugzilla.kernel.org/show_bug.cgi?id=216157 Fixes: 8d520b4de3ed ("r8169: work around RTL8125 UDP hw bug") Reported-by: Erhard F. <erhard_f@mailbox.org> Tested-by: Erhard F. <erhard_f@mailbox.org> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/1b2c2b29-3dc0-f7b6-5694-97ec526d51a0@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-06net: rose: fix UAF bug caused by rose_t0timer_expiryDuoming Zhou1-2/+2
There are UAF bugs caused by rose_t0timer_expiry(). The root cause is that del_timer() could not stop the timer handler that is running and there is no synchronization. One of the race conditions is shown below: (thread 1) | (thread 2) | rose_device_event | rose_rt_device_down | rose_remove_neigh rose_t0timer_expiry | rose_stop_t0timer(rose_neigh) ... | del_timer(&neigh->t0timer) | kfree(rose_neigh) //[1]FREE neigh->dce_mode //[2]USE | The rose_neigh is deallocated in position [1] and use in position [2]. The crash trace triggered by POC is like below: BUG: KASAN: use-after-free in expire_timers+0x144/0x320 Write of size 8 at addr ffff888009b19658 by task swapper/0/0 ... Call Trace: <IRQ> dump_stack_lvl+0xbf/0xee print_address_description+0x7b/0x440 print_report+0x101/0x230 ? expire_timers+0x144/0x320 kasan_report+0xed/0x120 ? expire_timers+0x144/0x320 expire_timers+0x144/0x320 __run_timers+0x3ff/0x4d0 run_timer_softirq+0x41/0x80 __do_softirq+0x233/0x544 ... This patch changes rose_stop_ftimer() and rose_stop_t0timer() in rose_remove_neigh() to del_timer_sync() in order that the timer handler could be finished before the resources such as rose_neigh and so on are deallocated. As a result, the UAF bugs could be mitigated. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/20220705125610.77971-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-06usbnet: fix memory leak in error caseOliver Neukum1-5/+12
usbnet_write_cmd_async() mixed up which buffers need to be freed in which error case. v2: add Fixes tag v3: fix uninitialized buf pointer Fixes: 877bd862f32b8 ("usbnet: introduce usbnet 3 command helpers") Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20220705125351.17309-1-oneukum@suse.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-06nvme: use struct group for generic command dwordsKeith Busch2-1/+3
This will allow the trace event to know the full size of the data intended to be copied and silence read overflow checks. Reported-by: John Garry <john.garry@huawei.com> Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-07-06Merge tag 'for-linus' of https://github.com/openrisc/linuxLinus Torvalds2-2/+1
Pull OpenRISC fixes from Stafford Horne: "Fixups for OpenRISC found during recent testing: - An OpenRISC irqchip fix to stop acking level interrupts which was causing issues on SMP platforms - A comment typo fix in our unwinder code" * tag 'for-linus' of https://github.com/openrisc/linux: openrisc: unwinder: Fix grammar issue in comment irqchip: or1k-pic: Undefine mask_ack for level triggered hardware
2022-07-06Merge tag 'sound-5.19-rc6' of ↵Linus Torvalds43-249/+812
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "This became largish as it includes the pending ASoC fixes. Almost all changes are device-specific small fixes, while many of them are coverage for mixer issues that were detected by selftest. In addition, usual suspects for HD/USB-audio are there" * tag 'sound-5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (43 commits) ALSA: cs46xx: Fix missing snd_card_free() call at probe error ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0) ALSA: usb-audio: Add quirk for Fiero SC-01 ALSA: hda/realtek: Add quirk for Clevo L140PU ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices ASoC: madera: Fix event generation for rate controls ASoC: madera: Fix event generation for OUT1 demux ASoC: cs47l15: Fix event generation for low power mux control ASoC: cs35l41: Add ASP TX3/4 source to register patch ASoC: dapm: Initialise kcontrol data for mux/demux controls ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error ASoC: cs35l41: Correct some control names ASoC: wm5110: Fix DRE control ASoC: wm_adsp: Fix event for preloader MAINTAINERS: update ASoC Qualcomm maintainer email-id ASoC: rockchip: i2s: switch BCLK to GPIO ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states ASoC: SOF: pm: add definitions for S4 and S5 states ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2 ASoC: SOF: Intel: hda: Fix compressed stream position tracking ...
2022-07-06Merge tag 'irqchip-fixes-5.19-2' of ↵Thomas Gleixner3-12/+33
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes from Marc Zygnier: - Gracefully handle failure to request MMIO resources in the GICv3 driver - Make a static key static in the Apple AIC driver - Fix the Xilinx intc driver dependency on OF_ADDRESS Link: https://lore.kernel.org/all/20220701133531.1545319-1-maz@kernel.org
2022-07-06dt-bindings: dma: allwinner,sun50i-a64-dma: Fix min/max typoSamuel Holland1-1/+1
The conditional block for variants with a second clock should have set minItems, not maxItems, which was already 2. Since clock-names requires two items, this typo should not have caused any problems. Fixes: edd14218bd66 ("dt-bindings: dmaengine: Convert Allwinner A31 and A64 DMA to a schema") Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220702031903.21703-1-samuel@sholland.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-07-06nvme-pci: phison e16 has bogus namespace idsKeith Busch1-1/+2
Add the quirk. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216049 Reported-by: Chris Egolf <cegolf@ugholf.net> Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-07-06video: of_display_timing.h: include errno.hHsin-Yi Wang1-0/+2
If CONFIG_OF is not enabled, default of_get_display_timing() returns an errno, so include the header. Fixes: 422b67e0b31a ("videomode: provide dummy inline functions for !CONFIG_OF") Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Helge Deller <deller@gmx.de>
2022-07-06fbdev: fbmem: Fix logo center image dx issueGuiling Deng1-1/+1
Image.dx gets wrong value because of missing '()'. If xres == logo->width and n == 1, image.dx = -16. Signed-off-by: Guiling Deng <greens9@163.com> Fixes: 3d8b1933eb1c ("fbdev: fbmem: add config option to center the bootup logo") Cc: stable@vger.kernel.org # v5.0+ Signed-off-by: Helge Deller <deller@gmx.de>
2022-07-06Revert "tls: rx: move counting TlsDecryptErrors for sync"Gal Pressman1-4/+4
This reverts commit 284b4d93daee56dff3e10029ddf2e03227f50dbf. When using TLS device offload and coming from tls_device_reencrypt() flow, -EBADMSG error in tls_do_decryption() should not be counted towards the TLSTlsDecryptError counter. Move the counter increase back to the decrypt_internal() call site in decrypt_skb_update(). This also fixes an issue where: if (n_sgin < 1) return -EBADMSG; Errors in decrypt_internal() were not counted after the cited patch. Fixes: 284b4d93daee ("tls: rx: move counting TlsDecryptErrors for sync") Cc: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06Merge branch 'mptcp-path-manager-fixes'David S. Miller7-31/+192
Mat Martineau says: ==================== mptcp: Path manager fixes for 5.19 The MPTCP userspace path manager is new in 5.19, and these patches fix some issues in that new code. Patches 1-3 fix path manager locking issues. Patches 4 and 5 allow userspace path managers to change priority of established subflows using the existing MPTCP_PM_CMD_SET_FLAGS generic netlink command. Includes corresponding self test update. Patches 6 and 7 fix accounting of available endpoint IDs and the MPTCP_MIB_RMSUBFLOW counter. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06mptcp: update MIB_RMSUBFLOW in cmd_sf_destroyGeliang Tang1-0/+2
This patch increases MPTCP_MIB_RMSUBFLOW mib counter in userspace pm destroy subflow function mptcp_nl_cmd_sf_destroy() when removing subflow. Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establishment") Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06mptcp: fix local endpoint accountingPaolo Abeni1-1/+2
In mptcp_pm_nl_rm_addr_or_subflow() we always mark as available the id corresponding to the just removed address. The used bitmap actually tracks only the local IDs: we must restrict the operation when a (local) subflow is removed. Fixes: a88c9e496937 ("mptcp: do not block subflows creation on errors") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06selftests: mptcp: userspace PM support for MP_PRIO signalsKishen Maloor2-2/+103
This change updates the testing sample (pm_nl_ctl) to exercise the updated MPTCP_PM_CMD_SET_FLAGS command for userspace PMs to issue MP_PRIO signals over the selected subflow. E.g. ./pm_nl_ctl set 10.0.1.2 port 47234 flags backup token 823274047 rip 10.0.1.1 rport 50003 userspace_pm.sh has a new selftest that invokes this command. Fixes: 259a834fadda ("selftests: mptcp: functional tests for the userspace PM type") Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Kishen Maloor <kishen.maloor@intel.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06mptcp: netlink: issue MP_PRIO signals from userspace PMsKishen Maloor3-6/+62
This change updates MPTCP_PM_CMD_SET_FLAGS to allow userspace PMs to issue MP_PRIO signals over a specific subflow selected by the connection token, local and remote address+port. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/286 Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establishment") Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Kishen Maloor <kishen.maloor@intel.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06mptcp: Acquire the subflow socket lock before modifying MP_PRIO flagsMat Martineau3-3/+12
When setting up a subflow's flags for sending MP_PRIO MPTCP options, the subflow socket lock was not held while reading and modifying several struct members that are also read and modified in mptcp_write_options(). Acquire the subflow socket lock earlier and send the MP_PRIO ACK with that lock already acquired. Add a new variant of the mptcp_subflow_send_ack() helper to use with the subflow lock held. Fixes: 067065422fcd ("mptcp: add the outgoing MP_PRIO support") Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06mptcp: Avoid acquiring PM lock for subflow priority changesMat Martineau2-6/+5
The in-kernel path manager code for changing subflow flags acquired both the msk socket lock and the PM lock when possibly changing the "backup" and "fullmesh" flags. mptcp_pm_nl_mp_prio_send_ack() does not access anything protected by the PM lock, and it must release and reacquire the PM lock. By pushing the PM lock to where it is needed in mptcp_pm_nl_fullmesh(), the lock is only acquired when the fullmesh flag is changed and the backup flag code no longer has to release and reacquire the PM lock. The change in locking context requires the MIB update to be modified - move that to a better location instead. This change also makes it possible to call mptcp_pm_nl_mp_prio_send_ack() for the userspace PM commands without manipulating the in-kernel PM lock. Fixes: 0f9f696a502e ("mptcp: add set_flags command in PM netlink") Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06mptcp: fix locking in mptcp_nl_cmd_sf_destroy()Paolo Abeni1-13/+6
The user-space PM subflow removal path uses a couple of helpers that must be called under the msk socket lock and the current code lacks such requirement. Change the existing lock scope so that the relevant code is under its protection. Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establishment") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/287 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06Merge branch 'act_police-continue-offload-fix'David S. Miller3-8/+8
Vlad Buslov says: ==================== net: Fix police 'continue' action offload TC act_police with 'continue' action had been supported by mlx5 matchall classifier offload implementation for some time. However, 'continue' was assumed implicitly and recently got broken in multiple places. Fix it in both TC hardware offload validation code and mlx5 driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06net/mlx5e: Fix matchall police parameters validationVlad Buslov1-7/+6
Referenced commit prepared the code for upcoming extension that allows mlx5 to offload police action attached to flower classifier. However, with regard to existing matchall classifier offload validation should be reversed as FLOW_ACTION_CONTINUE is the only supported notexceed police action type. Fix the problem by allowing FLOW_ACTION_CONTINUE for police action and extend scan_tc_matchall_fdb_actions() to only allow such actions with matchall classifier. Fixes: d97b4b105ce7 ("flow_offload: reject offload for all drivers with invalid police parameters") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Acked-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06net/sched: act_police: allow 'continue' action offloadVlad Buslov2-1/+2
Offloading police with action TC_ACT_UNSPEC was erroneously disabled even though it was supported by mlx5 matchall offload implementation, which didn't verify the action type but instead assumed that any single police action attached to matchall classifier is a 'continue' action. Lack of action type check made it non-obvious what mlx5 matchall implementation actually supports and caused implementers and reviewers of referenced commits to disallow it as a part of improved validation code. Fixes: b8cd5831c61c ("net: flow_offload: add tc police action parameters") Fixes: b50e462bc22d ("net/sched: act_police: Add extack messages for offload failure") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Tested-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-06iommu/vt-d: Fix RID2PASID setup/teardown failureLu Baolu4-94/+3
The IOMMU driver shares the pasid table for PCI alias devices. When the RID2PASID entry of the shared pasid table has been filled by the first device, the subsequent device will encounter the "DMAR: Setup RID2PASID failed" failure as the pasid entry has already been marked as present. As the result, the IOMMU probing process will be aborted. On the contrary, when any alias device is hot-removed from the system, for example, by writing to /sys/bus/pci/devices/.../remove, the shared RID2PASID will be cleared without any notifications to other devices. As the result, any DMAs from those rest devices are blocked. Sharing pasid table among PCI alias devices could save two memory pages for devices underneath the PCIe-to-PCI bridges. Anyway, considering that those devices are rare on modern platforms that support VT-d in scalable mode and the saved memory is negligible, it's reasonable to remove this part of immature code to make the driver feasible and stable. Fixes: ef848b7e5a6a0 ("iommu/vt-d: Setup pasid entry for RID2PASID support") Reported-by: Chenyi Qiang <chenyi.qiang@intel.com> Reported-by: Ethan Zhao <haifeng.zhao@linux.intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Ethan Zhao <haifeng.zhao@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220623065720.727849-1-baolu.lu@linux.intel.com Link: https://lore.kernel.org/r/20220625133430.2200315-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-07-06iommu/vt-d: Fix PCI bus rescan device hot addYian Chen1-1/+1
Notifier calling chain uses priority to determine the execution order of the notifiers or listeners registered to the chain. PCI bus device hot add utilizes the notification mechanism. The current code sets low priority (INT_MIN) to Intel dmar_pci_bus_notifier and postpones DMAR decoding after adding new device into IOMMU. The result is that struct device pointer cannot be found in DRHD search for the new device's DMAR/IOMMU. Subsequently, the device is put under the "catch-all" IOMMU instead of the correct one. This could cause system hang when device TLB invalidation is sent to the wrong IOMMU. Invalidation timeout error and hard lockup have been observed and data inconsistency/crush may occur as well. This patch fixes the issue by setting a positive priority(1) for dmar_pci_bus_notifier while the priority of IOMMU bus notifier uses the default value(0), therefore DMAR decoding will be in advance of DRHD search for a new device to find the correct IOMMU. Following is a 2-step example that triggers the bug by simulating PCI device hot add behavior in Intel Sapphire Rapids server. echo 1 > /sys/bus/pci/devices/0000:6a:01.0/remove echo 1 > /sys/bus/pci/rescan Fixes: 59ce0515cdaf ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Zhang, Bernice <bernice.zhang@intel.com> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Yian Chen <yian.chen@intel.com> Link: https://lore.kernel.org/r/20220521002115.1624069-1-yian.chen@intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-07-06x86/compressed/64: Add identity mappings for setup_data entriesMichael Roth1-0/+13
The decompressed kernel initially relies on the identity map set up by the boot/compressed kernel for accessing things like boot_params. With the recent introduction of SEV-SNP support, the decompressed kernel also needs to access the setup_data entries pointed to by boot_params->hdr.setup_data. This can lead to a crash in the kexec kernel during early boot due to these entries not currently being included in the initial identity map, see thread at Link below. Include mappings for the setup_data entries in the initial identity map. [ bp: Massage commit message and use a helper var for better readability. ] Fixes: b190a043c49a ("x86/sev: Add SEV-SNP feature detection/setup") Reported-by: Jun'ichi Nomura <junichi.nomura@nec.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/TYCPR01MB694815CD815E98945F63C99183B49@TYCPR01MB6948.jpnprd01.prod.outlook.com
2022-07-06dmaengine: lgm: Fix an error handling path in intel_ldma_probe()Christophe JAILLET1-1/+2
ldma_clk_disable() calls both: clk_disable_unprepare(d->core_clk); reset_control_assert(d->rst); So, should devm_reset_control_get_optional() fail, core_clk should not be prepare_enable'd before it, otherwise it will never be disable_unprepare'd. Reorder the code to handle the error handling path as expected. Fixes: 32d31c79a1a4 ("dmaengine: Add Intel LGM SoC DMA support.") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/18504549bc4d2b62a72a02cb22a2e4d8e6a58720.1653241224.git.christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-07-06dmaengine: pl330: Fix lockdep warning about non-static keyDmitry Osipenko1-1/+1
The DEFINE_SPINLOCK() macro shouldn't be used for dynamically allocated spinlocks. The lockdep warns about this and disables locking validator. Fix the warning by making lock static. INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Hardware name: Radxa ROCK Pi 4C (DT) Call trace: dump_backtrace.part.0+0xcc/0xe0 show_stack+0x18/0x6c dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 register_lock_class+0x4a8/0x4cc __lock_acquire+0x78/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 _raw_spin_lock_irqsave+0x84/0xc4 add_desc+0x44/0xc0 pl330_get_desc+0x15c/0x1d0 pl330_prep_dma_cyclic+0x100/0x270 snd_dmaengine_pcm_trigger+0xec/0x1c0 dmaengine_pcm_trigger+0x18/0x24 ... Fixes: e588710311ee ("dmaengine: pl330: fix descriptor allocation fail") Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20220520181432.149904-1-dmitry.osipenko@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-07-05net: lan966x: hardcode the number of external portsMichael Walle2-6/+3
Instead of counting the child nodes in the device tree, hardcode the number of ports in the driver itself. The counting won't work at all if an ethernet port is marked as disabled, e.g. because it is not connected on the board at all. It turns out that the LAN9662 and LAN9668 use the same switching IP with the same synthesis parameters. The only difference is that the output ports are not connected. Thus, we can just hardcode the number of physical ports to 8. Fixes: db8bcaad5393 ("net: lan966x: add the basic lan966x driver") Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20220704153654.1167886-1-michael@walle.cc Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-05Merge tag 'for-net-2022-07-05' of ↵Jakub Kicinski2-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - Fix deadlock when powering on. * tag 'for-net-2022-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: core: Fix deadlock on hci_power_on_sync. ==================== Link: https://lore.kernel.org/r/20220705202700.1689796-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-05Bluetooth: core: Fix deadlock on hci_power_on_sync.Vasyl Vavrychuk2-1/+3
`cancel_work_sync(&hdev->power_on)` was moved to hci_dev_close_sync in commit [1] to ensure that power_on work is canceled after HCI interface down. But, in certain cases power_on work function may call hci_dev_close_sync itself: hci_power_on -> hci_dev_do_close -> hci_dev_close_sync -> cancel_work_sync(&hdev->power_on), causing deadlock. In particular, this happens when device is rfkilled on boot. To avoid deadlock, move power_on work canceling out of hci_dev_do_close/hci_dev_close_sync. Deadlock introduced by commit [1] was reported in [2,3] as broken suspend. Suspend did not work because `hdev->req_lock` held as result of `power_on` work deadlock. In fact, other BT features were not working. It was not observed when testing [1] since it was verified without rfkill in place. NOTE: It is not needed to cancel power_on work from other places where hci_dev_do_close/hci_dev_close_sync is called in case: * Requests were serialized due to `hdev->req_workqueue`. The power_on work is first in that workqueue. * hci_rfkill_set_block which won't close device anyway until HCI_SETUP is on. * hci_sock_release which runs after hci_sock_bind which ensures HCI_SETUP was cleared. As result, behaviour is the same as in pre-dd06ed7 commit, except power_on work cancel added to hci_dev_close. [1]: commit ff7f2926114d ("Bluetooth: core: Fix missing power_on work cancel on HCI close") [2]: https://lore.kernel.org/lkml/20220614181706.26513-1-max.oss.09@gmail.com/ [2]: https://lore.kernel.org/lkml/1236061d-95dd-c3ad-a38f-2dae7aae51ef@o2.pl/ Fixes: ff7f2926114d ("Bluetooth: core: Fix missing power_on work cancel on HCI close") Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com> Reported-by: Max Krummenacher <max.krummenacher@toradex.com> Reported-by: Mateusz Jonczyk <mat.jonczyk@o2.pl> Tested-by: Max Krummenacher <max.krummenacher@toradex.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-05ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supportedMario Limonciello3-1/+26
commit 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") added support for claiming to support CPPC in _OSC on non-Intel platforms. This unfortunately caused a regression on a vartiety of AMD platforms in the field because a number of AMD platforms don't set the `_OSC` bit 5 or 6 to indicate CPPC or CPPC v2 support. As these AMD platforms already claim CPPC support via a dedicated MSR from `X86_FEATURE_CPPC`, use this enable this feature rather than requiring the `_OSC` on platforms with a dedicated MSR. If there is additional breakage on the shared memory designs also missing this _OSC, additional follow up changes may be needed. Fixes: 72f2ecb7ece7 ("Set CPPC _OSC bits for all and when CPPC_LIB is supported") Reported-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-07-05ACPI: CPPC: Only probe for _CPC if CPPC v2 is ackedMario Limonciello3-8/+9
Previously the kernel used to ignore whether the firmware masked CPPC or CPPCv2 and would just pretend that it worked. When support for the USB4 bit in _OSC was introduced from commit 9e1f561afb ("ACPI: Execute platform _OSC also with query bit clear") the kernel began to look at the return when the query bit was clear. This caused regressions that were misdiagnosed and attempted to be solved as part of commit 2ca8e6285250 ("Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag""). This caused a different regression where non-Intel systems weren't able to negotiate _OSC properly. This was reverted in commit 2ca8e6285250 ("Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag"") and attempted to be fixed by commit c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not supported by firmware") but the regression still returned. These systems with the regression only load support for CPPC from an SSDT dynamically when _OSC reports CPPC v2. Avoid the problem by not letting CPPC satisfy the requirement in `acpi_cppc_processor_probe`. Reported-by: CUI Hao <cuihao.leo@gmail.com> Reported-by: maxim.novozhilov@gmail.com Reported-by: lethe.tree@protonmail.com Reported-by: garystephenwright@gmail.com Reported-by: galaxyking0419@gmail.com Fixes: c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not supported by firmware") Fixes: 2ca8e6285250 ("Revert "ACPI Pass the same capabilities to the _OSC regardless of the query flag"") Link: https://bugzilla.kernel.org/show_bug.cgi?id=213023 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2075387 Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: CUI Hao <cuihao.leo@gmail.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-07-05Merge tag 'xsa-5.19-tag' of ↵Linus Torvalds3-23/+93
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen security fixes from Juergen Gross: - XSA-403 (4 patches for blkfront and netfront drivers): Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). - XSA-405 (1 patch for netfront driver, only 5.10 and newer): While adding logic to support XDP (eXpress Data Path), a code label was moved in a way allowing for SKBs having references (pointers) retained for further processing to nevertheless be freed. - XSA-406 (1 patch for Arm specific dom0 code): When mapping pages of guests on Arm, dom0 is using an rbtree to keep track of the foreign mappings. Updating of that rbtree is not always done completely with the related lock held, resulting in a small race window, which can be used by unprivileged guests via PV devices to cause inconsistencies of the rbtree. These inconsistencies can lead to Denial of Service (DoS) of dom0, e.g. by causing crashes or the inability to perform further mappings of other guests' memory pages. * tag 'xsa-5.19-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/arm: Fix race in RB-tree based P2M accounting xen-netfront: restore __skb_queue_tail() positioning in xennet_get_responses() xen/blkfront: force data bouncing when backend is untrusted xen/netfront: force data bouncing when backend is untrusted xen/netfront: fix leaking data in shared pages xen/blkfront: fix leaking data in shared pages
2022-07-05ALSA: cs46xx: Fix missing snd_card_free() call at probe errorTakashi Iwai1-9/+13
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 5bff69b3645d ("ALSA: cs46xx: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Reported-and-tested-by: Jan Engelhardt <jengelh@inai.de> Link: https://lore.kernel.org/r/p2p1s96o-746-74p4-s95-61qo1p7782pn@vanv.qr Link: https://lore.kernel.org/r/20220705152336.350-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-19 23:30:39 +0000