summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-06platform/surface: Replace deprecated strcpy() in surface_button_add()Thorsten Blum
strcpy() has been deprecated [1] because it performs no bounds checking on the destination buffer, which can lead to buffer overflows. Replace it with the safer strscpy(). No functional changes. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1] Reviewed-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260105145045.52764-2-thorsten.blum@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-06dt-bindings: soc: samsung: exynos-pmu: Drop unnecessary select schemaRob Herring (Arm)
The "select" schema is not necessary because "syscon" compatible is already excluded from the default select logic. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260105212858.3454174-1-robh@kernel.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-01-06media: ov02c10: Remove unnecessary hflip and vflip pointersHans de Goede
The cci_update_bits() inside ov02c10_set_ctrl() can use the passed data in the ctrl argument to access the vflip control value. After changing this there is no need to store a pointer to the hflip and vflip controls inside struct ov02c10, drop these. Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Tested-by: Sebastian Reichel <sre@kernel.org> # T14s Gen6 Snapdragon Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-06media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down sensorsHans de Goede
The Dell XPS 13 9350 and XPS 16 9640 both have an upside-down mounted OV02C10 sensor. This rotation of 180° is reported in neither the SSDB nor the _PLD for the sensor (both report a rotation of 0°). Add a DMI quirk mechanism for upside-down sensors and add 2 initial entries to the DMI quirk list for these 2 laptops. Note the OV02C10 driver was originally developed on a XPS 16 9640 which resulted in inverted vflip + hflip settings making it look like the sensor was upright on the XPS 16 9640 and upside down elsewhere this has been fixed in commit d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip"). This makes this commit a regression fix since now the video is upside down on these Dell XPS models where it was not before. Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip") Cc: stable@vger.kernel.org Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-06media: ov02c10: Fix the horizontal flip controlHans de Goede
During sensor calibration I noticed that with the hflip control set to false/disabled the image was mirrored. The horizontal flip control is inverted and needs to be set to 1 to not flip. This is something which seems to be common with various recent Omnivision sensors, the ov01a10 and ov08x40 also have an inverted mirror control. Invert the hflip control to fix the sensor mirroring by default. Fixes: b7cd2ba3f692 ("media: ov02c10: Support hflip and vflip") Cc: stable@vger.kernel.org Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Tested-by: Sebastian Reichel <sre@kernel.org> # T14s Gen6 Snapdragon Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-06media: ov02c10: Adjust x-win/y-win when changing flipping to preserve ↵Hans de Goede
bayer-pattern The ov02c10 is capable of having its (crop) window shifted around with 1 pixel precision while streaming. This allows changing the x/y window coordinates when changing flipping to preserve the bayer-pattern. __v4l2_ctrl_handler_setup() will now write the window coordinates at 0x3810 and 0x3812 so these can be dropped from sensor_1928x1092_30fps_setting. Since the bayer-pattern is now unchanged, the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag can be dropped from the flip controls. Note the original use of the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag was incomplete, besides setting the flag the driver should also have reported a different mbus code when getting the source pad's format depending on the hflip / vflip settings see the ov2680.c driver for example. Fixes: b7cd2ba3f692 ("media: ov02c10: Support hflip and vflip") Cc: stable@vger.kernel.org Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Tested-by: Sebastian Reichel <sre@kernel.org> # T14s Gen6 Snapdragon Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-06media: ov02c10: Fix bayer-pattern change after default vflip changeHans de Goede
After commit d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip") the reported bayer-pattern of MEDIA_BUS_FMT_SGRBG10_1X10 is no longer correct. Change the 16-bit x-win register (0x3810) value from 2 to 1 so that the sensor will generate data in GRBG bayer-order again. Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip") Cc: stable@vger.kernel.org Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-06media: rzg2l-cru: csi-2: Support RZ/V2H input sizesJacopo Mondi
The CRU version on the RZ/V2H SoC supports larger input sizes (4096x4096) compared to the version on the RZ/G2L (2800x4095). Store the per-SoC min/max sizes in the device match info and use them in place of the hardcoded ones. While at it, use the min sizes reported by the info structure to replace the RZG2L_CSI2_DEFAULT_WIDTH/HEIGHT macros. Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-06media: uapi: mali-c55-config: Remove version identifierJacopo Mondi
The Mali C55 driver uses the v4l2-isp framework, which defines its own versioning number which does not need to be defined again in each platform-specific header. Remove the definition of mali_c55_param_buffer_version enumeration from the Mali C55 uAPI header. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-06media: mali-c55: Remove duplicated version checkJacopo Mondi
The Mali C55 driver uses the v4l2-isp framework, which performs validation of the parameters buffer versioning in the v4l2_isp_params_validate_buffer() function. It is not necessary to replicate the validation of the parameters buffer versioning in the platform-specific implementation. Remove it. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-06media: Documentation: mali-c55: Use v4l2-isp version identifierJacopo Mondi
The Mali C55 driver uses the v4l2-isp framework, which defines its own versioning numbers. Do not use the Mali C55 specific version identifier in the code example in the documentation of the Mali C55 stats and params metadata formats. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-06drm/fb-helper: Fix vblank timeout during suspend/resetChengjun Yao
During GPU reset, VBlank interrupts are disabled which causes drm_fb_helper_fb_dirty() to wait for VBlank timeout. This will create call traces like (seen on an RX7900 series dGPU): [ 101.313646] ------------[ cut here ]------------ [ 101.313648] amdgpu 0000:03:00.0: [drm] vblank wait timed out on crtc 0 [ 101.313657] WARNING: CPU: 0 PID: 461 at drivers/gpu/drm/drm_vblank.c:1320 drm_wait_one_vblank+0x176/0x220 [ 101.313663] Modules linked in: amdgpu amdxcp drm_panel_backlight_quirks gpu_sched drm_buddy drm_ttm_helper ttm drm_exec drm_suballoc_helper drm_display_helper cec rc_core i2c_algo_bit nf_conntrack_netlink xt_nat xt_tcpudp veth xt_conntrack xt_MASQUERADE bridge stp llc xfrm_user xfrm_algo xt_set ip_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype nft_compat x_tables nf_tables overlay qrtr sunrpc snd_hda_codec_alc882 snd_hda_codec_realtek_lib snd_hda_codec_generic snd_hda_codec_atihdmi snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hda_core snd_intel_dspcfg snd_intel_sdw_acpi snd_hwdep snd_pcm amd_atl intel_rapl_msr snd_seq_midi intel_rapl_common asus_ec_sensors snd_seq_midi_event snd_rawmidi snd_seq eeepc_wmi snd_seq_device edac_mce_amd asus_wmi polyval_clmulni ghash_clmulni_intel snd_timer platform_profile aesni_intel wmi_bmof sparse_keymap joydev snd rapl input_leds i2c_piix4 soundcore ccp k10temp i2c_smbus gpio_amdpt mac_hid binfmt_misc sch_fq_codel msr parport_pc ppdev lp parport [ 101.313745] efi_pstore nfnetlink dmi_sysfs autofs4 hid_generic usbhid hid r8169 realtek ahci libahci video wmi [ 101.313760] CPU: 0 UID: 0 PID: 461 Comm: kworker/0:2 Not tainted 6.18.0-rc6-174403b3b920 #1 PREEMPT(voluntary) [ 101.313763] Hardware name: ASUS System Product Name/TUF GAMING X670E-PLUS, BIOS 0821 11/15/2022 [ 101.313765] Workqueue: events drm_fb_helper_damage_work [ 101.313769] RIP: 0010:drm_wait_one_vblank+0x176/0x220 [ 101.313772] Code: 7c 24 08 4c 8b 77 50 4d 85 f6 0f 84 a1 00 00 00 e8 2f 11 03 00 44 89 e9 4c 89 f2 48 c7 c7 d0 ad 0d a8 48 89 c6 e8 2a e0 4a ff <0f> 0b e9 f2 fe ff ff 48 85 ff 74 04 4c 8b 67 08 4d 8b 6c 24 50 4d [ 101.313774] RSP: 0018:ffffc99c00d47d68 EFLAGS: 00010246 [ 101.313777] RAX: 0000000000000000 RBX: 000000000200038a RCX: 0000000000000000 [ 101.313778] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 101.313779] RBP: ffffc99c00d47dc0 R08: 0000000000000000 R09: 0000000000000000 [ 101.313781] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8948c4280010 [ 101.313782] R13: 0000000000000000 R14: ffff894883263a50 R15: ffff89488c384830 [ 101.313784] FS: 0000000000000000(0000) GS:ffff895424692000(0000) knlGS:0000000000000000 [ 101.313785] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 101.313787] CR2: 00007773650ee200 CR3: 0000000588e40000 CR4: 0000000000f50ef0 [ 101.313788] PKRU: 55555554 [ 101.313790] Call Trace: [ 101.313791] <TASK> [ 101.313795] ? __pfx_autoremove_wake_function+0x10/0x10 [ 101.313800] drm_crtc_wait_one_vblank+0x17/0x30 [ 101.313802] drm_client_modeset_wait_for_vblank+0x61/0x80 [ 101.313805] drm_fb_helper_damage_work+0x46/0x1a0 [ 101.313808] process_one_work+0x1a1/0x3f0 [ 101.313812] worker_thread+0x2ba/0x3d0 [ 101.313816] kthread+0x107/0x220 [ 101.313818] ? __pfx_worker_thread+0x10/0x10 [ 101.313821] ? __pfx_kthread+0x10/0x10 [ 101.313823] ret_from_fork+0x202/0x230 [ 101.313826] ? __pfx_kthread+0x10/0x10 [ 101.313828] ret_from_fork_asm+0x1a/0x30 [ 101.313834] </TASK> [ 101.313835] ---[ end trace 0000000000000000 ]--- Cancel pending damage work synchronously before console_lock() to ensure any in-flight framebuffer damage operations complete before suspension. Also check for FBINFO_STATE_RUNNING in drm_fb_helper_damage_work() to avoid executing damage work if it is rescheduled while the device is suspended. Fixes: d8c4bddcd8bc ("drm/fb-helper: Synchronize dirty worker with vblank") Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Chengjun Yao <Chengjun.Yao@amd.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251215081822.432005-1-Chengjun.Yao@amd.com
2026-01-06PCI/VGA: Don't assume the only VGA device on a system is `boot_vga`Mario Limonciello (AMD)
Some systems ship with multiple display class devices but not all of them are VGA devices. If the "only" VGA device on the system is not used for displaying the image on the screen marking it as `boot_vga` because nothing was found is totally wrong. This behavior actually leads to mistakes of the wrong device being advertised to userspace and then userspace can make incorrect decisions. As there is an accurate `boot_display` sysfs file stop lying about `boot_vga` by assuming if nothing is found it's the right device. Reported-by: Aaron Erhardt <aer@tuxedocomputers.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220712 Tested-by: Aaron Erhardt <aer@tuxedocomputers.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: ad90860bd10ee ("fbcon: Use screen info to find primary device") Tested-by: Luke D. Jones <luke@ljones.dev> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260106044638.52906-1-superm1@kernel.org
2026-01-05mm: drop mem_cgroup_usage() declaration from memcontrol.hRoman Gushchin
mem_cgroup_usage() is not used outside of memcg-v1 code, the declaration was added by a mistake. Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> Link: https://lore.kernel.org/r/20260106042313.140256-1-roman.gushchin@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-06drm/msm/dp: Update msm_dp_controller IDs for sa8775pMani Chandana Ballary Kuntumalla
The Qualcomm SA8775P platform comes with 2 DisplayPort controllers for each mdss. Update controller id for DPTX0 and DPTX1 of mdss1. Fixes: dcb380d19e58 ("drm/msm/dp: Add DisplayPort controller for SA8775P") Signed-off-by: Mani Chandana Ballary Kuntumalla <quic_mkuntuma@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/690234/ Link: https://lore.kernel.org/r/20251125105622.1755651-2-quic_mkuntuma@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-06drm/msm/dp: Enable support for eDP v1.4+ link rates tableDale Whinham
The MSM DRM driver currently does not support panels which report their supported link rates via the SUPPORTED_LINK_RATES table. For panels which do not offer the optional eDP v1.3 fallback via MAX_LINK_RATE, this will cause a panel probe failure (e.g. Samsung ATNA30DW01-1 as found in Microsoft Surface Pro 11). Detect eDP v1.4 panels and parse the SUPPORTED_LINK_RATES table when present. Additionally, set the rate using LINK_RATE_SET instead of LINK_BW_SET, but only if LINK_BW_SET hasn't already been written to. Signed-off-by: Dale Whinham <daleyo@gmail.com> Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com> Tested-by: Steev Klimaszewski <threeway@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695064/ Link: https://lore.kernel.org/r/20251218-drm-msm-edp14-v2-1-2e56c2338ab1@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-06drm/msm/dpu: fix WD timer handling on DPU 8.xDmitry Baryshkov
Since DPU 8.x Watchdog timer settings were moved from the TOP to the INTF block. Support programming the timer in the INTF block. Fixes tag points to the commit which removed register access to those registers on DPU 8.x+ (and which also should have added proper support for WD timer on those devices). Fixes: 43e3293fc614 ("drm/msm/dpu: add support for MDP_TOP blackhole") Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/696586/ Link: https://lore.kernel.org/r/20251230-intf-fix-wd-v6-2-98203d150611@oss.qualcomm.com
2026-01-06drm/msm/dpu: Set vsync source irrespective of mdp top supportTeguh Sobirin
Since DPU 5.x the vsync source TE setup is split between MDP TOP and INTF blocks. Currently all code to setup vsync_source is only executed if MDP TOP implements the setup_vsync_source() callback. However on DPU >= 8.x this callback is not implemented, making DPU driver skip all vsync setup. Move the INTF part out of this condition, letting DPU driver to setup TE vsync selection on all new DPU devices. Signed-off-by: Teguh Sobirin <teguh@sobir.in> Fixes: 2f69e5458447 ("drm/msm/dpu: skip watchdog timer programming through TOP on >= SM8450") [DB: restored top->ops.setup_vsync_source call] Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/696584/ Link: https://lore.kernel.org/r/20251230-intf-fix-wd-v6-1-98203d150611@oss.qualcomm.com
2026-01-06drm/msm/disp/dpu: add merge3d support for sc7280Mahadevan P
On SC7280 targets, display modes with a width greater than the max_mixer_width (2400) are rejected during mode validation when merge3d is disabled. This limitation exists because, without a 3D merge block, two layer mixers cannot be combined(non-DSC interface), preventing large layers from being split across mixers. As a result, higher resolution modes cannot be supported. Enable merge3d support on SC7280 to allow combining streams from two layer mixers into a single non-DSC interface. This capability removes the width restriction and enables buffer sizes beyond the 2400-pixel limit. Fixes: 591e34a091d1 ("drm/msm/disp/dpu1: add support for display for SC7280 target") Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/696713/ Link: https://lore.kernel.org/r/20260101-4k-v2-1-712ae3c1f816@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-06dt-bindings: display: msm: document DSI controller and phy on QCS8300Ayushi Makhija
Document DSI controller and phy on QCS8300 platform. Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/696787/ Link: https://lore.kernel.org/r/20260104134442.732876-4-quic_amakhija@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-06dt-bindings: msm: dsi-controller-main: document the QCS8300 DSI CTRLAyushi Makhija
QCS8300 MDSS DSI controller reuses the same IP as SA8775P, with identical register layout and programming model. Introduce a QCS8300-specific compatible with a fallback to `qcom,sa8775p-dsi-ctrl` to reflect this hardware reuse. Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/696784/ Link: https://lore.kernel.org/r/20260104134442.732876-3-quic_amakhija@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-06dt-bindings: display: msm-dsi-phy-7nm: document the QCS8300 DSI PHYAyushi Makhija
QCS8300 uses the same 5nm MDSS DSI PHY IP as SA8775P, sharing an identical register layout and programming model. Introduce a QCS8300-specific compatible with a fallback to `qcom,sa8775p-dsi-phy-5nm` to reflect this hardware reuse. Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/696783/ Link: https://lore.kernel.org/r/20260104134442.732876-2-quic_amakhija@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-05cxl/region: fix format string for resource_size_tArnd Bergmann
The size of this type is architecture specific, and the recommended way to print it portably is through the custom %pap format string. Fixes: d6602e25819d ("cxl/region: Add support to indicate region has extended linear cache") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com>> --- Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20251204095237.1032528-1-arnd@kernel.org Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-01-05x86/kaslr: Recognize all ZONE_DEVICE users as physaddr consumersDan Williams
Commit 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems") is too narrow. The effect being mitigated in that commit is caused by ZONE_DEVICE which PCI_P2PDMA has a dependency. ZONE_DEVICE, in general, lets any physical address be added to the direct-map. I.e. not only ACPI hotplug ranges, CXL Memory Windows, or EFI Specific Purpose Memory, but also any PCI MMIO range for the DEVICE_PRIVATE and PCI_P2PDMA cases. Update the mitigation, limit KASLR entropy, to apply in all ZONE_DEVICE=y cases. Distro kernels typically have PCI_P2PDMA=y, so the practical exposure of this problem is limited to the PCI_P2PDMA=n case. A potential path to recover entropy would be to walk ACPI and determine the limits for hotplug and PCI MMIO before kernel_randomize_memory(). On smaller systems that could yield some KASLR address bits. This needs additional investigation to determine if some limited ACPI table scanning can happen this early without an open coded solution like arch/x86/boot/compressed/acpi.c needs to deploy. Cc: Ingo Molnar <mingo@kernel.org> Cc: Kees Cook <kees@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Logan Gunthorpe <logang@deltatee.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: David Hildenbrand <david@redhat.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Michal Hocko <mhocko@suse.com> Fixes: 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems") Cc: <stable@vger.kernel.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Balbir Singh <balbirs@nvidia.com> Tested-by: Yasunori Goto <y-goto@fujitsu.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: http://patch.msgid.link/692e08b2516d4_261c1100a3@dwillia2-mobl4.notmuch Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-01-05net: fix memory leak in skb_segment_list for GRO packetsMohammad Heib
When skb_segment_list() is called during packet forwarding, it handles packets that were aggregated by the GRO engine. Historically, the segmentation logic in skb_segment_list assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments. Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), this truesize subtraction in skb_segment_list() was valid because fragments still carry a reference to the original socket. However, commit ed4cccef64c1 ("gro: fix ownership transfer") changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb->sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skb_segment_list() was never updated. As a result, the current code unconditionally adds each fragment's truesize to delta_truesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes sk_wmem_alloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak. The leak can be observed via KMEMLEAK when tearing down the networking environment: unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmem_cache_alloc_noprof+0x5c6/0x800 sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0 Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLIST packets constructed by GRO, the truesize adjustment is removed. The call to skb_release_head_state() must be preserved. As documented in commit cf673ed0e057 ("net: fix fraglist segmentation reference count leak"), it is still required to correctly drop references to SKB extensions that may be overwritten during __copy_skb_header(). Fixes: ed4cccef64c1 ("gro: fix ownership transfer") Signed-off-by: Mohammad Heib <mheib@redhat.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260104213101.352887-1-mheib@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05riscv: kexec_image: Fix dead link to boot-image-header.rstSoham Metha
Fix the reference to 'boot-image-header.rst', which was moved to 'Documentation/arch/riscv/' in commit 'ed843ae947f8' ("docs: move riscv under arch"). Signed-off-by: Soham Metha <sohammetha01@gmail.com> Link: https://patch.msgid.link/20251203194355.63265-1-sohammetha01@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-05netlink: specs: netdev: clarify the page pool API a littleJakub Kicinski
The phrasing of the page-pool-get doc is very confusing. It's supposed to highlight that support depends on the driver doing its part but it sounds like orphaned page pools won't be visible. The description of the ifindex is completely wrong. We move the page pool to loopback and skip the attribute if ifindex is loopback. Link: https://lore.kernel.org/20260104084347.5de3a537@kernel.org Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> Link: https://patch.msgid.link/20260104165232.710460-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05riscv: pgtable: Cleanup useless VA_USER_XXX definitionsGuo Ren (Alibaba DAMO Academy)
These marcos are not used after commit b5b4287accd7 ("riscv: mm: Use hint address in mmap if available"). Cleanup VA_USER_XXX definitions in asm/pgtable.h. Fixes: b5b4287accd7 ("riscv: mm: Use hint address in mmap if available") Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20251201005850.702569-1-guoren@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-05riscv: cpufeature: Fix Zk bundled extension missing ZknhGuodong Xu
The Zk extension is a bundle consisting of Zkn, Zkr, and Zkt. The Zkn extension itself is a bundle consisting of Zbkb, Zbkc, Zbkx, Zknd, Zkne, and Zknh. The current implementation of riscv_zk_bundled_exts manually listed the dependencies but missed RISCV_ISA_EXT_ZKNH. Fix this by introducing a RISCV_ISA_EXT_ZKN macro that lists the Zkn components and using it in both riscv_zk_bundled_exts and riscv_zkn_bundled_exts. This adds the missing Zknh extension to Zk and reduces code duplication. Fixes: 0d8295ed975b ("riscv: add ISA extension parsing for scalar crypto") Link: https://patch.msgid.link/20231114141256.126749-4-cleger@rivosinc.com/ Signed-off-by: Guodong Xu <guodong@riscstar.com> Reviewed-by: Clément Léger <cleger@rivosinc.com> Link: https://patch.msgid.link/20251223-zk-missing-zknh-v1-1-b627c990ee1a@riscstar.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-05Merge branch 'rust-net-replace-kernel-c_str-with-c-strings'Jakub Kicinski
Tamir Duberstein says: ==================== rust: net: replace `kernel::c_str!` with C-Strings C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. ==================== Link: https://patch.msgid.link/20260103-cstr-net-v2-0-8688f504b85d@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05drivers: net: replace `kernel::c_str!` with C-StringsTamir Duberstein
C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Link: https://patch.msgid.link/20260103-cstr-net-v2-2-8688f504b85d@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05rust: net: replace `kernel::c_str!` with C-StringsTamir Duberstein
C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Link: https://patch.msgid.link/20260103-cstr-net-v2-1-8688f504b85d@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05net: airoha: Fix npu rx DMA definitionsLorenzo Bianconi
Fix typos in npu rx DMA descriptor definitions. Fixes: b3ef7bdec66fb ("net: airoha: Add airoha_offload.h header") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260102-airoha-npu-dma-rx-def-fixes-v1-1-205fc6bf7d94@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05selftests: mptcp: Mark xerror and die_perror __noreturnAnkit Khushwaha
Compiler reports potential uses of uninitialized variables in mptcp_connect.c when xerror() is called from failure paths. mptcp_connect.c:1262:11: warning: variable 'raw_addr' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] xerror() terminates execution by calling exit(), but it is not visible to the compiler & assumes control flow may continue past the call. Annotate xerror() with __noreturn so the compiler can correctly reason about control flow and avoid false-positive uninitialized variable warnings. Signed-off-by: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com> Link: https://patch.msgid.link/20260101172840.90186-1-ankitkhushwaha.linux@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05Merge branch 'net-sched-fix-memory-leak-on-mirred-loop'Jakub Kicinski
Jamal Hadi Salim says: ==================== net/sched: Fix memory leak on mirred loop Initialize at_ingress earlier before the if statement. ==================== Link: https://patch.msgid.link/20260101135608.253079-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05selftests/tc-testing: Add test case redirecting to self on egressVictor Nogueira
Add single mirred test case that attempts to redirect to self on egress using clsact Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260101135608.253079-3-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05net/sched: act_mirred: Fix leak when redirecting to self on egressJamal Hadi Salim
Whenever a mirred redirect to self on egress happens, mirred allocates a new skb (skb_to_send). The loop to self check was done after that allocation, but was not freeing the newly allocated skb, causing a leak. Fix this by moving the if-statement to before the allocation of the new skb. The issue was found by running the accompanying tdc test in 2/2 with config kmemleak enabled. After a few minutes the kmemleak thread ran and reported the leak coming from mirred. Fixes: 1d856251a009 ("net/sched: act_mirred: fix loop detection") Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260101135608.253079-2-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-06btrfs: show correct warning if can't read data reloc treeMark Harmstone
If a filesystem is missing its data reloc tree, we get something like this in dmesg: BTRFS warning (device loop11): failed to read root (objectid=4): -2 BTRFS error (device loop11): open_ctree failed: -2 objectid is BTRFS_DEV_TREE_OBJECTID, but this should actually be the value of BTRFS_DATA_RELOC_TREE_OBJECTID. btrfs_read_roots() prints location.objectid on failure, but this isn't set when reading the data reloc tree. Set location.objectid to the correct value on failure, so that the error message makes sense. Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Mark Harmstone <mark@harmstone.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-01-06btrfs: fix NULL pointer dereference in do_abort_log_replay()Suchit Karunakaran
Coverity reported a NULL pointer dereference issue (CID 1666756) in do_abort_log_replay(). When btrfs_alloc_path() fails in replay_one_buffer(), wc->subvol_path is NULL, but btrfs_abort_log_replay() calls do_abort_log_replay() which unconditionally dereferences wc->subvol_path when attempting to print debug information. Fix this by adding a NULL check before dereferencing wc->subvol_path in do_abort_log_replay(). Fixes: 2753e4917624 ("btrfs: dump detailed info and specific messages on log replay failures") Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Suchit Karunakaran <suchitkarunakaran@gmail.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-01-06btrfs: force free space tree for bs > ps casesQu Wenruo
[BUG] Currently we only enforcing the free space tree for bs < ps cases, but with the recently added bs > ps support, we lack the free space tree enforcing, causing explicit v1 cache mount option to fail on bs > ps cases: # mount -o space_cache=v1 /dev/test/scratch1 /mnt/btrfs/ mount: /mnt/btrfs: wrong fs type, bad option, bad superblock on /dev/mapper/test-scratch1, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call. # dmesg -t | tail -n7 BTRFS: device fsid ac14a6fa-4ec9-449e-aec9-7d1777bfdc06 devid 1 transid 11 /dev/mapper/test-scratch1 (253:3) scanned by mount (2849) BTRFS info (device dm-3): first mount of filesystem ac14a6fa-4ec9-449e-aec9-7d1777bfdc06 BTRFS info (device dm-3): using crc32c checksum algorithm BTRFS warning (device dm-3): support for block size 8192 with page size 4096 is experimental, some features may be missing BTRFS warning (device dm-3): space cache v1 is being deprecated and will be removed in a future release, please use -o space_cache=v2 BTRFS warning (device dm-3): v1 space cache is not supported for page size 4096 with sectorsize 8192 BTRFS error (device dm-3): open_ctree failed: -22 [FIX] Just enable the same free space tree for bs > ps cases, aligning the behavior to bs < ps cases. Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-01-06btrfs: only enforce free space tree if v1 cache is required for bs < ps casesQu Wenruo
[BUG] Since the introduction of btrfs bs < ps support, v1 cache was never on the plan due to its hard coded PAGE_SIZE usage, and the future plan to properly deprecate it. However for bs < ps cases, even if 'nospace_cache,clear_cache' mount option is specified, it's never respected and free space tree is always enabled: mkfs.btrfs -f -O ^bgt,fst $dev mount $dev $mnt -o clear_cache,nospace_cache umount $mnt btrfs ins dump-super $dev ... compat_ro_flags 0x3 ( FREE_SPACE_TREE | FREE_SPACE_TREE_VALID ) ... This means a different behavior compared to bs >= ps cases. [CAUSE] The forcing usage of v2 space cache is done inside btrfs_set_free_space_cache_settings(), however it never checks if we're even using space cache but always enabling v2 cache. [FIX] Instead unconditionally enable v2 cache, only forcing v2 cache if the old v1 cache is required. Now v2 space cache can be properly disabled on bs < ps cases: mkfs.btrfs -f -O ^bgt,fst $dev mount $dev $mnt -o clear_cache,nospace_cache umount $mnt btrfs ins dump-super $dev ... compat_ro_flags 0x0 ... Fixes: 9f73f1aef98b ("btrfs: force v2 space cache usage for subpage mount") Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-01-06btrfs: release path before initializing extent tree in btrfs_read_locked_inode()Filipe Manana
In btrfs_read_locked_inode() we are calling btrfs_init_file_extent_tree() while holding a path with a read locked leaf from a subvolume tree, and btrfs_init_file_extent_tree() may do a GFP_KERNEL allocation, which can trigger reclaim. This can create a circular lock dependency which lockdep warns about with the following splat: [6.1433] ====================================================== [6.1574] WARNING: possible circular locking dependency detected [6.1583] 6.18.0+ #4 Tainted: G U [6.1591] ------------------------------------------------------ [6.1599] kswapd0/117 is trying to acquire lock: [6.1606] ffff8d9b6333c5b8 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x39/0x2f0 [6.1625] but task is already holding lock: [6.1633] ffffffffa4ab8ce0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x195/0xc60 [6.1646] which lock already depends on the new lock. [6.1657] the existing dependency chain (in reverse order) is: [6.1667] -> #2 (fs_reclaim){+.+.}-{0:0}: [6.1677] fs_reclaim_acquire+0x9d/0xd0 [6.1685] __kmalloc_cache_noprof+0x59/0x750 [6.1694] btrfs_init_file_extent_tree+0x90/0x100 [6.1702] btrfs_read_locked_inode+0xc3/0x6b0 [6.1710] btrfs_iget+0xbb/0xf0 [6.1716] btrfs_lookup_dentry+0x3c5/0x8e0 [6.1724] btrfs_lookup+0x12/0x30 [6.1731] lookup_open.isra.0+0x1aa/0x6a0 [6.1739] path_openat+0x5f7/0xc60 [6.1746] do_filp_open+0xd6/0x180 [6.1753] do_sys_openat2+0x8b/0xe0 [6.1760] __x64_sys_openat+0x54/0xa0 [6.1768] do_syscall_64+0x97/0x3e0 [6.1776] entry_SYSCALL_64_after_hwframe+0x76/0x7e [6.1784] -> #1 (btrfs-tree-00){++++}-{3:3}: [6.1794] lock_release+0x127/0x2a0 [6.1801] up_read+0x1b/0x30 [6.1808] btrfs_search_slot+0x8e0/0xff0 [6.1817] btrfs_lookup_inode+0x52/0xd0 [6.1825] __btrfs_update_delayed_inode+0x73/0x520 [6.1833] btrfs_commit_inode_delayed_inode+0x11a/0x120 [6.1842] btrfs_log_inode+0x608/0x1aa0 [6.1849] btrfs_log_inode_parent+0x249/0xf80 [6.1857] btrfs_log_dentry_safe+0x3e/0x60 [6.1865] btrfs_sync_file+0x431/0x690 [6.1872] do_fsync+0x39/0x80 [6.1879] __x64_sys_fsync+0x13/0x20 [6.1887] do_syscall_64+0x97/0x3e0 [6.1894] entry_SYSCALL_64_after_hwframe+0x76/0x7e [6.1903] -> #0 (&delayed_node->mutex){+.+.}-{3:3}: [6.1913] __lock_acquire+0x15e9/0x2820 [6.1920] lock_acquire+0xc9/0x2d0 [6.1927] __mutex_lock+0xcc/0x10a0 [6.1934] __btrfs_release_delayed_node.part.0+0x39/0x2f0 [6.1944] btrfs_evict_inode+0x20b/0x4b0 [6.1952] evict+0x15a/0x2f0 [6.1958] prune_icache_sb+0x91/0xd0 [6.1966] super_cache_scan+0x150/0x1d0 [6.1974] do_shrink_slab+0x155/0x6f0 [6.1981] shrink_slab+0x48e/0x890 [6.1988] shrink_one+0x11a/0x1f0 [6.1995] shrink_node+0xbfd/0x1320 [6.1002] balance_pgdat+0x67f/0xc60 [6.1321] kswapd+0x1dc/0x3e0 [6.1643] kthread+0xff/0x240 [6.1965] ret_from_fork+0x223/0x280 [6.1287] ret_from_fork_asm+0x1a/0x30 [6.1616] other info that might help us debug this: [6.1561] Chain exists of: &delayed_node->mutex --> btrfs-tree-00 --> fs_reclaim [6.1503] Possible unsafe locking scenario: [6.1110] CPU0 CPU1 [6.1411] ---- ---- [6.1707] lock(fs_reclaim); [6.1998] lock(btrfs-tree-00); [6.1291] lock(fs_reclaim); [6.1581] lock(&delayed_node->mutex); [6.1874] *** DEADLOCK *** [6.1716] 2 locks held by kswapd0/117: [6.1999] #0: ffffffffa4ab8ce0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x195/0xc60 [6.1294] #1: ffff8d998344b0e0 (&type->s_umount_key#40){++++}- {3:3}, at: super_cache_scan+0x37/0x1d0 [6.1596] stack backtrace: [6.1183] CPU: 11 UID: 0 PID: 117 Comm: kswapd0 Tainted: G U 6.18.0+ #4 PREEMPT(lazy) [6.1185] Tainted: [U]=USER [6.1186] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023 [6.1187] Call Trace: [6.1187] <TASK> [6.1189] dump_stack_lvl+0x6e/0xa0 [6.1192] print_circular_bug.cold+0x17a/0x1c0 [6.1194] check_noncircular+0x175/0x190 [6.1197] __lock_acquire+0x15e9/0x2820 [6.1200] lock_acquire+0xc9/0x2d0 [6.1201] ? __btrfs_release_delayed_node.part.0+0x39/0x2f0 [6.1204] __mutex_lock+0xcc/0x10a0 [6.1206] ? __btrfs_release_delayed_node.part.0+0x39/0x2f0 [6.1208] ? __btrfs_release_delayed_node.part.0+0x39/0x2f0 [6.1211] ? __btrfs_release_delayed_node.part.0+0x39/0x2f0 [6.1213] __btrfs_release_delayed_node.part.0+0x39/0x2f0 [6.1215] btrfs_evict_inode+0x20b/0x4b0 [6.1217] ? lock_acquire+0xc9/0x2d0 [6.1220] evict+0x15a/0x2f0 [6.1222] prune_icache_sb+0x91/0xd0 [6.1224] super_cache_scan+0x150/0x1d0 [6.1226] do_shrink_slab+0x155/0x6f0 [6.1228] shrink_slab+0x48e/0x890 [6.1229] ? shrink_slab+0x2d2/0x890 [6.1231] shrink_one+0x11a/0x1f0 [6.1234] shrink_node+0xbfd/0x1320 [6.1236] ? shrink_node+0xa2d/0x1320 [6.1236] ? shrink_node+0xbd3/0x1320 [6.1239] ? balance_pgdat+0x67f/0xc60 [6.1239] balance_pgdat+0x67f/0xc60 [6.1241] ? finish_task_switch.isra.0+0xc4/0x2a0 [6.1246] kswapd+0x1dc/0x3e0 [6.1247] ? __pfx_autoremove_wake_function+0x10/0x10 [6.1249] ? __pfx_kswapd+0x10/0x10 [6.1250] kthread+0xff/0x240 [6.1251] ? __pfx_kthread+0x10/0x10 [6.1253] ret_from_fork+0x223/0x280 [6.1255] ? __pfx_kthread+0x10/0x10 [6.1257] ret_from_fork_asm+0x1a/0x30 [6.1260] </TASK> This is because: 1) The fsync task is holding an inode's delayed node mutex (for a directory) while calling __btrfs_update_delayed_inode() and that needs to do a search on the subvolume's btree (therefore read lock some extent buffers); 2) The lookup task, at btrfs_lookup(), triggered reclaim with the GFP_KERNEL allocation done by btrfs_init_file_extent_tree() while holding a read lock on a subvolume leaf; 3) The reclaim triggered kswapd which is doing inode eviction for the directory inode the fsync task is using as an argument to btrfs_commit_inode_delayed_inode() - but in that call chain we are trying to read lock the same leaf that the lookup task is holding while calling btrfs_init_file_extent_tree() and doing the GFP_KERNEL allocation. Fix this by calling btrfs_init_file_extent_tree() after we don't need the path anymore and release it in btrfs_read_locked_inode(). Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/linux-btrfs/6e55113a22347c3925458a5d840a18401a38b276.camel@linux.intel.com/ Fixes: 8679d2687c35 ("btrfs: initialize inode::file_extent_tree after i_mode has been set") Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-01-06btrfs: avoid access-beyond-folio for bs > ps encoded writesQu Wenruo
[POTENTIAL BUG] If the system page size is 4K and fs block size is 8K, and max_inline mount option is set to 6K, we can inline a 6K sized data extent. Then a encoded write submitted a compressed extent which is at file offset 0, and the compressed length is 6K, which is allowed to be inlined. Now a read beyond page boundary is triggered inside write_extent_buffer() from insert_inline_extent(). [CAUSE] Currently the function __cow_file_range_inline() can only accept a single folio. For regular compressed write path, we always allocate the compressed folios using the minimal order matching the block size, thus the @compressed_folio should always cover a full fs block thus it is fine. But for encoded writes, they allocate page size folios, this means we can hit a case where the compressed data is smaller than block size but still larger than page size, in that case __cow_file_range_inline() will be called with @compressed_size larger than a page. In that case we will trigger a read beyond the folio inside insert_inline_extent(). Thankfully this is not that common, as the default max_inline is only 2048 bytes, smaller than PAGE_SIZE, and bs > ps support is still experimental. [FIX] We need to either allow insert_inline_extent() to accept a page array to properly support such case, or reject such inline extent. The latter is a much simpler solution, and considering bs > ps will stay as a corner case and non-default max_inline will be even rarer, I don't think we really need to fulfill such niche. So just reject any inline extent that's larger than PAGE_SIZE, and add an extra ASSERT() to insert_inline_extent() to catch such beyond-boundary access. Fixes: ec20799064c8 ("btrfs: enable encoded read/write/send for bs > ps cases") Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-01-05net: marvell: prestera: correct return type of prestera_ldr_wait_buf()Alok Tiwari
prestera_ldr_wait_buf() returns the result of readl_poll_timeout(), which is 0 on success or -ETIMEDOUT on failure. Its current return type is u32. Assigning this u32 value to an int variable works today because the bit pattern of (u32)-ETIMEDOUT (0xffffff92) is correctly interpreted as -ETIMEDOUT when stored in an int. However, keeping the function return type as u32 is misleading and fragile. Change the return type to int to reflect the actual semantic of returning negative error codes and to avoid potential issues with unsigned casts. There is no functional change. Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260103174313.1172197-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05net: phy: mediatek: enable interrupts on AN7581Aleksander Jan Bajkowski
Interrupts work just like on MT7988. Suggested-by: Benjamin Larsson <benjamin.larsson@genexis.eu> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260102113222.3519900-1-olek2@wp.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05ipv4: Improve martian logsClara Engler
At the current moment, the logs for martian packets are as follows: ``` martian source {DST} from {SRC}, on dev {DEV} martian destination {DST} from {SRC}, dev {DEV} ``` These messages feel rather hard to understand in production, especially the "martian source" one, mostly because it is grammatically ambitious to parse which part is now the source address and which part is the destination address. For example, "{DST}" may there be interpreted as the actual source address due to following the word "source", thereby implying the actual source address to be the destination one. Personally, I discovered this bug while toying around with TUN interfaces and using them as a tunnel (receiving packets via a TUN interface and sending them over a TCP stream; receiving packets from a TCP stream and writing them to a TUN).[^1] When these IP addresses contained local IPs (i.e. 10.0.0.0/8 in source and destination), everything worked fine. However, sending them to a real routable IP address on the internet led to them being treated as a martian packet, obviously. Using a few sysctl(8) and iptables(8) settings[^2] fixed it, but while debugging I found the log message starting with "martian source" rather confusing, as I was unsure on whether the packet that gets dropped was the packet originating from me or the response from the endpoint, as "martian source <ROUTABLE IP>" could also be falsely interpreted as the response packet being martian, due to the word "source" followed by the routable IP address, implying the source address of that packet is set to this IP, as explained above. In the end, I had to look into the source code of the kernel on where this error message gets generated, which is usually an indicator of there being room for improvement with regard to this error message. In terms of improvement, this commit changes the error messages for martian source and martian destination packets as follows: ``` martian source (src={SRC}, dst={DST}, dev={DEV}) martian destination (src={SRC}, dst={DST}, dev={DEV}) ``` These new wordings leave pretty much no room for ambiguity as all parameters are prefixed with a respective key explaining their semantic meaning. See also the following thread on LKML.[^3] [^1]: <https://backreference.org/2010/03/26/tuntap-interface-tutorial> [^2]: sysctl net.ipv4.ip_forward=1 && \ iptables -A INPUT -i tun0 -j ACCEPT && \ iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE [^3]: <https://lore.kernel.org/all/aSd4Xj8rHrh-krjy@4944566b5c925f79/> Signed-off-by: Clara Engler <cve@cve.cx> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260101125114.2608-1-cve@cve.cx Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05Merge branch 'vsock-fix-so_zerocopy-on-accept-ed-vsocks'Jakub Kicinski
Michal Luczaj says: ==================== vsock: Fix SO_ZEROCOPY on accept()ed vsocks vsock has its own handling of setsockopt(SO_ZEROCOPY). Which works just fine unless socket comes from a call to accept(). Because SOCK_CUSTOM_SOCKOPT flag is missing, attempting to set the option always results in errno EOPNOTSUPP. ==================== Link: https://patch.msgid.link/20251229-vsock-child-sock-custom-sockopt-v2-0-64778d6c4f88@rbox.co Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05vsock/test: Test setting SO_ZEROCOPY on accept()ed socketMichal Luczaj
Make sure setsockopt(SOL_SOCKET, SO_ZEROCOPY) on an accept()ed socket is handled by vsock's implementation. Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Michal Luczaj <mhal@rbox.co> Link: https://patch.msgid.link/20251229-vsock-child-sock-custom-sockopt-v2-2-64778d6c4f88@rbox.co Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05vsock: Make accept()ed sockets use custom setsockopt()Michal Luczaj
SO_ZEROCOPY handling in vsock_connectible_setsockopt() does not get called on accept()ed sockets due to a missing flag. Flip it. Fixes: e0718bd82e27 ("vsock: enable setting SO_ZEROCOPY") Signed-off-by: Michal Luczaj <mhal@rbox.co> Link: https://patch.msgid.link/20251229-vsock-child-sock-custom-sockopt-v2-1-64778d6c4f88@rbox.co Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05io_uring: Trim out unused includesGabriel Krisman Bertazi
Clean up some left overs of refactoring io_uring into multiple files. Compile tested with a few configurations. Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
generated by cgit v1.2.3 (git 2.25.1) at 2026-10-02 16:46:46 +0000