aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2024-02-23Merge tag 'parisc-for-6.8-rc6' of ↵HEADmasterLinus Torvalds4-18/+9
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc architecture fixes from Helge Deller: "Fixes CPU hotplug, the parisc stack unwinder and two possible build errors in kprobes and ftrace area: - Fix CPU hotplug - Fix unaligned accesses and faults in stack unwinder - Fix potential build errors by always including asm-generic/kprobes.h - Fix build bug by add missing CONFIG_DYNAMIC_FTRACE check" * tag 'parisc-for-6.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix stack unwinder parisc/kprobes: always include asm-generic/kprobes.h parisc/ftrace: add missing CONFIG_DYNAMIC_FTRACE check Revert "parisc: Only list existing CPUs in cpu_possible_mask"
2024-02-23Merge tag 'arm-fixes-6.8-2' of ↵Linus Torvalds69-134/+126
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull arm and RISC-V SoC fixes from Arnd Bergmann: "The Rockchip and IMX8 platforms get a number of fixes for dts files in order to address some misconfigurations, including a regression for USB-C support on some boards. The other dts fixes are part of a series by Rob Herring to clean up another class of dtc compiler warnings across all platforms, with a few others helping out as well. With this, we can enable the warning for the coming merge window without introducing regressions. Conor Dooley has collected fixes for RISC-V platforms, both for the dts files and for platofrm specific drivers. The ep93xx platform gets a regression for for its gpio descriptors" * tag 'arm-fixes-6.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (28 commits) ARM: dts: renesas: rcar-gen2: Add missing #interrupt-cells to DA9063 nodes cache: ax45mp_cache: Align end size to cache boundary in ax45mp_dma_cache_wback() arm64: dts: qcom: Fix interrupt-map cell sizes arm: dts: Fix dtc interrupt_map warnings arm64: dts: Fix dtc interrupt_provider warnings arm: dts: Fix dtc interrupt_provider warnings arm64: dts: freescale: Disable interrupt_map check ARM: ep93xx: Add terminator to gpiod_lookup_table riscv: dts: sifive: add missing #interrupt-cells to pmic arm64: dts: rockchip: Correct Indiedroid Nova GPIO Names arm64: dts: rockchip: Drop interrupts property from rk3328 pwm-rockchip node arm64: dts: rockchip: set num-cs property for spi on px30 arm64: dts: rockchip: minor rk3588 whitespace cleanup riscv: dts: starfive: replace underscores in node names bus: imx-weim: fix valid range check Revert "arm64: dts: imx8mn-var-som-symphony: Describe the USB-C connector" Revert "arm64: dts: imx8mp-dhcom-pdk3: Describe the USB-C connector" arm64: dts: tqma8mpql: fix audio codec iov-supply arm64: dts: rockchip: drop unneeded status from rk3588-jaguar gpio-leds ARM: dts: rockchip: Drop interrupts property from pwm-rockchip nodes ...
2024-02-23Merge tag 'arm64-fixes' of ↵Linus Torvalds5-13/+30
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "A simple fix to a definition in the CXL PMU driver, a couple of patches to restore SME control registers on the resume path (since Arm's fast model now clears them) and a revert for our jump label asm constraints after Geert noticed they broke the build with GCC 5.5. There was then the ensuing discussion about raising the minimum GCC (and corresponding binutils) versions at [1], but for now we'll keep things working as they were until that goes ahead. - Revert fix to jump label asm constraints, as it regresses the build with some GCC 5.5 toolchains. - Restore SME control registers when resuming from suspend - Fix incorrect filter definition in CXL PMU driver" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64/sme: Restore SMCR_EL1.EZT0 on exit from suspend arm64/sme: Restore SME registers on exit from suspend Revert "arm64: jump_label: use constraints "Si" instead of "i"" perf: CXL: fix CPMU filter value mask length
2024-02-23Merge tag 's390-6.8-3' of ↵Linus Torvalds6-20/+10
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Heiko Carstens: - Fix invalid -EBUSY on ccw_device_start() which can lead to failing device initialization - Add missing multiplication by 8 in __iowrite64_copy() to get the correct byte length before calling zpci_memcpy_toio() - Various config updates * tag 's390-6.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/cio: fix invalid -EBUSY on ccw_device_start s390: use the correct count for __iowrite64_copy() s390/configs: update default configurations s390/configs: enable INIT_STACK_ALL_ZERO in all configurations s390/configs: provide compat topic configuration target
2024-02-23Merge tag 'mm-hotfixes-stable-2024-02-22-15-02' of ↵Linus Torvalds17-25/+147
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "A batch of MM (and one non-MM) hotfixes. Ten are cc:stable and the remainder address post-6.7 issues or aren't considered appropriate for backporting" * tag 'mm-hotfixes-stable-2024-02-22-15-02' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: kasan: guard release_free_meta() shadow access with kasan_arch_is_ready() mm/damon/lru_sort: fix quota status loss due to online tunings mm/damon/reclaim: fix quota stauts loss due to online tunings MAINTAINERS: mailmap: update Shakeel's email address mm/damon/sysfs-schemes: handle schemes sysfs dir removal before commit_schemes_quota_goals mm: memcontrol: clarify swapaccount=0 deprecation warning mm/memblock: add MEMBLOCK_RSRV_NOINIT into flagname[] array mm/zswap: invalidate duplicate entry when !zswap_enabled lib/Kconfig.debug: TEST_IOV_ITER depends on MMU mm/swap: fix race when skipping swapcache mm/swap_state: update zswap LRU's protection range with the folio locked selftests/mm: uffd-unit-test check if huge page size is 0 mm/damon/core: check apply interval in damon_do_apply_schemes() mm: zswap: fix missing folio cleanup in writeback race path
2024-02-23Merge tag 'for-6.8/dm-fixes-2' of ↵Linus Torvalds4-38/+256
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mike Snitzer: - Stable fixes for 3 DM targets (integrity, verity and crypt) to address systemic failure that can occur if user provided pages map to the same block. - Fix DM crypt to not allow modifying data that being encrypted for authenticated encryption. - Fix DM crypt and verity targets to align their respective bvec_iter struct members to avoid the need for byte level access (due to __packed attribute) that is costly on some arches (like RISC). * tag 'for-6.8/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm-crypt, dm-integrity, dm-verity: bump target version dm-verity, dm-crypt: align "struct bvec_iter" correctly dm-crypt: recheck the integrity tag after a failure dm-crypt: don't modify the data when using authenticated encryption dm-verity: recheck the hash after a failure dm-integrity: recheck the integrity tag after a failure
2024-02-23Merge tag 'drm-fixes-2024-02-23' of git://anongit.freedesktop.org/drm/drmLinus Torvalds40-190/+183
Pull drm fixes from Dave Airlie: "This is the weekly drm fixes. Non-drivers there is a fbdev/sparc fix, syncobj, ttm and buddy fixes. On the driver side, ivpu, meson, i915 have a small fix each. Then amdgpu and xe have a bunch. Nouveau has some minor uapi additions to give userspace some useful info along with a Kconfig change to allow the new GSP firmware paths to be used by default on the GPUs it supports. Seems about the usual amount for this time of release cycle. fbdev: - fix sparc undefined reference syncobj: - fix sync obj fence waiting - handle NULL fence in syncobj eventfd code ttm: - fix invalid free buddy: - fix list handling - fix 32-bit build meson: - don't remove bridges from other drivers nouveau: - fix build warnings - add two minor info parameters - add a Kconfig to allow GSP by default on some GPUs ivpu: - allow fw to do initial tile config i915: - fix TV mode amdgpu: - Suspend/resume fixes - Backlight error fix - DCN 3.5 fixes - Misc fixes xe: - Remove support for persistent exec_queues - Drop a reduntant sysfs newline printout - A three-patch fix for a VM_BIND rebind optimization path - Fix a modpost warning on an xe KUNIT module" * tag 'drm-fixes-2024-02-23' of git://anongit.freedesktop.org/drm/drm: (27 commits) nouveau: add an ioctl to report vram usage nouveau: add an ioctl to return vram bar size. nouveau/gsp: add kconfig option to enable GSP paths by default drm/amdgpu: Fix the runtime resume failure issue drm/amd/display: fix null-pointer dereference on edid reading drm/amd/display: Fix memory leak in dm_sw_fini() drm/amd/display: fix input states translation error for dcn35 & dcn351 drm/amd/display: Fix potential null pointer dereference in dc_dmub_srv drm/amd/display: Only allow dig mapping to pwrseq in new asic drm/amd/display: adjust few initialization order in dm drm/syncobj: handle NULL fence in syncobj_eventfd_entry_func drm/syncobj: call drm_syncobj_fence_add_wait when WAIT_AVAILABLE flag is set drm/ttm: Fix an invalid freeing on already freed page in error path sparc: Fix undefined reference to fb_is_primary_device drm/xe: Fix modpost warning on xe_mocs kunit module drm/xe/xe_gt_idle: Drop redundant newline in name drm/xe: Return 2MB page size for compact 64k PTEs drm/xe: Add XE_VMA_PTE_64K VMA flag drm/xe: Fix xe_vma_set_pte_size drm/xe/uapi: Remove support for persistent exec_queues ...
2024-02-23Merge tag 'ata-6.8-rc6' of ↵Linus Torvalds3-76/+122
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fixes from Niklas Cassel: - Do not try to set a sleeping device to standby. Sleep is a deeper sleep state than standby, and needs a reset to wake up the drive. A system resume will reset the port. Sending a command other than reset to a sleeping device is not wise, as the command will timeout (Damien Le Moal) - Do not try to put a device to standby twice during system shutdown. ata_dev_power_set_standby() is currently called twice during shutdown, once after the scsi device is removed, and another when ata_pci_shutdown_one() executes. Modify ata_dev_power_set_standby() to do nothing if the device is already in standby (Damien Le Moal) - Add a quirk for ASM1064 to fixup the number of implemented ports. We probe all ports that the hardware reports to be implemented. Probing ports that are not implemented causes significantly increased boot time (Andrey Jr. Melnikov) - Fix error handling for the ahci_ceva driver. Ensure that the ahci_ceva driver does a proper cleanup of its resources in the error path (Radhey Shyam Pandey) * tag 'ata-6.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: libata-core: Do not call ata_dev_power_set_standby() twice ata: ahci_ceva: fix error handling for Xilinx GT PHY support ahci: asm1064: correct count of reported ports ata: libata-core: Do not try to set sleeping devices to standby
2024-02-23Merge tag 'gpio-fixes-for-v6.8-rc6' of ↵Linus Torvalds1-0/+5
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fix from Bartosz Golaszewski: - fix a use-case where no pins are mapped to GPIOs in gpiochip_generic_config() * tag 'gpio-fixes-for-v6.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpiolib: Handle no pin_ranges in gpiochip_generic_config()
2024-02-23Merge tag 'hwmon-for-v6.8-rc6' of ↵Linus Torvalds1-2/+12
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fix from Guenter Roeck: "Fix a global-out-of-bounds bug in nct6775 driver" * tag 'hwmon-for-v6.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (nct6775) Fix access to temperature configuration registers
2024-02-23Merge tag 'renesas-fixes-for-v6.8-tag1' of ↵Arnd Bergmann8-0/+8
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes Renesas fixes for v6.8 - Add missing #interrupt-cells to DA9063 nodes. * tag 'renesas-fixes-for-v6.8-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: ARM: dts: renesas: rcar-gen2: Add missing #interrupt-cells to DA9063 nodes Link: https://lore.kernel.org/r/cover.1708597150.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-23Merge tag 'riscv-dt-fixes-for-v6.8-rc6' of ↵Arnd Bergmann3-8/+9
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes RISC-V Devicetree fixes for v6.8-rc6 Two fixes for W=2 issues in devicetrees, which should constitute fixes for all reasonable-to-fix W=2 problems on RISC-V. The others are caused by standard USB and MMC property names containing underscores that are not likely to ever change. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-dt-fixes-for-v6.8-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: riscv: dts: sifive: add missing #interrupt-cells to pmic riscv: dts: starfive: replace underscores in node names Link: https://lore.kernel.org/r/20240221-foil-glade-09dbf1aa3fe2@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-23Merge tag 'riscv-soc-drivers-fixes-for-v6.8-rc6' of ↵Arnd Bergmann1-1/+1
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes RISC-V SoC driver fixes for v6.8-rc6 A fix for a kconfig symbol whose help text has been unhelpful since its introduction. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-soc-drivers-fixes-for-v6.8-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: soc: microchip: Fix POLARFIRE_SOC_SYS_CTRL input prompt Link: https://lore.kernel.org/r/20240221-irate-outrage-cf7f96f83074@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-23Merge tag 'riscv-firmware-fixes-for-v6.8-rc6' of ↵Arnd Bergmann1-1/+1
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes Microchip firmware driver fixes for v6.8-rc6 A single fix for me incorrectly using sizeof(). Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-firmware-fixes-for-v6.8-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: firmware: microchip: fix wrong sizeof argument Link: https://lore.kernel.org/r/20240221-recognize-dust-4bb575f4e67b@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-23Merge tag 'riscv-cache-fixes-for-v6.8-rc6' of ↵Arnd Bergmann1-0/+4
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes RISC-V Cache driver fixes for v6.8-rc6 A single fix for an inconsistency reported during CIP review by Pavel in the newly added ax45mp cache driver. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-cache-fixes-for-v6.8-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: cache: ax45mp_cache: Align end size to cache boundary in ax45mp_dma_cache_wback() Link: https://lore.kernel.org/r/20240221-keenness-handheld-b930aaa77708@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-23nouveau: add an ioctl to report vram usageDave Airlie2-0/+12
This reports the currently used vram allocations. userspace using this has been proposed for nvk, but it's a rather trivial uapi addition. Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Notes: Fixed-by: f7916c47f66d ("nouveau: report byte usage in VRAM usage.") # v6.8-rc7
2024-02-23nouveau: add an ioctl to return vram bar size.Dave Airlie2-0/+11
This returns the BAR resources size so userspace can make decisions based on rebar support. userspace using this has been proposed for nvk, but it's a rather trivial uapi addition. Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2024-02-23nouveau/gsp: add kconfig option to enable GSP paths by defaultDave Airlie2-1/+13
Turing and Ampere will continue to use the old paths by default, but we should allow distros to decide what the policy is. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240214040632.661069-1-airlied@gmail.com Notes: Lore: https://lore.kernel.org/r/20240214034036.660921-1-airlied@gmail.com # dri-devel, nouveau Lore: https://lore.kernel.org/r/20240214040632.661069-1-airlied@gmail.com # dri-devel, nouveau
2024-02-23Merge tag 'drm-xe-fixes-2024-02-22' of ↵Dave Airlie13-103/+28
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes UAPI Changes: - Remove support for persistent exec_queues - Drop a reduntant sysfs newline printout Cross-subsystem Changes: Core Changes: Driver Changes: - A three-patch fix for a VM_BIND rebind optimization path - Fix a modpost warning on an xe KUNIT module Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZdcsNrxdWMMM417v@fedora
2024-02-23Merge tag 'amd-drm-fixes-6.8-2024-02-22' of ↵Dave Airlie9-53/+71
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.8-2024-02-22: amdgpu: - Suspend/resume fixes - Backlight error fix - DCN 3.5 fixes - Misc fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240222195338.5809-1-alexander.deucher@amd.com
2024-02-23Merge tag 'drm-intel-fixes-2024-02-22' of ↵Dave Airlie2-10/+10
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fixup for TV mode Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZdcwT9kltvEgJZZE@jlahtine-mobl.ger.corp.intel.com
2024-02-23Merge tag 'drm-misc-fixes-2024-02-22' of ↵Dave Airlie12-24/+39
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes A list handling fix and 64bit division on 32bit platform fix for the drm/buddy allocator, a cast warning and an initialization fix for nouveau, a bridge handling fix for meson, an initialisation fix for ivpu, a SPARC build fix for fbdev, a double-free fix for ttm, and two fence handling fixes for syncobj. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/gl2antuifidtzn3dfm426p7xwh5fxj23behagwh26owfnosh2w@gqoa7vj5prnh
2024-02-22Merge tag 'block-6.8-2024-02-22' of git://git.kernel.dk/linuxLinus Torvalds5-68/+54
Pull block fixes from Jens Axboe: "Mostly just fixlets for md, but also a sed-opal parsing fix" * tag 'block-6.8-2024-02-22' of git://git.kernel.dk/linux: block: sed-opal: handle empty atoms when parsing response md: Don't suspend the array for interrupted reshape md: Don't register sync_thread for reshape directly md: Make sure md_do_sync() will set MD_RECOVERY_DONE md: Don't ignore read-only array in md_check_recovery() md: Don't ignore suspended array in md_check_recovery() md: Fix missing release of 'active_io' for flush
2024-02-22Merge tag 'for-linus-iommufd' of ↵Linus Torvalds7-63/+210
git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd Pull iommufd fixes from Jason Gunthorpe: - Fix dirty tracking bitmap collection when using reporting bitmaps that are not neatly aligned to u64's or match the IO page table radix tree layout. - Add self tests to cover the cases that were found to be broken. - Add missing enforcement of invalidation type in the uapi. - Fix selftest config generation * tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd: selftests/iommu: fix the config fragment iommufd: Reject non-zero data_type if no data_len is provided iommufd/iova_bitmap: Consider page offset for the pages to be pinned iommufd/selftest: Add mock IO hugepages tests iommufd/selftest: Hugepage mock domain support iommufd/selftest: Refactor mock_domain_read_and_clear_dirty() iommufd/selftest: Refactor dirty bitmap tests iommufd/iova_bitmap: Handle recording beyond the mapped pages iommufd/selftest: Test u64 unaligned bitmaps iommufd/iova_bitmap: Switch iova_bitmap::bitmap to an u8 array iommufd/iova_bitmap: Bounds check mapped::pages access
2024-02-22Merge tag 'platform-drivers-x86-v6.8-3' of ↵Linus Torvalds13-97/+182
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Hans de Goede: "Regression fixes: - Fix INT0002 vGPIO events no longer working after 6.8 ACPI SCI changes - AMD-PMF: Fix laptops (e.g. Framework 13 AMD) hanging on suspend - x86-android-tablets: Fix touchscreen no longer working on Lenovo Yogabook - x86-android-tablets: Fix serdev instantiation regression - intel-vbtn: Fix ThinkPad X1 Tablet Gen2 no longer suspending Bug fixes: - think-lmi: Fix changing BIOS settings on Lenovo workstations - touchscreen_dmi: Fix Hi8 Air touchscreen data sometimes missing - AMD-PMF: Fix Smart PC support not working after suspend/resume Other misc small fixes" * tag 'platform-drivers-x86-v6.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: thinkpad_acpi: Only update profile if successfully converted platform/x86: intel-vbtn: Stop calling "VBDL" from notify_handler platform/x86: x86-android-tablets: Fix acer_b1_750_goodix_gpios name platform/x86: x86-android-tablets: Fix serdev instantiation no longer working platform/x86: Add new get_serdev_controller() helper platform/x86: x86-android-tablets: Fix keyboard touchscreen on Lenovo Yogabook1 X90 platform/x86/amd/pmf: Fix a potential race with policy binary sideload platform/x86/amd/pmf: Fixup error handling for amd_pmf_init_smart_pc() platform/x86/amd/pmf: Add debugging message for missing policy data platform/x86/amd/pmf: Fix a suspend hang on Framework 13 platform/x86/amd/pmf: Fix TEE enact command failure after suspend and resume platform/x86/amd/pmf: Remove smart_pc_status enum platform/x86: touchscreen_dmi: Consolidate Goodix upside-down touchscreen data platform/x86: touchscreen_dmi: Allow partial (prefix) matches for ACPI names platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to request_irq() platform/x86: think-lmi: Fix password opcode ordering for workstations
2024-02-22Merge tag 'clk-fixes-for-linus' of ↵Linus Torvalds2-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "Here are some Samsung clk driver fixes I've been sitting on for far too long. They fix the bindings and clk driver for the Google GS101 SoC" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: samsung: clk-gs101: comply with the new dt cmu_misc clock names dt-bindings: clock: gs101: rename cmu_misc clock-names
2024-02-22Merge tag 'vfs-6.8-rc6.fixes' of ↵Linus Torvalds11-19/+32
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - Fix a memory leak in cachefiles - Restrict aio cancellations to I/O submitted through the aio interfaces as this is otherwise causing issues for I/O submitted via io_uring - Increase buffer for afs volume status to avoid overflow - Fix a missing zero-length check in unbuffered writes in the netfs library. If generic_write_checks() returns zero make netfs_unbuffered_write_iter() return right away - Prevent a leak in i_dio_count caused by netfs_begin_read() operating past i_size. It will return early and leave i_dio_count incremented - Account for ipv4 addresses as well as ipv6 addresses when processing incoming callbacks in afs * tag 'vfs-6.8-rc6.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio afs: Increase buffer size in afs_update_volume_status() afs: Fix ignored callbacks over ipv4 cachefiles: fix memory leak in cachefiles_add_cache() netfs: Fix missing zero-length check in unbuffered write netfs: Fix i_dio_count leak on DIO read past i_size
2024-02-22Merge tag 'net-6.8.0-rc6' of ↵Linus Torvalds75-378/+870
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from bpf and netfilter. Current release - regressions: - af_unix: fix another unix GC hangup Previous releases - regressions: - core: fix a possible AF_UNIX deadlock - bpf: fix NULL pointer dereference in sk_psock_verdict_data_ready() - netfilter: nft_flow_offload: release dst in case direct xmit path is used - bridge: switchdev: ensure MDB events are delivered exactly once - l2tp: pass correct message length to ip6_append_data - dccp/tcp: unhash sk from ehash for tb2 alloc failure after check_estalblished() - tls: fixes for record type handling with PEEK - devlink: fix possible use-after-free and memory leaks in devlink_init() Previous releases - always broken: - bpf: fix an oops when attempting to read the vsyscall page through bpf_probe_read_kernel - sched: act_mirred: use the backlog for mirred ingress - netfilter: nft_flow_offload: fix dst refcount underflow - ipv6: sr: fix possible use-after-free and null-ptr-deref - mptcp: fix several data races - phonet: take correct lock to peek at the RX queue Misc: - handful of fixes and reliability improvements for selftests" * tag 'net-6.8.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (72 commits) l2tp: pass correct message length to ip6_append_data net: phy: realtek: Fix rtl8211f_config_init() for RTL8211F(D)(I)-VD-CG PHY selftests: ioam: refactoring to align with the fix Fix write to cloned skb in ipv6_hop_ioam() phonet/pep: fix racy skb_queue_empty() use phonet: take correct lock to peek at the RX queue net: sparx5: Add spinlock for frame transmission from CPU net/sched: flower: Add lock protection when remove filter handle devlink: fix port dump cmd type net: stmmac: Fix EST offset for dwmac 5.10 tools: ynl: don't leak mcast_groups on init error tools: ynl: make sure we always pass yarg to mnl_cb_run net: mctp: put sock on tag allocation failure netfilter: nf_tables: use kzalloc for hook allocation netfilter: nf_tables: register hooks last when adding new chain/flowtable netfilter: nft_flow_offload: release dst in case direct xmit path is used netfilter: nft_flow_offload: reset dst in route object after setting up flow netfilter: nf_tables: set dormant flag on hook register failure selftests: tls: add test for peeking past a record of a different type selftests: tls: add test for merging of same-type control messages ...
2024-02-22drm/amdgpu: Fix the runtime resume failure issueMa Jun1-0/+3
Don't set power state flag when system enter runtime suspend, or it may cause runtime resume failure issue. Fixes: 3a9626c816db ("drm/amd: Stop evicting resources on APUs in suspend") Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Notes: Fixes: 3a9626c816db ("drm/amd: Stop evicting resources on APUs in suspend") # v6.8-rc5 Lore: https://lore.kernel.org/r/20240221093515.1787230-1-Jun.Ma2@amd.com # amd-gfx Lore: https://lore.kernel.org/r/20240227131635.393069585@linuxfoundation.org # linux-patches, stable
2024-02-22drm/amd/display: fix null-pointer dereference on edid readingMelissa Wen1-4/+15
Use i2c adapter when there isn't aux_mode in dc_link to fix a null-pointer derefence that happens when running igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector detected as below: [ +0.178146] BUG: kernel NULL pointer dereference, address: 00000000000004c0 [ +0.000010] #PF: supervisor read access in kernel mode [ +0.000005] #PF: error_code(0x0000) - not-present page [ +0.000004] PGD 0 P4D 0 [ +0.000006] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000006] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ #152 [ +0.000005] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS F.01 07/14/2021 [ +0.000004] RIP: 0010:i2c_transfer+0xd/0x100 [ +0.000011] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 <48> 8b 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16 [ +0.000004] RSP: 0018:ffff9c4f89c0fad0 EFLAGS: 00010246 [ +0.000005] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000080 [ +0.000003] RDX: 0000000000000002 RSI: ffff9c4f89c0fb20 RDI: 00000000000004b0 [ +0.000003] RBP: ffff9c4f89c0fb80 R08: 0000000000000080 R09: ffff8d8e0b15b980 [ +0.000003] R10: 00000000000380e0 R11: 0000000000000000 R12: 0000000000000080 [ +0.000002] R13: 0000000000000002 R14: ffff9c4f89c0fb0e R15: ffff9c4f89c0fb0f [ +0.000004] FS: 00007f9ad2176c40(0000) GS:ffff8d90fe9c0000(0000) knlGS:0000000000000000 [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000004] CR2: 00000000000004c0 CR3: 0000000121bc4000 CR4: 0000000000750ee0 [ +0.000003] PKRU: 55555554 [ +0.000003] Call Trace: [ +0.000006] <TASK> [ +0.000006] ? __die+0x23/0x70 [ +0.000011] ? page_fault_oops+0x17d/0x4c0 [ +0.000008] ? preempt_count_add+0x6e/0xa0 [ +0.000008] ? srso_alias_return_thunk+0x5/0x7f [ +0.000011] ? exc_page_fault+0x7f/0x180 [ +0.000009] ? asm_exc_page_fault+0x26/0x30 [ +0.000013] ? i2c_transfer+0xd/0x100 [ +0.000010] drm_do_probe_ddc_edid+0xc2/0x140 [drm] [ +0.000067] ? srso_alias_return_thunk+0x5/0x7f [ +0.000006] ? _drm_do_get_edid+0x97/0x3c0 [drm] [ +0.000043] ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm] [ +0.000042] edid_block_read+0x3b/0xd0 [drm] [ +0.000043] _drm_do_get_edid+0xb6/0x3c0 [drm] [ +0.000041] ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm] [ +0.000043] drm_edid_read_custom+0x37/0xd0 [drm] [ +0.000044] amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu] [ +0.000153] drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper] [ +0.000000] __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper] [ +0.000000] ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu] [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f [ +0.000000] drm_helper_probe_single_connector_modes+0x2ab/0x540 [drm_kms_helper] [ +0.000000] status_store+0xb2/0x1f0 [drm] [ +0.000000] kernfs_fop_write_iter+0x136/0x1d0 [ +0.000000] vfs_write+0x24d/0x440 [ +0.000000] ksys_write+0x6f/0xf0 [ +0.000000] do_syscall_64+0x60/0xc0 [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f [ +0.000000] ? syscall_exit_to_user_mode+0x2b/0x40 [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f [ +0.000000] ? do_syscall_64+0x6c/0xc0 [ +0.000000] ? do_syscall_64+0x6c/0xc0 [ +0.000000] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ +0.000000] RIP: 0033:0x7f9ad46b4b00 [ +0.000000] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89 [ +0.000000] RSP: 002b:00007ffcbd3bd6d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [ +0.000000] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9ad46b4b00 [ +0.000000] RDX: 0000000000000002 RSI: 00007f9ad48a7417 RDI: 0000000000000009 [ +0.000000] RBP: 0000000000000002 R08: 0000000000000064 R09: 0000000000000000 [ +0.000000] R10: 0000000000000000 R11: 0000000000000202 R12: 00007f9ad48a7417 [ +0.000000] R13: 0000000000000009 R14: 00007ffcbd3bd760 R15: 0000000000000001 [ +0.000000] </TASK> [ +0.000000] Modules linked in: ctr ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel btmtk bluetooth uvcvideo videobuf2_vmalloc sha3_generic videobuf2_memops uvc jitterentropy_rng videobuf2_v4l2 videodev drbg videobuf2_common ansi_cprng mc ecdh_generic ecc qrtr binfmt_misc hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio snd_ctl_led joydev hid_sensor_iio_common rtw89_8852ae rtw89_8852a rtw89_pci snd_hda_codec_realtek rtw89_core snd_hda_codec_generic intel_rapl_msr ledtrig_audio intel_rapl_common snd_hda_codec_hdmi mac80211 snd_hda_intel snd_intel_dspcfg kvm_amd snd_hda_codec snd_soc_dmic snd_acp3x_rn snd_acp3x_pdm_dma libarc4 snd_hwdep snd_soc_core kvm snd_hda_core cfg80211 snd_pci_acp6x snd_pcm nls_ascii snd_timer hp_wmi snd_pci_acp5x nls_cp437 snd_rn_pci_acp3x ucsi_acpi sparse_keymap ccp snd platform_profile snd_acp_config typec_ucsi irqbypass vfat sp5100_tco [ +0.000000] snd_soc_acpi fat rapl pcspkr wmi_bmof roles rfkill rng_core snd_pci_acp3x soundcore k10temp watchdog typec battery ac amd_pmc acpi_tad button hid_sensor_hub hid_multitouch evdev serio_raw msr parport_pc ppdev lp parport fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic dm_crypt dm_mod efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c crc32c_generic xor raid6_pq raid1 raid0 multipath linear md_mod amdgpu amdxcp i2c_algo_bit drm_ttm_helper ttm crc32_pclmul crc32c_intel drm_exec gpu_sched drm_suballoc_helper nvme ghash_clmulni_intel drm_buddy drm_display_helper sha512_ssse3 nvme_core ahci xhci_pci sha512_generic hid_generic xhci_hcd libahci rtsx_pci_sdmmc t10_pi i2c_hid_acpi drm_kms_helper i2c_hid mmc_core libata aesni_intel crc64_rocksoft_generic crypto_simd amd_sfh crc64_rocksoft scsi_mod usbcore cryptd crc_t10dif cec drm crct10dif_generic hid rtsx_pci crct10dif_pclmul scsi_common rc_core crc64 i2c_piix4 [ +0.000000] usb_common crct10dif_common video wmi [ +0.000000] CR2: 00000000000004c0 [ +0.000000] ---[ end trace 0000000000000000 ]--- Fixes: 0e859faf8670 ("drm/amd/display: Remove unwanted drm edid references") Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Notes: Fixes: 0e859faf8670 ("drm/amd/display: Remove unwanted drm edid references") # v6.7-rc1 Lore: https://lore.kernel.org/r/20240215173509.152760-1-mwen@igalia.com # amd-gfx Lore: https://lore.kernel.org/r/20240227131641.721200735@linuxfoundation.org # linux-patches, stable
2024-02-22drm/amd/display: Fix memory leak in dm_sw_fini()Armin Wolf1-0/+1
After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak: unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu] [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90 [<ffffffff996918a3>] pci_device_probe+0xc3/0x230 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff990012d1>] do_one_initcall+0x41/0x300 Fix this by freeing dmub_srv after destroying it. Fixes: 743b9786b14a ("drm/amd/display: Hook up the DMUB service in DM") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Notes: Fixes: 743b9786b14a ("drm/amd/display: Hook up the DMUB service in DM") # v5.6-rc1 Stable: 10c6b90e9753 # v6.6.19 Stable: 58168005337e # v6.1.80 Stable: 33f649f1b1ce # v5.15.150 Stable: b49b022f7dfc # v5.10.211 Lore: https://lore.kernel.org/r/20240213005050.4442-1-W_Armin@gmx.de # amd-gfx, dri-devel, lkml Lore: https://lore.kernel.org/r/20240227131602.562736053@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131616.446566361@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.840452253@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.973839157@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.686561443@linuxfoundation.org # linux-patches, stable
2024-02-22drm/amd/display: fix input states translation error for dcn35 & dcn351Swapnil Patel1-1/+8
[Why] Currently there is an error while translating input clock sates into output clock states. The highest fclk setting from output sates is being dropped because of this error. [How] For dcn35 and dcn351, make output_states equal to input states. Reviewed-by: Charlene Liu <charlene.liu@amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Swapnil Patel <swapnil.patel@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Notes: Lore: https://lore.kernel.org/r/20240229203729.2860356-24-sashal@kernel.org # lkml, stable
2024-02-22drm/amd/display: Fix potential null pointer dereference in dc_dmub_srvSrinivasan Shanmugam1-2/+5
Fixes potential null pointer dereference warnings in the dc_dmub_srv_cmd_list_queue_execute() and dc_dmub_srv_is_hw_pwr_up() functions. In both functions, the 'dc_dmub_srv' variable was being dereferenced before it was checked for null. This could lead to a null pointer dereference if 'dc_dmub_srv' is null. The fix is to check if 'dc_dmub_srv' is null before dereferencing it. Thus moving the null checks for 'dc_dmub_srv' to the beginning of the functions to ensure that 'dc_dmub_srv' is not null when it is dereferenced. Found by smatch & thus fixing the below: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:133 dc_dmub_srv_cmd_list_queue_execute() warn: variable dereferenced before check 'dc_dmub_srv' (see line 128) drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_is_hw_pwr_up() warn: variable dereferenced before check 'dc_dmub_srv' (see line 1164) Fixes: 028bac583449 ("drm/amd/display: decouple dmcub execution to reduce lock granularity") Fixes: 65138eb72e1f ("drm/amd/display: Add DCN35 DMUB") Cc: JinZe.Xu <jinze.xu@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Josip Pavic <josip.pavic@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Qingqing Zhuo <Qingqing.Zhuo@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Notes: Fixes: 028bac583449 ("drm/amd/display: decouple dmcub execution to reduce lock granularity") # v6.7-rc1 Fixes: 65138eb72e1f ("drm/amd/display: Add DCN35 DMUB") # v6.7-rc1 Lore: https://lore.kernel.org/r/20240227131641.642322567@linuxfoundation.org # linux-patches, stable
2024-02-22Merge tag 'trace-v6.8-rc5' of ↵Linus Torvalds1-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fix from Steven Rostedt: - While working on the ring buffer I noticed that the counter used for knowing where the end of the data is on a sub-buffer was not a full "int" but just 20 bits. It was masked out to 0xfffff. With the new code that allows the user to change the size of the sub-buffer, it is theoretically possible to ask for a size bigger than 2^20. If that happens, unexpected results may occur as there's no code checking if the counter overflowed the 20 bits of the write mask. There are other checks to make sure events fit in the sub-buffer, but if the sub-buffer itself is too big, that is not checked. Add a check in the resize of the sub-buffer to make sure that it never goes beyond the size of the counter that holds how much data is on it. * tag 'trace-v6.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: ring-buffer: Do not let subbuf be bigger than write mask
2024-02-22drm/amd/display: Only allow dig mapping to pwrseq in new asicLewis Huang5-27/+21
[Why] The old asic only have 1 pwrseq hw. We don't need to map the diginst to pwrseq inst in old asic. [How] 1. Only mapping dig to pwrseq for new asic. 2. Move mapping function into dcn specific panel control component Cc: Stable <stable@vger.kernel.org> # v6.6+ Cc: Mario Limonciello <mario.limonciello@amd.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3122 Reviewed-by: Anthony Koo <anthony.koo@amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Lewis Huang <lewis.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Notes: Lore: https://lore.kernel.org/r/20240214184006.1356137-8-Rodrigo.Siqueira@amd.com # stable Lore: https://lore.kernel.org/r/20240227131635.333629692@linuxfoundation.org # linux-patches, stable
2024-02-22drm/amd/display: adjust few initialization order in dmWayne Lin1-19/+18
[Why] Observe error message "Can't retrieve aconnector in hpd_rx_irq_offload_work" when boot up with a mst tbt4 dock connected. After analyzing, there are few parts needed to be adjusted: 1. hpd_rx_offload_wq[].aconnector is not initialzed before the dmub outbox hpd_irq handler get registered which causes the error message. 2. registeration of hpd and hpd_rx_irq event for usb4 dp tunneling is not aligned with legacy interface sequence [How] Put DMUB_NOTIFICATION_HPD and DMUB_NOTIFICATION_HPD_IRQ handler registration into register_hpd_handlers() to align other interfaces and get hpd_rx_offload_wq[].aconnector initialized earlier than that. Leave DMUB_NOTIFICATION_AUX_REPLY registered as it was since we need that while calling dc_link_detect(). USB4 connection status will be proactively detected by dc_link_detect_connection_type() in amdgpu_dm_initialize_drm_device() Cc: Stable <stable@vger.kernel.org> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Notes: Stable: fec5aea66916 # v6.6.19 Lore: https://lore.kernel.org/r/20240214184006.1356137-7-Rodrigo.Siqueira@amd.com # amd-gfx, stable Lore: https://lore.kernel.org/r/20240227131630.424816053@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.363480102@linuxfoundation.org # linux-patches, stable
2024-02-22s390/cio: fix invalid -EBUSY on ccw_device_startPeter Oberparleiter1-3/+3
The s390 common I/O layer (CIO) returns an unexpected -EBUSY return code when drivers try to start I/O while a path-verification (PV) process is pending. This can lead to failed device initialization attempts with symptoms like broken network connectivity after boot. Fix this by replacing the -EBUSY return code with a deferred condition code 1 reply to make path-verification handling consistent from a driver's point of view. The problem can be reproduced semi-regularly using the following process, while repeating steps 2-3 as necessary (example assumes an OSA device with bus-IDs 0.0.a000-0.0.a002 on CHPID 0.02): 1. echo 0.0.a000,0.0.a001,0.0.a002 >/sys/bus/ccwgroup/drivers/qeth/group 2. echo 0 > /sys/bus/ccwgroup/devices/0.0.a000/online 3. echo 1 > /sys/bus/ccwgroup/devices/0.0.a000/online ; \ echo on > /sys/devices/css0/chp0.02/status Background information: The common I/O layer starts path-verification I/Os when it receives indications about changes in a device path's availability. This occurs for example when hardware events indicate a change in channel-path status, or when a manual operation such as a CHPID vary or configure operation is performed. If a driver attempts to start I/O while a PV is running, CIO reports a successful I/O start (ccw_device_start() return code 0). Then, after completion of PV, CIO synthesizes an interrupt response that indicates an asynchronous status condition that prevented the start of the I/O (deferred condition code 1). If a PV indication arrives while a device is busy with driver-owned I/O, PV is delayed until after I/O completion was reported to the driver's interrupt handler. To ensure that PV can be started eventually, CIO reports a device busy condition (ccw_device_start() return code -EBUSY) if a driver tries to start another I/O while PV is pending. In some cases this -EBUSY return code causes device drivers to consider a device not operational, resulting in failed device initialization. Note: The code that introduced the problem was added in 2003. Symptoms started appearing with the following CIO commit that causes a PV indication when a device is removed from the cio_ignore list after the associated parent subchannel device was probed, but before online processing of the CCW device has started: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers") During boot, the cio_ignore list is modified by the cio_ignore dracut module [1] as well as Linux vendor-specific systemd service scripts[2]. When combined, this commit and boot scripts cause a frequent occurrence of the problem during boot. [1] https://github.com/dracutdevs/dracut/tree/master/modules.d/81cio_ignore [2] https://github.com/SUSE/s390-tools/blob/master/cio_ignore.service Cc: stable@vger.kernel.org # v5.15+ Fixes: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers") Tested-By: Thorsten Winkler <twinkler@linux.ibm.com> Reviewed-by: Thorsten Winkler <twinkler@linux.ibm.com> Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Notes: Fixes: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers") # v5.15-rc1 Stable: cf245e831afc # v6.6.19 Stable: 65c5a1ba2c32 # v6.1.80 Stable: f6a765a61e0e # v5.10.211 Lore: https://lore.kernel.org/r/20240227131601.159189596@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131613.323105008@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131630.464096678@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.427399260@linuxfoundation.org # linux-patches, stable
2024-02-22selftests/iommu: fix the config fragmentMuhammad Usama Anjum1-2/+3
The config fragment doesn't follow the correct format to enable those config options which make the config options getting missed while merging with other configs. ➜ merge_config.sh -m .config tools/testing/selftests/iommu/config Using .config as base Merging tools/testing/selftests/iommu/config ➜ make olddefconfig .config:5295:warning: unexpected data: CONFIG_IOMMUFD .config:5296:warning: unexpected data: CONFIG_IOMMUFD_TEST While at it, add CONFIG_FAULT_INJECTION as well which is needed for CONFIG_IOMMUFD_TEST. If CONFIG_FAULT_INJECTION isn't present in base config (such as x86 defconfig), CONFIG_IOMMUFD_TEST doesn't get enabled. Fixes: 57f0988706fe ("iommufd: Add a selftest") Link: https://lore.kernel.org/r/20240222074934.71380-1-usama.anjum@collabora.com Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Notes: Fixes: 57f0988706fe ("iommufd: Add a selftest") # v6.2-rc1 Stable: 7a8a8a6a4f1e # v6.6.19 Lore: https://lore.kernel.org/r/20240222074934.71380-1-usama.anjum@collabora.com # linux-iommu, linux-kselftest, lkml Lore: https://lore.kernel.org/r/20240227131634.944726482@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.606330166@linuxfoundation.org # linux-patches, stable
2024-02-22drm/syncobj: handle NULL fence in syncobj_eventfd_entry_funcErik Kurzinger1-1/+12
During syncobj_eventfd_entry_func, dma_fence_chain_find_seqno may set the fence to NULL if the given seqno is signaled and a later seqno has already been submitted. In that case, the eventfd should be signaled immediately which currently does not happen. This is a similar issue to the one addressed by commit b19926d4f3a6 ("drm/syncobj: Deal with signalled fences in drm_syncobj_find_fence."). As a fix, if the return value of dma_fence_chain_find_seqno indicates success but it sets the fence to NULL, we will assign a stub fence to ensure the following code still signals the eventfd. v1 -> v2: assign a stub fence instead of signaling the eventfd Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> Fixes: c7a472297169 ("drm/syncobj: add IOCTL to register an eventfd") Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20240221184527.37667-1-ekurzinger@nvidia.com Notes: Fixes: c7a472297169 ("drm/syncobj: add IOCTL to register an eventfd") # v6.6-rc1 Stable: 20e1e1a2b8a4 # v6.6.19 Lore: https://lore.kernel.org/r/20240125180321.41173-1-ekurzinger@nvidia.com # dri-devel Lore: https://lore.kernel.org/r/20240227131634.909449014@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.568941687@linuxfoundation.org # linux-patches, stable
2024-02-22drm/syncobj: call drm_syncobj_fence_add_wait when WAIT_AVAILABLE flag is setErik Kurzinger1-2/+4
When waiting for a syncobj timeline point whose fence has not yet been submitted with the WAIT_FOR_SUBMIT flag, a callback is registered using drm_syncobj_fence_add_wait and the thread is put to sleep until the timeout expires. If the fence is submitted before then, drm_syncobj_add_point will wake up the sleeping thread immediately which will proceed to wait for the fence to be signaled. However, if the WAIT_AVAILABLE flag is used instead, drm_syncobj_fence_add_wait won't get called, meaning the waiting thread will always sleep for the full timeout duration, even if the fence gets submitted earlier. If it turns out that the fence *has* been submitted by the time it eventually wakes up, it will still indicate to userspace that the wait completed successfully (it won't return -ETIME), but it will have taken much longer than it should have. To fix this, we must call drm_syncobj_fence_add_wait if *either* the WAIT_FOR_SUBMIT flag or the WAIT_AVAILABLE flag is set. The only difference being that with WAIT_FOR_SUBMIT we will also wait for the fence to be signaled after it has been submitted while with WAIT_AVAILABLE we will return immediately. IGT test patch: https://lists.freedesktop.org/archives/igt-dev/2024-January/067537.html v1 -> v2: adjust lockdep_assert_none_held_once condition (cherry picked from commit 8c44ea81634a4a337df70a32621a5f3791be23df) Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8") Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20240119163208.3723457-1-ekurzinger@nvidia.com Notes: Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8") # v5.2-rc1 Stable: 716cfee8053e # v6.6.19 Stable: fd7b4f4fdc7c # v6.1.80 Stable: 9a03126588e5 # v5.15.150 Stable: c6551ff227f6 # v5.10.211 Stable: c28fc1aa6f82 # v5.4.270 Lore: https://lore.kernel.org/r/20240227131555.545442293@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131602.531018298@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131616.413213860@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.810454944@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.880281268@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.454251286@linuxfoundation.org # linux-patches, stable
2024-02-22drm/ttm: Fix an invalid freeing on already freed page in error pathThomas Hellström1-1/+1
If caching mode change fails due to, for example, OOM we free the allocated pages in a two-step process. First the pages for which the caching change has already succeeded. Secondly the pages for which a caching change did not succeed. However the second step was incorrectly freeing the pages already freed in the first step. Fix. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path") Cc: Christian König <christian.koenig@amd.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.4+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellstrom@linux.intel.com Notes: Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path") # v6.4-rc1 Fixes-stable: d2151c5d9dbe ("drm/ttm/pool: Fix ttm_pool_alloc error path") # v6.1.28 Fixes-stable: 678b3f29aaaf ("drm/ttm/pool: Fix ttm_pool_alloc error path") # v5.15.111 Stable: 47bacc3c7fbb # v6.6.19 Stable: 47647795a630 # v6.1.80 Stable: d580f0dcb5e3 # v5.15.150 Lore: https://lore.kernel.org/r/20240221073324.3303-1-thomas.hellstrom@linux.intel.com # stable Lore: https://lore.kernel.org/r/20240227131613.291946379@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131617.776837919@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131630.361371422@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.229615976@linuxfoundation.org # linux-patches, stable
2024-02-22ARM: dts: renesas: rcar-gen2: Add missing #interrupt-cells to DA9063 nodesGeert Uytterhoeven8-0/+8
make dtbs_check W=2: arch/arm/boot/dts/renesas/r8a7790-lager.dts:444.11-458.5: Warning (interrupt_provider): /i2c-mux4/pmic@58: Missing '#interrupt-cells' in interrupt provider ... Fix this by adding the missing #interrupt-cells properties. Reported-by: Rob Herring <robh@kernel.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/a351e503ea97fb1af68395843f513925ff1bdf26.1707922460.git.geert+renesas@glider.be Notes: Lore: https://lore.kernel.org/r/20240229203729.2860356-23-sashal@kernel.org # linux-devicetree, linux-renesas-soc, lkml, stable Lore: https://lore.kernel.org/r/20240229203933.2861006-22-sashal@kernel.org # linux-devicetree, linux-renesas-soc, lkml, stable Lore: https://lore.kernel.org/r/a351e503ea97fb1af68395843f513925ff1bdf26.1707922460.git.geert+renesas@glider.be # linux-arm-kernel, linux-renesas-soc
2024-02-22l2tp: pass correct message length to ip6_append_dataTom Parkin1-1/+1
l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent. Fixes: 9d4c75800f61 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()") Cc: David Howells <dhowells@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Tom Parkin <tparkin@katalix.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240220122156.43131-1-tparkin@katalix.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Notes: Fixes: 9d4c75800f61 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()") # v6.6-rc5 Fixes-stable: f6a7182179c0 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()") # v6.1.57 Fixes-stable: cd1189956393 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()") # v5.15.135 Fixes-stable: 96b2e1090397 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()") # v5.10.198 Fixes-stable: 1fc793d68d50 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()") # v5.4.258 Fixes-stable: 559d697c5d07 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()") # v4.19.296 Fixes-stable: 7626b9fed530 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()") # v4.14.327 Stable: 804bd8650a3a # v6.6.19 Stable: 13cd1daeea84 # v6.1.80 Stable: 0da15a703951 # v5.15.150 Stable: dcb4d1426859 # v5.10.211 Stable: c1d3a84a67db # v5.4.270 Stable: 4c3ce64bc9d3 # v4.19.308 Lore: https://lore.kernel.org/r/20240220122132.42990-1-tparkin@katalix.com # stable Lore: https://lore.kernel.org/r/20240220122156.43131-1-tparkin@katalix.com # netdev, stable Lore: https://lore.kernel.org/r/20240227131549.552470778@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131554.726924165@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131601.356528459@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131614.095491115@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131618.023052691@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131631.508246819@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.067433745@linuxfoundation.org # linux-patches, stable
2024-02-22Merge tag 'nf-24-02-22' of ↵Paolo Abeni3-43/+57
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) If user requests to wake up a table and hook fails, restore the dormant flag from the error path, from Florian Westphal. 2) Reset dst after transferring it to the flow object, otherwise dst gets released twice from the error path. 3) Release dst in case the flowtable selects a direct xmit path, eg. transmission to bridge port. Otherwise, dst is memleaked. 4) Register basechain and flowtable hooks at the end of the command. Error path releases these datastructure without waiting for the rcu grace period. 5) Use kzalloc() to initialize struct nft_hook to fix a KMSAN report on access to hook type, also from Florian Westphal. netfilter pull request 24-02-22 * tag 'nf-24-02-22' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: use kzalloc for hook allocation netfilter: nf_tables: register hooks last when adding new chain/flowtable netfilter: nft_flow_offload: release dst in case direct xmit path is used netfilter: nft_flow_offload: reset dst in route object after setting up flow netfilter: nf_tables: set dormant flag on hook register failure ==================== Link: https://lore.kernel.org/r/20240222000843.146665-1-pablo@netfilter.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-02-22Merge tag 'for-netdev' of ↵Paolo Abeni15-17/+217
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2024-02-22 The following pull-request contains BPF updates for your *net* tree. We've added 11 non-merge commits during the last 24 day(s) which contain a total of 15 files changed, 217 insertions(+), 17 deletions(-). The main changes are: 1) Fix a syzkaller-triggered oops when attempting to read the vsyscall page through bpf_probe_read_kernel and friends, from Hou Tao. 2) Fix a kernel panic due to uninitialized iter position pointer in bpf_iter_task, from Yafang Shao. 3) Fix a race between bpf_timer_cancel_and_free and bpf_timer_cancel, from Martin KaFai Lau. 4) Fix a xsk warning in skb_add_rx_frag() (under CONFIG_DEBUG_NET) due to incorrect truesize accounting, from Sebastian Andrzej Siewior. 5) Fix a NULL pointer dereference in sk_psock_verdict_data_ready, from Shigeru Yoshida. 6) Fix a resolve_btfids warning when bpf_cpumask symbol cannot be resolved, from Hari Bathini. bpf-for-netdev * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready() selftests/bpf: Add negtive test cases for task iter bpf: Fix an issue due to uninitialized bpf_iter_task selftests/bpf: Test racing between bpf_timer_cancel_and_free and bpf_timer_cancel bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel selftest/bpf: Test the read of vsyscall page under x86-64 x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault() x86/mm: Move is_vsyscall_vaddr() into asm/vsyscall.h bpf, scripts: Correct GPL license name xsk: Add truesize to skb_add_rx_frag(). bpf: Fix warning for bpf_cpumask in verifier ==================== Link: https://lore.kernel.org/r/20240221231826.1404-1-daniel@iogearbox.net Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-02-22net: phy: realtek: Fix rtl8211f_config_init() for RTL8211F(D)(I)-VD-CG PHYSiddharth Vadapalli1-1/+3
Commit bb726b753f75 ("net: phy: realtek: add support for RTL8211F(D)(I)-VD-CG") extended support of the driver from the existing support for RTL8211F(D)(I)-CG PHY to the newer RTL8211F(D)(I)-VD-CG PHY. While that commit indicated that the RTL8211F_PHYCR2 register is not supported by the "VD-CG" PHY model and therefore updated the corresponding section in rtl8211f_config_init() to be invoked conditionally, the call to "genphy_soft_reset()" was left as-is, when it should have also been invoked conditionally. This is because the call to "genphy_soft_reset()" was first introduced by the commit 0a4355c2b7f8 ("net: phy: realtek: add dt property to disable CLKOUT clock") since the RTL8211F guide indicates that a PHY reset should be issued after setting bits in the PHYCR2 register. As the PHYCR2 register is not applicable to the "VD-CG" PHY model, fix the rtl8211f_config_init() function by invoking "genphy_soft_reset()" conditionally based on the presence of the "PHYCR2" register. Fixes: bb726b753f75 ("net: phy: realtek: add support for RTL8211F(D)(I)-VD-CG") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240220070007.968762-1-s-vadapalli@ti.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Notes: Fixes: bb726b753f75 ("net: phy: realtek: add support for RTL8211F(D)(I)-VD-CG") # v6.1-rc1 Stable: c7818378953d # v6.6.19 Stable: b9196289e36c # v6.1.80 Lore: https://lore.kernel.org/r/20240220070007.968762-1-s-vadapalli@ti.com # linux-arm-kernel, lkml, netdev Lore: https://lore.kernel.org/r/20240227131616.378923934@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.849880262@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.424978510@linuxfoundation.org # linux-patches, stable
2024-02-22Merge branch 'ioam6-fix-write-to-cloned-skb-s'Paolo Abeni3-67/+76
Justin Iurman says: ==================== ioam6: fix write to cloned skb's Make sure the IOAM data insertion is not applied on cloned skb's. As a consequence, ioam selftests needed a refactoring. ==================== Link: https://lore.kernel.org/r/20240219135255.15429-1-justin.iurman@uliege.be Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-02-22selftests: ioam: refactoring to align with the fixJustin Iurman2-67/+66
ioam6_parser uses a packet socket. After the fix to prevent writing to cloned skb's, the receiver does not see its IOAM data anymore, which makes input/forward ioam-selftests to fail. As a workaround, ioam6_parser now uses an IPv6 raw socket and leverages ancillary data to get hop-by-hop options. As a consequence, the hook is "after" the IOAM data insertion by the receiver and all tests are working again. Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Notes: Lore: https://lore.kernel.org/r/20240219134821.14009-3-justin.iurman@uliege.be # lkml, netdev Lore: https://lore.kernel.org/r/20240219135255.15429-3-justin.iurman@uliege.be # lkml, netdev
2024-02-22Fix write to cloned skb in ipv6_hop_ioam()Justin Iurman1-0/+10
ioam6_fill_trace_data() writes inside the skb payload without ensuring it's writeable (e.g., not cloned). This function is called both from the input and output path. The output path (ioam6_iptunnel) already does the check. This commit provides a fix for the input path, inside ipv6_hop_ioam(). It also updates ip6_parse_tlv() to refresh the network header pointer ("nh") when returning from ipv6_hop_ioam(). Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace") Reported-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Notes: Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace") # v5.15-rc1 Stable: 8fbc19196dbe # v6.6.19 Stable: 37919ef31d7c # v6.1.80 Lore: https://lore.kernel.org/r/20240219134821.14009-2-justin.iurman@uliege.be # lkml, netdev Lore: https://lore.kernel.org/r/20240219135255.15429-2-justin.iurman@uliege.be # lkml, netdev Lore: https://lore.kernel.org/r/20240227131616.346583875@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.817527902@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.390800714@linuxfoundation.org # linux-patches, stable
2024-02-22phonet/pep: fix racy skb_queue_empty() useRémi Denis-Courmont1-9/+32
The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skb_peek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer. Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol") Signed-off-by: Rémi Denis-Courmont <courmisch@gmail.com> Link: https://lore.kernel.org/r/20240218081214.4806-2-remi@remlab.net Signed-off-by: Paolo Abeni <pabeni@redhat.com> Notes: Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol") # v2.6.28-rc1 Stable: 0a9f558c72c4 # v6.6.19 Stable: 9d5523e065b5 # v6.1.80 Lore: https://lore.kernel.org/r/20240210125054.71391-2-remi@remlab.net # lkml, netdev Lore: https://lore.kernel.org/r/20240218081214.4806-2-remi@remlab.net # lkml, netdev Lore: https://lore.kernel.org/r/20240227131616.314202994@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.788020418@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.356956716@linuxfoundation.org # linux-patches, stable
2024-02-22phonet: take correct lock to peek at the RX queueRémi Denis-Courmont1-2/+2
The receive queue is protected by its embedded spin-lock, not the socket lock, so we need the former lock here (and only that one). Fixes: 107d0d9b8d9a ("Phonet: Phonet datagram transport protocol") Reported-by: Luosili <rootlab@huawei.com> Signed-off-by: Rémi Denis-Courmont <courmisch@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20240218081214.4806-1-remi@remlab.net Signed-off-by: Paolo Abeni <pabeni@redhat.com> Notes: Fixes: 107d0d9b8d9a ("Phonet: Phonet datagram transport protocol") # v2.6.28-rc1 Stable: 3ebd19073efd # v6.6.19 Stable: f556a352fdb2 # v6.1.80 Lore: https://lore.kernel.org/r/20240210125054.71391-1-remi@remlab.net # lkml, netdev Lore: https://lore.kernel.org/r/20240218081214.4806-1-remi@remlab.net # lkml, netdev Lore: https://lore.kernel.org/r/20240227131616.280793263@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.757883271@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.327539412@linuxfoundation.org # linux-patches, stable
2024-02-21net: sparx5: Add spinlock for frame transmission from CPUHoratiu Vultur3-0/+4
Both registers used when doing manual injection or fdma injection are shared between all the net devices of the switch. It was noticed that when having two process which each of them trying to inject frames on different ethernet ports, that the HW started to behave strange, by sending out more frames then expected. When doing fdma injection it is required to set the frame in the DCB and then make sure that the next pointer of the last DCB is invalid. But because there is no locks for this, then easily this pointer between the DCB can be broken and then it would create a loop of DCBs. And that means that the HW will continuously transmit these frames in a loop. Until the SW will break this loop. Therefore to fix this issue, add a spin lock for when accessing the registers for manual or fdma injection. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Daniel Machon <daniel.machon@microchip.com> Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support") Link: https://lore.kernel.org/r/20240219080043.1561014-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support") # v5.14-rc1 Stable: 9adfd66b42d2 # v6.6.19 Stable: 1623161f80a4 # v6.1.80 Lore: https://lore.kernel.org/r/20240213121705.4070598-1-horatiu.vultur@microchip.com # linux-arm-kernel, lkml, netdev Lore: https://lore.kernel.org/r/20240215083333.2139380-1-horatiu.vultur@microchip.com # linux-arm-kernel, lkml, netdev Lore: https://lore.kernel.org/r/20240219080043.1561014-1-horatiu.vultur@microchip.com # linux-arm-kernel, lkml, netdev Lore: https://lore.kernel.org/r/20240227131616.247542040@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.728511436@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.286307432@linuxfoundation.org # linux-patches, stable
2024-02-21net/sched: flower: Add lock protection when remove filter handleJianbo Liu1-1/+4
As IDR can't protect itself from the concurrent modification, place idr_remove() under the protection of tp->lock. Fixes: 08a0063df3ae ("net/sched: flower: Move filter handle initialization earlier") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://lore.kernel.org/r/20240220085928.9161-1-jianbol@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: 08a0063df3ae ("net/sched: flower: Move filter handle initialization earlier") # v6.3-rc1 Stable: 88895d424720 # v6.6.19 Lore: https://lore.kernel.org/r/20240220085928.9161-1-jianbol@nvidia.com # netdev Lore: https://lore.kernel.org/r/20240227131634.694306099@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.256872898@linuxfoundation.org # linux-patches, stable
2024-02-21devlink: fix port dump cmd typeJiri Pirko1-1/+1
Unlike other commands, due to a c&p error, port dump fills-up cmd with wrong value, different from port-get request cmd, port-get doit reply and port notification. Fix it by filling cmd with value DEVLINK_CMD_PORT_NEW. Skimmed through devlink userspace implementations, none of them cares about this cmd value. Only ynl, for which, this is actually a fix, as it expects doit and dumpit ops rsp_value to be the same. Omit the fixes tag, even thought this is fix, better to target this for next release. Fixes: bfcd3a466172 ("Introduce devlink infrastructure") Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20240220075245.75416-1-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: bfcd3a466172 ("Introduce devlink infrastructure") # v4.6-rc1 Stable: 30d8d56aee70 # v6.6.19 Lore: https://lore.kernel.org/r/20240216113147.50797-1-jiri@resnulli.us # netdev Lore: https://lore.kernel.org/r/20240220075245.75416-1-jiri@resnulli.us # netdev Lore: https://lore.kernel.org/r/20240227131634.663948444@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.217816671@linuxfoundation.org # linux-patches, stable
2024-02-21net: stmmac: Fix EST offset for dwmac 5.10Kurt Kanzenbach1-1/+1
Fix EST offset for dwmac 5.10. Currently configuring Qbv doesn't work as expected. The schedule is configured, but never confirmed: |[ 128.250219] imx-dwmac 428a0000.ethernet eth1: configured EST The reason seems to be the refactoring of the EST code which set the wrong EST offset for the dwmac 5.10. After fixing this it works as before: |[ 106.359577] imx-dwmac 428a0000.ethernet eth1: configured EST |[ 128.430715] imx-dwmac 428a0000.ethernet eth1: EST: SWOL has been switched Tested on imx93. Fixes: c3f3b97238f6 ("net: stmmac: Refactor EST implementation") Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20240220-stmmac_est-v1-1-c41f9ae2e7b7@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: c3f3b97238f6 ("net: stmmac: Refactor EST implementation") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240220-stmmac_est-v1-1-c41f9ae2e7b7@linutronix.de # linux-arm-kernel, netdev Lore: https://lore.kernel.org/r/20240222135222.7332-1-rohan.g.thomas@intel.com # linux-arm-kernel, netdev
2024-02-21Merge branch 'tools-ynl-fix-impossible-errors'Jakub Kicinski1-4/+15
Jakub Kicinski says: ==================== tools: ynl: fix impossible errors Fix bugs discovered while I was hacking in low level stuff in YNL and kept breaking the socket, exercising the "impossible" error paths. v1: https://lore.kernel.org/all/20240217001742.2466993-1-kuba@kernel.org/ ==================== Link: https://lore.kernel.org/r/20240220161112.2735195-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-21tools: ynl: don't leak mcast_groups on init errorJakub Kicinski1-1/+7
Make sure to free the already-parsed mcast_groups if we don't get an ack from the kernel when reading family info. This is part of the ynl_sock_create() error path, so we won't get a call to ynl_sock_destroy() to free them later. Fixes: 86878f14d71a ("tools: ynl: user space helpers") Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240220161112.2735195-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: 86878f14d71a ("tools: ynl: user space helpers") # v6.5-rc1 Stable: a702e9883342 # v6.6.19 Lore: https://lore.kernel.org/r/20240217001742.2466993-4-kuba@kernel.org # netdev Lore: https://lore.kernel.org/r/20240220161112.2735195-3-kuba@kernel.org # netdev
2024-02-21tools: ynl: make sure we always pass yarg to mnl_cb_runJakub Kicinski1-3/+8
There is one common error handler in ynl - ynl_cb_error(). It expects priv to be a pointer to struct ynl_parse_arg AKA yarg. To avoid potential crashes if we encounter a stray NLMSG_ERROR always pass yarg as priv (or a struct which has it as the first member). ynl_cb_null() has a similar problem directly - it expects yarg but priv passed by the caller is ys. Found by code inspection. Fixes: 86878f14d71a ("tools: ynl: user space helpers") Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240220161112.2735195-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: 86878f14d71a ("tools: ynl: user space helpers") # v6.5-rc1 Stable: 91addaf5f02b # v6.6.19 Lore: https://lore.kernel.org/r/20240217001742.2466993-3-kuba@kernel.org # netdev Lore: https://lore.kernel.org/r/20240220161112.2735195-2-kuba@kernel.org # netdev Lore: https://lore.kernel.org/r/20240227131634.593776416@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.131570803@linuxfoundation.org # linux-patches, stable
2024-02-21net: mctp: put sock on tag allocation failureJeremy Kerr1-1/+1
We may hold an extra reference on a socket if a tag allocation fails: we optimistically allocate the sk_key, and take a ref there, but do not drop if we end up not using the allocated key. Ensure we're dropping the sock on this failure by doing a proper unref rather than directly kfree()ing. Fixes: de8a6b15d965 ("net: mctp: add an explicit reference from a mctp_sk_key to sock") Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/ce9b61e44d1cdae7797be0c5e3141baf582d23a0.1707983487.git.jk@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: de8a6b15d965 ("net: mctp: add an explicit reference from a mctp_sk_key to sock") # v6.2-rc6 Fixes-stable: d0cdcc3da926 ("net: mctp: add an explicit reference from a mctp_sk_key to sock") # v6.1.9 Stable: 18a3d49aee31 # v6.6.19 Stable: c22ad76cfc43 # v6.1.80 Lore: https://lore.kernel.org/r/20240227131616.215598146@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.559363383@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.102198188@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/ce9b61e44d1cdae7797be0c5e3141baf582d23a0.1707983487.git.jk@codeconstruct.com.au # netdev
2024-02-22netfilter: nf_tables: use kzalloc for hook allocationFlorian Westphal1-1/+1
KMSAN reports unitialized variable when registering the hook, reg->hook_ops_type == NF_HOOK_OP_BPF) ~~~~~~~~~~~ undefined This is a small structure, just use kzalloc to make sure this won't happen again when new fields get added to nf_hook_ops. Fixes: 7b4b2fa37587 ("netfilter: annotate nf_tables base hook ops") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Notes: Fixes: 7b4b2fa37587 ("netfilter: annotate nf_tables base hook ops") # v5.14-rc1 Stable: 73a7cdb48779 # v6.6.19 Stable: ea33b8166912 # v6.1.80 Lore: https://lore.kernel.org/r/20240221173848.5929-1-fw@strlen.de # netfilter-devel Lore: https://lore.kernel.org/r/20240222000843.146665-6-pablo@netfilter.org # netdev, netfilter-devel Lore: https://lore.kernel.org/r/20240227131616.183715203@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.527809975@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.073045942@linuxfoundation.org # linux-patches, stable
2024-02-22netfilter: nf_tables: register hooks last when adding new chain/flowtablePablo Neira Ayuso1-38/+40
Register hooks last when adding chain/flowtable to ensure that packets do not walk over datastructure that is being released in the error path without waiting for the rcu grace period. Fixes: 91c7b38dc9f0 ("netfilter: nf_tables: use new transaction infrastructure to handle chain") Fixes: 3b49e2e94e6e ("netfilter: nf_tables: add flow table netlink frontend") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Notes: Fixes: 3b49e2e94e6e ("netfilter: nf_tables: add flow table netlink frontend") # v4.16-rc1 Fixes: 91c7b38dc9f0 ("netfilter: nf_tables: use new transaction infrastructure to handle chain") # v3.16-rc1 Stable: fe9f4d1c531a # v6.6.19 Stable: f30535918672 # v6.1.80 Lore: https://lore.kernel.org/r/20240221173403.139996-1-pablo@netfilter.org # netfilter-devel Lore: https://lore.kernel.org/r/20240222000843.146665-5-pablo@netfilter.org # netdev, netfilter-devel Lore: https://lore.kernel.org/r/20240227131616.151468141@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.497237741@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.034073635@linuxfoundation.org # linux-patches, stable
2024-02-22netfilter: nft_flow_offload: release dst in case direct xmit path is usedPablo Neira Ayuso1-0/+1
Direct xmit does not use it since it calls dev_queue_xmit() to send packets, hence it calls dst_release(). kmemleak reports: unreferenced object 0xffff88814f440900 (size 184): comm "softirq", pid 0, jiffies 4294951896 hex dump (first 32 bytes): 00 60 5b 04 81 88 ff ff 00 e6 e8 82 ff ff ff ff .`[............. 21 0b 50 82 ff ff ff ff 00 00 00 00 00 00 00 00 !.P............. backtrace (crc cb2bf5d6): [<000000003ee17107>] kmem_cache_alloc+0x286/0x340 [<0000000021a5de2c>] dst_alloc+0x43/0xb0 [<00000000f0671159>] rt_dst_alloc+0x2e/0x190 [<00000000fe5092c9>] __mkroute_output+0x244/0x980 [<000000005fb96fb0>] ip_route_output_flow+0xc0/0x160 [<0000000045367433>] nf_ip_route+0xf/0x30 [<0000000085da1d8e>] nf_route+0x2d/0x60 [<00000000d1ecd1cb>] nft_flow_route+0x171/0x6a0 [nft_flow_offload] [<00000000d9b2fb60>] nft_flow_offload_eval+0x4e8/0x700 [nft_flow_offload] [<000000009f447dbb>] expr_call_ops_eval+0x53/0x330 [nf_tables] [<00000000072e1be6>] nft_do_chain+0x17c/0x840 [nf_tables] [<00000000d0551029>] nft_do_chain_inet+0xa1/0x210 [nf_tables] [<0000000097c9d5c6>] nf_hook_slow+0x5b/0x160 [<0000000005eccab1>] ip_forward+0x8b6/0x9b0 [<00000000553a269b>] ip_rcv+0x221/0x230 [<00000000412872e5>] __netif_receive_skb_one_core+0xfe/0x110 Fixes: fa502c865666 ("netfilter: flowtable: simplify route logic") Reported-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Notes: Fixes: fa502c865666 ("netfilter: flowtable: simplify route logic") # v6.5-rc1 Fixes-stable: 9c5662e95a8d ("netfilter: flowtable: simplify route logic") # v6.1.80 Fixes-stable: 7c71b831220e ("netfilter: flowtable: simplify route logic") # v5.15.150 Stable: 9256ab9232e3 # v6.6.19 Stable: a6cafdb49a7b # v6.1.80 Stable: 13b57b5cd591 # v5.15.150 Lore: https://lore.kernel.org/r/20240221173241.131482-2-pablo@netfilter.org # netfilter-devel Lore: https://lore.kernel.org/r/20240222000843.146665-4-pablo@netfilter.org # netdev, netfilter-devel Lore: https://lore.kernel.org/r/20240227131616.086509134@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.780237196@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.465588695@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.004272213@linuxfoundation.org # linux-patches, stable
2024-02-22netfilter: nft_flow_offload: reset dst in route object after setting up flowPablo Neira Ayuso2-4/+14
dst is transferred to the flow object, route object does not own it anymore. Reset dst in route object, otherwise if flow_offload_add() fails, error path releases dst twice, leading to a refcount underflow. Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Notes: Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression") # v4.16-rc1 Stable: 558b00a30e05 # v6.6.19 Stable: 012df10717da # v6.1.80 Stable: 4c167af9f6b5 # v5.15.150 Lore: https://lore.kernel.org/r/20240221173241.131482-1-pablo@netfilter.org # netfilter-devel Lore: https://lore.kernel.org/r/20240222000843.146665-3-pablo@netfilter.org # netdev, netfilter-devel Lore: https://lore.kernel.org/r/20240227131616.054331791@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.749874460@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.435355438@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.964094896@linuxfoundation.org # linux-patches, stable
2024-02-22netfilter: nf_tables: set dormant flag on hook register failureFlorian Westphal1-0/+1
We need to set the dormant flag again if we fail to register the hooks. During memory pressure hook registration can fail and we end up with a table marked as active but no registered hooks. On table/base chain deletion, nf_tables will attempt to unregister the hook again which yields a warn splat from the nftables core. Reported-and-tested-by: syzbot+de4025c006ec68ac56fc@syzkaller.appspotmail.com Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Notes: Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates") # v5.13-rc5 Fixes-stable: d9c4da8cb74e ("netfilter: nf_tables: fix table flag updates") # v5.10.202 Fixes-stable: e10f661adc55 ("netfilter: nf_tables: fix table flag updates") # v5.4.262 Stable: f2135bbf1494 # v6.6.19 Stable: 0c9302a6da26 # v6.1.80 Stable: 664264a5c55b # v5.15.150 Stable: 31ea574aeca1 # v5.10.211 Stable: ae4360cbd385 # v5.4.270 Lore: https://lore.kernel.org/r/20240219155809.9651-1-fw@strlen.de # netfilter-devel Lore: https://lore.kernel.org/r/20240222000843.146665-2-pablo@netfilter.org # netdev, netfilter-devel Lore: https://lore.kernel.org/r/20240227131555.477222132@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131602.466379837@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131615.987753526@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.689067738@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.405853804@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.933121095@linuxfoundation.org # linux-patches, stable Syzbot: https://syzkaller.appspot.com/bug?extid=de4025c006ec68ac56fc
2024-02-21Merge branch 'tls-fixes-for-record-type-handling-with-peek'Jakub Kicinski2-8/+61
Sabrina Dubroca says: ==================== tls: fixes for record type handling with PEEK There are multiple bugs in tls_sw_recvmsg's handling of record types when MSG_PEEK flag is used, which can lead to incorrectly merging two records: - consecutive non-DATA records shouldn't be merged, even if they're the same type (partly handled by the test at the end of the main loop) - records of the same type (even DATA) shouldn't be merged if one record of a different type comes in between ==================== Link: https://lore.kernel.org/r/cover.1708007371.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-21selftests: tls: add test for peeking past a record of a different typeSabrina Dubroca1-0/+19
If we queue 3 records: - record 1, type DATA - record 2, some other type - record 3, type DATA the current code can look past the 2nd record and merge the 2 data records. Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/4623550f8617c239581030c13402d3262f2bd14f.1708007371.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Lore: https://lore.kernel.org/r/4623550f8617c239581030c13402d3262f2bd14f.1708007371.git.sd@queasysnail.net # linux-kselftest, netdev
2024-02-21selftests: tls: add test for merging of same-type control messagesSabrina Dubroca1-0/+26
Two consecutive control messages of the same type should never be merged into one large received blob of data. Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/018f1633d5471684c65def5fe390de3b15c3d683.1708007371.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Lore: https://lore.kernel.org/r/018f1633d5471684c65def5fe390de3b15c3d683.1708007371.git.sd@queasysnail.net # linux-kselftest, netdev
2024-02-21tls: don't skip over different type records from the rx_listSabrina Dubroca1-8/+14
If we queue 3 records: - record 1, type DATA - record 2, some other type - record 3, type DATA and do a recv(PEEK), the rx_list will contain the first two records. The next large recv will walk through the rx_list and copy data from record 1, then stop because record 2 is a different type. Since we haven't filled up our buffer, we will process the next available record. It's also DATA, so we can merge it with the current read. We shouldn't do that, since there was a record in between that we ignored. Add a flag to let process_rx_list inform tls_sw_recvmsg that it had more data available. Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/f00c0c0afa080c60f016df1471158c1caf983c34.1708007371.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") # v5.1-rc1 Stable: 4f13a79ea3cf # v6.6.19 Stable: bdaf6bbfc1f2 # v6.1.80 Lore: https://lore.kernel.org/r/f00c0c0afa080c60f016df1471158c1caf983c34.1708007371.git.sd@queasysnail.net # linux-kselftest, netdev
2024-02-21tls: stop recv() if initial process_rx_list gave us non-DATASabrina Dubroca1-1/+1
If we have a non-DATA record on the rx_list and another record of the same type still on the queue, we will end up merging them: - process_rx_list copies the non-DATA record - we start the loop and process the first available record since it's of the same type - we break out of the loop since the record was not DATA Just check the record type and jump to the end in case process_rx_list did some work. Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/bd31449e43bd4b6ff546f5c51cf958c31c511deb.1708007371.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") # v5.1-rc1 Stable: 3b952d8fdfcf # v6.6.19 Stable: 6756168add1c # v6.1.80 Stable: 4338032aa90b # v5.15.150 Stable: 31e10d6cb0c9 # v5.10.211 Stable: f310143961e2 # v5.4.270 Lore: https://lore.kernel.org/r/20240227131555.442695028@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131602.433947198@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131615.924910161@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.658412194@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.341203243@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.864842832@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/bd31449e43bd4b6ff546f5c51cf958c31c511deb.1708007371.git.sd@queasysnail.net # linux-kselftest, netdev
2024-02-21tls: break out of main loop when PEEK gets a non-data recordSabrina Dubroca1-0/+2
PEEK needs to leave decrypted records on the rx_list so that we can receive them later on, so it jumps back into the async code that queues the skb. Unfortunately that makes us skip the TLS_RECORD_TYPE_DATA check at the bottom of the main loop, so if two records of the same (non-DATA) type are queued, we end up merging them. Add the same record type check, and make it unlikely to not penalize the async fastpath. Async decrypt only applies to data record, so this check is only needed for PEEK. process_rx_list also has similar issues. Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/3df2eef4fdae720c55e69472b5bea668772b45a2.1708007371.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") # v5.1-rc1 Stable: 80b1d6a0c0c0 # v6.6.19 Stable: ca89b4f5034d # v6.1.80 Lore: https://lore.kernel.org/r/20240227131615.891632388@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.310736916@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.827947777@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/3df2eef4fdae720c55e69472b5bea668772b45a2.1708007371.git.sd@queasysnail.net # linux-kselftest, netdev
2024-02-21gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()Vasiliy Kovalev1-5/+5
The gtp_net_ops pernet operations structure for the subsystem must be registered before registering the generic netlink family. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ? __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0 Cc: stable@vger.kernel.org Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org> Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Link: https://lore.kernel.org/r/20240214162733.34214-1-kovalev@altlinux.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Notes: Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") # v4.7-rc1 Stable: ba6b8b02a331 # v6.6.19 Stable: 3963f16cc764 # v6.1.80 Stable: a576308800be # v5.15.150 Stable: 2e534fd15e5c # v5.10.211 Stable: f8cbd1791900 # v5.4.270 Stable: f0ecdfa67918 # v4.19.308 Lore: https://lore.kernel.org/r/20240124101404.161655-1-kovalev@altlinux.org # lkml, netdev Lore: https://lore.kernel.org/r/20240124101404.161655-2-kovalev@altlinux.org # lkml, netdev Lore: https://lore.kernel.org/r/20240214162733.34214-1-kovalev@altlinux.org # lkml, netdev, stable Lore: https://lore.kernel.org/r/20240227131549.520078638@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131554.661534472@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131601.290702458@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131613.933962722@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131617.963471280@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131631.316523508@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.852838686@linuxfoundation.org # linux-patches, stable
2024-02-21hwmon: (nct6775) Fix access to temperature configuration registersGuenter Roeck1-2/+12
The number of temperature configuration registers does not always match the total number of temperature registers. This can result in access errors reported if KASAN is enabled. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x5654/0x6fe9 nct6775_core Reported-by: Erhard Furtner <erhard_f@mailbox.org> Closes: https://lore.kernel.org/linux-hwmon/d51181d1-d26b-42b2-b002-3f5a4037721f@roeck-us.net/ Fixes: b7f1f7b2523a ("hwmon: (nct6775) Additional TEMP registers for nct6799") Cc: Ahmad Khalifa <ahmad@khalifa.ws> Tested-by: Ahmad Khalifa <ahmad@khalifa.ws> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Notes: Fixes: b7f1f7b2523a ("hwmon: (nct6775) Additional TEMP registers for nct6799") # v6.6-rc1 Stable: f006c45a3ea4 # v6.6.19 Lore: https://lore.kernel.org/r/20240227131634.280229182@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.790098521@linuxfoundation.org # linux-patches, stable
2024-02-21ata: libata-core: Do not call ata_dev_power_set_standby() twiceDamien Le Moal1-29/+30
For regular system shutdown, ata_dev_power_set_standby() will be executed twice: once the scsi device is removed and another when ata_pci_shutdown_one() executes and EH completes unloading the devices. Make the second call to ata_dev_power_set_standby() do nothing by using ata_dev_power_is_active() and return if the device is already in standby. Fixes: 2da4c5e24e86 ("ata: libata-core: Improve ata_dev_power_set_active()") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Notes: Fixes: 2da4c5e24e86 ("ata: libata-core: Improve ata_dev_power_set_active()") # v6.7-rc1 Lore: https://lore.kernel.org/r/20240216112008.1112538-1-cassel@kernel.org # linux-ide, stable Lore: https://lore.kernel.org/r/20240219154431.1294581-1-cassel@kernel.org # linux-ide, stable Lore: https://lore.kernel.org/r/20240227131635.500998589@linuxfoundation.org # linux-patches, stable
2024-02-21Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds1-0/+5
Pull kvm fixes from Paolo Bonzini: "Two fixes for ARM ITS emulation. Unmapped interrupts were used instead of ignored, causing NULL pointer dereferences" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handler KVM: arm64: vgic-its: Test for valid IRQ in its_sync_lpi_pending_table()
2024-02-21Merge tag 'for-6.8-rc5-tag' of ↵Linus Torvalds2-18/+46
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - Fix a deadlock in fiemap. There was a big lock around the whole operation that can interfere with a page fault and mkwrite. Reducing the lock scope can also speed up fiemap - Fix range condition for extent defragmentation which could lead to worse layout in some cases * tag 'for-6.8-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix deadlock with fiemap and extent locking btrfs: defrag: avoid unnecessary defrag caused by incorrect extent size
2024-02-21Merge tag 'v6.8-p4' of ↵Linus Torvalds1-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix a stack overflow in virtio" * tag 'v6.8-p4' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: virtio/akcipher - Fix stack overflow on memcpy
2024-02-21cache: ax45mp_cache: Align end size to cache boundary in ↵Lad Prabhakar1-0/+4
ax45mp_dma_cache_wback() Align the end size to cache boundary size in ax45mp_dma_cache_wback() callback likewise done in ax45mp_dma_cache_inv() callback. Additionally return early in case of start == end. Fixes: d34599bcd2e4 ("cache: Add L2 cache management for Andes AX45MP RISC-V core") Reported-by: Pavel Machek <pavel@denx.de> Link: https://lore.kernel.org/cip-dev/ZYsdKDiw7G+kxQ3m@duo.ucw.cz/ Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Notes: Fixes: d34599bcd2e4 ("cache: Add L2 cache management for Andes AX45MP RISC-V core") # v6.6-rc1 Stable: 50b30655b224 # v6.6.19 Lore: https://lore.kernel.org/r/20240203212640.129797-1-prabhakar.mahadev-lad.rj@bp.renesas.com # linux-renesas-soc, linux-riscv, lkml Lore: https://lore.kernel.org/r/20240227131634.250191003@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.751326122@linuxfoundation.org # linux-patches, stable
2024-02-21bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()Shigeru Yoshida1-2/+5
syzbot reported the following NULL pointer dereference issue [1]: BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:0x0 [...] Call Trace: <TASK> sk_psock_verdict_data_ready+0x232/0x340 net/core/skmsg.c:1230 unix_stream_sendmsg+0x9b4/0x1230 net/unix/af_unix.c:2293 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 If sk_psock_verdict_data_ready() and sk_psock_stop_verdict() are called concurrently, psock->saved_data_ready can be NULL, causing the above issue. This patch fixes this issue by calling the appropriate data ready function using the sk_psock_data_ready() helper and protecting it from concurrency with sk->sk_callback_lock. Fixes: 6df7f764cd3c ("bpf, sockmap: Wake up polling after data copy") Reported-by: syzbot+fd7b34375c1c8ce29c93@syzkaller.appspotmail.com Signed-off-by: Shigeru Yoshida <syoshida@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: syzbot+fd7b34375c1c8ce29c93@syzkaller.appspotmail.com Acked-by: John Fastabend <john.fastabend@gmail.com> Closes: https://syzkaller.appspot.com/bug?extid=fd7b34375c1c8ce29c93 [1] Link: https://lore.kernel.org/bpf/20240218150933.6004-1-syoshida@redhat.com Notes: Fixes: 6df7f764cd3c ("bpf, sockmap: Wake up polling after data copy") # v6.4-rc4 Fixes-stable: dd628fc697ee ("bpf, sockmap: Wake up polling after data copy") # v6.1.32 Stable: 9b099ed46dca # v6.6.19 Stable: 4588b13abcbd # v6.1.80 Lore: https://lore.kernel.org/r/20240218150933.6004-1-syoshida@redhat.com # bpf, lkml, netdev Lore: https://lore.kernel.org/r/20240227131615.859367107@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.220340952@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.720755218@linuxfoundation.org # linux-patches, stable Syzbot: https://syzkaller.appspot.com/bug?extid=fd7b34375c1c8ce29c93
2024-02-21fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaioBart Van Assche2-1/+10
If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the following kernel warning appears: WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Call trace: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is submitted by libaio. Suggested-by: Jens Axboe <axboe@kernel.dk> Cc: Christoph Hellwig <hch@lst.de> Cc: Avi Kivity <avi@scylladb.com> Cc: Sandeep Dhavale <dhavale@google.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: stable@vger.kernel.org Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20240215204739.2677806-2-bvanassche@acm.org Signed-off-by: Christian Brauner <brauner@kernel.org> Notes: Fixed-by: 961ebd120565 ("fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion") # master Stable: e7e23fc5d5fe # v6.6.19 Stable: 18f614369def # v6.1.80 Stable: d7b6fa97ec89 # v5.15.150 Stable: ea1cd64d59f2 # v5.10.211 Stable: b4eea7a05ee0 # v5.4.270 Stable: 337b543e274f # v4.19.308 Lore: https://lore.kernel.org/r/20240215204739.2677806-2-bvanassche@acm.org # linux-fsdevel, stable Lore: https://lore.kernel.org/r/20240226192950.4136472-1-bvanassche@acm.org # stable Lore: https://lore.kernel.org/r/20240226193234.4177638-1-bvanassche@acm.org # stable Lore: https://lore.kernel.org/r/20240226193421.16169-1-bvanassche@acm.org # stable Lore: https://lore.kernel.org/r/20240226193604.59623-1-bvanassche@acm.org # stable Lore: https://lore.kernel.org/r/20240226193726.93631-1-bvanassche@acm.org # stable Lore: https://lore.kernel.org/r/20240227131550.210449345@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131555.580101633@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131602.630277329@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131616.612391729@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.962672342@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131630.535091139@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.535878649@linuxfoundation.org # linux-patches, stable
2024-02-21ring-buffer: Do not let subbuf be bigger than write maskSteven Rostedt (Google)1-0/+4
The data on the subbuffer is measured by a write variable that also contains status flags. The counter is just 20 bits in length. If the subbuffer is bigger than then counter, it will fail. Make sure that the subbuffer can not be set to greater than the counter that keeps track of the data on the subbuffer. Link: https://lore.kernel.org/linux-trace-kernel/20240220095112.77e9cb81@gandalf.local.home Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Fixes: 2808e31ec12e5 ("ring-buffer: Add interface for configuring trace sub buffer size") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Notes: Fixes: 2808e31ec12e ("ring-buffer: Add interface for configuring trace sub buffer size") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240220095112.77e9cb81@gandalf.local.home # linux-trace-kernel, lkml
2024-02-21s390: use the correct count for __iowrite64_copy()Jason Gunthorpe1-1/+1
The signature for __iowrite64_copy() requires the number of 64 bit quantities, not bytes. Multiple by 8 to get to a byte length before invoking zpci_memcpy_toio() Fixes: 87bc359b9822 ("s390/pci: speed up __iowrite64_copy by using pci store block insn") Acked-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/0-v1-9223d11a7662+1d7785-s390_iowrite64_jgg@nvidia.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Notes: Fixes: 87bc359b9822 ("s390/pci: speed up __iowrite64_copy by using pci store block insn") # v3.8-rc1 Stable: ef6566d10cf7 # v6.6.19 Stable: 11277d189267 # v6.1.80 Stable: 39603a6d4e71 # v5.15.150 Stable: 5d4e4eff791d # v5.10.211 Stable: 06de2302549f # v5.4.270 Stable: 2b505745a91e # v4.19.308 Lore: https://lore.kernel.org/r/0-v1-9223d11a7662+1d7785-s390_iowrite64_jgg@nvidia.com # linux-patches, linux-s390 Lore: https://lore.kernel.org/r/20240227131550.080328801@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131555.343296328@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131602.336458681@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131615.826081545@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.563852824@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.189771997@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.689639906@linuxfoundation.org # linux-patches, stable
2024-02-21iommufd: Reject non-zero data_type if no data_len is providedJason Gunthorpe1-1/+2
Since the current design doesn't forward the data_type to the driver to check unless there is a data_len/uptr for a driver specific struct we should check and ensure that data_type is 0 if data_len is 0. Otherwise any value is permitted. Fixes: bd529dbb661d ("iommufd: Add a nested HW pagetable object") Link: https://lore.kernel.org/r/0-v1-9b1ea6869554+110c60-iommufd_ck_data_type_jgg@nvidia.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Notes: Fixes: bd529dbb661d ("iommufd: Add a nested HW pagetable object") # v6.7-rc1 Lore: https://lore.kernel.org/r/0-v1-9b1ea6869554+110c60-iommufd_ck_data_type_jgg@nvidia.com # linux-iommu, linux-patches Lore: https://lore.kernel.org/r/20240227131640.657548875@linuxfoundation.org # linux-patches, stable
2024-02-21sparc: Fix undefined reference to fb_is_primary_deviceJavier Martinez Canillas2-2/+2
Commit 55bffc8170bb ("fbdev: Split frame buffer support in FB and FB_CORE symbols") added a new FB_CORE Kconfig symbol, that can be enabled to only have fbcon/VT and DRM fbdev emulation, but without support for any legacy fbdev driver. Unfortunately, it missed to change the CONFIG_FB in arch/sparc makefiles, which leads to the following linking error in some sparc64 configurations: sparc64-linux-ld: drivers/video/fbdev/core/fbcon.o: in function `fbcon_fb_registered': >> fbcon.c:(.text+0x4f60): undefined reference to `fb_is_primary_device' Fixes: 55bffc8170bb ("fbdev: Split frame buffer support in FB and FB_CORE symbols") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202401290306.IV8rhJ02-lkp@intel.com/ Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: <stable@vger.kernel.org> # v6.6+ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240220095428.3341195-1-javierm@redhat.com Notes: Fixes: 55bffc8170bb ("fbdev: Split frame buffer support in FB and FB_CORE symbols") # v6.6-rc1 Stable: 8b004583dbc9 # v6.6.19 Lore: https://lore.kernel.org/r/20240220003433.3316148-1-javierm@redhat.com # lkml, oe-kbuild-all, sparclinux Lore: https://lore.kernel.org/r/20240220095428.3341195-1-javierm@redhat.com # lkml, oe-kbuild-all, sparclinux Lore: https://lore.kernel.org/r/20240227131631.160053744@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.447518418@linuxfoundation.org # linux-patches, stable
2024-02-21MAINTAINERS: Add framer headers to NETWORKING [GENERAL]Simon Horman1-0/+2
The cited commit [1] added framer support under drivers/net/wan, which is covered by NETWORKING [GENERAL]. And it is implied that framer-provider.h and framer.h, which were also added buy the same patch, are also maintained as part of NETWORKING [GENERAL]. Make this explicit by adding these files to the corresponding section in MAINTAINERS. [1] 82c944d05b1a ("net: wan: Add framer framework support") Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Herve Codina <herve.codina@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-21af_unix: Drop oob_skb ref before purging queue in GC.Kuniyuki Iwashima1-13/+9
syzbot reported another task hung in __unix_gc(). [0] The current while loop assumes that all of the left candidates have oob_skb and calling kfree_skb(oob_skb) releases the remaining candidates. However, I missed a case that oob_skb has self-referencing fd and another fd and the latter sk is placed before the former in the candidate list. Then, the while loop never proceeds, resulting the task hung. __unix_gc() has the same loop just before purging the collected skb, so we can call kfree_skb(oob_skb) there and let __skb_queue_purge() release all inflight sockets. [0]: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 2784 Comm: kworker/u4:8 Not tainted 6.8.0-rc4-syzkaller-01028-g71b605d32017 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: events_unbound __unix_gc RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:200 Code: 89 fb e8 23 00 00 00 48 8b 3d 84 f5 1a 0c 48 89 de 5b e9 43 26 57 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f 1e fa 48 8b 04 24 65 48 8b 0d 90 52 70 7e 65 8b 15 91 52 70 RSP: 0018:ffffc9000a17fa78 EFLAGS: 00000287 RAX: ffffffff8a0a6108 RBX: ffff88802b6c2640 RCX: ffff88802c0b3b80 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffc9000a17fbf0 R08: ffffffff89383f1d R09: 1ffff1100ee5ff84 R10: dffffc0000000000 R11: ffffed100ee5ff85 R12: 1ffff110056d84ee R13: ffffc9000a17fae0 R14: 0000000000000000 R15: ffffffff8f47b840 FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffef5687ff8 CR3: 0000000029b34000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> __unix_gc+0xe69/0xf40 net/unix/garbage.c:343 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x913/0x1420 kernel/workqueue.c:2706 worker_thread+0xa5f/0x1000 kernel/workqueue.c:2787 kthread+0x2ef/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 </TASK> Reported-and-tested-by: syzbot+ecab4d36f920c3574bf9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ecab4d36f920c3574bf9 Fixes: 25236c91b5ab ("af_unix: Fix task hung while purging oob_skb in GC.") Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 25236c91b5ab ("af_unix: Fix task hung while purging oob_skb in GC.") # v6.8-rc5 Fixes-stable: 69e0f04460f4 ("af_unix: Fix task hung while purging oob_skb in GC.") # v6.6.21 Fixes-stable: 2a3d40b4025f ("af_unix: Fix task hung while purging oob_skb in GC.") # v6.1.81 Fixes-stable: 36f7371de977 ("af_unix: Fix task hung while purging oob_skb in GC.") # v5.15.149 Stable: e9eac260369d # v6.6.21 Stable: c4c795b21dd2 # v6.1.81 Stable: 6c480d0f1318 # v5.15.151 Lore: https://lore.kernel.org/r/20240219174657.6047-1-kuniyu@amazon.com # netdev Lore: https://lore.kernel.org/r/20240304211544.833096606@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240304211553.628661477@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240304211555.983949547@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240304211603.222980327@linuxfoundation.org # linux-patches, stable Syzbot: https://syzkaller.appspot.com/bug?extid=ecab4d36f920c3574bf9
2024-02-21net: ipa: don't overrun IPA suspend interrupt registersAlex Elder1-1/+1
In newer hardware, IPA supports more than 32 endpoints. Some registers--such as IPA interrupt registers--represent endpoints as bits in a 4-byte register, and such registers are repeated as needed to represent endpoints beyond the first 32. In ipa_interrupt_suspend_clear_all(), we clear all pending IPA suspend interrupts by reading all status register(s) and writing corresponding registers to clear interrupt conditions. Unfortunately the number of registers to read/write is calculated incorrectly, and as a result we access *many* more registers than intended. This bug occurs only when the IPA hardware signals a SUSPEND interrupt, which happens when a packet is received for an endpoint (or its underlying GSI channel) that is suspended. This situation is difficult to reproduce, but possible. Fix this by correctly computing the number of interrupt registers to read and write. This is the only place in the code where registers that map endpoints or channels this way perform this calculation. Fixes: f298ba785e2d ("net: ipa: add a parameter to suspend registers") Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: f298ba785e2d ("net: ipa: add a parameter to suspend registers") # v6.2-rc1 Stable: 0a32395fd1e3 # v6.6.19 Lore: https://lore.kernel.org/r/20240218190450.331390-1-elder@linaro.org # linux-arm-msm, lkml, netdev Lore: https://lore.kernel.org/r/20240219144015.355462-1-elder@linaro.org # linux-arm-msm, lkml, netdev
2024-02-21net: implement lockless setsockopt(SO_PEEK_OFF)Eric Dumazet3-34/+15
syzbot reported a lockdep violation [1] involving af_unix support of SO_PEEK_OFF. Since SO_PEEK_OFF is inherently not thread safe (it uses a per-socket sk_peek_off field), there is really no point to enforce a pointless thread safety in the kernel. After this patch : - setsockopt(SO_PEEK_OFF) no longer acquires the socket lock. - skb_consume_udp() no longer has to acquire the socket lock. - af_unix no longer needs a special version of sk_set_peek_off(), because it does not lock u->iolock anymore. As a followup, we could replace prot->set_peek_off to be a boolean and avoid an indirect call, since we always use sk_set_peek_off(). [1] WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Not tainted syz-executor.2/30025 is trying to acquire lock: ffff8880765e7d80 (&u->iolock){+.+.}-{3:3}, at: unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789 but task is already holding lock: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_UNIX){+.+.}-{0:0}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_nested+0x48/0x100 net/core/sock.c:3524 lock_sock include/net/sock.h:1691 [inline] __unix_dgram_recvmsg+0x1275/0x12c0 net/unix/af_unix.c:2415 sock_recvmsg_nosec+0x18e/0x1d0 net/socket.c:1046 ____sys_recvmsg+0x3c0/0x470 net/socket.c:2801 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 -> #0 (&u->iolock){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789 sk_setsockopt+0x207e/0x3360 do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307 __sys_setsockopt+0x1ad/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_UNIX); lock(&u->iolock); lock(sk_lock-AF_UNIX); lock(&u->iolock); *** DEADLOCK *** 1 lock held by syz-executor.2/30025: #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193 stack backtrace: CPU: 0 PID: 30025 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187 check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789 sk_setsockopt+0x207e/0x3360 do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307 __sys_setsockopt+0x1ad/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f78a1c7dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f78a0fde0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007f78a1dac050 RCX: 00007f78a1c7dda9 RDX: 000000000000002a RSI: 0000000000000001 RDI: 0000000000000006 RBP: 00007f78a1cca47a R08: 0000000000000004 R09: 0000000000000000 R10: 0000000020000180 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f78a1dac050 R15: 00007ffe5cd81ae8 Fixes: 859051dd165e ("bpf: Implement cgroup sockaddr hooks for unix sockets") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Cc: Daan De Meyer <daan.j.demeyer@gmail.com> Cc: Kuniyuki Iwashima <kuniyu@amazon.com> Cc: Martin KaFai Lau <martin.lau@kernel.org> Cc: David Ahern <dsahern@kernel.org> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 859051dd165e ("bpf: Implement cgroup sockaddr hooks for unix sockets") # v6.7-rc1 Lore: https://lore.kernel.org/r/20240219141220.908047-1-edumazet@google.com # netdev Lore: https://lore.kernel.org/r/20240227131640.594841376@linuxfoundation.org # linux-patches, stable
2024-02-21octeontx2-af: Consider the action set by PFSubbaraya Sundeep1-0/+4
AF reserves MCAM entries for each PF, VF present in the system and populates the entry with DMAC and action with default RSS so that basic packet I/O works. Since PF/VF is not aware of the RSS action installed by AF, AF only fixup the actions of the rules installed by PF/VF with corresponding default RSS action. This worked well for rules installed by PF/VF for features like RX VLAN offload and DMAC filters but rules involving action like drop/forward to queue are also getting modified by AF. Hence fix it by setting the default RSS action only if requested by PF/VF. Fixes: 967db3529eca ("octeontx2-af: add support for multicast/promisc packet replication feature") Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 967db3529eca ("octeontx2-af: add support for multicast/promisc packet replication feature") # v5.14-rc1 Stable: 734b494eac2f # v6.6.19 Stable: 18580e48e624 # v6.1.80 Stable: 8cae520f21ad # v5.15.150 Lore: https://lore.kernel.org/r/1708347314-21624-1-git-send-email-sbhatta@marvell.com # lkml, netdev Lore: https://lore.kernel.org/r/20240227131615.793411317@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.533118000@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.130459863@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.564029844@linuxfoundation.org # linux-patches, stable
2024-02-21Merge tag 'kvmarm-fixes-6.8-3' of ↵Paolo Bonzini1-0/+5
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 6.8, take #3 - Check for the validity of interrupts handled by a MOVALL command - Check for the validity of interrupts while reading the pending state on enabling LPIs.
2024-02-21drm/xe: Fix modpost warning on xe_mocs kunit moduleAshutosh Dixit1-0/+1
$ make W=1 -j100 M=drivers/gpu/drm/xe MODPOST drivers/gpu/drm/xe/Module.symvers WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/xe/tests/xe_mocs_test.o Fix is identical to '1d425066f15f ("drm/xe: Fix modpost warning on kunit modules")'. Fixes: a6a4ea6d7d37 ("drm/xe: Add mocs kunit") Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit bb619d71224ea85ec94e0a83b2bb82ebe7df2a41) Link: https://patchwork.freedesktop.org/patch/msgid/20240213033548.76219-1-ashutosh.dixit@intel.com Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Notes: Fixes: a6a4ea6d7d37 ("drm/xe: Add mocs kunit") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240213033548.76219-1-ashutosh.dixit@intel.com # intel-xe
2024-02-21KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handlerOliver Upton1-0/+2
It is possible that an LPI mapped in a different ITS gets unmapped while handling the MOVALL command. If that is the case, there is no state that can be migrated to the destination. Silently ignore it and continue migrating other LPIs. Cc: stable@vger.kernel.org Fixes: ff9c114394aa ("KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE") Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240221092732.4126848-3-oliver.upton@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org> Notes: Fixes: ff9c114394aa ("KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE") # v4.15-rc1 Stable: fcf90b4703bd # v6.6.19 Stable: 72fdbc728c33 # v6.1.80 Stable: 4deb8413eccb # v5.15.150 Stable: 615af9cb3e70 # v5.10.211 Stable: 9d17e7350403 # v5.4.270 Stable: e7908309867e # v4.19.308 Lore: https://lore.kernel.org/r/20240221092732.4126848-3-oliver.upton@linux.dev # kvmarm, stable Lore: https://lore.kernel.org/r/20240226213822.1228736-3-oliver.upton@linux.dev # stable Lore: https://lore.kernel.org/r/20240226215612.1387774-3-oliver.upton@linux.dev # stable Lore: https://lore.kernel.org/r/20240227131550.178198134@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131552.946973582@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131601.225565731@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131613.871883250@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131617.901798585@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131631.221285443@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.750697106@linuxfoundation.org # linux-patches, stable
2024-02-21KVM: arm64: vgic-its: Test for valid IRQ in its_sync_lpi_pending_table()Oliver Upton1-0/+3
vgic_get_irq() may not return a valid descriptor if there is no ITS that holds a valid translation for the specified INTID. If that is the case, it is safe to silently ignore it and continue processing the LPI pending table. Cc: stable@vger.kernel.org Fixes: 33d3bc9556a7 ("KVM: arm64: vgic-its: Read initial LPI pending table") Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240221092732.4126848-2-oliver.upton@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org> Notes: Fixes: 33d3bc9556a7 ("KVM: arm64: vgic-its: Read initial LPI pending table") # v4.8-rc1 Stable: 3f70ed98f776 # v6.6.19 Stable: 3ac3624a74cf # v6.1.80 Stable: d81e2dc20395 # v5.15.150 Stable: 6e5069b40fb4 # v5.10.211 Stable: 68799371c9c1 # v5.4.270 Stable: c2462b26faab # v4.19.308 Lore: https://lore.kernel.org/r/20240221092732.4126848-2-oliver.upton@linux.dev # kvmarm, stable Lore: https://lore.kernel.org/r/20240226213822.1228736-2-oliver.upton@linux.dev # stable Lore: https://lore.kernel.org/r/20240226215612.1387774-2-oliver.upton@linux.dev # stable Lore: https://lore.kernel.org/r/20240227131550.145939523@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131552.915484885@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131601.257628033@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131613.903749245@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131617.932501709@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131631.250930034@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.788638122@linuxfoundation.org # linux-patches, stable
2024-02-21drm/xe/xe_gt_idle: Drop redundant newline in nameAshutosh Dixit1-2/+2
Newline in name is redunant and produces an unnecessary empty line during 'cat name'. Newline is added during sysfs_emit. See '27a1a1e2e47d ("drm/xe: stringify the argument to avoid potential vulnerability")'. v2: Add Fixes tag (Riana) Fixes: 7b076d14f21a ("drm/xe/mtl: Add support to get C6 residency/status of MTL") Reviewed-by: Riana Tauro <riana.tauro@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> (cherry picked from commit e5626eb80026c4b63f8682cdeca1456303c65791) Link: https://patchwork.freedesktop.org/patch/msgid/20240206192731.3533608-1-ashutosh.dixit@intel.com Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Notes: Fixes: 7b076d14f21a ("drm/xe/mtl: Add support to get C6 residency/status of MTL") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240202223525.3221158-1-ashutosh.dixit@intel.com # intel-xe Lore: https://lore.kernel.org/r/20240202225623.3225443-1-ashutosh.dixit@intel.com # intel-xe Lore: https://lore.kernel.org/r/20240206192731.3533608-1-ashutosh.dixit@intel.com # intel-xe
2024-02-21drm/xe: Return 2MB page size for compact 64k PTEsMatthew Brost3-2/+6
Compact 64k PTEs are only intended to be used within a single VMA which covers the entire 2MB range of the compact 64k PTEs. Add XE_VMA_PTE_COMPACT VMA flag to indicate compact 64k PTEs are used and update xe_vma_max_pte_size to return at least 2MB if set. v2: Include missing changes Fixes: 8f33b4f054fc ("drm/xe: Avoid doing rebinds") Fixes: c47794bdd63d ("drm/xe: Set max pte size when skipping rebinds") Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/758 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219211942.3633795-4-matthew.brost@intel.com (cherry picked from commit 0f688c0eb63a643ef0568b29b12cefbb23181e1a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Notes: Fixes: 8f33b4f054fc ("drm/xe: Avoid doing rebinds") # v6.8-rc1 Fixes: c47794bdd63d ("drm/xe: Set max pte size when skipping rebinds") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240219211616.3633630-4-matthew.brost@intel.com # intel-xe Lore: https://lore.kernel.org/r/20240219211942.3633795-4-matthew.brost@intel.com # intel-xe
2024-02-21drm/xe: Add XE_VMA_PTE_64K VMA flagMatthew Brost3-2/+10
Add XE_VMA_PTE_64K VMA flag to ensure skipping rebinds does not cross 64k page boundaries. Fixes: 8f33b4f054fc ("drm/xe: Avoid doing rebinds") Fixes: c47794bdd63d ("drm/xe: Set max pte size when skipping rebinds") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219211942.3633795-3-matthew.brost@intel.com (cherry picked from commit 15f0e0c2c46dddd8ee56d9b3db679fd302cc4b91) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Notes: Fixes: 8f33b4f054fc ("drm/xe: Avoid doing rebinds") # v6.8-rc1 Fixes: c47794bdd63d ("drm/xe: Set max pte size when skipping rebinds") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240219211616.3633630-3-matthew.brost@intel.com # intel-xe Lore: https://lore.kernel.org/r/20240219211942.3633795-3-matthew.brost@intel.com # intel-xe
2024-02-21drm/xe: Fix xe_vma_set_pte_sizeMatthew Brost1-3/+4
xe_vma_set_pte_size had a return value and did not set the 4k VMA flag. Both of these were incorrect. Fix these. Fixes: c47794bdd63d ("drm/xe: Set max pte size when skipping rebinds") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219211942.3633795-2-matthew.brost@intel.com (cherry picked from commit 19adaccef8b246182dc89a7470aa7758245efd5d) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Notes: Fixes: c47794bdd63d ("drm/xe: Set max pte size when skipping rebinds") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240219211616.3633630-2-matthew.brost@intel.com # intel-xe Lore: https://lore.kernel.org/r/20240219211942.3633795-2-matthew.brost@intel.com # intel-xe
2024-02-21drm/xe/uapi: Remove support for persistent exec_queuesThomas Hellström8-94/+5
Persistent exec_queues delays explicit destruction of exec_queues until they are done executing, but destruction on process exit is still immediate. It turns out no UMD is relying on this functionality, so remove it. If there turns out to be a use-case in the future, let's re-add. Persistent exec_queues were never used for LR VMs v2: - Don't add an "UNUSED" define for the missing property (Lucas, Rodrigo) v3: - Remove the remaining struct xe_exec_queue::persistent state (Niranjana, Lucas) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240209113444.8396-1-thomas.hellstrom@linux.intel.com (cherry picked from commit f1a9abc0cf311375695bede1590364864c05976d) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Notes: Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240130125220.5517-1-thomas.hellstrom@linux.intel.com # intel-xe Lore: https://lore.kernel.org/r/20240208083845.4303-1-thomas.hellstrom@linux.intel.com # intel-xe Lore: https://lore.kernel.org/r/20240209113444.8396-1-thomas.hellstrom@linux.intel.com # intel-xe
2024-02-21drm/i915/tv: Fix TV modeMaxime Ripard2-10/+10
Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed to update all the users of the struct drm_tv_connector_state mode field, which resulted in a build failure in i915. However, a subsequent commit in the same series reintroduced a mode field in that structure, with a different semantic but the same type, with the assumption that all previous users were updated. Since that didn't happen, the i915 driver now compiles, but mixes accesses to the legacy_mode field and the newer mode field, but with the previous semantics. This obviously doesn't work very well, so we need to update the accesses that weren't in the legacy renaming commit. Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220131251.453060-1-mripard@kernel.org (cherry picked from commit bf7626f19d6ff14b9722273e23700400cc4d78ba) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Notes: Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") # v6.3-rc1 Stable: 16bc939f224d # v6.6.19 Lore: https://lore.kernel.org/r/20240220131251.453060-1-mripard@kernel.org # dri-devel, intel-gfx, intel-xe Lore: https://lore.kernel.org/r/20240227131634.100768741@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.300610856@linuxfoundation.org # linux-patches, stable
2024-02-20Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds15-36/+84
Pull rdma fixes from Jason Gunthorpe: "Mostly irdma and bnxt_re fixes: - Missing error unwind in hf1 - For bnxt - fix fenching behavior to work on new chips, fail unsupported SRQ resize back to userspace, propogate SRQ FW failure back to userspace. - Correctly fail unsupported SRQ resize back to userspace in bnxt - Adjust a memcpy in mlx5 to not overflow a struct field. - Prevent userspace from triggering mlx5 fw syndrome logging from sysfs - Use the correct access mode for MLX5_IB_METHOD_DEVX_OBJ_MODIFY to avoid a userspace failure on modify - For irdma - Don't UAF a concurrent tasklet during destroy, prevent userspace from issuing invalid QP attrs, fix a possible CQ overflow, capture a missing HW async error event - sendmsg() triggerable memory access crash in hfi1 - Fix the srpt_service_guid parameter to not crash due to missing function pointer - Don't leak objects in error unwind in qedr - Don't weirdly cast function pointers in srpt" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: RDMA/srpt: fix function pointer cast warnings RDMA/qedr: Fix qedr_create_user_qp error flow RDMA/srpt: Support specifying the srpt_service_guid parameter IB/hfi1: Fix sdma.h tx->num_descs off-by-one error RDMA/irdma: Add AE for too many RNRS RDMA/irdma: Set the CQ read threshold for GEN 1 RDMA/irdma: Validate max_send_wr and max_recv_wr RDMA/irdma: Fix KASAN issue with tasklet RDMA/mlx5: Relax DEVX access upon modify commands IB/mlx5: Don't expose debugfs entries for RRoCE general parameters if not supported RDMA/mlx5: Fix fortify source warning while accessing Eth segment RDMA/bnxt_re: Add a missing check in bnxt_qplib_query_srq RDMA/bnxt_re: Return error for SRQ resize RDMA/bnxt_re: Fix unconditional fence for newer adapters RDMA/bnxt_re: Remove a redundant check inside bnxt_re_vf_res_config RDMA/bnxt_re: Avoid creating fence MR for newer adapters IB/hfi1: Fix a memleak in init_credit_return
2024-02-20kasan: guard release_free_meta() shadow access with kasan_arch_is_ready()Benjamin Gray1-0/+3
release_free_meta() accesses the shadow directly through the path kasan_slab_free __kasan_slab_free kasan_release_object_meta release_free_meta kasan_mem_to_shadow There are no kasan_arch_is_ready() guards here, allowing an oops when the shadow is not initialized. The oops can be seen on a Power8 KVM guest. This patch adds the guard to release_free_meta(), as it's the first level that specifically requires the shadow. It is safe to put the guard at the start of this function, before the stack put: only kasan_save_free_info() can initialize the saved stack, which itself is guarded with kasan_arch_is_ready() by its caller poison_slab_object(). If the arch becomes ready before release_free_meta() then we will not observe KASAN_SLAB_FREE_META in the object's shadow, so we will not put an uninitialized stack either. Link: https://lkml.kernel.org/r/20240213033958.139383-1-bgray@linux.ibm.com Fixes: 63b85ac56a64 ("kasan: stop leaking stack trace handles") Signed-off-by: Benjamin Gray <bgray@linux.ibm.com> Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: 63b85ac56a64 ("kasan: stop leaking stack trace handles") # v6.8-rc1
2024-02-20mm/damon/lru_sort: fix quota status loss due to online tuningsSeongJae Park1-7/+36
For online parameters change, DAMON_LRU_SORT creates new schemes based on latest values of the parameters and replaces the old schemes with the new one. When creating it, the internal status of the quotas of the old schemes is not preserved. As a result, charging of the quota starts from zero after the online tuning. The data that collected to estimate the throughput of the scheme's action is also reset, and therefore the estimation should start from the scratch again. Because the throughput estimation is being used to convert the time quota to the effective size quota, this could result in temporal time quota inaccuracy. It would be recovered over time, though. In short, the quota accuracy could be temporarily degraded after online parameters update. Fix the problem by checking the case and copying the internal fields for the status. Link: https://lkml.kernel.org/r/20240216194025.9207-3-sj@kernel.org Fixes: 40e983cca927 ("mm/damon: introduce DAMON-based LRU-lists Sorting") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> [6.0+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: 40e983cca927 ("mm/damon: introduce DAMON-based LRU-lists Sorting") # v6.0-rc1 Stable: 3c4441b23bf7 # v6.6.19 Stable: 4c815c3a4834 # v6.1.80 Lore: https://lore.kernel.org/r/20240216194025.9207-3-sj@kernel.org # damon, linux-mm, lkml, stable Lore: https://lore.kernel.org/r/20240227131613.676788177@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131630.972857586@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.090852858@linuxfoundation.org # linux-patches, stable
2024-02-20mm/damon/reclaim: fix quota stauts loss due to online tuningsSeongJae Park1-1/+17
Patch series "mm/damon: fix quota status loss due to online tunings". DAMON_RECLAIM and DAMON_LRU_SORT is not preserving internal quota status when applying new user parameters, and hence could cause temporal quota accuracy degradation. Fix it by preserving the status. This patch (of 2): For online parameters change, DAMON_RECLAIM creates new scheme based on latest values of the parameters and replaces the old scheme with the new one. When creating it, the internal status of the quota of the old scheme is not preserved. As a result, charging of the quota starts from zero after the online tuning. The data that collected to estimate the throughput of the scheme's action is also reset, and therefore the estimation should start from the scratch again. Because the throughput estimation is being used to convert the time quota to the effective size quota, this could result in temporal time quota inaccuracy. It would be recovered over time, though. In short, the quota accuracy could be temporarily degraded after online parameters update. Fix the problem by checking the case and copying the internal fields for the status. Link: https://lkml.kernel.org/r/20240216194025.9207-1-sj@kernel.org Link: https://lkml.kernel.org/r/20240216194025.9207-2-sj@kernel.org Fixes: e035c280f6df ("mm/damon/reclaim: support online inputs update") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> [5.19+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: e035c280f6df ("mm/damon/reclaim: support online inputs update") # v5.19-rc1 Stable: 9cad9a2e896c # v6.6.19 Stable: 7ebeee513f8f # v6.1.80 Lore: https://lore.kernel.org/r/20240216194025.9207-2-sj@kernel.org # damon, linux-mm, lkml, stable Lore: https://lore.kernel.org/r/20240227051335.168121-1-sj@kernel.org # damon, linux-mm, lkml, stable Lore: https://lore.kernel.org/r/20240227131616.573533752@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131631.040373204@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.208291226@linuxfoundation.org # linux-patches, stable
2024-02-20MAINTAINERS: mailmap: update Shakeel's email addressShakeel Butt2-1/+2
Moving to linux.dev based email for kernel work. Link: https://lkml.kernel.org/r/20240219205050.887810-1-shakeel.butt@linux.dev Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-02-20mm/damon/sysfs-schemes: handle schemes sysfs dir removal before ↵SeongJae Park1-0/+4
commit_schemes_quota_goals 'commit_schemes_quota_goals' command handler, damos_sysfs_set_quota_scores() assumes the number of schemes sysfs directory will be same to the number of schemes of the DAMON context. The assumption is wrong since users can remove schemes sysfs directories while DAMON is running. In the case, illegal memory accesses can happen. Fix it by checking the case. Link: https://lkml.kernel.org/r/20240213023633.124928-1-sj@kernel.org Fixes: d91beaa505a0 ("mm/damon/sysfs-schemes: implement a command for scheme quota goals only commit") Signed-off-by: SeongJae Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: d91beaa505a0 ("mm/damon/sysfs-schemes: implement a command for scheme quota goals only commit") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240213023633.124928-1-sj@kernel.org # damon, linux-mm, lkml
2024-02-20mm: memcontrol: clarify swapaccount=0 deprecation warningJohannes Weiner1-3/+7
The swapaccount deprecation warning is throwing false positives. Since we deprecated the knob and defaulted to enabling, the only reports we've been getting are from folks that set swapaccount=1. While this is a nice affirmation that always-enabling was the right choice, we certainly don't want to warn when users request the supported mode. Only warn when disabling is requested, and clarify the warning. [colin.i.king@gmail.com: spelling: "commdandline" -> "commandline"] Link: https://lkml.kernel.org/r/20240215090544.1649201-1-colin.i.king@gmail.com Link: https://lkml.kernel.org/r/20240213081634.3652326-1-hannes@cmpxchg.org Fixes: b25806dcd3d5 ("mm: memcontrol: deprecate swapaccounting=0 mode") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reported-by: "Jonas Schäfer" <jonas@wielicki.name> Reported-by: Narcis Garcia <debianlists@actiu.net> Suggested-by: Yosry Ahmed <yosryahmed@google.com> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reviewed-by: Yosry Ahmed <yosryahmed@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Shakeel Butt <shakeelb@google.com> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: b25806dcd3d5 ("mm: memcontrol: deprecate swapaccounting=0 mode") # v6.1-rc1 Stable: 8350888b0226 # v6.6.19 Stable: 19e5dc2e6bf7 # v6.1.80 Lore: https://lore.kernel.org/r/20240213081634.3652326-1-hannes@cmpxchg.org # cgroups, linux-mm, lkml Lore: https://lore.kernel.org/r/20240227131613.709997610@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131631.009790249@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.129546768@linuxfoundation.org # linux-patches, stable
2024-02-20mm/memblock: add MEMBLOCK_RSRV_NOINIT into flagname[] arrayAnshuman Khandual1-0/+1
The commit 77e6c43e137c ("memblock: introduce MEMBLOCK_RSRV_NOINIT flag") skipped adding this newly introduced memblock flag into flagname[] array, thus preventing a correct memblock flags output for applicable memblock regions. Link: https://lkml.kernel.org/r/20240209030912.1382251-1-anshuman.khandual@arm.com Fixes: 77e6c43e137c ("memblock: introduce MEMBLOCK_RSRV_NOINIT flag") Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Reviewed-by: Mike Rapoport <rppt@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: 77e6c43e137c ("memblock: introduce MEMBLOCK_RSRV_NOINIT flag") # v6.7-rc1 Lore: https://lore.kernel.org/r/20240209030912.1382251-1-anshuman.khandual@arm.com # linux-mm, lkml Lore: https://lore.kernel.org/r/20240227131636.248497324@linuxfoundation.org # linux-patches, stable
2024-02-20mm/zswap: invalidate duplicate entry when !zswap_enabledChengming Zhou1-1/+5
We have to invalidate any duplicate entry even when !zswap_enabled since zswap can be disabled anytime. If the folio store success before, then got dirtied again but zswap disabled, we won't invalidate the old duplicate entry in the zswap_store(). So later lru writeback may overwrite the new data in swapfile. Link: https://lkml.kernel.org/r/20240208023254.3873823-1-chengming.zhou@linux.dev Fixes: 42c06a0e8ebe ("mm: kill frontswap") Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Nhat Pham <nphamcs@gmail.com> Cc: Yosry Ahmed <yosryahmed@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: 42c06a0e8ebe ("mm: kill frontswap") # v6.6-rc1 Stable: 7a3610956d3b # v6.6.19 Lore: https://lore.kernel.org/r/20240208023254.3873823-1-chengming.zhou@linux.dev # linux-mm, lkml, stable Lore: https://lore.kernel.org/r/20240227022540.3441860-1-chengming.zhou@linux.dev # stable Lore: https://lore.kernel.org/r/20240227022654.3442054-1-chengming.zhou@linux.dev # stable Lore: https://lore.kernel.org/r/20240227131635.068054332@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.857057816@linuxfoundation.org # linux-patches, stable
2024-02-20lib/Kconfig.debug: TEST_IOV_ITER depends on MMUGuenter Roeck1-0/+1
Trying to run the iov_iter unit test on a nommu system such as the qemu kc705-nommu emulation results in a crash. KTAP version 1 # Subtest: iov_iter # module: kunit_iov_iter 1..9 BUG: failure at mm/nommu.c:318/vmap()! Kernel panic - not syncing: BUG! The test calls vmap() directly, but vmap() is not supported on nommu systems, causing the crash. TEST_IOV_ITER therefore needs to depend on MMU. Link: https://lkml.kernel.org/r/20240208153010.1439753-1-linux@roeck-us.net Fixes: 2d71340ff1d4 ("iov_iter: Kunit tests for copying to/from an iterator") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: David Howells <dhowells@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: 2d71340ff1d4 ("iov_iter: Kunit tests for copying to/from an iterator") # v6.6-rc1 Stable: e6316749d603 # v6.6.19 Lore: https://lore.kernel.org/r/20240208153010.1439753-1-linux@roeck-us.net # lkml Lore: https://lore.kernel.org/r/20240227131630.565178217@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.569793808@linuxfoundation.org # linux-patches, stable
2024-02-20mm/swap: fix race when skipping swapcacheKairui Song4-0/+43
When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads swapin the same entry at the same time, they get different pages (A, B). Before one thread (T0) finishes the swapin and installs page (A) to the PTE, another thread (T1) could finish swapin of page (B), swap_free the entry, then swap out the possibly modified page reusing the same entry. It breaks the pte_same check in (T0) because PTE value is unchanged, causing ABA problem. Thread (T0) will install a stalled page (A) into the PTE and cause data corruption. One possible callstack is like this: CPU0 CPU1 ---- ---- do_swap_page() do_swap_page() with same entry <direct swapin path> <direct swapin path> <alloc page A> <alloc page B> swap_read_folio() <- read to page A swap_read_folio() <- read to page B <slow on later locks or interrupt> <finished swapin first> ... set_pte_at() swap_free() <- entry is free <write to page B, now page A stalled> <swap out page B to same swap entry> pte_same() <- Check pass, PTE seems unchanged, but page A is stalled! swap_free() <- page B content lost! set_pte_at() <- staled page A installed! And besides, for ZRAM, swap_free() allows the swap device to discard the entry content, so even if page (B) is not modified, if swap_read_folio() on CPU0 happens later than swap_free() on CPU1, it may also cause data loss. To fix this, reuse swapcache_prepare which will pin the swap entry using the cache flag, and allow only one thread to swap it in, also prevent any parallel code from putting the entry in the cache. Release the pin after PT unlocked. Racers just loop and wait since it's a rare and very short event. A schedule_timeout_uninterruptible(1) call is added to avoid repeated page faults wasting too much CPU, causing livelock or adding too much noise to perf statistics. A similar livelock issue was described in commit 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") Reproducer: This race issue can be triggered easily using a well constructed reproducer and patched brd (with a delay in read path) [1]: With latest 6.8 mainline, race caused data loss can be observed easily: $ gcc -g -lpthread test-thread-swap-race.c && ./a.out Polulating 32MB of memory region... Keep swapping out... Starting round 0... Spawning 65536 workers... 32746 workers spawned, wait for done... Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss! Round 0 Failed, 15 data loss! This reproducer spawns multiple threads sharing the same memory region using a small swap device. Every two threads updates mapped pages one by one in opposite direction trying to create a race, with one dedicated thread keep swapping out the data out using madvise. The reproducer created a reproduce rate of about once every 5 minutes, so the race should be totally possible in production. After this patch, I ran the reproducer for over a few hundred rounds and no data loss observed. Performance overhead is minimal, microbenchmark swapin 10G from 32G zram: Before: 10934698 us After: 11157121 us Cached: 13155355 us (Dropping SWP_SYNCHRONOUS_IO flag) [kasong@tencent.com: v4] Link: https://lkml.kernel.org/r/20240219082040.7495-1-ryncsn@gmail.com Link: https://lkml.kernel.org/r/20240206182559.32264-1-ryncsn@gmail.com Fixes: 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device") Reported-by: "Huang, Ying" <ying.huang@intel.com> Closes: https://lore.kernel.org/lkml/87bk92gqpx.fsf_-_@yhuang6-desk2.ccr.corp.intel.com/ Link: https://github.com/ryncsn/emm-test-project/tree/master/swap-stress-race [1] Signed-off-by: Kairui Song <kasong@tencent.com> Reviewed-by: "Huang, Ying" <ying.huang@intel.com> Acked-by: Yu Zhao <yuzhao@google.com> Acked-by: David Hildenbrand <david@redhat.com> Acked-by: Chris Li <chrisl@kernel.org> Cc: Hugh Dickins <hughd@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Yosry Ahmed <yosryahmed@google.com> Cc: Yu Zhao <yuzhao@google.com> Cc: Barry Song <21cnbao@gmail.com> Cc: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device") # v4.15-rc1 Stable: 305152314df8 # v6.6.19 Stable: 2dedda77d449 # v6.1.80 Lore: https://lore.kernel.org/r/20240206182559.32264-1-ryncsn@gmail.com # linux-mm, lkml, stable Lore: https://lore.kernel.org/r/20240216095105.14502-1-ryncsn@gmail.com # linux-mm, lkml, stable Lore: https://lore.kernel.org/r/20240219082040.7495-1-ryncsn@gmail.com # linux-mm, lkml, stable Lore: https://lore.kernel.org/r/20240227131613.644649376@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131630.941814285@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.045937598@linuxfoundation.org # linux-patches, stable
2024-02-20mm/swap_state: update zswap LRU's protection range with the folio lockedNhat Pham2-8/+9
When a folio is swapped in, the protection size of the corresponding zswap LRU is incremented, so that the zswap shrinker is more conservative with its reclaiming action. This field is embedded within the struct lruvec, so updating it requires looking up the folio's memcg and lruvec. However, currently this lookup can happen after the folio is unlocked, for instance if a new folio is allocated, and swap_read_folio() unlocks the folio before returning. In this scenario, there is no stability guarantee for the binding between a folio and its memcg and lruvec: * A folio's memcg and lruvec can be freed between the lookup and the update, leading to a UAF. * Folio migration can clear the now-unlocked folio's memcg_data, which directs the zswap LRU protection size update towards the root memcg instead of the original memcg. This was recently picked up by the syzbot thanks to a warning in the inlined folio_lruvec() call. Move the zswap LRU protection range update above the swap_read_folio() call, and only when a new page is allocated, to prevent this. [nphamcs@gmail.com: add VM_WARN_ON_ONCE() to zswap_folio_swapin()] Link: https://lkml.kernel.org/r/20240206180855.3987204-1-nphamcs@gmail.com [nphamcs@gmail.com: remove unneeded if (folio) checks] Link: https://lkml.kernel.org/r/20240206191355.83755-1-nphamcs@gmail.com Link: https://lkml.kernel.org/r/20240205232442.3240571-1-nphamcs@gmail.com Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") Reported-by: syzbot+17a611d10af7d18a7092@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000ae47f90610803260@google.com/ Signed-off-by: Nhat Pham <nphamcs@gmail.com> Reviewed-by: Chengming Zhou <zhouchengming@bytedance.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Yosry Ahmed <yosryahmed@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240205232442.3240571-1-nphamcs@gmail.com # linux-mm, lkml Lore: https://lore.kernel.org/r/20240206180855.3987204-1-nphamcs@gmail.com # linux-mm, lkml Syzbot: https://syzkaller.appspot.com/bug?extid=17a611d10af7d18a7092
2024-02-20selftests/mm: uffd-unit-test check if huge page size is 0Terry Tritton1-0/+6
If HUGETLBFS is not enabled then the default_huge_page_size function will return 0 and cause a divide by 0 error. Add a check to see if the huge page size is 0 and skip the hugetlb tests if it is. Link: https://lkml.kernel.org/r/20240205145055.3545806-2-terry.tritton@linaro.org Fixes: 16a45b57cbf2 ("selftests/mm: add framework for uffd-unit-test") Signed-off-by: Terry Tritton <terry.tritton@linaro.org> Cc: Peter Griffin <peter.griffin@linaro.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Peter Xu <peterx@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: 16a45b57cbf2 ("selftests/mm: add framework for uffd-unit-test") # v6.4-rc1 Stable: 0b34dca1bfd5 # v6.6.19 Lore: https://lore.kernel.org/r/20240205145055.3545806-2-terry.tritton@linaro.org # linux-kselftest, linux-mm, lkml Lore: https://lore.kernel.org/r/20240227131630.911204771@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.014085964@linuxfoundation.org # linux-patches, stable
2024-02-20mm/damon/core: check apply interval in damon_do_apply_schemes()SeongJae Park1-4/+11
kdamond_apply_schemes() checks apply intervals of schemes and avoid further applying any schemes if no scheme passed its apply interval. However, the following schemes applying function, damon_do_apply_schemes() iterates all schemes without the apply interval check. As a result, the shortest apply interval is applied to all schemes. Fix the problem by checking the apply interval in damon_do_apply_schemes(). Link: https://lkml.kernel.org/r/20240205201306.88562-1-sj@kernel.org Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> [6.7.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval") # v6.7-rc1 Lore: https://lore.kernel.org/r/20240205201306.88562-1-sj@kernel.org # damon, linux-mm, lkml, stable Lore: https://lore.kernel.org/r/20240227131636.160105212@linuxfoundation.org # linux-patches, stable
2024-02-20mm: zswap: fix missing folio cleanup in writeback race pathYosry Ahmed1-0/+2
In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely. Link: https://lkml.kernel.org/r/20240125085127.1327013-1-yosryahmed@google.com Fixes: 04fc7816089c ("mm: fix zswap writeback race condition") Signed-off-by: Yosry Ahmed <yosryahmed@google.com> Reviewed-by: Chengming Zhou <zhouchengming@bytedance.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Reviewed-by: Nhat Pham <nphamcs@gmail.com> Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Notes: Fixes: 04fc7816089c ("mm: fix zswap writeback race condition") # v6.4-rc3 Fixes-stable: 2cab13f500a6 ("mm: fix zswap writeback race condition") # v6.1.30 Stable: 6156277d1b26 # v6.6.19 Stable: 14f1992430ef # v6.1.80 Lore: https://lore.kernel.org/r/20240125085127.1327013-1-yosryahmed@google.com # linux-mm, lkml, stable Lore: https://lore.kernel.org/r/20240226220340.1238261-1-yosryahmed@google.com # stable Lore: https://lore.kernel.org/r/20240226221017.1332778-1-yosryahmed@google.com # stable Lore: https://lore.kernel.org/r/20240226221647.1425311-1-yosryahmed@google.com # stable Lore: https://lore.kernel.org/r/20240227100346.2095761-1-yosryahmed@google.com # stable Lore: https://lore.kernel.org/r/20240227131616.645069638@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.099623139@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131641.782155287@linuxfoundation.org # linux-patches, stable
2024-02-20arm64: dts: qcom: Fix interrupt-map cell sizesRob Herring2-12/+12
The PCI node interrupt-map properties have the wrong size as #address-cells in the interrupt parent are not accounted for. The dtc interrupt_map check catches this, but the warning is off because its dependency, interrupt_provider, is off by default. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-5-f2dee1292525@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Notes: Lore: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-5-f2dee1292525@kernel.org # linux-arm-msm, linux-devicetree, linux-kbuild, linux-mediatek, linux-omap, linux-renesas-soc, linux-tegra, lkml, openbmc, soc Lore: https://lore.kernel.org/r/20240229203729.2860356-22-sashal@kernel.org # linux-arm-msm, linux-devicetree, lkml, stable Lore: https://lore.kernel.org/r/20240229203933.2861006-21-sashal@kernel.org # linux-arm-msm, linux-devicetree, lkml, stable
2024-02-20arm: dts: Fix dtc interrupt_map warningsRob Herring3-4/+8
The dtc interrupt_map warning is off because its dependency, interrupt_provider, is off by default. Fix all the warnings so it can be enabled. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-4-f2dee1292525@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Notes: Lore: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-4-f2dee1292525@kernel.org # linux-arm-msm, linux-devicetree, linux-kbuild, linux-mediatek, linux-omap, linux-renesas-soc, linux-tegra, lkml, openbmc, soc Lore: https://lore.kernel.org/r/20240229203729.2860356-21-sashal@kernel.org # linux-arm-kernel, linux-arm-msm, linux-devicetree, lkml, stable Lore: https://lore.kernel.org/r/20240229203933.2861006-20-sashal@kernel.org # linux-arm-kernel, linux-arm-msm, linux-devicetree, lkml, stable
2024-02-20arm64: dts: Fix dtc interrupt_provider warningsRob Herring9-5/+7
The dtc interrupt_provider warning is off by default. Fix all the warnings so it can be enabled. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-By: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> # Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> #Broadcom Acked-by: Chanho Min <chanho.min@lge.com> Link: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-3-f2dee1292525@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Notes: Lore: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-3-f2dee1292525@kernel.org # linux-arm-msm, linux-devicetree, linux-kbuild, linux-mediatek, linux-omap, linux-renesas-soc, linux-tegra, lkml, openbmc, soc Lore: https://lore.kernel.org/r/20240229203729.2860356-20-sashal@kernel.org # linux-arm-kernel, linux-devicetree, linux-mediatek, linux-renesas-soc, lkml, stable Lore: https://lore.kernel.org/r/20240229203933.2861006-19-sashal@kernel.org # linux-arm-kernel, linux-devicetree, linux-mediatek, linux-renesas-soc, lkml, stable Lore: https://lore.kernel.org/r/20240229204039.2861519-12-sashal@kernel.org # linux-arm-kernel, linux-devicetree, linux-mediatek, linux-renesas-soc, lkml, stable
2024-02-20arm: dts: Fix dtc interrupt_provider warningsRob Herring24-58/+18
The dtc interrupt_provider warning is off by default. Fix all the warnings so it can be enabled. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Reviewed-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> #Broadcom Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-2-f2dee1292525@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Notes: Lore: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-2-f2dee1292525@kernel.org # linux-arm-msm, linux-devicetree, linux-kbuild, linux-mediatek, linux-omap, linux-renesas-soc, linux-tegra, lkml, openbmc, soc Lore: https://lore.kernel.org/r/20240229203729.2860356-19-sashal@kernel.org # linux-arm-kernel, linux-devicetree, linux-omap, linux-tegra, lkml, openbmc, stable Lore: https://lore.kernel.org/r/20240229203933.2861006-18-sashal@kernel.org # linux-arm-kernel, linux-devicetree, linux-omap, linux-tegra, lkml, openbmc, stable
2024-02-20arm64: dts: freescale: Disable interrupt_map checkRob Herring1-0/+19
Several Freescale Layerscape platforms extirq binding use a malformed interrupt-map property missing parent address cells. These are documented in of_irq_imap_abusers list in drivers/of/irq.c. In order to enable dtc interrupt_map check tree wide, we need to disable it for these platforms which will not be fixed (as that would break compatibility). Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-1-f2dee1292525@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Notes: Lore: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-1-f2dee1292525@kernel.org # linux-arm-msm, linux-devicetree, linux-kbuild, linux-mediatek, linux-omap, linux-renesas-soc, linux-tegra, lkml, openbmc, soc
2024-02-20Merge tag 'v6.8-rockchip-dtsfixes1' of ↵Arnd Bergmann10-26/+21
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes Some fixes to make devicetrees conform to bindings better (pwm irqs), dt styling fixes (unneeded jaguar status, whitespaces, Cool Pi regulator naming) and functionality fixes (px30 spi chipselect number, allowing rk3588-evb1 to turn off, pcie lane numbers on CoolPi, wrong gpio-names on Indidroid Nova and some CoolPi sdmmc aliases to match what uboot uses). * tag 'v6.8-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: Correct Indiedroid Nova GPIO Names arm64: dts: rockchip: Drop interrupts property from rk3328 pwm-rockchip node arm64: dts: rockchip: set num-cs property for spi on px30 arm64: dts: rockchip: minor rk3588 whitespace cleanup arm64: dts: rockchip: drop unneeded status from rk3588-jaguar gpio-leds ARM: dts: rockchip: Drop interrupts property from pwm-rockchip nodes arm64: dts: rockchip: Fix the num-lanes of pcie3x4 on Cool Pi CM5 EVB arm64: dts: rockchip: rename vcc5v0_usb30_host regulator for Cool Pi CM5 EVB arm64: dts: rockchip: aliase sdmmc as mmc1 for Cool Pi CM5 EVB arm64: dts: rockchip: aliase sdmmc as mmc1 for Cool Pi 4B arm64: dts: rockchip: mark system power controller on rk3588-evb1 Link: https://lore.kernel.org/r/2450634.jE0xQCEvom@phil Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-20drm/tests/drm_buddy: fix build failure on 32-bit targetsLinus Torvalds1-3/+2
Guenter Roeck reports that commit a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") causes build failures on 32-bit targets: "This patch breaks the build on all 32-bit systems since it introduces an unhandled direct 64-bit divide operation. ERROR: modpost: "__umoddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! ERROR: modpost: "__moddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined!" and the uses of 'u64' are all entirely pointless. Yes, the arguments to drm_buddy_init() and drm_buddy_alloc_blocks() are in fact of type 'u64', but none of the values here are remotely relevant, and the compiler will happily just do the type expansion. Of course, in a perfect world the compiler would also have just noticed that all the values in question are tiny, and range analysis would have shown that doing a 64-bit divide is pointless, but that is admittedly expecting a fair amount of the compiler. IOW, we shouldn't write code that the compiler then has to notice is unnecessarily complicated just to avoid extra work. We do have fairly high expectations of compilers, but kernel code should be reasonable to begin with. It turns out that there are also other issues with this code: the KUnit assertion messages have incorrect types in the format strings, but that's a widely spread issue caused by the KUnit infrastructure not having enabled format string verification. We'll get that sorted out separately. Reported-by: Guenter Roeck <linux@roeck-us.net> Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") Link: https://lore.kernel.org/all/538327ff-8d34-41d5-a9ae-1a334744f5ae@roeck-us.net/ Cc: Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Notes: Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") # v6.8-rc5
2024-02-20dm-crypt, dm-integrity, dm-verity: bump target versionMike Snitzer3-3/+3
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2024-02-20dm-verity, dm-crypt: align "struct bvec_iter" correctlyMikulas Patocka2-4/+4
"struct bvec_iter" is defined with the __packed attribute, so it is aligned on a single byte. On X86 (and on other architectures that support unaligned addresses in hardware), "struct bvec_iter" is accessed using the 8-byte and 4-byte memory instructions, however these instructions are less efficient if they operate on unaligned addresses. (on RISC machines that don't have unaligned access in hardware, GCC generates byte-by-byte accesses that are very inefficient - see [1]) This commit reorders the entries in "struct dm_verity_io" and "struct convert_context", so that "struct bvec_iter" is aligned on 8 bytes. [1] https://lore.kernel.org/all/ZcLuWUNRZadJr0tQ@fedora/T/ Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@kernel.org> Notes: Lore: https://lore.kernel.org/r/20240229203729.2860356-18-sashal@kernel.org # dm-devel, lkml, stable Lore: https://lore.kernel.org/r/20240229203933.2861006-17-sashal@kernel.org # dm-devel, lkml, stable Lore: https://lore.kernel.org/r/20240229204039.2861519-11-sashal@kernel.org # dm-devel, lkml, stable Lore: https://lore.kernel.org/r/20240229204107.2861780-9-sashal@kernel.org # dm-devel, lkml, stable Lore: https://lore.kernel.org/r/20240229204127.2861980-8-sashal@kernel.org # dm-devel, lkml, stable Lore: https://lore.kernel.org/r/20240229204150.2862196-6-sashal@kernel.org # dm-devel, lkml, stable Lore: https://lore.kernel.org/r/20240229204208.2862333-4-sashal@kernel.org # dm-devel, lkml, stable Lore: https://lore.kernel.org/r/8ebe6f5b-4941-6ca8-9445-91ae36fa2f39@redhat.com # dm-devel
2024-02-20dm-crypt: recheck the integrity tag after a failureMikulas Patocka1-16/+73
If a userspace process reads (with O_DIRECT) multiple blocks into the same buffer, dm-crypt reports an authentication error [1]. The error is reported in a log and it may cause RAID leg being kicked out of the array. This commit fixes dm-crypt, so that if integrity verification fails, the data is read again into a kernel buffer (where userspace can't modify it) and the integrity tag is rechecked. If the recheck succeeds, the content of the kernel buffer is copied into the user buffer; if the recheck fails, an integrity error is reported. [1] https://people.redhat.com/~mpatocka/testcases/blk-auth-modify/read2.c Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@kernel.org> Notes: Stable: 0f6cf136974a # v6.6.19 Stable: 5583552eec30 # v6.1.80 Lore: https://lore.kernel.org/r/20240227131613.388198076@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131630.595180886@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.611176966@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/7641d5f-ebe-f7db-35b7-d64e6d65476@redhat.com # dm-devel
2024-02-20dm-crypt: don't modify the data when using authenticated encryptionMikulas Patocka1-0/+6
It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/ Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@kernel.org> Notes: Stable: 64ba01a36598 # v6.6.19 Stable: e08c2a8d27e9 # v6.1.80 Stable: 1a4371db68a3 # v5.15.150 Stable: 3c652f6fa1e1 # v5.10.211 Stable: 0dccbb93538f # v5.4.270 Stable: 43a202bd5529 # v4.19.308
2024-02-20dm-verity: recheck the hash after a failureMikulas Patocka2-6/+86
If a userspace process reads (with O_DIRECT) multiple blocks into the same buffer, dm-verity reports an error [1]. This commit fixes dm-verity, so that if hash verification fails, the data is read again into a kernel buffer (where userspace can't modify it) and the hash is rechecked. If the recheck succeeds, the content of the kernel buffer is copied into the user buffer; if the recheck fails, an error is reported. [1] https://people.redhat.com/~mpatocka/testcases/blk-auth-modify/read2.c Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@kernel.org> Notes: Fixed-by: 66ad2fbcdbea ("dm-integrity, dm-verity: reduce stack usage for recheck") # v6.8-rc6 Fixed-by-stable: 763f1f13d856 ("dm-integrity, dm-verity: reduce stack usage for recheck") # v6.6.19 Fixed-by-stable: 943c8b1fcc86 ("dm-integrity, dm-verity: reduce stack usage for recheck") # v6.1.80 Stable: e5cc2309f6b3 # v6.6.19 Stable: 27c1ade6068f # v6.1.80 Lore: https://lore.kernel.org/r/20240227131613.517406327@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131630.726561642@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.754055269@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/2eaf23b3-557f-89a5-48a3-4e45edd8cf2@redhat.com # dm-devel
2024-02-20dm-integrity: recheck the integrity tag after a failureMikulas Patocka1-9/+84
If a userspace process reads (with O_DIRECT) multiple blocks into the same buffer, dm-integrity reports an error [1]. The error is reported in a log and it may cause RAID leg being kicked out of the array. This commit fixes dm-integrity, so that if integrity verification fails, the data is read again into a kernel buffer (where userspace can't modify it) and the integrity tag is rechecked. If the recheck succeeds, the content of the kernel buffer is copied into the user buffer; if the recheck fails, an integrity error is reported. [1] https://people.redhat.com/~mpatocka/testcases/blk-auth-modify/read2.c Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@kernel.org> Notes: Fixed-by: 66ad2fbcdbea ("dm-integrity, dm-verity: reduce stack usage for recheck") # v6.8-rc6 Fixed-by-stable: 763f1f13d856 ("dm-integrity, dm-verity: reduce stack usage for recheck") # v6.6.19 Fixed-by-stable: 943c8b1fcc86 ("dm-integrity, dm-verity: reduce stack usage for recheck") # v6.1.80 Stable: d6824a28b244 # v6.6.19 Stable: 906414f45964 # v6.1.80 Lore: https://lore.kernel.org/r/20240227131613.453026115@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131630.667582525@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.672630053@linuxfoundation.org # linux-patches, stable
2024-02-20sched/membarrier: reduce the ability to hammer on sys_membarrierLinus Torvalds1-0/+6
On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-and-tested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by: Borislav Petkov <bp@alien8.de> Fixes: 22e4ebb97582 ("membarrier: Provide expedited private command") Fixes: c5f58bd58f43 ("membarrier: Provide GLOBAL_EXPEDITED command") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Notes: Fixes: CVE-2024-26602 # https://www.cve.org/CVERecord?id=CVE-2024-26602 Fixes: 22e4ebb97582 ("membarrier: Provide expedited private command") # v4.14-rc1 Fixes: c5f58bd58f43 ("membarrier: Provide GLOBAL_EXPEDITED command") # v4.16-rc1 Stable: b6a2a9cbb675 # v6.6.18 Stable: 24ec7504a08a # v6.1.79 Stable: 50fb4e17df31 # v5.15.149 Stable: db896bbe4a9c # v5.10.210 Stable: 2441a64070b8 # v5.4.269 Stable: 3cd139875e9a # v4.19.307 Lore: https://lore.kernel.org/r/20240221125938.189914810@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240221125948.290127023@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240221130006.007379036@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240221130025.091533832@linuxfoundation.org # linux-patches, stable
2024-02-20Merge tag 'imx-fixes-6.8' of ↵Arnd Bergmann5-19/+17
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 6.8: - A tqma8mpql device tree fix to correct audio codec iov-supply. - A couple of USB-C connector DT description revert to fix regression on imx8mp-dhcom-pdk3 and imx8mn-var-som-symphony board. - Fix valid range check for imx-weim bus driver. - Disable UART4 on Data Modul i.MX8M Plus eDM SBC to avoid boot hang in case that RDC protection is in place. * tag 'imx-fixes-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: bus: imx-weim: fix valid range check Revert "arm64: dts: imx8mn-var-som-symphony: Describe the USB-C connector" Revert "arm64: dts: imx8mp-dhcom-pdk3: Describe the USB-C connector" arm64: dts: tqma8mpql: fix audio codec iov-supply arm64: dts: imx8mp: Disable UART4 by default on Data Modul i.MX8M Plus eDM SBC Link: https://lore.kernel.org/r/20240206151744.2459-1-shawnguo2@yeah.net Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-20ARM: ep93xx: Add terminator to gpiod_lookup_tableNikita Shubin1-0/+1
Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops. Cc: stable@vger.kernel.org Fixes: b2e63555592f ("i2c: gpio: Convert to use descriptors") Reported-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20240205102337.439002-1-alexander.sverdlin@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> Notes: Fixes: b2e63555592f ("i2c: gpio: Convert to use descriptors") # v4.15-rc1 Stable: 97ba7c1f9c0a # v6.6.19 Stable: 786f089086b5 # v6.1.80 Stable: eec6cbbfa1e8 # v5.15.150 Stable: 70d92abbe296 # v5.10.211 Stable: 999a8bb70da2 # v5.4.270 Stable: 9e200a06ae2a # v4.19.308 Lore: https://lore.kernel.org/r/20231212-ep93xx-v6-1-c307b8ac9aa8@maquefel.me # b4-sent, linux-arm-kernel, lkml Lore: https://lore.kernel.org/r/20240118-ep93xx-v7-1-d953846ae771@maquefel.me # b4-sent, linux-arm-kernel, lkml Lore: https://lore.kernel.org/r/20240205102337.439002-1-alexander.sverdlin@gmail.com # soc, stable Lore: https://lore.kernel.org/r/20240227131549.588085742@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131554.759821590@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131601.391052191@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131614.129179043@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131618.053495467@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131631.538178990@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.106690641@linuxfoundation.org # linux-patches, stable
2024-02-20accel/ivpu: Don't enable any tiles by default on VPU40xxAndrzej Kacprowski1-1/+1
There is no point in requesting 1 tile on VPU40xx as the FW will probably need more tiles to run workloads, so it will have to reconfigure PLL anyway. Don't enable any tiles and allow the FW to perform initial tile configuration. This improves NPU boot stability as the tiles are always enabled only by the FW from the same initial state. Fixes: 79cdc56c4a54 ("accel/ivpu: Add initial support for VPU 4") Cc: stable@vger.kernel.org Signed-off-by: Andrzej Kacprowski <Andrzej.Kacprowski@intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220131624.1447813-1-jacek.lawrynowicz@linux.intel.com Notes: Fixes: 79cdc56c4a54 ("accel/ivpu: Add initial support for VPU 4") # v6.6-rc1 Stable: cca20208515e # v6.6.19 Lore: https://lore.kernel.org/r/20240220110830.1439719-1-jacek.lawrynowicz@linux.intel.com # dri-devel, stable Lore: https://lore.kernel.org/r/20240220131624.1447813-1-jacek.lawrynowicz@linux.intel.com # dri-devel, stable
2024-02-20platform/x86: thinkpad_acpi: Only update profile if successfully convertedMario Limonciello1-2/+3
Randomly a Lenovo Z13 will trigger a kernel warning traceback from this condition: ``` if (WARN_ON((profile < 0) || (profile >= ARRAY_SIZE(profile_names)))) ``` This happens because thinkpad-acpi always assumes that convert_dytc_to_profile() successfully updated the profile. On the contrary a condition can occur that when dytc_profile_refresh() is called the profile doesn't get updated as there is a -EOPNOTSUPP branch. Catch this situation and avoid updating the profile. Also log this into dynamic debugging in case any other modes should be added in the future. Fixes: c3bfcd4c6762 ("platform/x86: thinkpad_acpi: Add platform profile support") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240217022311.113879-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Notes: Fixes: c3bfcd4c6762 ("platform/x86: thinkpad_acpi: Add platform profile support") # v5.12-rc2 Stable: f9f8f23c5851 # v6.6.19 Stable: 6216509a2e11 # v6.1.80 Lore: https://lore.kernel.org/r/20240217022311.113879-1-mario.limonciello@amd.com # lkml, platform-driver-x86 Lore: https://lore.kernel.org/r/20240227131615.762204358@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.071129630@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.263096437@linuxfoundation.org # linux-patches, stable
2024-02-20platform/x86: intel-vbtn: Stop calling "VBDL" from notify_handlerHans de Goede1-3/+0
Commit 14c200b7ca46 ("platform/x86: intel-vbtn: Fix missing tablet-mode-switch events") causes 2 issues on the ThinkPad X1 Tablet Gen2: 1. The ThinkPad will wake up immediately from suspend 2. When put in tablet mode SW_TABLET_MODE reverts to 0 after about 1 second Both these issues are caused by the "VBDL" ACPI method call added at the end of the notify_handler. And it never became entirely clear if this call is even necessary to fix the issue of missing tablet-mode-switch events on the Dell Inspiron 7352. Drop the "VBDL" ACPI method call again to fix the 2 issues this is causing on the ThinkPad X1 Tablet Gen2. Fixes: 14c200b7ca46 ("platform/x86: intel-vbtn: Fix missing tablet-mode-switch events") Reported-by: Alexander Kobel <a-kobel@a-kobel.de> Closes: https://lore.kernel.org/platform-driver-x86/295984ce-bd4b-49bd-adc5-ffe7c898d7f0@a-kobel.de/ Cc: regressions@lists.linux.dev Cc: Arnold Gozum <arngozum@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Alexander Kobel <a-kobel@a-kobel.de> Link: https://lore.kernel.org/r/20240216203300.245826-1-hdegoede@redhat.com Notes: Fixes: 14c200b7ca46 ("platform/x86: intel-vbtn: Fix missing tablet-mode-switch events") # v6.7-rc6 Fixes-stable: 4dceffd823b7 ("platform/x86: intel-vbtn: Fix missing tablet-mode-switch events") # v6.6.13 Fixes-stable: bb0e510b742b ("platform/x86: intel-vbtn: Fix missing tablet-mode-switch events") # v6.1.74 Fixes-stable: 7b0586ada944 ("platform/x86: intel-vbtn: Fix missing tablet-mode-switch events") # v5.15.148 Stable: e78a4e221ebf # v6.6.19 Stable: fff39f496265 # v6.1.80 Stable: 79d7504a24a3 # v5.15.150 Lore: https://lore.kernel.org/r/20240216203300.245826-1-hdegoede@redhat.com # platform-driver-x86, regressions Lore: https://lore.kernel.org/r/20240227131613.742771568@linuxfoundation.org # linux-patches, regressions, stable Lore: https://lore.kernel.org/r/20240227131617.839986631@linuxfoundation.org # linux-patches, regressions, stable Lore: https://lore.kernel.org/r/20240227131631.070692170@linuxfoundation.org # linux-patches, regressions, stable Lore: https://lore.kernel.org/r/20240227131636.318820529@linuxfoundation.org # linux-patches, regressions, stable
2024-02-20platform/x86: x86-android-tablets: Fix acer_b1_750_goodix_gpios nameHans de Goede1-2/+2
The Acer B1 750 tablet used a Novatek NVT-ts touchscreen, not a Goodix touchscreen. Rename acer_b1_750_goodix_gpios to acer_b1_750_nvt_ts_gpios to correctly reflect this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240216201721.239791-5-hdegoede@redhat.com Notes: Lore: https://lore.kernel.org/r/20240216201721.239791-5-hdegoede@redhat.com # platform-driver-x86 Lore: https://lore.kernel.org/r/20240229203729.2860356-17-sashal@kernel.org # lkml, platform-driver-x86, stable Lore: https://lore.kernel.org/r/20240229203933.2861006-16-sashal@kernel.org # lkml, platform-driver-x86, stable
2024-02-20platform/x86: x86-android-tablets: Fix serdev instantiation no longer workingHans de Goede1-26/+9
After commit b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") x86_instantiate_serdev() no longer works due to the serdev-controller-device moving in the device hierarchy from (e.g.) /sys/devices/pci0000:00/8086228A:00/serial0 to /sys/devices/pci0000:00/8086228A:00/8086228A:00:0/8086228A:00:0.0/serial0 Use the new get_serdev_controller() helper function to fix this. Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240216201721.239791-4-hdegoede@redhat.com Notes: Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240216201721.239791-4-hdegoede@redhat.com # platform-driver-x86
2024-02-20platform/x86: Add new get_serdev_controller() helperHans de Goede1-0/+80
In some cases UART attached devices which require an in kernel driver, e.g. UART attached Bluetooth HCIs are described in the ACPI tables by an ACPI device with a broken or missing UartSerialBusV2() resource. This causes the kernel to create a /dev/ttyS# char-device for the UART instead of creating an in kernel serdev-controller + serdev-device pair for the in kernel driver. The quirk handling in acpi_quirk_skip_serdev_enumeration() makes the kernel create a serdev-controller device for these UARTs instead of a /dev/ttyS#. Instantiating the actual serdev-device to bind to is up to pdx86 code, so far this was handled by the x86-android-tablets code. But since commit b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") the serdev-controller device has moved in the device hierarchy from (e.g.) /sys/devices/pci0000:00/8086228A:00/serial0 to /sys/devices/pci0000:00/8086228A:00/8086228A:00:0/8086228A:00:0.0/serial0 . This makes this a bit trickier to do and another driver is in the works which will also need this functionality. Add a new helper to get the serdev-controller device, so that the new code for this can be shared. Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240216201721.239791-3-hdegoede@redhat.com Notes: Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240216201721.239791-3-hdegoede@redhat.com # platform-driver-x86
2024-02-20platform/x86: x86-android-tablets: Fix keyboard touchscreen on Lenovo ↵Hans de Goede3-0/+5
Yogabook1 X90 After commit 4014ae236b1d ("platform/x86: x86-android-tablets: Stop using gpiolib private APIs") the touchscreen in the keyboard half of the Lenovo Yogabook1 X90 stopped working with the following error: Goodix-TS i2c-goodix_ts: error -EBUSY: Failed to get irq GPIO The problem is that when getting the IRQ for instantiated i2c_client-s from a GPIO (rather then using an IRQ directly from the IOAPIC), x86_acpi_irq_helper_get() now properly requests the GPIO, which disallows other drivers from requesting it. Normally this is a good thing, but the goodix touchscreen also uses the IRQ as an output during reset to select which of its 2 possible I2C addresses should be used. Add a new free_gpio flag to struct x86_acpi_irq_data to deal with this and release the GPIO after getting the IRQ in this special case. Fixes: 4014ae236b1d ("platform/x86: x86-android-tablets: Stop using gpiolib private APIs") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240216201721.239791-2-hdegoede@redhat.com Notes: Fixes: 4014ae236b1d ("platform/x86: x86-android-tablets: Stop using gpiolib private APIs") # v6.7-rc1 Lore: https://lore.kernel.org/r/20240216201721.239791-2-hdegoede@redhat.com # platform-driver-x86, stable Lore: https://lore.kernel.org/r/20240227131636.285482008@linuxfoundation.org # linux-patches, stable
2024-02-20arm64/sme: Restore SMCR_EL1.EZT0 on exit from suspendMark Brown1-0/+2
The fields in SMCR_EL1 reset to an architecturally UNKNOWN value. Since we do not otherwise manage the traps configured in this register at runtime we need to reconfigure them after a suspend in case nothing else was kind enough to preserve them for us. Do so for SMCR_EL1.EZT0. Fixes: d4913eee152d ("arm64/sme: Add basic enumeration for SME2") Reported-by: Jackson Cooper-Driver <Jackson.Cooper-Driver@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240213-arm64-sme-resume-v3-2-17e05e493471@kernel.org Signed-off-by: Will Deacon <will@kernel.org> Notes: Fixes: d4913eee152d ("arm64/sme: Add basic enumeration for SME2") # v6.3-rc1 Stable: 79491ddfb429 # v6.6.19 Lore: https://lore.kernel.org/r/20240130-arm64-sme-resume-v1-2-0e60ebba18df@kernel.org # linux-arm-kernel, lkml Lore: https://lore.kernel.org/r/20240227131634.041201409@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.219652875@linuxfoundation.org # linux-patches, stable
2024-02-20arm64/sme: Restore SME registers on exit from suspendMark Brown3-0/+19
The fields in SMCR_EL1 and SMPRI_EL1 reset to an architecturally UNKNOWN value. Since we do not otherwise manage the traps configured in this register at runtime we need to reconfigure them after a suspend in case nothing else was kind enough to preserve them for us. The vector length will be restored as part of restoring the SME state for the next SME using task. Fixes: a1f4ccd25cc2 ("arm64/sme: Provide Kconfig for SME") Reported-by: Jackson Cooper-Driver <Jackson.Cooper-Driver@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240213-arm64-sme-resume-v3-1-17e05e493471@kernel.org Signed-off-by: Will Deacon <will@kernel.org> Notes: Fixes: a1f4ccd25cc2 ("arm64/sme: Provide Kconfig for SME") # v5.19-rc1 Stable: 7c892383227f # v6.6.19 Stable: 38c83c2488dc # v6.1.80 Lore: https://lore.kernel.org/r/20240227131615.728895625@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131634.010823713@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.189313429@linuxfoundation.org # linux-patches, stable
2024-02-20Revert "arm64: jump_label: use constraints "Si" instead of "i""Will Deacon1-8/+4
This reverts commit f9daab0ad01cf9d165dbbbf106ca4e61d06e7fe8. Geert reports that his particular GCC 5.5 vintage toolchain fails to build an arm64 defconfig because of this change: | arch/arm64/include/asm/jump_label.h:25:2: error: invalid 'asm': | invalid operand | asm goto( ^ Aopparently, this is something we claim to support, so let's revert back to the old jump label constraint for now while discussions about raising the minimum GCC version are ongoing. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/CAMuHMdX+6fnAf8Hm6EqYJPAjrrLO9T7c=Gu3S8V_pqjSDowJ6g@mail.gmail.com Signed-off-by: Will Deacon <will@kernel.org>
2024-02-20perf: CXL: fix CPMU filter value mask lengthHojin Nam1-5/+5
CPMU filter value is described as 4B length in CXL r3.0 8.2.7.2.2. However, it is used as 2B length in code and comments. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Hojin Nam <hj96.nam@samsung.com> Link: https://lore.kernel.org/r/20240216014522.32321-1-hj96.nam@samsung.com Signed-off-by: Will Deacon <will@kernel.org> Notes: Lore: https://lore.kernel.org/r/20240214045214epcms2p81d2ea826483fb4aecf19930f2755d55b@epcms2p8 # linux-arm-kernel, linux-cxl, lkml Lore: https://lore.kernel.org/r/20240215080906epcms2p2c49c6b9bfe271e1d089ad35ab527b958@epcms2p2 # linux-arm-kernel, linux-cxl, lkml Lore: https://lore.kernel.org/r/20240216014522.32321-1-hj96.nam@samsung.com # linux-arm-kernel, linux-cxl, lkml Lore: https://lore.kernel.org/r/20240229203729.2860356-16-sashal@kernel.org # linux-arm-kernel, linux-cxl, lkml, stable Lore: https://lore.kernel.org/r/20240229203933.2861006-15-sashal@kernel.org # linux-arm-kernel, linux-cxl, lkml, stable
2024-02-20gpiolib: Handle no pin_ranges in gpiochip_generic_config()Emil Renner Berthing1-0/+5
Similar to gpiochip_generic_request() and gpiochip_generic_free() the gpiochip_generic_config() function needs to handle the case where there are no pinctrl pins mapped to the GPIOs, usually through the gpio-ranges device tree property. Commit f34fd6ee1be8 ("gpio: dwapb: Use generic request, free and set_config") set the .set_config callback to gpiochip_generic_config() in the dwapb GPIO driver so the GPIO API can set pinctrl configuration for the corresponding pins. Most boards using the dwapb driver do not set the gpio-ranges device tree property though, and in this case gpiochip_generic_config() would return -EPROPE_DEFER rather than the previous -ENOTSUPP return value. This in turn makes gpio_set_config_with_argument_optional() fail and propagate the error to any driver requesting GPIOs. Fixes: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips") Reported-by: Jisheng Zhang <jszhang@kernel.org> Closes: https://lore.kernel.org/linux-gpio/ZdC_g3U4l0CJIWzh@xhacker/ Tested-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Notes: Fixes: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips") # v4.11-rc1 Lore: https://lore.kernel.org/r/20240219172514.203750-1-emil.renner.berthing@canonical.com # linux-gpio, lkml Lore: https://lore.kernel.org/r/20240227131640.158883113@linuxfoundation.org # linux-patches, stable
2024-02-20docs: netdev: update the link to the CI repoJakub Kicinski1-1/+1
Netronome graciously transferred the original NIPA repo to our new netdev umbrella org. Link to that instead of my private fork. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240216161945.2208842-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Notes: Lore: https://lore.kernel.org/r/20240216161945.2208842-1-kuba@kernel.org # linux-doc, netdev
2024-02-20arp: Prevent overflow in arp_req_get().Kuniyuki Iwashima1-1/+2
syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it's not a problem. However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN), arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling arp_req_get(). To avoid the overflow, let's limit the max length of memcpy(). Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") just silenced syzkaller. [0]: memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK> Reported-by: syzkaller <syzkaller@googlegroups.com> Reported-by: Bjoern Doebel <doebel@amazon.de> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20240215230516.31330-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Notes: Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") # v2.6.12-rc2 Stable: a3f2c083cb57 # v6.6.19 Stable: f119f2325ba7 # v6.1.80 Stable: 97eaa2955db4 # v5.15.150 Stable: dbc9b22d0ed3 # v5.10.211 Lore: https://lore.kernel.org/r/20240215230516.31330-1-kuniyu@amazon.com # netdev Lore: https://lore.kernel.org/r/20240227131602.662533021@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131616.808580994@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.993226566@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131633.981002822@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.082407006@linuxfoundation.org # linux-patches, stable
2024-02-20devlink: fix possible use-after-free and memory leaks in devlink_init()Vasiliy Kovalev1-3/+9
The pernet operations structure for the subsystem must be registered before registering the generic netlink family. Make an unregister in case of unsuccessful registration. Fixes: 687125b5799c ("devlink: split out core code") Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org> Link: https://lore.kernel.org/r/20240215203400.29976-1-kovalev@altlinux.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Notes: Fixes: 687125b5799c ("devlink: split out core code") # v6.3-rc1 Stable: 919092bd5482 # v6.6.19 Lore: https://lore.kernel.org/r/20240215203400.29976-1-kovalev@altlinux.org # netdev Lore: https://lore.kernel.org/r/20240227131633.951234831@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.053366078@linuxfoundation.org # linux-patches, stable
2024-02-20ipv6: sr: fix possible use-after-free and null-ptr-derefVasiliy Kovalev1-9/+11
The pernet operations structure for the subsystem must be registered before registering the generic netlink family. Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6") Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org> Link: https://lore.kernel.org/r/20240215202717.29815-1-kovalev@altlinux.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Notes: Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6") # v4.10-rc1 Stable: 9e02973dbc6a # v6.6.19 Stable: 8391b9b651cf # v6.1.80 Stable: 91b020aaa1e5 # v5.15.150 Stable: 65c38f23d10f # v5.10.211 Stable: 82831e3ff76e # v5.4.270 Stable: 953f42934533 # v4.19.308 Lore: https://lore.kernel.org/r/20240215202717.29815-1-kovalev@altlinux.org # netdev Lore: https://lore.kernel.org/r/20240227131550.015311375@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131555.278696558@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131602.239658029@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131615.663052854@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.408368232@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131633.921117022@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131640.023922825@linuxfoundation.org # linux-patches, stable
2024-02-20afs: Increase buffer size in afs_update_volume_status()Daniil Dulov1-2/+2
The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. [DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()] Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation") Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/r/20240211150442.3416-1-d.dulov@aladdin.ru/ # v1 Link: https://lore.kernel.org/r/20240212083347.10742-1-d.dulov@aladdin.ru/ # v2 Link: https://lore.kernel.org/r/20240219143906.138346-3-dhowells@redhat.com Signed-off-by: Christian Brauner <brauner@kernel.org> Notes: Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation") # v4.15-rc1 Stable: 6e6065dd25b6 # v6.6.19 Stable: e8530b170e46 # v6.1.80 Stable: e56662160fc2 # v5.15.150 Stable: d9b5e2b7a819 # v5.10.211 Stable: 5c27d85a69fa # v5.4.270 Lore: https://lore.kernel.org/r/20240211150442.3416-1-d.dulov@aladdin.ru # lkml Lore: https://lore.kernel.org/r/20240212083347.10742-1-d.dulov@aladdin.ru # lkml Lore: https://lore.kernel.org/r/20240219143906.138346-3-dhowells@redhat.com # linux-fsdevel, lkml Lore: https://lore.kernel.org/r/20240227131555.244829070@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131602.206419086@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131615.633280383@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.378220623@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131633.891423371@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131639.994994006@linuxfoundation.org # linux-patches, stable
2024-02-20afs: Fix ignored callbacks over ipv4Marc Dionne3-15/+8
When searching for a matching peer, all addresses need to be searched, not just the ipv6 ones in the fs_addresses6 list. Given that the lists no longer contain addresses, there is little reason to splitting things between separate lists, so unify them into a single list. When processing an incoming callback from an ipv4 address, this would lead to a failure to set call->server, resulting in the callback being ignored and the client seeing stale contents. Fixes: 72904d7b9bfb ("rxrpc, afs: Allow afs to pin rxrpc_peer objects") Reported-by: Markus Suvanto <markus.suvanto@gmail.com> Link: https://lists.infradead.org/pipermail/linux-afs/2024-February/008035.html Signed-off-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://lists.infradead.org/pipermail/linux-afs/2024-February/008037.html # v1 Link: https://lists.infradead.org/pipermail/linux-afs/2024-February/008066.html # v2 Link: https://lore.kernel.org/r/20240219143906.138346-2-dhowells@redhat.com Signed-off-by: Christian Brauner <brauner@kernel.org> Notes: Fixes: 72904d7b9bfb ("rxrpc, afs: Allow afs to pin rxrpc_peer objects") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240219143906.138346-2-dhowells@redhat.com # linux-fsdevel, lkml
2024-02-20cachefiles: fix memory leak in cachefiles_add_cache()Baokun Li2-0/+3
The following memory leak was reported after unbinding /dev/cachefiles: ================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370 [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0 [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120 [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0 [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520 [<ffffffff8ebc5069>] ksys_write+0x69/0xf0 [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140 [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ================================================================== Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks. Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem") CC: stable@vger.kernel.org Signed-off-by: Baokun Li <libaokun1@huawei.com> Link: https://lore.kernel.org/r/20240217081431.796809-1-libaokun1@huawei.com Acked-by: David Howells <dhowells@redhat.com> Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org> Notes: Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem") # v2.6.30-rc1 Stable: 38e921616320 # v6.6.19 Stable: 8b218e2f0a27 # v6.1.80 Stable: 94965be37add # v5.15.151 Stable: 43eccc582373 # v5.10.212 Stable: 037d5a949b04 # v5.4.271 Stable: cb5466783793 # v4.19.309 Lore: https://lore.kernel.org/r/20240131091717.1277013-1-libaokun1@huawei.com # lkml, netfs, stable Lore: https://lore.kernel.org/r/20240217081431.796809-1-libaokun1@huawei.com # linux-erofs, linux-fsdevel, lkml, netfs, stable Lore: https://lore.kernel.org/r/20240227131613.808225072@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131631.129821066@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.412659947@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227141606.1047435-1-libaokun1@huawei.com # linux-patches, stable Lore: https://lore.kernel.org/r/20240304211534.897717612@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240304211536.536168902@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240304211538.870750093@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240304211544.737047637@linuxfoundation.org # linux-patches, stable
2024-02-19parisc: Fix stack unwinderGuenter Roeck1-8/+6
Debugging shows a large number of unaligned access traps in the unwinder code. Code analysis reveals a number of issues with this code: - handle_interruption is passed twice through dereference_kernel_function_descriptor() - ret_from_kernel_thread, syscall_exit, intr_return, _switch_to_ret, and _call_on_stack are passed through dereference_kernel_function_descriptor() even though they are not declared as function pointers. To fix the problems, drop one of the calls to dereference_kernel_function_descriptor() for handle_interruption, and compare the other pointers directly. Fixes: 6414b30b39f9 ("parisc: unwind: Avoid missing prototype warning for handle_interruption()") Fixes: 8e0ba125c2bf ("parisc/unwind: fix unwinder when CONFIG_64BIT is enabled") Cc: Helge Deller <deller@gmx.de> Cc: Sven Schnelle <svens@stackframe.org> Cc: John David Anglin <dave.anglin@bell.net> Cc: Charlie Jenkins <charlie@rivosinc.com> Cc: David Laight <David.Laight@ACULAB.COM> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Helge Deller <deller@gmx.de> Notes: Fixes: 6414b30b39f9 ("parisc: unwind: Avoid missing prototype warning for handle_interruption()") # v6.5-rc1 Fixes: 8e0ba125c2bf ("parisc/unwind: fix unwinder when CONFIG_64BIT is enabled") # v5.16-rc1 Fixes-stable: 028459fab9a6 ("parisc/unwind: fix unwinder when CONFIG_64BIT is enabled") # v5.15.3 Fixes-stable: a1ec31a0befa ("parisc/unwind: fix unwinder when CONFIG_64BIT is enabled") # v5.10.80 Fixes-stable: cbe28724277c ("parisc/unwind: fix unwinder when CONFIG_64BIT is enabled") # v5.4.160 Fixes-stable: 4847dcb44233 ("parisc/unwind: fix unwinder when CONFIG_64BIT is enabled") # v4.19.218 Stable: 287a0e6d3a62 # v6.6.19 Lore: https://lore.kernel.org/r/20240227131633.860842006@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131639.965122617@linuxfoundation.org # linux-patches, stable
2024-02-19platform/x86/amd/pmf: Fix a potential race with policy binary sideloadMario Limonciello1-2/+3
The debugfs `update_policy` file is created before amd_pmf_start_policy_engine() has completed, and thus there could be a possible (albeit unlikely) race between sideloading a policy and the BIOS policy getting setup. Move the debugfs file creation after all BIOS policy is setup. Fixes: 10817f28e533 ("platform/x86/amd/pmf: Add capability to sideload of policy binary") Reported-by: Hans de Goede <hdegoede@redhat.com> Closes: https://lore.kernel.org/platform-driver-x86/15df7d02-b0aa-457a-954a-9d280a592843@redhat.com/T/#m2c445f135e5ef9b53184be7fc9df84e15f89d4d9 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240217015642.113806-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Notes: Fixes: 10817f28e533 ("platform/x86/amd/pmf: Add capability to sideload of policy binary") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240217015642.113806-1-mario.limonciello@amd.com # lkml, platform-driver-x86
2024-02-19platform/x86/amd/pmf: Fixup error handling for amd_pmf_init_smart_pc()Mario Limonciello1-25/+40
amd_pmf_init_smart_pc() calls out to amd_pmf_get_bios_buffer() but the error handling flow doesn't clean everything up allocated memory. As amd_pmf_get_bios_buffer() is only called by amd_pmf_init_smart_pc(), fold it into the function and add labels to clean up any step that can fail along the way. Explicitly set everything allocated to NULL as there are other features that may access some of the same variables. Fixes: 7c45534afa44 ("platform/x86/amd/pmf: Add support for PMF Policy Binary") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240217014107.113749-3-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Notes: Fixed-by: 0314cebb29be ("platform/x86/amd/pmf: Fix missing error code in amd_pmf_init_smart_pc()") # master Fixes: 7c45534afa44 ("platform/x86/amd/pmf: Add support for PMF Policy Binary") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240217012205.113614-3-mario.limonciello@amd.com # lkml, platform-driver-x86, regressions Lore: https://lore.kernel.org/r/20240217014107.113749-3-mario.limonciello@amd.com # lkml, platform-driver-x86
2024-02-19platform/x86/amd/pmf: Add debugging message for missing policy dataMario Limonciello1-1/+3
If a machine advertises Smart PC support but is missing policy data show a debugging message to help clarify why Smart PC wasn't enabled. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240217014107.113749-2-mario.limonciello@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Notes: Lore: https://lore.kernel.org/r/20240217012205.113614-2-mario.limonciello@amd.com # lkml, platform-driver-x86, regressions Lore: https://lore.kernel.org/r/20240217014107.113749-2-mario.limonciello@amd.com # lkml, platform-driver-x86
2024-02-19platform/x86/amd/pmf: Fix a suspend hang on Framework 13Mario Limonciello1-2/+0
The buffer is cleared in the suspend handler but used in the delayed work for amd_pmf_get_metrics(). Stop clearing it to fix the hang. Reported-by: Trolli Schmittlauch <t.schmittlauch@orlives.de> Closes: https://lore.kernel.org/regressions/ed2226ff-257b-4cfd-afd6-bf3be9785474@localhost/ Closes: https://community.frame.work/t/kernel-6-8-rc-system-freezes-after-resuming-from-suspend-reproducers-wanted/45381 Fixes: 2b3a7f06caaf ("platform/x86/amd/pmf: Change return type of amd_pmf_set_dram_addr()") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240217005216.113408-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Notes: Fixes: 2b3a7f06caaf ("platform/x86/amd/pmf: Change return type of amd_pmf_set_dram_addr()") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240217005216.113408-1-mario.limonciello@amd.com # lkml, platform-driver-x86, regressions
2024-02-19platform/x86/amd/pmf: Fix TEE enact command failure after suspend and resumeShyam Sundar S K1-0/+6
TEE enact command failures are seen after each suspend/resume cycle; fix this by cancelling the policy builder workqueue before going into suspend and reschedule the workqueue after resume. [ 629.516792] ccp 0000:c2:00.2: tee: command 0x5 timed out, disabling PSP [ 629.516835] amd-pmf AMDI0102:00: TEE enact cmd failed. err: ffff000e, ret:0 [ 630.550464] amd-pmf AMDI0102:00: AMD_PMF_REGISTER_RESPONSE:1 [ 630.550511] amd-pmf AMDI0102:00: AMD_PMF_REGISTER_ARGUMENT:7 [ 630.550548] amd-pmf AMDI0102:00: AMD_PMF_REGISTER_MESSAGE:16 Fixes: ae82cef7d9c5 ("platform/x86/amd/pmf: Add support for PMF-TA interaction") Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240216064112.962582-2-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Notes: Fixes: ae82cef7d9c5 ("platform/x86/amd/pmf: Add support for PMF-TA interaction") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240212092440.4135787-1-Shyam-sundar.S-k@amd.com # platform-driver-x86 Lore: https://lore.kernel.org/r/20240213073651.404220-2-Shyam-sundar.S-k@amd.com # platform-driver-x86 Lore: https://lore.kernel.org/r/20240216064112.962582-2-Shyam-sundar.S-k@amd.com # platform-driver-x86
2024-02-19platform/x86/amd/pmf: Remove smart_pc_status enumShyam Sundar S K3-10/+10
Improve code readability by removing smart_pc_status enum, as the same can be done with a simple true/false check; Update the code checks accordingly. Also add a missing return on amd_pmf_init_smart_pc() success, to skip trying to setup the auto / slider modes which should not be used in this case. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240216064112.962582-1-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Notes: Lore: https://lore.kernel.org/r/20240213073651.404220-1-Shyam-sundar.S-k@amd.com # platform-driver-x86 Lore: https://lore.kernel.org/r/20240216064112.962582-1-Shyam-sundar.S-k@amd.com # platform-driver-x86
2024-02-19platform/x86: touchscreen_dmi: Consolidate Goodix upside-down touchscreen dataHans de Goede1-15/+10
Now that prefix matches for ACPI names are supported, the ts_dmi_data structs for "GDIX1001:00" and "GDIX1001:01" can be consolidated into a single match matching on "GDIX1001". For consistency also change gdix1002_00_upside_down_data to match. Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240212120608.30469-2-hdegoede@redhat.com Notes: Lore: https://lore.kernel.org/r/20240212120608.30469-2-hdegoede@redhat.com # platform-driver-x86
2024-02-19platform/x86: touchscreen_dmi: Allow partial (prefix) matches for ACPI namesHans de Goede1-2/+2
On some devices the ACPI name of the touchscreen is e.g. either MSSL1680:00 or MSSL1680:01 depending on the BIOS version. This happens for example on the "Chuwi Hi8 Air" tablet where the initial commit's ts_data uses "MSSL1680:00" but the tablets from the github issue and linux-hardware.org probe linked below both use "MSSL1680:01". Replace the strcmp() match on ts_data->acpi_name with a strstarts() check to allow using a partial match on just the ACPI HID of "MSSL1680" and change the ts_data->acpi_name for the "Chuwi Hi8 Air" accordingly to fix the touchscreen not working on models where it is "MSSL1680:01". Note this drops the length check for I2C_NAME_SIZE. This never was necessary since the ACPI names used are never more then 11 chars and I2C_NAME_SIZE is 20 so the replaced strncmp() would always stop long before reaching I2C_NAME_SIZE. Link: https://linux-hardware.org/?computer=AC4301C0542A Fixes: bbb97d728f77 ("platform/x86: touchscreen_dmi: Add info for the Chuwi Hi8 Air tablet") Closes: https://github.com/onitake/gsl-firmware/issues/91 Cc: stable@vger.kernel.org Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240212120608.30469-1-hdegoede@redhat.com Notes: Fixes: bbb97d728f77 ("platform/x86: touchscreen_dmi: Add info for the Chuwi Hi8 Air tablet") # v5.1-rc1 Stable: 557cac23bee3 # v6.6.19 Stable: 9e7fc40377ec # v6.1.80 Stable: e20b24b175c9 # v5.15.150 Stable: bf85def4b6cb # v5.10.212 Lore: https://lore.kernel.org/r/20240212120608.30469-1-hdegoede@redhat.com # platform-driver-x86 Lore: https://lore.kernel.org/r/20240227131613.775826942@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131617.871296840@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131631.100194584@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131636.365738434@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240304211537.679129630@linuxfoundation.org # linux-patches, stable
2024-02-19platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to request_irq()Hans de Goede1-1/+1
Since commit 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") the ACPI OSL code passes IRQF_ONESHOT when requesting the SCI. Since the INT0002 GPIO is typically shared with the ACPI SCI the INT0002 driver must pass the same flags. This fixes the INT0002 driver failing to probe due to following error + as well as removing the backtrace that follows this error: "genirq: Flags mismatch irq 9. 00000084 (INT0002) vs. 00002080 (acpi)" Fixes: 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240210110149.12803-1-hdegoede@redhat.com Notes: Fixes: 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240210110149.12803-1-hdegoede@redhat.com # platform-driver-x86
2024-02-19platform/x86: think-lmi: Fix password opcode ordering for workstationsMark Pearson1-9/+11
The Lenovo workstations require the password opcode to be run before the attribute value is changed (if Admin password is enabled). Tested on some Thinkpads to confirm they are OK with this order too. Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> Fixes: 640a5fa50a42 ("platform/x86: think-lmi: Opcode support") Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240209152359.528919-1-mpearson-lenovo@squebb.ca Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Notes: Fixes: 640a5fa50a42 ("platform/x86: think-lmi: Opcode support") # v5.17-rc1 Lore: https://lore.kernel.org/r/20240209152359.528919-1-mpearson-lenovo@squebb.ca # lkml, platform-driver-x86 Lore: https://lore.kernel.org/r/20240227131639.930126707@linuxfoundation.org # linux-patches, stable
2024-02-19selftests/bpf: Add negtive test cases for task iterYafang Shao2-1/+12
Incorporate a test case to assess the handling of invalid flags or task__nullable parameters passed to bpf_iter_task_new(). Prior to the preceding commit, this scenario could potentially trigger a kernel panic. However, with the previous commit, this test case is expected to function correctly. Signed-off-by: Yafang Shao <laoar.shao@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20240217114152.1623-3-laoar.shao@gmail.com Notes: Lore: https://lore.kernel.org/r/20240208090906.56337-3-laoar.shao@gmail.com # bpf Lore: https://lore.kernel.org/r/20240217114152.1623-3-laoar.shao@gmail.com # bpf
2024-02-19bpf: Fix an issue due to uninitialized bpf_iter_taskYafang Shao1-0/+2
Failure to initialize it->pos, coupled with the presence of an invalid value in the flags variable, can lead to it->pos referencing an invalid task, potentially resulting in a kernel panic. To mitigate this risk, it's crucial to ensure proper initialization of it->pos to NULL. Fixes: ac8148d957f5 ("bpf: bpf_iter_task_next: use next_task(kit->task) rather than next_task(kit->pos)") Signed-off-by: Yafang Shao <laoar.shao@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Acked-by: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/bpf/20240217114152.1623-2-laoar.shao@gmail.com Notes: Fixes: ac8148d957f5 ("bpf: bpf_iter_task_next: use next_task(kit->task) rather than next_task(kit->pos)") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240208090906.56337-2-laoar.shao@gmail.com # bpf Lore: https://lore.kernel.org/r/20240217114152.1623-2-laoar.shao@gmail.com # bpf
2024-02-19selftests/bpf: Test racing between bpf_timer_cancel_and_free and ↵Martin KaFai Lau2-2/+67
bpf_timer_cancel This selftest is based on a Alexei's test adopted from an internal user to troubleshoot another bug. During this exercise, a separate racing bug was discovered between bpf_timer_cancel_and_free and bpf_timer_cancel. The details can be found in the previous patch. This patch is to add a selftest that can trigger the bug. I can trigger the UAF everytime in my qemu setup with KASAN. The idea is to have multiple user space threads running in a tight loop to exercise both bpf_map_update_elem (which calls into bpf_timer_cancel_and_free) and bpf_timer_cancel. Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Hou Tao <houtao1@huawei.com> Link: https://lore.kernel.org/bpf/20240215211218.990808-2-martin.lau@linux.dev Notes: Lore: https://lore.kernel.org/r/20240215211218.990808-2-martin.lau@linux.dev # bpf
2024-02-19bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancelMartin KaFai Lau1-1/+4
The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer. bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period. Fixes: b00628b1c7d5 ("bpf: Introduce bpf timers.") Suggested-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Hou Tao <houtao1@huawei.com> Link: https://lore.kernel.org/bpf/20240215211218.990808-1-martin.lau@linux.dev Notes: Fixes: b00628b1c7d5 ("bpf: Introduce bpf timers.") # v5.15-rc1 Stable: 8327ed12e8eb # v6.6.19 Stable: addf5e297e6c # v6.1.80 Stable: 5268bb02107b # v5.15.150 Lore: https://lore.kernel.org/r/20240215211218.990808-1-martin.lau@linux.dev # bpf Lore: https://lore.kernel.org/r/20240227131615.601402459@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.348191075@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131633.830677078@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131639.901359058@linuxfoundation.org # linux-patches, stable
2024-02-19enic: Avoid false positive under FORTIFY_SOURCEKees Cook1-1/+2
FORTIFY_SOURCE has been ignoring 0-sized destinations while the kernel code base has been converted to flexible arrays. In order to enforce the 0-sized destinations (e.g. with __counted_by), the remaining 0-sized destinations need to be handled. Unfortunately, struct vic_provinfo resists full conversion, as it contains a flexible array of flexible arrays, which is only possible with the 0-sized fake flexible array. Use unsafe_memcpy() to avoid future false positives under CONFIG_FORTIFY_SOURCE. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Lore: https://lore.kernel.org/r/20240216233004.work.012-kees@kernel.org # linux-hardening, lkml, netdev Lore: https://lore.kernel.org/r/20240229203729.2860356-15-sashal@kernel.org # linux-hardening, lkml, netdev, stable Lore: https://lore.kernel.org/r/20240229203933.2861006-14-sashal@kernel.org # linux-hardening, lkml, netdev, stable Lore: https://lore.kernel.org/r/20240229204039.2861519-10-sashal@kernel.org # linux-hardening, lkml, netdev, stable
2024-02-19ionic: use pci_is_enabled not open codeShannon Nelson1-1/+1
Since there is a utility available for this, use the API rather than open code. Fixes: 13943d6c8273 ("ionic: prevent pci disable of already disabled device") Reviewed-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 13943d6c8273 ("ionic: prevent pci disable of already disabled device") # v6.8-rc1 Lore: https://lore.kernel.org/r/20240216225259.72875-1-shannon.nelson@amd.com # netdev
2024-02-19btrfs: fix deadlock with fiemap and extent lockingJosef Bacik1-17/+45
While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it. Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking. To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before. The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag. With this patch applied we no longer deadlock with my testcase. CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Notes: Fixed-by: a1a4a9ca77f1 ("btrfs: fix race between ordered extent completion and fiemap") # v6.8-rc7 Fixed-by-stable: d43f8e58f10a ("btrfs: fix race between ordered extent completion and fiemap") # v6.6.21 Lore: https://lore.kernel.org/r/20240304211549.931535666@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240304211551.880347593@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/47ac92a6c8be53a5e10add9315255460c062b52d.1706817512.git.josef@toxicpanda.com # linux-btrfs Lore: https://lore.kernel.org/r/49c34d4ede23d28d916eab4a22d4ec698f77f498.1707756893.git.josef@toxicpanda.com # linux-btrfs
2024-02-19btrfs: defrag: avoid unnecessary defrag caused by incorrect extent sizeQu Wenruo1-1/+1
[BUG] With the following file extent layout, defrag would do unnecessary IO and result more on-disk space usage. # mkfs.btrfs -f $dev # mount $dev $mnt # xfs_io -f -c "pwrite 0 40m" $mnt/foobar # sync # xfs_io -f -c "pwrite 40m 16k" $mnt/foobar # sync Above command would lead to the following file extent layout: item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53 generation 7 type 1 (regular) extent data disk byte 298844160 nr 41943040 extent data offset 0 nr 41943040 ram 41943040 extent compression 0 (none) item 7 key (257 EXTENT_DATA 41943040) itemoff 15763 itemsize 53 generation 8 type 1 (regular) extent data disk byte 13631488 nr 16384 extent data offset 0 nr 16384 ram 16384 extent compression 0 (none) Which is mostly fine. We can allow the final 16K to be merged with the previous 40M, but it's upon the end users' preference. But if we defrag the file using the default parameters, it would result worse file layout: # btrfs filesystem defrag $mnt/foobar # sync item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53 generation 7 type 1 (regular) extent data disk byte 298844160 nr 41943040 extent data offset 0 nr 8650752 ram 41943040 extent compression 0 (none) item 7 key (257 EXTENT_DATA 8650752) itemoff 15763 itemsize 53 generation 9 type 1 (regular) extent data disk byte 340787200 nr 33292288 extent data offset 0 nr 33292288 ram 33292288 extent compression 0 (none) item 8 key (257 EXTENT_DATA 41943040) itemoff 15710 itemsize 53 generation 8 type 1 (regular) extent data disk byte 13631488 nr 16384 extent data offset 0 nr 16384 ram 16384 extent compression 0 (none) Note the original 40M extent is still there, but a new 32M extent is created for no benefit at all. [CAUSE] There is an existing check to make sure we won't defrag a large enough extent (the threshold is by default 32M). But the check is using the length to the end of the extent: range_len = em->len - (cur - em->start); /* Skip too large extent */ if (range_len >= extent_thresh) goto next; This means, for the first 8MiB of the extent, the range_len is always smaller than the default threshold, and would not be defragged. But after the first 8MiB, the remaining part would fit the requirement, and be defragged. Such different behavior inside the same extent caused the above problem, and we should avoid different defrag decision inside the same extent. [FIX] Instead of using @range_len, just use @em->len, so that we have a consistent decision among the same file extent. Now with this fix, we won't touch the extent, thus not making it any worse. Reported-by: Filipe Manana <fdmanana@suse.com> Fixes: 0cb5950f3f3b ("btrfs: fix deadlock when reserving space during defrag") CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Notes: Fixes: 0cb5950f3f3b ("btrfs: fix deadlock when reserving space during defrag") # v5.17-rc2 Stable: 0bb020dca6d8 # v6.6.19 Lore: https://lore.kernel.org/r/20240227131630.329797566@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.199179400@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/abb506b3d54837f79119cdff6c3e08a61e28eba7.1707259963.git.wqu@suse.com # linux-btrfs
2024-02-19drm/tests/drm_buddy: fix 32b buildMatthew Auld1-8/+8
Doesn't seem to compile on 32b, presumably due to u64 mod/division. Simplest is to just switch over to u32 here. Also make print modifiers consistent with that. Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240215174431.285069-7-matthew.auld@intel.com Signed-off-by: Christian König <christian.koenig@amd.com> Notes: Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") # v6.8-rc5 Lore: https://lore.kernel.org/r/20240215174431.285069-7-matthew.auld@intel.com # dri-devel, intel-xe
2024-02-19ata: ahci_ceva: fix error handling for Xilinx GT PHY supportRadhey Shyam Pandey1-46/+79
Platform clock and phy error resources are not cleaned up in Xilinx GT PHY error path. To fix introduce the function ceva_ahci_platform_enable_resources() which is a customized version of ahci_platform_enable_resources() and inline with SATA IP programming sequence it does: - Assert SATA reset - Program PS GTR phy - Bring SATA by de-asserting the reset - Wait for GT lane PLL to be locked ceva_ahci_platform_enable_resources() is also used in the resume path as the same SATA programming sequence (as in probe) should be followed. Also cleanup the mixed usage of ahci_platform_enable_resources() and custom implementation in the probe function as both are not required. Fixes: 9a9d3abe24bb ("ata: ahci: ceva: Update the driver to support xilinx GT phy") Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Notes: Fixes: 9a9d3abe24bb ("ata: ahci: ceva: Update the driver to support xilinx GT phy") # v5.13-rc1 Stable: d4c58764dab8 # v6.6.19 Stable: 9a581b17b722 # v6.1.80 Stable: 6800ad7417f3 # v5.15.150 Lore: https://lore.kernel.org/r/1705604904-471889-2-git-send-email-radhey.shyam.pandey@amd.com # linux-ide, lkml Lore: https://lore.kernel.org/r/1708020060-1439879-1-git-send-email-radhey.shyam.pandey@amd.com # linux-ide, lkml Lore: https://lore.kernel.org/r/1708107297-1798828-1-git-send-email-radhey.shyam.pandey@amd.com # linux-ide, lkml Lore: https://lore.kernel.org/r/20240227131615.569281217@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.317872337@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131633.800675478@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131639.871975533@linuxfoundation.org # linux-patches, stable
2024-02-19ahci: asm1064: correct count of reported portsAndrey Jr. Melnikov1-3/+11
The ASM1064 SATA host controller always reports wrongly, that it has 24 ports. But in reality, it only has four ports. before: ahci 0000:04:00.0: SSS flag set, parallel bus scan disabled ahci 0000:04:00.0: AHCI 0001.0301 32 slots 24 ports 6 Gbps 0xffff0f impl SATA mode ahci 0000:04:00.0: flags: 64bit ncq sntf stag pm led only pio sxs deso sadm sds apst after: ahci 0000:04:00.0: ASM1064 has only four ports ahci 0000:04:00.0: forcing port_map 0xffff0f -> 0xf ahci 0000:04:00.0: SSS flag set, parallel bus scan disabled ahci 0000:04:00.0: AHCI 0001.0301 32 slots 24 ports 6 Gbps 0xf impl SATA mode ahci 0000:04:00.0: flags: 64bit ncq sntf stag pm led only pio sxs deso sadm sds apst Signed-off-by: "Andrey Jr. Melnikov" <temnota.am@gmail.com> Signed-off-by: Niklas Cassel <cassel@kernel.org> Notes: Lore: https://lore.kernel.org/r/20240214165758.986896-1-cassel@kernel.org # linux-ide Lore: https://lore.kernel.org/r/vbpzr7uqpfemb3qa6xy2fxioct44l5vugg2wkywyolfpzqcmau@jgrrhmk2scaj # linux-ide, lkml
2024-02-19selftests: bonding: set active slave to primary eth1 specificallyHangbin Liu1-0/+2
In bond priority testing, we set the primary interface to eth1 and add eth0,1,2 to bond in serial. This is OK in normal times. But when in debug kernel, the bridge port that eth0,1,2 connected would start slowly (enter blocking, forwarding state), which caused the primary interface down for a while after enslaving and active slave changed. Here is a test log from Jakub's debug test[1]. [ 400.399070][ T50] br0: port 1(s0) entered disabled state [ 400.400168][ T50] br0: port 4(s2) entered disabled state [ 400.941504][ T2791] bond0: (slave eth0): making interface the new active one [ 400.942603][ T2791] bond0: (slave eth0): Enslaving as an active interface with an up link [ 400.943633][ T2766] br0: port 1(s0) entered blocking state [ 400.944119][ T2766] br0: port 1(s0) entered forwarding state [ 401.128792][ T2792] bond0: (slave eth1): making interface the new active one [ 401.130771][ T2792] bond0: (slave eth1): Enslaving as an active interface with an up link [ 401.131643][ T69] br0: port 2(s1) entered blocking state [ 401.132067][ T69] br0: port 2(s1) entered forwarding state [ 401.346201][ T2793] bond0: (slave eth2): Enslaving as a backup interface with an up link [ 401.348414][ T50] br0: port 4(s2) entered blocking state [ 401.348857][ T50] br0: port 4(s2) entered forwarding state [ 401.519669][ T250] bond0: (slave eth0): link status definitely down, disabling slave [ 401.526522][ T250] bond0: (slave eth1): link status definitely down, disabling slave [ 401.526986][ T250] bond0: (slave eth2): making interface the new active one [ 401.629470][ T250] bond0: (slave eth0): link status definitely up [ 401.630089][ T250] bond0: (slave eth1): link status definitely up [...] # TEST: prio (active-backup ns_ip6_target primary_reselect 1) [FAIL] # Current active slave is eth2 but not eth1 Fix it by setting active slave to primary slave specifically before testing. [1] https://netdev-3.bots.linux.dev/vmksft-bonding-dbg/results/464301/1-bond-options-sh/stdout Fixes: 481b56e0391e ("selftests: bonding: re-format bond option tests") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 481b56e0391e ("selftests: bonding: re-format bond option tests") # v6.3-rc7 Stable: 3e831970cf7f # v6.6.19 Lore: https://lore.kernel.org/r/20240214091955.3040930-1-liuhangbin@gmail.com # netdev Lore: https://lore.kernel.org/r/20240215023325.3309817-1-liuhangbin@gmail.com # netdev Lore: https://lore.kernel.org/r/20240227131633.770362352@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131639.834998330@linuxfoundation.org # linux-patches, stable
2024-02-19drm/meson: Don't remove bridges which are created by other driversMartin Blumenstingl3-3/+0
Stop calling drm_bridge_remove() for bridges allocated/managed by other drivers in the remove paths of meson_encoder_{cvbs,dsi,hdmi}. drm_bridge_remove() unregisters the bridge so it cannot be used anymore. Doing so for bridges we don't own can lead to the video pipeline not being able to come up after -EPROBE_DEFER of the VPU because we're unregistering a bridge that's managed by another driver. The other driver doesn't know that we have unregistered it's bridge and on subsequent .probe() we're not able to find those bridges anymore (since nobody re-creates them). This fixes probe errors on Meson8b boards with the CVBS outputs enabled. Fixes: 09847723c12f ("drm/meson: remove drm bridges at aggregate driver unbind time") Fixes: 42dcf15f901c ("drm/meson: add DSI encoder") Cc: <stable@vger.kernel.org> Reported-by: Steve Morvai <stevemorvai@hotmail.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Steve Morvai <stevemorvai@hotmail.com> Link: https://lore.kernel.org/r/20240215220442.1343152-1-martin.blumenstingl@googlemail.com Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240215220442.1343152-1-martin.blumenstingl@googlemail.com Notes: Fixes: 09847723c12f ("drm/meson: remove drm bridges at aggregate driver unbind time") # v6.1-rc1 Fixes: 42dcf15f901c ("drm/meson: add DSI encoder") # v6.5-rc1 Stable: d715ee6cbe7c # v6.6.19 Stable: 7d34b1078665 # v6.1.81 Lore: https://lore.kernel.org/r/20240215220442.1343152-1-martin.blumenstingl@googlemail.com # linux-amlogic, linux-arm-kernel, lkml, stable
2024-02-18Linux 6.8-rc5v6.8-rc5Linus Torvalds1-1/+1
2024-02-18Merge tag 'kbuild-fixes-v6.8-2' of ↵Linus Torvalds9-32/+33
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Reformat nested if-conditionals in Makefiles with 4 spaces - Fix CONFIG_DEBUG_INFO_BTF builds for big endian - Fix modpost for module srcversion - Fix an escape sequence warning in gen_compile_commands.py - Fix kallsyms to ignore ARMv4 thunk symbols * tag 'kbuild-fixes-v6.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kallsyms: ignore ARMv4 thunks along with others modpost: trim leading spaces when processing source files list gen_compile_commands: fix invalid escape sequence warning kbuild: Fix changing ELF file type for output of gen_btf for big endian docs: kconfig: Fix grammar and formatting kbuild: use 4-space indentation when followed by conditionals
2024-02-18Merge tag 'x86_urgent_for_v6.8_rc5' of ↵Linus Torvalds1-5/+18
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fix from Borislav Petkov: - Use a GB page for identity mapping only when memory of this size is requested so that mapping of reserved regions is prevented which would otherwise lead to system crashes on UV machines * tag 'x86_urgent_for_v6.8_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
2024-02-18Merge tag 'irq_urgent_for_v6.8_rc5' of ↵Linus Torvalds4-26/+47
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Borislav Petkov: - Fix GICv4.1 affinity update - Restore a quirk for ACPI-based GICv4 systems - Handle non-coherent GICv4 redistributors properly - Prevent spurious interrupts on Broadcom devices using GIC v3 architecture - Other minor fixes * tag 'irq_urgent_for_v6.8_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic-v3-its: Fix GICv4.1 VPE affinity update irqchip/gic-v3-its: Restore quirk probing for ACPI-based systems irqchip/gic-v3-its: Handle non-coherent GICv4 redistributors irqchip/qcom-mpm: Fix IS_ERR() vs NULL check in qcom_mpm_init() irqchip/loongson-eiointc: Use correct struct type in eiointc_domain_alloc() irqchip/irq-brcmstb-l2: Add write memory barrier before exit
2024-02-18Merge tag 'i2c-for-6.8-rc5' of ↵Linus Torvalds4-13/+17
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Two fixes for i801 and qcom-geni devices. Meanwhile, a fix from Arnd addresses a compilation error encountered during compile test on powerpc" * tag 'i2c-for-6.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: i801: Fix block process call transactions i2c: pasemi: split driver into two separate modules i2c: qcom-geni: Correct I2C TRE sequence
2024-02-18Merge branch 'bcmasp-fixes'David S. Miller2-3/+6
Justin Chen says: ==================== net: bcmasp: bug fixes for bcmasp Fix two bugs. - Indicate that PM is managed by mac to prevent double pm calls. This doesn't lead to a crash, but waste a noticable amount of time suspending/resuming. - Sanity check for OOB write was off by one. Leading to a false error when using the full array. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-18net: bcmasp: Sanity check is off by oneJustin Chen1-3/+3
A sanity check for OOB write is off by one leading to a false positive when the array is full. Fixes: 9b90aca97f6d ("net: ethernet: bcmasp: fix possible OOB write in bcmasp_netfilt_get_all_active()") Signed-off-by: Justin Chen <justin.chen@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 9b90aca97f6d ("net: ethernet: bcmasp: fix possible OOB write in bcmasp_netfilt_get_all_active()") # v6.6-rc2 Stable: 7bcb0a2510ce # v6.6.19 Lore: https://lore.kernel.org/r/20240215182732.1536941-3-justin.chen@broadcom.com # lkml, netdev Lore: https://lore.kernel.org/r/20240227131633.710135255@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131639.767658110@linuxfoundation.org # linux-patches, stable
2024-02-18net: bcmasp: Indicate MAC is in charge of PHY PMFlorian Fainelli1-0/+3
Avoid the PHY library call unnecessarily into the suspend/resume functions by setting phydev->mac_managed_pm to true. The ASP driver essentially does exactly what mdio_bus_phy_resume() does. Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Justin Chen <justin.chen@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller") # v6.6-rc1 Stable: ae24a16a8343 # v6.6.19 Lore: https://lore.kernel.org/r/20240215182732.1536941-2-justin.chen@broadcom.com # lkml, netdev Lore: https://lore.kernel.org/r/20240227131633.680254534@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131639.737999817@linuxfoundation.org # linux-patches, stable
2024-02-18Merge branch 'mptcp-fixes'David S. Miller12-68/+116
Matthieu Baerts says: ==================== mptcp: misc. fixes for v6.8 This series includes 4 types of fixes: Patches 1 and 2 force the path-managers not to allocate a new address entry when dealing with the "special" ID 0, reserved to the address of the initial subflow. These patches can be backported up to v5.19 and v5.12 respectively. Patch 3 to 6 fix the in-kernel path-manager not to create duplicated subflows. Patch 6 is the main fix, but patches 3 to 5 are some kind of pre-requisities: they fix some data races that could also lead to the creation of unexpected subflows. These patches can be backported up to v5.7, v5.10, v6.0, and v5.15 respectively. Note that patch 3 modifies the existing ULP API. No better solutions have been found for -net, and there is some similar prior art, see commit 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info"). Please also note that TLS ULP Diag has likely the same issue. Patches 7 to 9 fix issues in the selftests, when executing them on older kernels, e.g. when testing the last version of these kselftests on the v5.15.148 kernel as it is done by LKFT when validating stable kernels. These patches only avoid printing expected errors the console and marking some tests as "OK" while they have been skipped. Patches 7 and 8 can be backported up to v6.6. Patches 10 to 13 make sure all MPTCP selftests subtests have a unique name. It is important to have a unique (sub)test name in TAP, because that's the test identifier. Some CI environments might drop tests with duplicated names. Patches 10 to 12 can be backported up to v6.6. ==================== Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-18selftests: mptcp: diag: unique 'cestab' subtest namesMatthieu Baerts (NGI0)1-6/+11
It is important to have a unique (sub)test name in TAP, because some CI environments drop tests with duplicated name. Some 'cestab' subtests from the diag selftest had the same names, e.g.: ....chk 0 cestab Now the previous value is taken, to have different names, e.g.: ....chk 2->0 cestab after flush While at it, the 'after flush' info is added, similar to what is done with the 'in use' subtests. Also inspired by these 'in use' subtests, 'many' is displayed instead of a large number: many msk socket present [ ok ] ....chk many msk in use [ ok ] ....chk many cestab [ ok ] ....chk many->0 msk in use after flush [ ok ] ....chk many->0 cestab after flush [ ok ] Fixes: 81ab772819da ("selftests: mptcp: diag: check CURRESTAB counters") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 81ab772819da ("selftests: mptcp: diag: check CURRESTAB counters") # v6.8-rc1 Fixes-stable: 1f24ba67ba49 ("selftests: mptcp: diag: check CURRESTAB counters") # v6.6.19 Stable: a7f34a068467 # v6.6.19
2024-02-18selftests: mptcp: diag: unique 'in use' subtest namesMatthieu Baerts (NGI0)1-8/+12
It is important to have a unique (sub)test name in TAP, because some CI environments drop tests with duplicated name. Some 'in use' subtests from the diag selftest had the same names, e.g.: chk 0 msk in use after flush Now the previous value is taken, to have different names, e.g.: chk 2->0 msk in use after flush While at it, avoid repeating the full message, declare it once in the helper. Fixes: ce9902573652 ("selftests: mptcp: diag: format subtests results in TAP") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: ce9902573652 ("selftests: mptcp: diag: format subtests results in TAP") # v6.6-rc1 Stable: 6b51994e1994 # v6.6.19
2024-02-18selftests: mptcp: userspace_pm: unique subtest namesMatthieu Baerts (NGI0)1-2/+2
It is important to have a unique (sub)test name in TAP, because some CI environments drop tests with duplicated names. Some subtests from the userspace_pm selftest had the same names. That's because different subflows are created (and deleted) between the same pair of IP addresses. Simply adding the destination port in the name is then enough to have different names, because the destination port is always different. Note that adding such info takes a bit more space, so we need to increase a bit the width to print the name, simply to keep all the '[ OK ]' aligned as before. Fixes: f589234e1af0 ("selftests: mptcp: userspace_pm: format subtests results in TAP") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: f589234e1af0 ("selftests: mptcp: userspace_pm: format subtests results in TAP") # v6.6-rc1 Stable: 5b9bc8e6275a # v6.6.19 Lore: https://lore.kernel.org/r/20240227131632.152833129@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.839013727@linuxfoundation.org # linux-patches, stable
2024-02-18selftests: mptcp: simult flows: fix some subtest namesMatthieu Baerts (NGI0)1-1/+2
The selftest was correctly recording all the results, but the 'reverse direction' part was missing in the name when needed. It is important to have a unique (sub)test name in TAP, because some CI environments drop tests with duplicated name. Fixes: 675d99338e7a ("selftests: mptcp: simult flows: format subtests results in TAP") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 675d99338e7a ("selftests: mptcp: simult flows: format subtests results in TAP") # v6.6-rc1 Stable: db887e24f95f # v6.6.19 Lore: https://lore.kernel.org/r/20240227131632.187935596@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.869373743@linuxfoundation.org # linux-patches, stable
2024-02-18selftests: mptcp: diag: fix bash warnings on older kernelsMatthieu Baerts (NGI0)1-2/+2
Since the 'Fixes' commit mentioned below, the command that is executed in __chk_nr() helper can return nothing if the feature is not supported. This is the case when the MPTCP CURRESTAB counter is not supported. To avoid this warning ... ./diag.sh: line 65: [: !=: unary operator expected ... we just need to surround '$nr' with double quotes, to support an empty string when the feature is not supported. Fixes: 81ab772819da ("selftests: mptcp: diag: check CURRESTAB counters") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 81ab772819da ("selftests: mptcp: diag: check CURRESTAB counters") # v6.8-rc1 Fixes-stable: 1f24ba67ba49 ("selftests: mptcp: diag: check CURRESTAB counters") # v6.6.19 Stable: 509bf4e553eb # v6.6.19 Lore: https://lore.kernel.org/r/20240227131632.307720815@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131638.015919949@linuxfoundation.org # linux-patches, stable
2024-02-18selftests: mptcp: pm nl: avoid error msg on older kernelsMatthieu Baerts (NGI0)1-1/+1
Since the 'Fixes' commit mentioned below, and if the kernel being tested doesn't support the 'fullmesh' flag, this error will be printed: netlink error -22 (Invalid argument) ./pm_nl_ctl: bailing out due to netlink error[s] But that can be normal if the kernel doesn't support the feature, no need to print this worrying error message while everything else looks OK. So we can mute stderr. Failures will still be detected if any. Fixes: 1dc88d241f92 ("selftests: mptcp: pm_nl_ctl: always look for errors") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 1dc88d241f92 ("selftests: mptcp: pm_nl_ctl: always look for errors") # v6.6-rc1 Stable: 1b1ce669a1f0 # v6.6.19 Lore: https://lore.kernel.org/r/20240227131632.247481639@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.933714127@linuxfoundation.org # linux-patches, stable
2024-02-18selftests: mptcp: pm nl: also list skipped testsMatthieu Baerts (NGI0)1-0/+6
If the feature is not supported by older kernels, and instead of just ignoring some tests, we should mark them as skipped, so we can still track them. Fixes: d85555ac11f9 ("selftests: mptcp: pm_netlink: format subtests results in TAP") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: d85555ac11f9 ("selftests: mptcp: pm_netlink: format subtests results in TAP") # v6.6-rc1 Stable: 4f1aa3853b95 # v6.6.19 Lore: https://lore.kernel.org/r/20240215-upstream-net-20240215-misc-fixes-v1-7-8c01a55d8f6a@kernel.org # linux-kselftest, lkml, mptcp, netdev, stable Lore: https://lore.kernel.org/r/20240227131632.217904897@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.903583489@linuxfoundation.org # linux-patches, stable
2024-02-18mptcp: fix duplicate subflow creationPaolo Abeni1-15/+18
Fullmesh endpoints could end-up unexpectedly generating duplicate subflows - same local and remote addresses - when multiple incoming ADD_ADDR are processed before the PM creates the subflow for the local endpoints. Address the issue explicitly checking for duplicates at subflow creation time. To avoid a quadratic computational complexity, track the unavailable remote address ids in a temporary bitmap and initialize such bitmap with the remote ids of all the existing subflows matching the local address currently processed. The above allows additionally replacing the existing code checking for duplicate entry in the current set with a simple bit test operation. Fixes: 2843ff6f36db ("mptcp: remote addresses fullmesh") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/435 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 2843ff6f36db ("mptcp: remote addresses fullmesh") # v5.15-rc1 Stable: 1ea7b252b47f # v6.6.19 Stable: fbccc5eb1652 # v6.1.81 Lore: https://lore.kernel.org/r/1392a4ef6a8a45ca3a920f933a12766283a828c6.1707144963.git.pabeni@redhat.com # mptcp Lore: https://lore.kernel.org/r/20240215-upstream-net-20240215-misc-fixes-v1-6-8c01a55d8f6a@kernel.org # linux-kselftest, lkml, mptcp, netdev, stable Lore: https://lore.kernel.org/r/20240227131632.122571171@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.807947516@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227180142.4029958-2-matttbe@kernel.org # mptcp, stable Lore: https://lore.kernel.org/r/20240304211600.175818877@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/65ea8b9d71895455ded0ed44d74e0de0e2c2481e.1707418323.git.pabeni@redhat.com # mptcp Lore: https://lore.kernel.org/r/cover.1707144963.git.pabeni@redhat.com # mptcp Lore: https://lore.kernel.org/r/cover.1707418323.git.pabeni@redhat.com # mptcp
2024-02-18mptcp: fix data races on remote_idPaolo Abeni2-7/+7
Similar to the previous patch, address the data race on remote_id, adding the suitable ONCE annotations. Fixes: bedee0b56113 ("mptcp: address lookup improvements") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: bedee0b56113 ("mptcp: address lookup improvements") # v6.0-rc1 Stable: 2dba5774e8ed # v6.6.19 Stable: e64148635509 # v6.1.81 Lore: https://lore.kernel.org/r/20240215-upstream-net-20240215-misc-fixes-v1-5-8c01a55d8f6a@kernel.org # linux-kselftest, lkml, mptcp, netdev, stable Lore: https://lore.kernel.org/r/20240227131632.092012127@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.777811868@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227180033.4028616-2-matttbe@kernel.org # mptcp, stable Lore: https://lore.kernel.org/r/20240304211600.146093744@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/7487c3a37301428f088edb73cab6d01e55049353.1707144963.git.pabeni@redhat.com # mptcp Lore: https://lore.kernel.org/r/e036aeeec2daca0fe03e18456d8862f5ea32f06f.1707418323.git.pabeni@redhat.com # mptcp
2024-02-18mptcp: fix data races on local_idPaolo Abeni6-13/+23
The local address id is accessed lockless by the NL PM, add all the required ONCE annotation. There is a caveat: the local id can be initialized late in the subflow life-cycle, and its validity is controlled by the local_id_valid flag. Remove such flag and encode the validity in the local_id field itself with negative value before initialization. That allows accessing the field consistently with a single read operation. Fixes: 0ee4261a3681 ("mptcp: implement mptcp_pm_remove_subflow") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 0ee4261a3681 ("mptcp: implement mptcp_pm_remove_subflow") # v5.10-rc1 Stable: ba2cf922502c # v6.6.19 Stable: e6e04845c2e8 # v6.1.81 Lore: https://lore.kernel.org/r/20240215-upstream-net-20240215-misc-fixes-v1-4-8c01a55d8f6a@kernel.org # linux-kselftest, lkml, mptcp, netdev, stable Lore: https://lore.kernel.org/r/20240227131632.061885168@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.746869466@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227175850.4026403-2-matttbe@kernel.org # mptcp, stable Lore: https://lore.kernel.org/r/20240304211600.110155297@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/34c617cdc777aa32b1fa4ecc5c23784255f5fa56.1707144963.git.pabeni@redhat.com # mptcp Lore: https://lore.kernel.org/r/6842c91dfceda8a883a90aa57cbb4df4c20908a5.1707418323.git.pabeni@redhat.com # mptcp
2024-02-18mptcp: fix lockless access in subflow ULP diagPaolo Abeni3-3/+7
Since the introduction of the subflow ULP diag interface, the dump callback accessed all the subflow data with lockless. We need either to annotate all the read and write operation accordingly, or acquire the subflow socket lock. Let's do latter, even if slower, to avoid a diffstat havoc. Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace") # v5.7-rc1 Fixed-by: d6a9608af9a7 ("mptcp: fix possible deadlock in subflow diag") # v6.8-rc7 Fixed-by-stable: fa8c776f4c32 ("mptcp: fix possible deadlock in subflow diag") # v6.6.21 Fixed-by-stable: f27d319df055 ("mptcp: fix possible deadlock in subflow diag") # v6.1.81 Fixed-by-stable: cc32ba2fdf3f ("mptcp: fix possible deadlock in subflow diag") # v5.15.151 Fixed-by-stable: 70e5b013538d ("mptcp: fix possible deadlock in subflow diag") # v5.10.212 Stable: e074c8297ee4 # v6.6.19 Stable: 71787c665d09 # v6.1.80 Stable: 7d6e8d7ee13b # v5.15.150 Stable: 8affdbb3e2ef # v5.10.211 Lore: https://lore.kernel.org/r/20240215-upstream-net-20240215-misc-fixes-v1-3-8c01a55d8f6a@kernel.org # linux-kselftest, lkml, mptcp, netdev, stable Lore: https://lore.kernel.org/r/20240227131601.812174675@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131614.669221206@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131618.604947029@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131632.032246466@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.716266321@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/96f99278110c7ebd0ac401094b367f9bbdf5240f.1707144963.git.pabeni@redhat.com # mptcp Lore: https://lore.kernel.org/r/96f99278110c7ebd0ac401094b367f9bbdf5240f.1707418323.git.pabeni@redhat.com # mptcp
2024-02-18mptcp: add needs_id for netlink appending addrGeliang Tang1-5/+19
Just the same as userspace PM, a new parameter needs_id is added for in-kernel PM mptcp_pm_nl_append_new_local_addr() too. Add a new helper mptcp_pm_has_addr_attr_id() to check whether an address ID is set from PM or not. In mptcp_pm_nl_get_local_id(), needs_id is always true, but in mptcp_pm_nl_add_addr_doit(), pass mptcp_pm_has_addr_attr_id() to needs_it. Fixes: efd5a4c04e18 ("mptcp: add the address ID assignment bitmap") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: efd5a4c04e18 ("mptcp: add the address ID assignment bitmap") # v5.12-rc2 Stable: 7e7a81f9f2da # v6.6.19 Stable: 70a4a2657201 # v6.1.80 Stable: 5101e9f11a87 # v5.15.151 Lore: https://lore.kernel.org/r/1d1970ac75aa9b924f1da17c3c89dcba96e5bb46.1706759413.git.tanggeliang@kylinos.cn # mptcp Lore: https://lore.kernel.org/r/20240215-upstream-net-20240215-misc-fixes-v1-2-8c01a55d8f6a@kernel.org # linux-kselftest, lkml, mptcp, netdev, stable Lore: https://lore.kernel.org/r/20240226215620.757784-2-matttbe@kernel.org # mptcp, stable Lore: https://lore.kernel.org/r/20240227131616.709399360@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131635.218651774@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.684501106@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240228173714.262012-4-matttbe@kernel.org # mptcp, stable Lore: https://lore.kernel.org/r/20240304211544.631172024@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/7a7abb740b313d77a06d644360ce3f21dd4d7f09.1705375746.git.tanggeliang@kylinos.cn # mptcp Lore: https://lore.kernel.org/r/be3463f397dc050c6a11cbdf6a281dccff9b0642.1705558030.git.tanggeliang@kylinos.cn # mptcp Lore: https://lore.kernel.org/r/c56153b95c3086a8cddf4a7d5efc34cbbf473b87.1704892316.git.geliang.tang@linux.dev # mptcp
2024-02-18mptcp: add needs_id for userspace appending addrGeliang Tang1-6/+7
When userspace PM requires to create an ID 0 subflow in "userspace pm create id 0 subflow" test like this: userspace_pm_add_sf $ns2 10.0.3.2 0 An ID 1 subflow, in fact, is created. Since in mptcp_pm_nl_append_new_local_addr(), 'id 0' will be treated as no ID is set by userspace, and will allocate a new ID immediately: if (!e->addr.id) e->addr.id = find_next_zero_bit(pernet->id_bitmap, MPTCP_PM_MAX_ADDR_ID + 1, 1); To solve this issue, a new parameter needs_id is added for mptcp_userspace_pm_append_new_local_addr() to distinguish between whether userspace PM has set an ID 0 or whether userspace PM has not set any address. needs_id is true in mptcp_userspace_pm_get_local_id(), but false in mptcp_pm_nl_announce_doit() and mptcp_pm_nl_subflow_create_doit(). Fixes: e5ed101a6028 ("mptcp: userspace pm allow creating id 0 subflow") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: e5ed101a6028 ("mptcp: userspace pm allow creating id 0 subflow") # v6.6-rc5 Fixes-stable: 454bb54b8fe8 ("mptcp: userspace pm allow creating id 0 subflow") # v6.1.57 Stable: 176421d7afba # v6.6.19 Stable: 9e8e59af3a4a # v6.1.80 Lore: https://lore.kernel.org/r/0d089da27becde2a0ff936dbbe856b2baf9bf710.1706759413.git.tanggeliang@kylinos.cn # mptcp Lore: https://lore.kernel.org/r/20240215-upstream-net-20240215-misc-fixes-v1-1-8c01a55d8f6a@kernel.org # linux-kselftest, lkml, mptcp, netdev, stable Lore: https://lore.kernel.org/r/20240227131614.637824589@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131632.001562012@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131637.654003160@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/7edcff9daf63a93fc7c71c48658d51761ded7e38.1705375746.git.tanggeliang@kylinos.cn # mptcp Lore: https://lore.kernel.org/r/aeeff185a55f2dead9c1213ae65b3070eda07185.1704892316.git.geliang.tang@linux.dev # mptcp Lore: https://lore.kernel.org/r/eb36016f963d58a1531b7e90e9ee9f753f48da9a.1705558030.git.tanggeliang@kylinos.cn # mptcp
2024-02-18Merge branch 'inet-fix-NLM_F_DUMP_INTR-logic'David S. Miller2-7/+35
Eric Dumazet says: ==================== inet: fix NLM_F_DUMP_INTR logic Make sure NLM_F_DUMP_INTR is generated if dev_base_seq and dev_addr_genid are changed by the same amount. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-18ipv6: properly combine dev_base_seq and ipv6.dev_addr_genidEric Dumazet1-3/+18
net->dev_base_seq and ipv6.dev_addr_genid are monotonically increasing. If we XOR their values, we could miss to detect if both values were changed with the same amount. Fixes: 63998ac24f83 ("ipv6: provide addr and netconf dump consistency info") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 63998ac24f83 ("ipv6: provide addr and netconf dump consistency info") # v3.10-rc1 Stable: cf761c81e413 # v6.6.19 Stable: e5703735e57a # v6.1.80 Stable: 302b92b37304 # v5.15.150 Stable: 2f56d7126299 # v5.10.211 Stable: 799a4afaa54c # v5.4.270 Lore: https://lore.kernel.org/r/20240215172107.3461054-3-edumazet@google.com # netdev Lore: https://lore.kernel.org/r/20240227131555.212737588@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131602.174100636@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131615.536290462@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.225347410@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131633.649852759@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131639.708084018@linuxfoundation.org # linux-patches, stable
2024-02-18ipv4: properly combine dev_base_seq and ipv4.dev_addr_genidEric Dumazet1-4/+17
net->dev_base_seq and ipv4.dev_addr_genid are monotonically increasing. If we XOR their values, we could miss to detect if both values were changed with the same amount. Fixes: 0465277f6b3f ("ipv4: provide addr and netconf dump consistency info") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 0465277f6b3f ("ipv4: provide addr and netconf dump consistency info") # v3.10-rc1 Stable: 6634a8ecacc6 # v6.6.19 Stable: b43a4fb42fef # v6.1.80 Stable: a75b49547831 # v5.15.150 Stable: dcc1375d41a0 # v5.10.211 Stable: 5888f3424907 # v5.4.270 Lore: https://lore.kernel.org/r/20240215172107.3461054-2-edumazet@google.com # netdev Lore: https://lore.kernel.org/r/20240227131555.180507987@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131602.141630918@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131615.505167092@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.195048004@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131633.609885709@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131639.667440244@linuxfoundation.org # linux-patches, stable
2024-02-17Merge tag 'powerpc-6.8-3' of ↵Linus Torvalds24-33/+77
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: "This is a bit of a big batch for rc4, but just due to holiday hangover and because I didn't send any fixes last week due to a late revert request. I think next week should be back to normal. - Fix ftrace bug on boot caused by exit text sections with '-fpatchable-function-entry' - Fix accuracy of stolen time on pseries since the switch to VIRT_CPU_ACCOUNTING_GEN - Fix a crash in the IOMMU code when doing DLPAR remove - Set pt_regs->link on scv entry to fix BPF stack unwinding - Add missing PPC_FEATURE_BOOKE on 64-bit e5500/e6500, which broke gdb - Fix boot on some 6xx platforms with STRICT_KERNEL_RWX enabled - Fix build failures with KASAN enabled and 32KB stack size - Some other minor fixes Thanks to Arnd Bergmann, Benjamin Gray, Christophe Leroy, David Engraf, Gaurav Batra, Jason Gunthorpe, Jiangfeng Xiao, Matthias Schiffer, Nathan Lynch, Naveen N Rao, Nicholas Piggin, Nysal Jan K.A, R Nageswara Sastry, Shivaprasad G Bhat, Shrikanth Hegde, Spoorthy, Srikar Dronamraju, and Venkat Rao Bagalkote" * tag 'powerpc-6.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/iommu: Fix the missing iommu_group_put() during platform domain attach powerpc/pseries: fix accuracy of stolen time powerpc/ftrace: Ignore ftrace locations in exit text sections powerpc/cputable: Add missing PPC_FEATURE_BOOKE on PPC64 Book-E powerpc/kasan: Limit KASAN thread size increase to 32KB Revert "powerpc/pseries/iommu: Fix iommu initialisation during DLPAR add" powerpc: 85xx: mark local functions static powerpc: udbg_memcons: mark functions static powerpc/kasan: Fix addr error caused by page alignment powerpc/6xx: set High BAT Enable flag on G2_LE cores selftests/powerpc/papr_vpd: Check devfd before get_system_loc_code() powerpc/64: Set task pt_regs->link to the LR value on scv entry powerpc/pseries/iommu: Fix iommu initialisation during DLPAR add powerpc/pseries/papr-sysparm: use u8 arrays for payloads
2024-02-17Merge tag 'bcachefs-2024-02-17' of https://evilpiepirate.org/git/bcachefsLinus Torvalds11-16/+35
Pull bcachefs fixes from Kent Overstreet: "Mostly pretty trivial, the user visible ones are: - don't barf when replicas_required > replicas - fix check_version_upgrade() so it doesn't do something nonsensical when we're downgrading" * tag 'bcachefs-2024-02-17' of https://evilpiepirate.org/git/bcachefs: bcachefs: Fix missing va_end() bcachefs: Fix check_version_upgrade() bcachefs: Clamp replicas_required to replicas bcachefs: fix missing endiannes conversion in sb_members bcachefs: fix kmemleak in __bch2_read_super error handling path bcachefs: Fix missing bch2_err_class() calls
2024-02-17net: stmmac: Fix incorrect dereference in interrupt handlersPavel Sakharov1-20/+0
If 'dev' or 'data' is NULL, the 'priv' variable has an incorrect address when dereferencing calling netdev_err(). Since we get as 'dev_id' or 'data' what was passed as the 'dev' argument to request_irq() during interrupt initialization (that is, the net_device and rx/tx queue pointers initialized at the time of the call) and since there are usually no checks for the 'dev_id' argument in such handlers in other drivers, remove these checks from the handlers in stmmac driver. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 8532f613bc78 ("net: stmmac: introduce MSI Interrupt routines for mac, safety, RX & TX") Signed-off-by: Pavel Sakharov <p.sakharov@ispras.ru> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Notes: Fixes: 8532f613bc78 ("net: stmmac: introduce MSI Interrupt routines for mac, safety, RX & TX") # v5.13-rc1 Stable: 37067e6bc241 # v6.6.19 Stable: 8e29f988ad32 # v6.1.80 Stable: 2a7b878a7dad # v5.15.150 Lore: https://lore.kernel.org/r/20240214092718.331891-1-p.sakharov@ispras.ru # linux-arm-kernel, lkml, netdev Lore: https://lore.kernel.org/r/20240227131615.469202951@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131622.164294290@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131633.579878110@linuxfoundation.org # linux-patches, stable Lore: https://lore.kernel.org/r/20240227131639.621645750@linuxfoundation.org # linux-patches, stable
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-05-22 18:03:58 +0000