aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-09-08Merge tag 'spi-fix-v6.0-rc4' of ↵Linus Torvalds5-9/+43
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "Several fixes that came in since the merge window, the major one being a fix for the spi-mux driver which was broken by the performance optimisations due to it peering inside the core's data structures more than it should" * tag 'spi-fix-v6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: spi: Fix queue hang if previous transfer failed spi: mux: Fix mux interaction with fast path optimisations spi: cadence-quadspi: Disable irqs during indirect reads spi: bitbang: Fix lsb-first Rx
2022-09-08Merge tag 'regulator-fix-v6.0-rc4' of ↵Linus Torvalds3-5/+9
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "One core fix here improving the error handling on enable failure, plus smaller fixes for the pfuze100 drive and the SPMI DT bindings" * tag 'regulator-fix-v6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: Fix qcom,spmi-regulator schema regulator: pfuze100: Fix the global-out-of-bounds access in pfuze100_regulator_probe() regulator: core: Clean up on enable failure
2022-09-08Merge tag 'regmap-fix-v6.0-rc4' of ↵Linus Torvalds1-0/+8
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap fix from Mark Brown: "A fix for how we handle controller constraints on SPI message sizes, only impacting systems with SPI controllers with very low limits like the AMD controller used in the Steam Deck" * tag 'regmap-fix-v6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: spi: Reserve space for register address/padding
2022-09-08Merge tag 'nvme-6.0-2022-09-08' of git://git.infradead.org/nvme into block-6.0Jens Axboe4-12/+32
Pull NVMe fixes from Christoph: "nvme fixes for Linux 6.1 - fix a use after free in nvmet (Bart Van Assche) - fix a use after free when detecting digest errors (Sagi Grimberg) - fix regression that causes sporadic TCP requests to time out (Sagi Grimberg) - fix two off by ones errors in the nvmet ZNS support (Dennis Maisenbacher) - requeue aen after firmware activation (Keith Busch)" * tag 'nvme-6.0-2022-09-08' of git://git.infradead.org/nvme: nvme: requeue aen after firmware activation nvmet: fix mar and mor off-by-one errors nvme-tcp: fix regression that causes sporadic requests to time out nvme-tcp: fix UAF when detecting digest errors nvmet: fix a use-after-free
2022-09-08perf dlfilter dlfilter-show-cycles: Fix types for print formatAdrian Hunter1-2/+2
Avoid compiler warning about format %llu that expects long long unsigned int but argument has type __u64. Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com> Fixes: c3afd6e50fce824f ("perf dlfilter: Add dlfilter-show-cycles") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/20220905074735.4513-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-09-08libperf evlist: Fix per-thread mmaps for multi-threaded targetsAdrian Hunter1-0/+50
The offending commit removed mmap_per_thread(), which did not consider the different set-output rules for per-thread mmaps i.e. in the per-thread case set-output is used for file descriptors of the same thread not the same cpu. This was not immediately noticed because it only happens with multi-threaded targets and we do not have a test for that yet. Reinstate mmap_per_thread() expanding it to cover also system-wide per-cpu events i.e. to continue to allow the mixing of per-thread and per-cpu mmaps. Debug messages (with -vv) show the file descriptors that are opened with sys_perf_event_open. New debug messages are added (needs -vvv) that show also which file descriptors are mmapped and which are redirected with set-output. In the per-cpu case (cpu != -1) file descriptors for the same CPU are set-output to the first file descriptor for that CPU. In the per-thread case (cpu == -1) file descriptors for the same thread are set-output to the first file descriptor for that thread. Example (process 17489 has 2 threads): Before (but with new debug prints): $ perf record --no-bpf-event -vvv --per-thread -p 17489 <SNIP> sys_perf_event_open: pid 17489 cpu -1 group_fd -1 flags 0x8 = 5 sys_perf_event_open: pid 17490 cpu -1 group_fd -1 flags 0x8 = 6 <SNIP> libperf: idx 0: mmapping fd 5 libperf: idx 0: set output fd 6 -> 5 failed to mmap with 22 (Invalid argument) After: $ perf record --no-bpf-event -vvv --per-thread -p 17489 <SNIP> sys_perf_event_open: pid 17489 cpu -1 group_fd -1 flags 0x8 = 5 sys_perf_event_open: pid 17490 cpu -1 group_fd -1 flags 0x8 = 6 <SNIP> libperf: mmap_per_thread: nr cpu values (may include -1) 1 nr threads 2 libperf: idx 0: mmapping fd 5 libperf: idx 1: mmapping fd 6 <SNIP> [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.018 MB perf.data (15 samples) ] Per-cpu example (process 20341 has 2 threads, same as above): $ perf record --no-bpf-event -vvv -p 20341 <SNIP> sys_perf_event_open: pid 20341 cpu 0 group_fd -1 flags 0x8 = 5 sys_perf_event_open: pid 20342 cpu 0 group_fd -1 flags 0x8 = 6 sys_perf_event_open: pid 20341 cpu 1 group_fd -1 flags 0x8 = 7 sys_perf_event_open: pid 20342 cpu 1 group_fd -1 flags 0x8 = 8 sys_perf_event_open: pid 20341 cpu 2 group_fd -1 flags 0x8 = 9 sys_perf_event_open: pid 20342 cpu 2 group_fd -1 flags 0x8 = 10 sys_perf_event_open: pid 20341 cpu 3 group_fd -1 flags 0x8 = 11 sys_perf_event_open: pid 20342 cpu 3 group_fd -1 flags 0x8 = 12 sys_perf_event_open: pid 20341 cpu 4 group_fd -1 flags 0x8 = 13 sys_perf_event_open: pid 20342 cpu 4 group_fd -1 flags 0x8 = 14 sys_perf_event_open: pid 20341 cpu 5 group_fd -1 flags 0x8 = 15 sys_perf_event_open: pid 20342 cpu 5 group_fd -1 flags 0x8 = 16 sys_perf_event_open: pid 20341 cpu 6 group_fd -1 flags 0x8 = 17 sys_perf_event_open: pid 20342 cpu 6 group_fd -1 flags 0x8 = 18 sys_perf_event_open: pid 20341 cpu 7 group_fd -1 flags 0x8 = 19 sys_perf_event_open: pid 20342 cpu 7 group_fd -1 flags 0x8 = 20 <SNIP> libperf: mmap_per_cpu: nr cpu values 8 nr threads 2 libperf: idx 0: mmapping fd 5 libperf: idx 0: set output fd 6 -> 5 libperf: idx 1: mmapping fd 7 libperf: idx 1: set output fd 8 -> 7 libperf: idx 2: mmapping fd 9 libperf: idx 2: set output fd 10 -> 9 libperf: idx 3: mmapping fd 11 libperf: idx 3: set output fd 12 -> 11 libperf: idx 4: mmapping fd 13 libperf: idx 4: set output fd 14 -> 13 libperf: idx 5: mmapping fd 15 libperf: idx 5: set output fd 16 -> 15 libperf: idx 6: mmapping fd 17 libperf: idx 6: set output fd 18 -> 17 libperf: idx 7: mmapping fd 19 libperf: idx 7: set output fd 20 -> 19 <SNIP> [ perf record: Woken up 7 times to write data ] [ perf record: Captured and wrote 0.020 MB perf.data (17 samples) ] Fixes: ae4f8ae16a078964 ("libperf evlist: Allow mixing per-thread and per-cpu mmaps") Reported-by: Tomáš Trnka <trnka@scm.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216441 Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20220905114209.8389-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-09-08io_uring/net: copy addr for zc on POLL_FIRSTPavel Begunkov1-3/+4
Every time we return from an issue handler and expect the request to be retried we should also setup it for async exec ourselves. Do that when we return on IORING_RECVSEND_POLL_FIRST in io_sendzc(), otherwise it'll re-read the address, which might be a surprise for the userspace. Fixes: 092aeedb750a9 ("io_uring: allow to pass addr into sendzc") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/ab1d0657890d6721339c56d2e161a4bba06f85d0.1662642013.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-08arm64/ptrace: Don't clear calling process' TIF_SME on OOMMark Brown1-2/+0
If allocating memory for the target SVE state in za_set() fails we clear TIF_SME for the ptracing task which is obviously not correct. If we are here we know that the target task already had neither TIF_SVE nor TIF_SME set since we only need to allocate if either the target had not used either SVE or SME and had no need to allocate state before or we just changed the vector length with vec_set_vector_length() which clears TIF_ for us on allocation failure so just remove the clear entirely. Reported-by: Wang ShaoBo <bobo.shaobowang@huawei.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220902132802.39682-1-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2022-09-08Merge tag 'asoc-fix-v6.0-rc4' of ↵Takashi Iwai13-131/+183
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.0 Quite a few fixes here, all driver specific and fairly small.
2022-09-08Merge tag 'net-6.0-rc5' of ↵Linus Torvalds82-420/+913
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from rxrpc, netfilter, wireless and bluetooth subtrees. Current release - regressions: - skb: export skb drop reaons to user by TRACE_DEFINE_ENUM - bluetooth: fix regression preventing ACL packet transmission Current release - new code bugs: - dsa: microchip: fix kernel oops on ksz8 switches - dsa: qca8k: fix NULL pointer dereference for of_device_get_match_data Previous releases - regressions: - netfilter: clean up hook list when offload flags check fails - wifi: mt76: fix crash in chip reset fail - rxrpc: fix ICMP/ICMP6 error handling - ice: fix DMA mappings leak - i40e: fix kernel crash during module removal Previous releases - always broken: - ipv6: sr: fix out-of-bounds read when setting HMAC data. - tcp: TX zerocopy should not sense pfmemalloc status - sch_sfb: don't assume the skb is still around after enqueueing to child - netfilter: drop dst references before setting - wifi: wilc1000: fix DMA on stack objects - rxrpc: fix an insufficiently large sglist in rxkad_verify_packet_2() - fec: use a spinlock to guard `fep->ptp_clk_on` Misc: - usb: qmi_wwan: add Quectel RM520N" * tag 'net-6.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (50 commits) sch_sfb: Also store skb len before calling child enqueue net: phy: lan87xx: change interrupt src of link_up to comm_ready net/smc: Fix possible access to freed memory in link clear net: ethernet: mtk_eth_soc: check max allowed hash in mtk_ppe_check_skb net: skb: export skb drop reaons to user by TRACE_DEFINE_ENUM net: ethernet: mtk_eth_soc: fix typo in __mtk_foe_entry_clear net: dsa: felix: access QSYS_TAG_CONFIG under tas_lock in vsc9959_sched_speed_set net: dsa: felix: disable cut-through forwarding for frames oversized for tc-taprio net: dsa: felix: tc-taprio intervals smaller than MTU should send at least one packet net: usb: qmi_wwan: add Quectel RM520N net: dsa: qca8k: fix NULL pointer dereference for of_device_get_match_data tcp: fix early ETIMEDOUT after spurious non-SACK RTO stmmac: intel: Simplify intel_eth_pci_remove() net: mvpp2: debugfs: fix memory leak when using debugfs_lookup() ipv6: sr: fix out-of-bounds read when setting HMAC data. bonding: accept unsolicited NA message bonding: add all node mcast address when slave up bonding: use unspecified address if no available link local address wifi: use struct_group to copy addresses wifi: mac80211_hwsim: check length for virtio packets ...
2022-09-08fs: only do a memory barrier for the first set_buffer_uptodate()Linus Torvalds1-0/+11
Commit d4252071b97d ("add barriers to buffer_uptodate and set_buffer_uptodate") added proper memory barriers to the buffer head BH_Uptodate bit, so that anybody who tests a buffer for being up-to-date will be guaranteed to actually see initialized state. However, that commit didn't _just_ add the memory barrier, it also ended up dropping the "was it already set" logic that the BUFFER_FNS() macro had. That's conceptually the right thing for a generic "this is a memory barrier" operation, but in the case of the buffer contents, we really only care about the memory barrier for the _first_ time we set the bit, in that the only memory ordering protection we need is to avoid anybody seeing uninitialized memory contents. Any other access ordering wouldn't be about the BH_Uptodate bit anyway, and would require some other proper lock (typically BH_Lock or the folio lock). A reader that races with somebody invalidating the buffer head isn't an issue wrt the memory ordering, it's a serialization issue. Now, you'd think that the buffer head operations don't matter in this day and age (and I certainly thought so), but apparently some loads still end up being heavy users of buffer heads. In particular, the kernel test robot reported that not having this bit access optimization in place caused a noticeable direct IO performance regression on ext4: fxmark.ssd_ext4_no_jnl_DWTL_54_directio.works/sec -26.5% regression although you presumably need a fast disk and a lot of cores to actually notice. Link: https://lore.kernel.org/all/Yw8L7HTZ%2FdE2%2Fo9C@xsang-OptiPlex-9020/ Reported-by: kernel test robot <oliver.sang@intel.com> Tested-by: Fengwei Yin <fengwei.yin@intel.com> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-09-08Merge tag 'efi-urgent-for-v6.0-1' of ↵Linus Torvalds3-25/+14
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "A couple of low-priority EFI fixes: - prevent the randstruct plugin from re-ordering EFI protocol definitions - fix a use-after-free in the capsule loader - drop unused variable" * tag 'efi-urgent-for-v6.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: capsule-loader: Fix use-after-free in efi_capsule_write efi/x86: libstub: remove unused variable efi: libstub: Disable struct randomization
2022-09-08drm/panfrost: devfreq: set opp to the recommended one to configure regulatorClément Péron1-0/+11
Enabling panfrost GPU OPP with dynamic regulator will make OPP responsible to enable and configure it. Unfortunately OPP configure and enable the regulator when an OPP is asked to be set, which is not the case during panfrost_devfreq_init(). This leave the regulator unconfigured and if no GPU load is triggered, no OPP is asked to be set which make the regulator framework switching it off during regulator_late_cleanup() without noticing and therefore make the board hang as any access to GPU memory space make bus locks up. Call dev_pm_opp_set_opp() with the recommend OPP in panfrost_devfreq_init() to enable the regulator, this will properly configure and enable the regulator and will avoid any switch off by regulator_late_cleanup(). Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Clément Péron <peron.clem@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906153034.153321-5-peron.clem@gmail.com
2022-09-08sch_sfb: Also store skb len before calling child enqueueToke Høiland-Jørgensen1-1/+2
Cong Wang noticed that the previous fix for sch_sfb accessing the queued skb after enqueueing it to a child qdisc was incomplete: the SFB enqueue function was also calling qdisc_qstats_backlog_inc() after enqueue, which reads the pkt len from the skb cb field. Fix this by also storing the skb len, and using the stored value to increment the backlog after enqueueing. Fixes: 9efd23297cca ("sch_sfb: Don't assume the skb is still around after enqueueing to child") Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> Acked-by: Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/20220905192137.965549-1-toke@toke.dk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-08net: phy: lan87xx: change interrupt src of link_up to comm_readyArun Ramadoss1-4/+54
Currently phy link up/down interrupt is enabled using the LAN87xx_INTERRUPT_MASK register. In the lan87xx_read_status function, phy link is determined using the T1_MODE_STAT_REG register comm_ready bit. comm_ready bit is set using the loc_rcvr_status & rem_rcvr_status. Whenever the phy link is up, LAN87xx_INTERRUPT_SOURCE link_up bit is set first but comm_ready bit takes some time to set based on local and remote receiver status. As per the current implementation, interrupt is triggered using link_up but the comm_ready bit is still cleared in the read_status function. So, link is always down. Initially tested with the shared interrupt mechanism with switch and internal phy which is working, but after implementing interrupt controller it is not working. It can fixed either by updating the read_status function to read from LAN87XX_INTERRUPT_SOURCE register or enable the interrupt mask for comm_ready bit. But the validation team recommends the use of comm_ready for link detection. This patch fixes by enabling the comm_ready bit for link_up in the LAN87XX_INTERRUPT_MASK_2 register (MISC Bank) and link_down in LAN87xx_INTERRUPT_MASK register. Fixes: 8a1b415d70b7 ("net: phy: added ethtool master-slave configuration support") Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220905152750.5079-1-arun.ramadoss@microchip.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-08drm/ttm: cleanup the resource of ghost objects after locking themChristian König1-5/+5
Otherwise lockdep will complain about cleaning up the bulk_move. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220907100051.570641-1-christian.koenig@amd.com Fixes: d91c411c744b ("drm/ttm: update bulk move object of ghost BO")
2022-09-08Merge tag 'amd-drm-fixes-6.0-2022-09-07' of ↵Dave Airlie6-9/+9
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.0-2022-09-07: amdgpu: - Firmware header fix - SMU 13.x fix - Debugfs memory leak fix - NBIO 7.7 fix - Firmware memory leak fix amdkfd: - Debug output fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908032332.5880-1-alexander.deucher@amd.com
2022-09-07drm/amdgpu: prevent toc firmware memory leakGuchun Chen1-2/+5
It's missed in psp fini. Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-07drm/amdgpu: correct doorbell range/size value for CSDMA_DOORBELL_RANGEYifan Zhang1-6/+0
current function mixes CSDMA_DOORBELL_RANGE and SDMA0_DOORBELL_RANGE range/size manipulation, while these 2 registers have difference size field mask. Remove range/size manipulation for SDMA0_DOORBELL_RANGE. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Xiaojian Du <Xiaojian.Du@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-07drm/amdkfd: print address in hex format rather than decimalYifan Zhang1-1/+1
Addresses should be printed in hex format. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-07drm/amd/display: fix memory leak when using debugfs_lookup()Greg Kroah-Hartman1-0/+1
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. Fix this up by properly calling dput(). Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: hersen wu <hersenxs.wu@amd.com> Cc: Wenjing Liu <wenjing.liu@amd.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Thelford Williams <tdwilliamsiv@gmail.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Yongzhi Liu <lyz_cs@pku.edu.cn> Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Cc: Bhanuprakash Modem <bhanuprakash.modem@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-07drm/amd/pm: add missing SetMGpuFanBoostLimitRpm mapping for SMU 13.0.7Evan Quan1-0/+1
Missing SetMGpuFanBoostLimitRpm mapping leads to loading failure for SMU 13.0.7. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-07drm/amd/amdgpu: add rlc_firmware_header_v2_4 to amdgpu_firmware_headerChengming Gui1-0/+1
Add missing structure to avoid incorrect size and version check. Signed-off-by: Chengming Gui <Jack.Gui@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-08powerpc/pseries: Fix plpks crash on non-pseriesMichael Ellerman1-1/+2
As reported[1] by Nathan, the recently added plpks driver will crash if it's built into the kernel and booted on a non-pseries machine, eg powernv: kernel BUG at arch/powerpc/kernel/syscall.c:39! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV ... NIP system_call_exception+0x90/0x3d0 LR system_call_common+0xec/0x250 Call Trace: 0xc0000000035c3e10 (unreliable) system_call_common+0xec/0x250 --- interrupt: c00 at plpar_hcall+0x38/0x60 NIP: c0000000000e4300 LR: c00000000202945c CTR: 0000000000000000 REGS: c0000000035c3e80 TRAP: 0c00 Not tainted (6.0.0-rc4) MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 28000284 XER: 00000000 ... NIP plpar_hcall+0x38/0x60 LR pseries_plpks_init+0x64/0x23c --- interrupt: c00 On powernv Linux is the hypervisor, so a hypercall just ends up going to the syscall path, which BUGs if the syscall (hypercall) didn't come from userspace. The fix is simply to not probe the plpks driver on non-pseries machines. [1] https://lore.kernel.org/linuxppc-dev/Yxe06fbq18Wv9y3W@dev-arch.thelio-3990X/ Fixes: 2454a7af0f2a ("powerpc/pseries: define driver for Platform KeyStore") Reported-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Tested-by: Dan Horák <dan@danny.cz> Reviewed-by: Dan Horák <dan@danny.cz> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20220907065038.1604504-1-mpe@ellerman.id.au
2022-09-07tools: Add new "test" taint to kernel-chktaintJoe Fradley1-0/+9
Commit c272612cb4a2 ("kunit: Taint the kernel when KUnit tests are run") added a new taint flag for when in-kernel tests run. This commit adds recognition of this new flag in kernel-chktaint. With this change the correct reason will be reported if the kernel is tainted because of a test run. Amended Commit log: Shuah Khan <skhan@linuxfoundation.org> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Joe Fradley <joefradley@google.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-09-07io_uring: recycle kbuf recycle on tw requeuePavel Begunkov1-0/+1
When we queue a request via tw for execution it's not going to be executed immediately, so when io_queue_async() hits IO_APOLL_READY and queues a tw but doesn't try to recycle/consume the buffer some other request may try to use the the buffer. Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/a19bc9e211e3184215a58e129b62f440180e9212.1662480490.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-07io_uring/kbuf: fix not advancing READV kbuf ringPavel Begunkov1-2/+6
When we don't recycle a selected ring buffer we should advance the head of the ring, so don't just skip io_kbuf_recycle() for IORING_OP_READV but adjust the ring. Fixes: 934447a603b22 ("io_uring: do not recycle buffer in READV") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Reviewed-by: Dylan Yudaken <dylany@fb.com> Link: https://lore.kernel.org/r/a6d85e2611471bcb5d5dcd63a8342077ddc2d73d.1662480490.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-07efi: capsule-loader: Fix use-after-free in efi_capsule_writeHyunwoo Kim1-24/+7
A race condition may occur if the user calls close() on another thread during a write() operation on the device node of the efi capsule. This is a race condition that occurs between the efi_capsule_write() and efi_capsule_flush() functions of efi_capsule_fops, which ultimately results in UAF. So, the page freeing process is modified to be done in efi_capsule_release() instead of efi_capsule_flush(). Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Link: https://lore.kernel.org/all/20220907102920.GA88602@ubuntu/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-09-07arch_topology: Make cluster topology span at least SMT CPUsYicong Yang1-1/+1
Currently cpu_clustergroup_mask() will return CPU mask if cluster span more or the same CPUs as cpu_coregroup_mask(). This will result topology borken on non-Cluster SMT machines when building with CONFIG_SCHED_CLUSTER=y. Test with: qemu-system-aarch64 -enable-kvm -machine virt \ -net none \ -cpu host \ -bios ./QEMU_EFI.fd \ -m 2G \ -smp 48,sockets=2,cores=12,threads=2 \ -kernel $Image \ -initrd $Rootfs \ -nographic -append "rdinit=init console=ttyAMA0 sched_verbose loglevel=8" We'll get below error: [ 3.084568] BUG: arch topology borken [ 3.084570] the SMT domain not a subset of the CLS domain Since cluster is a level higher than SMT, fix this by making cluster spans at least SMT CPUs. Fixes: bfcc4397435d ("arch_topology: Limit span of cpu_clustergroup_mask()") Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Ionela Voinescu <ionela.voinescu@arm.com> Cc: Greg KH <gregkh@linuxfoundation.org> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20220905122615.12946-1-yangyicong@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-07net/smc: Fix possible access to freed memory in link clearYacan Liu4-0/+13
After modifying the QP to the Error state, all RX WR would be completed with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context. Here is a crash example: BUG: unable to handle page fault for address: ffffffff8f220860 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> _raw_spin_lock_irqsave+0x30/0x40 mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib] smc_wr_rx_tasklet_fn+0x56/0xa0 [smc] tasklet_action_common.isra.21+0x66/0x100 __do_softirq+0xd5/0x29c asm_call_irq_on_stack+0x12/0x20 </IRQ> do_softirq_own_stack+0x37/0x40 irq_exit_rcu+0x9d/0xa0 sysvec_call_function_single+0x34/0x80 asm_sysvec_call_function_single+0x12/0x20 Fixes: bd4ad57718cc ("smc: initialize IB transport incl. PD, MR, QP, CQ, event, WR") Signed-off-by: Yacan Liu <liuyacan@corp.netease.com> Reviewed-by: Tony Lu <tonylu@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-07net: ethernet: mtk_eth_soc: check max allowed hash in mtk_ppe_check_skbLorenzo Bianconi1-0/+3
Even if max hash configured in hw in mtk_ppe_hash_entry is MTK_PPE_ENTRIES - 1, check theoretical OOB accesses in mtk_ppe_check_skb routine Fixes: c4f033d9e03e9 ("net: ethernet: mtk_eth_soc: rework hardware flow table management") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-07net: skb: export skb drop reaons to user by TRACE_DEFINE_ENUMMenglong Dong5-24/+87
As Eric reported, the 'reason' field is not presented when trace the kfree_skb event by perf: $ perf record -e skb:kfree_skb -a sleep 10 $ perf script ip_defrag 14605 [021] 221.614303: skb:kfree_skb: skbaddr=0xffff9d2851242700 protocol=34525 location=0xffffffffa39346b1 reason: The cause seems to be passing kernel address directly to TP_printk(), which is not right. As the enum 'skb_drop_reason' is not exported to user space through TRACE_DEFINE_ENUM(), perf can't get the drop reason string from the 'reason' field, which is a number. Therefore, we introduce the macro DEFINE_DROP_REASON(), which is used to define the trace enum by TRACE_DEFINE_ENUM(). With the help of DEFINE_DROP_REASON(), now we can remove the auto-generate that we introduced in the commit ec43908dd556 ("net: skb: use auto-generation to convert skb drop reason to string"), and define the string array 'drop_reasons'. Hmmmm...now we come back to the situation that have to maintain drop reasons in both enum skb_drop_reason and DEFINE_DROP_REASON. But they are both in dropreason.h, which makes it easier. After this commit, now the format of kfree_skb is like this: $ cat /tracing/events/skb/kfree_skb/format name: kfree_skb ID: 1524 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:void * skbaddr; offset:8; size:8; signed:0; field:void * location; offset:16; size:8; signed:0; field:unsigned short protocol; offset:24; size:2; signed:0; field:enum skb_drop_reason reason; offset:28; size:4; signed:0; print fmt: "skbaddr=%p protocol=%u location=%p reason: %s", REC->skbaddr, REC->protocol, REC->location, __print_symbolic(REC->reason, { 1, "NOT_SPECIFIED" }, { 2, "NO_SOCKET" } ...... Fixes: ec43908dd556 ("net: skb: use auto-generation to convert skb drop reason to string") Link: https://lore.kernel.org/netdev/CANn89i+bx0ybvE55iMYf5GJM48WwV1HNpdm9Q6t-HaEstqpCSA@mail.gmail.com/ Reported-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Menglong Dong <imagedong@tencent.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-07net: ethernet: mtk_eth_soc: fix typo in __mtk_foe_entry_clearLorenzo Bianconi1-1/+1
Set ib1 state to MTK_FOE_STATE_UNBIND in __mtk_foe_entry_clear routine. Fixes: 33fc42de33278 ("net: ethernet: mtk_eth_soc: support creating mac address based offload entries") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-07iommu/virtio: Fix interaction with VFIOJean-Philippe Brucker1-0/+11
Commit e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence") requires IOMMU drivers to advertise IOMMU_CAP_CACHE_COHERENCY, in order to be used by VFIO. Since VFIO does not provide to userspace the ability to maintain coherency through cache invalidations, it requires hardware coherency. Advertise the capability in order to restore VFIO support. The meaning of IOMMU_CAP_CACHE_COHERENCY also changed from "IOMMU can enforce cache coherent DMA transactions" to "IOMMU_CACHE is supported". While virtio-iommu cannot enforce coherency (of PCIe no-snoop transactions), it does support IOMMU_CACHE. We can distinguish different cases of non-coherent DMA: (1) When accesses from a hardware endpoint are not coherent. The host would describe such a device using firmware methods ('dma-coherent' in device-tree, '_CCA' in ACPI), since they are also needed without a vIOMMU. In this case mappings are created without IOMMU_CACHE. virtio-iommu doesn't need any additional support. It sends the same requests as for coherent devices. (2) When the physical IOMMU supports non-cacheable mappings. Supporting those would require a new feature in virtio-iommu, new PROBE request property and MAP flags. Device drivers would use a new API to discover this since it depends on the architecture and the physical IOMMU. (3) When the hardware supports PCIe no-snoop. It is possible for assigned PCIe devices to issue no-snoop transactions, and the virtio-iommu specification is lacking any mention of this. Arm platforms don't necessarily support no-snoop, and those that do cannot enforce coherency of no-snoop transactions. Device drivers must be careful about assuming that no-snoop transactions won't end up cached; see commit e02f5c1bb228 ("drm: disable uncached DMA optimization for ARM and arm64"). On x86 platforms, the host may or may not enforce coherency of no-snoop transactions with the physical IOMMU. But according to the above commit, on x86 a driver which assumes that no-snoop DMA is compatible with uncached CPU mappings will also work if the host enforces coherency. Although these issues are not specific to virtio-iommu, it could be used to facilitate discovery and configuration of no-snoop. This would require a new feature bit, PROBE property and ATTACH/MAP flags. Cc: stable@vger.kernel.org Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence") Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20220825154622.86759-1-jean-philippe@linaro.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-09-07iommu/vt-d: Fix lockdep splat due to klist iteration in atomic contextLu Baolu1-28/+19
With CONFIG_INTEL_IOMMU_DEBUGFS enabled, below lockdep splat are seen when an I/O fault occurs on a machine with an Intel IOMMU in it. DMAR: DRHD: handling fault status reg 3 DMAR: [DMA Write NO_PASID] Request device [00:1a.0] fault addr 0x0 [fault reason 0x05] PTE Write access is not set DMAR: Dump dmar0 table entries for IOVA 0x0 DMAR: root entry: 0x0000000127f42001 DMAR: context entry: hi 0x0000000000001502, low 0x000000012d8ab001 ================================ WARNING: inconsistent lock state 5.20.0-0.rc0.20220812git7ebfc85e2cd7.10.fc38.x86_64 #1 Not tainted -------------------------------- inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. rngd/1006 [HC1[1]:SC0[0]:HE0:SE1] takes: ff177021416f2d78 (&k->k_lock){?.+.}-{2:2}, at: klist_next+0x1b/0x160 {HARDIRQ-ON-W} state was registered at: lock_acquire+0xce/0x2d0 _raw_spin_lock+0x33/0x80 klist_add_tail+0x46/0x80 bus_add_device+0xee/0x150 device_add+0x39d/0x9a0 add_memory_block+0x108/0x1d0 memory_dev_init+0xe1/0x117 driver_init+0x43/0x4d kernel_init_freeable+0x1c2/0x2cc kernel_init+0x16/0x140 ret_from_fork+0x1f/0x30 irq event stamp: 7812 hardirqs last enabled at (7811): [<ffffffff85000e86>] asm_sysvec_apic_timer_interrupt+0x16/0x20 hardirqs last disabled at (7812): [<ffffffff84f16894>] irqentry_enter+0x54/0x60 softirqs last enabled at (7794): [<ffffffff840ff669>] __irq_exit_rcu+0xf9/0x170 softirqs last disabled at (7787): [<ffffffff840ff669>] __irq_exit_rcu+0xf9/0x170 The klist iterator functions using spin_*lock_irq*() but the klist insertion functions using spin_*lock(), combined with the Intel DMAR IOMMU driver iterating over klists from atomic (hardirq) context, where pci_get_domain_bus_and_slot() calls into bus_find_device() which iterates over klists. As currently there's no plan to fix the klist to make it safe to use in atomic context, this fixes the lockdep splat by avoid calling pci_get_domain_bus_and_slot() in the hardirq context. Fixes: 8ac0b64b9735 ("iommu/vt-d: Use pci_get_domain_bus_and_slot() in pgtable_walk()") Reported-by: Lennert Buytenhek <buytenh@wantstofly.org> Link: https://lore.kernel.org/linux-iommu/Yvo2dfpEh%2FWC+Wrr@wantstofly.org/ Link: https://lore.kernel.org/linux-iommu/YvyBdPwrTuHHbn5X@wantstofly.org/ Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20220819015949.4795-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-09-07iommu/vt-d: Fix recursive lock issue in iommu_flush_dev_iotlb()Lu Baolu1-16/+23
The per domain spinlock is acquired in iommu_flush_dev_iotlb(), which is possbile to be called in the interrupt context. For example, the drm-intel's CI system got completely blocked with below error: WARNING: inconsistent lock state 6.0.0-rc1-CI_DRM_11990-g6590d43d39b9+ #1 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/6/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff88810440d678 (&domain->lock){+.?.}-{2:2}, at: iommu_flush_dev_iotlb.part.61+0x23/0x80 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0xd3/0x310 _raw_spin_lock+0x2a/0x40 domain_update_iommu_cap+0x20b/0x2c0 intel_iommu_attach_device+0x5bd/0x860 __iommu_attach_device+0x18/0xe0 bus_iommu_probe+0x1f3/0x2d0 bus_set_iommu+0x82/0xd0 intel_iommu_init+0xe45/0x102a pci_iommu_init+0x9/0x31 do_one_initcall+0x53/0x2f0 kernel_init_freeable+0x18f/0x1e1 kernel_init+0x11/0x120 ret_from_fork+0x1f/0x30 irq event stamp: 162354 hardirqs last enabled at (162354): [<ffffffff81b59274>] _raw_spin_unlock_irqrestore+0x54/0x70 hardirqs last disabled at (162353): [<ffffffff81b5901b>] _raw_spin_lock_irqsave+0x4b/0x50 softirqs last enabled at (162338): [<ffffffff81e00323>] __do_softirq+0x323/0x48e softirqs last disabled at (162349): [<ffffffff810c1588>] irq_exit_rcu+0xb8/0xe0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&domain->lock); <Interrupt> lock(&domain->lock); *** DEADLOCK *** 1 lock held by swapper/6/0: This coverts the spin_lock/unlock() into the irq save/restore varieties to fix the recursive locking issues. Fixes: ffd5869d93530 ("iommu/vt-d: Replace spin_lock_irqsave() with spin_lock()") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20220817025650.3253959-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-09-07iommu/vt-d: Correctly calculate sagaw value of IOMMULu Baolu1-3/+25
The Intel IOMMU driver possibly selects between the first-level and the second-level translation tables for DMA address translation. However, the levels of page-table walks for the 4KB base page size are calculated from the SAGAW field of the capability register, which is only valid for the second-level page table. This causes the IOMMU driver to stop working if the hardware (or the emulated IOMMU) advertises only first-level translation capability and reports the SAGAW field as 0. This solves the above problem by considering both the first level and the second level when calculating the supported page table levels. Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level") Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20220817023558.3253263-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-09-07iommu/vt-d: Fix kdump kernels boot failure with scalable modeLu Baolu2-59/+50
The translation table copying code for kdump kernels is currently based on the extended root/context entry formats of ECS mode defined in older VT-d v2.5, and doesn't handle the scalable mode formats. This causes the kexec capture kernel boot failure with DMAR faults if the IOMMU was enabled in scalable mode by the previous kernel. The ECS mode has already been deprecated by the VT-d spec since v3.0 and Intel IOMMU driver doesn't support this mode as there's no real hardware implementation. Hence this converts ECS checking in copying table code into scalable mode. The existing copying code consumes a bit in the context entry as a mark of copied entry. It needs to work for the old format as well as for the extended context entries. As it's hard to find such a common bit for both legacy and scalable mode context entries. This replaces it with a per- IOMMU bitmap. Fixes: 7373a8cc38197 ("iommu/vt-d: Setup context and enable RID2PASID support") Cc: stable@vger.kernel.org Reported-by: Jerry Snitselaar <jsnitsel@redhat.com> Tested-by: Wen Jin <wen.jin@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20220817011035.3250131-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-09-07MIPS: OCTEON: irq: Fix octeon_irq_force_ciu_mapping()Alexander Sverdlin1-0/+10
For irq_domain_associate() to work the virq descriptor has to be pre-allocated in advance. Otherwise the following happens: WARNING: CPU: 0 PID: 0 at .../kernel/irq/irqdomain.c:527 irq_domain_associate+0x298/0x2e8 error: virq128 is not allocated Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.78-... #1 ... Call Trace: [<ffffffff801344c4>] show_stack+0x9c/0x130 [<ffffffff80769550>] dump_stack+0x90/0xd0 [<ffffffff801576d0>] __warn+0x118/0x130 [<ffffffff80157734>] warn_slowpath_fmt+0x4c/0x70 [<ffffffff801b83c0>] irq_domain_associate+0x298/0x2e8 [<ffffffff80a43bb8>] octeon_irq_init_ciu+0x4c8/0x53c [<ffffffff80a76cbc>] of_irq_init+0x1e0/0x388 [<ffffffff80a452cc>] init_IRQ+0x4c/0xf4 [<ffffffff80a3cc00>] start_kernel+0x404/0x698 Use irq_alloc_desc_at() to avoid the above problem. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2022-09-07MIPS: octeon: Get rid of preprocessor directives around RESERVE32Alexander Sverdlin2-20/+11
Some of them were pointless because CONFIG_CAVIUM_RESERVE32 is now always defined, some were not enough (Yu Zhao reported "Failed to allocate CAVIUM_RESERVE32 memory area" error). Removing the directives allows for compiler coverage of RESERVE32 code and replacing one of [always-true] "ifdef" with a compiler conditional fixes the [cosmetic] error message. Fixes: 3e3114ac460e ("MIPS: Introduce CAVIUM_RESERVE32 Kconfig option") Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2022-09-07Merge branch 'dsa-felix-fixes'David S. Miller1-49/+112
Vladimir Oltean says: ==================== Fixes for Felix DSA driver calculation of tc-taprio guard bands This series fixes some bugs which are not quite new, but date from v5.13 when static guard bands were enabled by Michael Walle to prevent tc-taprio overruns. The investigation started when Xiaoliang asked privately what is the expected max SDU for a traffic class when its minimum gate interval is 10 us. The answer, as it turns out, is not an L1 size of 1250 octets, but 1245 octets, since otherwise, the switch will not consider frames for egress scheduling, because the static guard band is exactly as large as the time interval. The switch needs a minimum of 33 ns outside of the guard band to consider a frame for scheduling, and the reduction of the max SDU by 5 provides exactly for that. The fix for that (patch 1/3) is relatively small, but during testing, it became apparent that cut-through forwarding prevents oversized frame dropping from working properly. This is solved through the larger patch 2/3. Finally, patch 3/3 fixes one more tc-taprio locking problem found through code inspection. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-07net: dsa: felix: access QSYS_TAG_CONFIG under tas_lock in ↵Vladimir Oltean1-2/+2
vsc9959_sched_speed_set The read-modify-write of QSYS_TAG_CONFIG from vsc9959_sched_speed_set() runs unlocked with respect to the other functions that access it, which are vsc9959_tas_guard_bands_update(), vsc9959_qos_port_tas_set() and vsc9959_tas_clock_adjust(). All the others are under ocelot->tas_lock, so move the vsc9959_sched_speed_set() access under that lock as well, to resolve the concurrency. Fixes: 55a515b1f5a9 ("net: dsa: felix: drop oversized frames with tc-taprio instead of hanging the port") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-07net: dsa: felix: disable cut-through forwarding for frames oversized for ↵Vladimir Oltean1-43/+79
tc-taprio Experimentally, it looks like when QSYS_QMAXSDU_CFG_7 is set to 605, frames even way larger than 601 octets are transmitted even though these should be considered as oversized, according to the documentation, and dropped. Since oversized frame dropping depends on frame size, which is only known at the EOF stage, and therefore not at SOF when cut-through forwarding begins, it means that the switch cannot take QSYS_QMAXSDU_CFG_* into consideration for traffic classes that are cut-through. Since cut-through forwarding has no UAPI to control it, and the driver enables it based on the mantra "if we can, then why not", the strategy is to alter vsc9959_cut_through_fwd() to take into consideration which tc's have oversize frame dropping enabled, and disable cut-through for them. Then, from vsc9959_tas_guard_bands_update(), we re-trigger the cut-through determination process. There are 2 strategies for vsc9959_cut_through_fwd() to determine whether a tc has oversized dropping enabled or not. One is to keep a bit mask of traffic classes per port, and the other is to read back from the hardware registers (a non-zero value of QSYS_QMAXSDU_CFG_* means the feature is enabled). We choose reading back from registers, because struct ocelot_port is shared with drivers (ocelot, seville) that don't support either cut-through nor tc-taprio, and we don't have a felix specific extension of struct ocelot_port. Furthermore, reading registers from the Felix hardware is quite cheap, since they are memory-mapped. Fixes: 55a515b1f5a9 ("net: dsa: felix: drop oversized frames with tc-taprio instead of hanging the port") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-07net: dsa: felix: tc-taprio intervals smaller than MTU should send at least ↵Vladimir Oltean1-4/+31
one packet The blamed commit broke tc-taprio schedules such as this one: tc qdisc replace dev $swp1 root taprio \ num_tc 8 \ map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ base-time 0 \ sched-entry S 0x7f 990000 \ sched-entry S 0x80 10000 \ flags 0x2 because the gate entry for TC 7 (S 0x80 10000 ns) now has a static guard band added earlier than its 'gate close' event, such that packet overruns won't occur in the worst case of the largest packet possible. Since guard bands are statically determined based on the per-tc QSYS_QMAXSDU_CFG_* with a fallback on the port-based QSYS_PORT_MAX_SDU, we need to discuss what happens with TC 7 depending on kernel version, since the driver, prior to commit 55a515b1f5a9 ("net: dsa: felix: drop oversized frames with tc-taprio instead of hanging the port"), did not touch QSYS_QMAXSDU_CFG_*, and therefore relied on QSYS_PORT_MAX_SDU. 1 (before vsc9959_tas_guard_bands_update): QSYS_PORT_MAX_SDU defaults to 1518, and at gigabit this introduces a static guard band (independent of packet sizes) of 12144 ns, plus QSYS::HSCH_MISC_CFG.FRM_ADJ (bit time of 20 octets => 160 ns). But this is larger than the time window itself, of 10000 ns. So, the queue system never considers a frame with TC 7 as eligible for transmission, since the gate practically never opens, and these frames are forever stuck in the TX queues and hang the port. 2 (after vsc9959_tas_guard_bands_update): Under the sole goal of enabling oversized frame dropping, we make an effort to set QSYS_QMAXSDU_CFG_7 to 1230 bytes. But QSYS_QMAXSDU_CFG_7 plays one more role, which we did not take into account: per-tc static guard band, expressed in L2 byte time (auto-adjusted for FCS and L1 overhead). There is a discrepancy between what the driver thinks (that there is no guard band, and 100% of min_gate_len[tc] is available for egress scheduling) and what the hardware actually does (crops the equivalent of QSYS_QMAXSDU_CFG_7 ns out of min_gate_len[tc]). In practice, this means that the hardware thinks it has exactly 0 ns for scheduling tc 7. In both cases, even minimum sized Ethernet frames are stuck on egress rather than being considered for scheduling on TC 7, even if they would fit given a proper configuration. Considering the current situation, with vsc9959_tas_guard_bands_update(), frames between 60 octets and 1230 octets in size are not eligible for oversized dropping (because they are smaller than QSYS_QMAXSDU_CFG_7), but won't be considered as eligible for scheduling either, because the min_gate_len[7] (10000 ns) minus the guard band determined by QSYS_QMAXSDU_CFG_7 (1230 octets * 8 ns per octet == 9840 ns) minus the guard band auto-added for L1 overhead by QSYS::HSCH_MISC_CFG.FRM_ADJ (20 octets * 8 ns per octet == 160 octets) leaves 0 ns for scheduling in the queue system proper. Investigating the hardware behavior, it becomes apparent that the queue system needs precisely 33 ns of 'gate open' time in order to consider a frame as eligible for scheduling to a tc. So the solution to this problem is to amend vsc9959_tas_guard_bands_update(), by giving the per-tc guard bands less space by exactly 33 ns, just enough for one frame to be scheduled in that interval. This allows the queue system to make forward progress for that port-tc, and prevents it from hanging. Fixes: 297c4de6f780 ("net: dsa: felix: re-enable TAS guard band mode") Reported-by: Xiaoliang Yang <xiaoliang.yang_1@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-07s390/smp: enforce lowcore protection on CPU restartAlexander Gordeev1-1/+1
As result of commit 915fea04f932 ("s390/smp: enable DAT before CPU restart callback is called") the low-address protection bit gets mistakenly unset in control register 0 save area of the absolute zero memory. That area is used when manual PSW restart happened to hit an offline CPU. In this case the low-address protection for that CPU will be dropped. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Fixes: 915fea04f932 ("s390/smp: enable DAT before CPU restart callback is called") Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2022-09-07s390/boot: fix absolute zero lowcore corruption on bootAlexander Gordeev2-1/+2
Crash dump always starts on CPU0. In case CPU0 is offline the prefix page is not installed and the absolute zero lowcore is used. However, struct lowcore::mcesad is never assigned and stays zero. That leads to __machine_kdump() -> save_vx_regs() call silently stores vector registers to the absolute lowcore at 0x11b0 offset. Fixes: a62bc0739253 ("s390/kdump: add support for vector extension") Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2022-09-07ALSA: usb-audio: Clear fixed clock rate at closing EPTakashi Iwai1-0/+2
The recent commit c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") tries to manage the clock rate shared by several endpoints. This was intended for avoiding the unmatched rate by a different endpoint, but unfortunately, it introduced a regression for PulseAudio and pipewire, too; those applications try to probe the multiple possible rates (44.1k and 48kHz) and setting up the normal rate fails but only the last rate is applied. The cause is that the last sample rate is still left to the clock reference even after closing the endpoint, and this value is still used at the next open. It happens only when applications set up via PCM prepare but don't start/stop the stream; the rate is reset when the stream is stopped, but it's not cleared at close. This patch addresses the issue above, simply by clearing the rate set in the clock reference at the last close of each endpoint. Fixes: c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") Reported-by: Jason A. Donenfeld <Jason@zx2c4.com> Tested-by: Jason A. Donenfeld <Jason@zx2c4.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/all/YxXIWv8dYmg1tnXP@zx2c4.com/ Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2620 Link: https://lore.kernel.org/r/20220907100421.6443-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-07iommu/amd: use full 64-bit value in build_completion_wait()John Sperbeck1-1/+2
We started using a 64 bit completion value. Unfortunately, we only stored the low 32-bits, so a very large completion value would never be matched in iommu_completion_wait(). Fixes: c69d89aff393 ("iommu/amd: Use 4K page for completion wait write-back semaphore") Signed-off-by: John Sperbeck <jsperbeck@google.com> Link: https://lore.kernel.org/r/20220801192229.3358786-1-jsperbeck@google.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-09-07dma-mapping: mark dma_supported staticChristoph Hellwig2-7/+1
Now that the remaining users in drivers are gone, this function can be marked static. Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-09-07swiotlb: fix a typoChao Gao1-1/+1
"overwirte" isn't a word. It should be "overwrite". Signed-off-by: Chao Gao <chao.gao@intel.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Powered by cgit, Gruvboxed by Blaster4385.