February 2025 - Linux-stable-mirror

[PATCH 0/4] media: nuvoton: Fix some reference handling issues

by Ricardo Ribalda

When trying out 6.13 cocci, some bugs were found. The fixes without using cleanup.h should be backported. The last two patches make use of cleanup.h to avoid this kind of errors in the future. Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Ricardo Ribalda (4): media: nuvoton: Fix reference handling of ece_pdev media: nuvoton: Fix reference handling of ece_node media: nuvoton: Use cleanup.h macros for device_node media: nuvoton: Use cleanup.h macros for put_device drivers/media/platform/nuvoton/npcm-video.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- base-commit: c4b7779abc6633677e6edb79e2809f4f61fde157 change-id: 20250121-nuvoton-fe870cbeffb6 Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

3 months, 2 weeks

4
8
0 0

Re: REGRESSION amdgpu 20241108 firmware breaks screen updating

by mail＠tteles.dev

I can confirm amdgpu.dcdebugmask=0x200 fixes it, no more stutters. It would be very beneficial to include the patch making this behavior default (https://lore.kernel.org/amd-gfx/20250221160145.1730752-3-zaeem.mohamed@amd.…) in the relevant linux-stable trees, as this is a major issue for affected systems. I CC'd stable(a)vger.kernel.org and ask for the patch to be included in linux-stable, even though it does not have a "Fixes:" tag, if the maintainers are okay with it. Thank you for the quick response! Tiago Feb 23, 2025, 17:26 by mario.limonciello(a)amd.com: > Hello, > > This sounds like to me a problem with PSR-SU. There have been a variety of these being reported the past few months. Enough so that the policy to enable it by default is being rolled back for now. > > https://lore.kernel.org/amd-gfx/20250221160145.1730752-3-zaeem.mohamed@amd.… > > To confirm that's the root cause you can disable it with amdgpu.dcdebugmask=0x200. > > Thanks, > > On 2/23/2025 10:08, mail(a)tteles.dev wrote: > >> Greetings, >> >> I wish to report a regression in amdgpu firmware introduced in commit c99eeb4d0e13f5831ae77f7ec521162594385d5f, the problem persists until git HEAD, and reverting to the previous commit fixes the issues with no further changes to the environment. >> >> The issue appears on a Lenovo IdeaPad Pro 5, with a Ryzen 8845HS processor, using the 780M iGPU (1002:1900 I believe). The screen on this laptop is 120Hz 2800x1800, supporting HDR. >> This was tested on Archlinux 6.13.3.arch1-1, with amdgpu drivers, on both Wayland (Gnome and Hyprland) and Xorg (i3wm). I'm using amd-pstate-epp scaling driver, tested with both performance and powersave governers, to the same effect. >> >> I will list the symptoms and attempt to guess at what the issue may be. >> >> - The screen stops updating if no mouse input is given while watching low resolution video (wherever it is, Brave and mpv, regardless of software or hw decoding). >> Low resolution matters here, I can play 4k video fine, 1080p with mild stutters, but lower becomes very bad. >> Here is an example using mpv with 360p sample video, recorded on my phone as to not disturb the environment its running in. (https://youtu.be/kYHqBjPxM2s You can tell it is very choppy, the original video https://www.youtube.com/watch?v=1HrXwe6s4W8 is not choppy) >> mpv did not report any dropped frames despite there obviously being a huge amount. >> >> - In some programs, text does not get displayed instantly from when typing it, having to type 5 or 6 characters for the previous to finally show. >> All these new characters show up at the same time. This was extremely noticeable with gnome's default "Console", it also happened in Brave Browser's search bar, and Signal, it does not seem to happen with Ghostty. >> >> Constantly waving my cursor fixes all these issues. Connecting a secondary display seems to fix the issue on all displays. >> >> From my limited knowledge this seems like a bug in damage detection for eDP + power management, where low enough power levels don't trigger redraws. >> >> I am confident the issue was introduced in that commit since I bisected linux-firmware commits affecting amdgpu until the issue was no longer found. >> >> >> Extra info: >> # dmesg | grep amd >> [ 0.414396] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 counters/bank). >> [ 1.875492] [drm] amdgpu kernel modesetting enabled. >> [ 1.878563] amdgpu: Virtual CRAT table created for CPU >> [ 1.878573] amdgpu: Topology: Add CPU node >> [ 1.882607] amdgpu 0000:63:00.0: amdgpu: Fetched VBIOS from VFCT >> [ 1.882610] amdgpu: ATOM BIOS: 113-PHXGENERIC-001 >> [ 1.909536] amdgpu 0000:63:00.0: vgaarb: deactivate vga console >> [ 1.909542] amdgpu 0000:63:00.0: amdgpu: Trusted Memory Zone (TMZ) feature enabled >> [ 1.909612] amdgpu 0000:63:00.0: amdgpu: VRAM: 4096M 0x0000008000000000 - 0x00000080FFFFFFFF (4096M used) >> [ 1.909614] amdgpu 0000:63:00.0: amdgpu: GART: 512M 0x00007FFF00000000 - 0x00007FFF1FFFFFFF >> [ 1.909829] [drm] amdgpu: 4096M of VRAM memory ready >> [ 1.909832] [drm] amdgpu: 13932M of GTT memory ready. >> [ 1.935030] amdgpu 0000:63:00.0: amdgpu: reserve 0x4000000 from 0x80f8000000 for PSP TMR >> [ 2.482626] amdgpu 0000:63:00.0: amdgpu: RAS: optional ras ta ucode is not available >> [ 2.491068] amdgpu 0000:63:00.0: amdgpu: RAP: optional rap ta ucode is not available >> [ 2.491071] amdgpu 0000:63:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available >> [ 2.521960] amdgpu 0000:63:00.0: amdgpu: SMU is initialized successfully! >> [ 2.601611] kfd kfd: amdgpu: Allocated 3969056 bytes on gart >> [ 2.601628] kfd kfd: amdgpu: Total number of KFD nodes to be created: 1 >> [ 2.602048] amdgpu: Virtual CRAT table created for GPU >> [ 2.602191] amdgpu: Topology: Add dGPU node [0x1900:0x1002] >> [ 2.602193] kfd kfd: amdgpu: added device 1002:1900 >> [ 2.602206] amdgpu 0000:63:00.0: amdgpu: SE 1, SH per SE 2, CU per SH 6, active_cu_number 12 >> [ 2.602212] amdgpu 0000:63:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0 >> [ 2.602215] amdgpu 0000:63:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 >> [ 2.602216] amdgpu 0000:63:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 >> [ 2.602217] amdgpu 0000:63:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0 >> [ 2.602219] amdgpu 0000:63:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0 >> [ 2.602220] amdgpu 0000:63:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0 >> [ 2.602221] amdgpu 0000:63:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0 >> [ 2.602222] amdgpu 0000:63:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0 >> [ 2.602223] amdgpu 0000:63:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0 >> [ 2.602224] amdgpu 0000:63:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0 >> [ 2.602225] amdgpu 0000:63:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8 >> [ 2.602226] amdgpu 0000:63:00.0: amdgpu: ring jpeg_dec uses VM inv eng 1 on hub 8 >> [ 2.602227] amdgpu 0000:63:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 13 on hub 0 >> [ 2.609481] amdgpu 0000:63:00.0: amdgpu: Runtime PM not available >> [ 2.610787] [drm] Initialized amdgpu 3.60.0 for 0000:63:00.0 on minor 1 >> [ 2.617618] fbcon: amdgpudrmfb (fb0) is primary device >> [ 3.788332] amdgpu 0000:63:00.0: [drm] fb0: amdgpudrmfb frame buffer device >> [ 5.120419] kvm_amd: TSC scaling supported >> [ 5.120426] kvm_amd: Nested Virtualization enabled >> [ 5.120428] kvm_amd: Nested Paging enabled >> [ 5.120430] kvm_amd: LBR virtualization supported >> [ 5.120443] kvm_amd: Virtual GIF supported >> [ 5.120444] kvm_amd: Virtual NMI enabled >> [ 5.170720] snd_hda_intel 0000:63:00.1: bound 0000:63:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu]) >> [ 5.191443] amd_atl: AMD Address Translation Library initialized >> >> >> Thank you for your time, >> Tiago Teles >>

3 months, 2 weeks

2
1
0 0

[PATCH v2 net 0/9] net: enetc: fix some known issues

by Wei Fang

There are some issues with the enetc driver, some of which are specific to the LS1028A platform, and some of which were introduced recently when i.MX95 ENETC support was added, so this patch set aims to clean up those issues. --- v1 link: https://lore.kernel.org/imx/20250217093906.506214-1-wei.fang@nxp.com/ v2 changes: 1. Remove the unneeded semicolon from patch 1 2. Modify the commit message of patch 1 3. Add new patch 9 to fix another off-by-one issue --- Wei Fang (9): net: enetc: fix the off-by-one issue in enetc_map_tx_buffs() net: enetc: correct the tx_swbd statistics net: enetc: correct the xdp_tx statistics net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNC net: enetc: update UDP checksum when updating originTimestamp field net: enetc: add missing enetc4_link_deinit() net: enetc: remove the mm_lock from the ENETC v4 driver net: enetc: correct the EMDIO base offset for ENETC v4 net: enetc: fix the off-by-one issue in enetc_map_tx_tso_buffs() drivers/net/ethernet/freescale/enetc/enetc.c | 59 ++++++++++++++----- .../net/ethernet/freescale/enetc/enetc4_hw.h | 3 + .../net/ethernet/freescale/enetc/enetc4_pf.c | 2 +- .../ethernet/freescale/enetc/enetc_ethtool.c | 7 ++- .../freescale/enetc/enetc_pf_common.c | 10 +++- 5 files changed, 63 insertions(+), 18 deletions(-) -- 2.34.1

3 months, 2 weeks

6
38
0 0

[PATCH v2] usb: gadget: Set self-powered based on MaxPower and bmAttributes

by Prashanth K

Currently the USB gadget will be set as bus-powered based solely on whether its bMaxPower is greater than 100mA, but this may miss devices that may legitimately draw less than 100mA but still want to report as bus-powered. Similarly during suspend & resume, USB gadget is incorrectly marked as bus/self powered without checking the bmAttributes field. Fix these by configuring the USB gadget as self or bus powered based on bmAttributes, and explicitly set it as bus-powered if it draws more than 100mA. Cc: stable(a)vger.kernel.org Fixes: 5e5caf4fa8d3 ("usb: gadget: composite: Inform controller driver of self-powered") Signed-off-by: Prashanth K <prashanth.k(a)oss.qualcomm.com> --- Changes in v2: - Didn't change anything from RFC. - Link to RFC: https://lore.kernel.org/all/20250204105908.2255686-1-prashanth.k@oss.qualco… drivers/usb/gadget/composite.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index bdda8c74602d..1fb28bbf6c45 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -1050,10 +1050,11 @@ static int set_config(struct usb_composite_dev *cdev, else usb_gadget_set_remote_wakeup(gadget, 0); done: - if (power <= USB_SELF_POWER_VBUS_MAX_DRAW) - usb_gadget_set_selfpowered(gadget); - else + if (power > USB_SELF_POWER_VBUS_MAX_DRAW || + !(c->bmAttributes & USB_CONFIG_ATT_SELFPOWER)) usb_gadget_clear_selfpowered(gadget); + else + usb_gadget_set_selfpowered(gadget); usb_gadget_vbus_draw(gadget, power); if (result >= 0 && cdev->delayed_status) @@ -2615,7 +2616,9 @@ void composite_suspend(struct usb_gadget *gadget) cdev->suspended = 1; - usb_gadget_set_selfpowered(gadget); + if (cdev->config->bmAttributes & USB_CONFIG_ATT_SELFPOWER) + usb_gadget_set_selfpowered(gadget); + usb_gadget_vbus_draw(gadget, 2); } @@ -2649,8 +2652,11 @@ void composite_resume(struct usb_gadget *gadget) else maxpower = min(maxpower, 900U); - if (maxpower > USB_SELF_POWER_VBUS_MAX_DRAW) + if (maxpower > USB_SELF_POWER_VBUS_MAX_DRAW || + !(cdev->config->bmAttributes & USB_CONFIG_ATT_SELFPOWER)) usb_gadget_clear_selfpowered(gadget); + else + usb_gadget_set_selfpowered(gadget); usb_gadget_vbus_draw(gadget, maxpower); } else { -- 2.25.1

3 months, 2 weeks

5
5
0 0

[PATCH] USB: Skip resume if pm_runtime_set_active() fails

by Ma Ke

A race condition occurs during system suspend if interrupted between usb_suspend() and the parent device’s PM suspend (e.g., a power domain). This triggers PM resume workflows (via usb_resume()), but if parent device is already runtime-suspended, pm_runtime_set_active() fails. Subsequent operations like pm_runtime_enable() and interface unbinding may leave the USB device in an inconsistent state or trigger unintended behavior. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 98d9a82e5f75 ("USB: cleanup the handling of the PM complete call") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/usb/core/driver.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c index 460d4dde5994..7478fcc11fd4 100644 --- a/drivers/usb/core/driver.c +++ b/drivers/usb/core/driver.c @@ -1624,11 +1624,17 @@ int usb_resume(struct device *dev, pm_message_t msg) status = usb_resume_both(udev, msg); if (status == 0) { pm_runtime_disable(dev); - pm_runtime_set_active(dev); + status = pm_runtime_set_active(dev); + if (status) { + pm_runtime_enable(dev); + goto out; + } + pm_runtime_enable(dev); unbind_marked_interfaces(udev); } +out: /* Avoid PM error messages for devices disconnected while suspended * as we'll display regular disconnect messages just a bit later. */ -- 2.25.1

3 months, 2 weeks

2
1
0 0

[PATCH] mm: abort vma_modify() on merge out of memory failure

by Lorenzo Stoakes

The remainder of vma_modify() relies upon the vmg state remaining pristine after a merge attempt. Usually this is the case, however in the one edge case scenario of a merge attempt failing not due to the specified range being unmergeable, but rather due to an out of memory error arising when attempting to commit the merge, this assumption becomes untrue. This results in vmg->start, end being modified, and thus the proceeding attempts to split the VMA will be done with invalid start/end values. Thankfully, it is likely practically impossible for us to hit this in reality, as it would require a maple tree node pre-allocation failure that would likely never happen due to it being 'too small to fail', i.e. the kernel would simply keep retrying reclaim until it succeeded. However, this scenario remains theoretically possible, and what we are doing here is wrong so we must correct it. The safest option is, when this scenario occurs, to simply give up the operation. If we cannot allocate memory to merge, then we cannot allocate memory to split either (perhaps moreso!). Any scenario where this would be happening would be under very extreme (likely fatal) memory pressure, so it's best we give up early. So there is no doubt it is appropriate to simply bail out in this scenario. However, in general we must if at all possible never assume VMG state is stable after a merge attempt, since merge operations update VMG fields. As a result, additionally also make this clear by storing start, end in local variables. The issue was reported originally by syzkaller, and by Brad Spengler (via an off-list discussion), and in both instances it manifested as a triggering of the assert: VM_WARN_ON_VMG(start >= end, vmg); In vma_merge_existing_range(). It seems at least one scenario in which this is occurring is one in which the merge being attempted is due to an madvise() across multiple VMAs which looks like this: start end |<------>| |----------|------| | vma | next | |----------|------| When madvise_walk_vmas() is invoked, we first find vma in the above (determining prev to be equal to vma as we are offset into vma), and then enter the loop. We determine the end of vma that forms part of the range we are madvise()'ing by setting 'tmp' to this value: /* Here vma->vm_start <= start < (end|vma->vm_end) */ tmp = vma->vm_end; We then invoke the madvise() operation via visit(), letting prev get updated to point to vma as part of the operation: /* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */ error = visit(vma, &prev, start, tmp, arg); Where the visit() function pointer in this instance is madvise_vma_behavior(). As observed in syzkaller reports, it is ultimately madvise_update_vma() that is invoked, calling vma_modify_flags_name() and vma_modify() in turn. Then, in vma_modify(), we attempt the merge: merged = vma_merge_existing_range(vmg); if (merged) return merged; We invoke this with vmg->start, end set to start, tmp as such: start tmp |<--->| |----------|------| | vma | next | |----------|------| We find ourselves in the merge right scenario, but the one in which we cannot remove the middle (we are offset into vma). Here we have a special case where vmg->start, end get set to perhaps unintuitive values - we intended to shrink the middle VMA and expand the next. This means vmg->start, end are set to... vma->vm_start, start. Now the commit_merge() fails, and vmg->start, end are left like this. This means we return to the rest of vma_modify() with vmg->start, end (here denoted as start', end') set as: start' end' |<-->| |----------|------| | vma | next | |----------|------| So we now erroneously try to split accordingly. This is where the unfortunate stuff begins. We start with: /* Split any preceding portion of the VMA. */ if (vma->vm_start < vmg->start) { ... } This doesn't trigger as we are no longer offset into vma at the start. But then we invoke: /* Split any trailing portion of the VMA. */ if (vma->vm_end > vmg->end) { ... } Which does get invoked. This leaves us with: start' end' |<-->| |----|-----|------| | vma| new | next | |----|-----|------| We then return ultimately to madvise_walk_vmas(). Here 'new' is unknown, and putting back the values known in this function we are faced with: start tmp end | | | |----|-----|------| | vma| new | next | |----|-----|------| prev Then: start = tmp; So: start end | | |----|-----|------| | vma| new | next | |----|-----|------| prev The following code does not cause anything to happen: if (prev && start < prev->vm_end) start = prev->vm_end; if (start >= end) break; And then we invoke: if (prev) vma = find_vma(mm, prev->vm_end); Which is where a problem occurs - we don't know about 'new' so we essentially look for the vma after prev, which is new, whereas we actually intended to discover next! So we end up with: start end | | |----|-----|------| |prev| vma | next | |----|-----|------| And we have successfully bypassed all of the checks madvise_walk_vmas() has to ensure early exit should we end up moving out of range. We loop around, and hit: /* Here vma->vm_start <= start < (end|vma->vm_end) */ tmp = vma->vm_end; Oh dear. Now we have: tmp start end | | |----|-----|------| |prev| vma | next | |----|-----|------| We then invoke: /* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */ error = visit(vma, &prev, start, tmp, arg); Where start == tmp. That is, a zero range. This is not good. We invoke visit() which is madvise_vma_behavior() which does not check the range (for good reason, it assumes all checks have been done before it was called), which in turn finally calls madvise_update_vma(). The madvise_update_vma() function calls vma_modify_flags_name() in turn, which ultimately invokes vma_modify() with... start == end. vma_modify() calls vma_merge_existing_range() and finally we hit: VM_WARN_ON_VMG(start >= end, vmg); Which triggers, as start == end. While it might be useful to add some CONFIG_DEBUG_VM asserts in these instances to catch this kind of error, since we have just eliminated any possibility of that happening, we will add such asserts separately as to reduce churn and aid backporting. Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Tested-by: Brad Spengler <brad.spengler(a)opensrcsec.com> Fixes: 2f1c6611b0a8 ("mm: introduce vma_merge_struct and abstract vma_merge(),vma_modify()") Reported-by: Brad Spengler <brad.spengler(a)opensrcsec.com> Reported-by: syzbot+46423ed8fa1f1148c6e4(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-mm/6774c98f.050a0220.25abdd.0991.GAE@google.c… Cc: stable(a)vger.kernel.org --- mm/vma.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/mm/vma.c b/mm/vma.c index c7abef5177cc..76bec07e30b7 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -1523,24 +1523,28 @@ int do_vmi_munmap(struct vma_iterator *vmi, struct mm_struct *mm, static struct vm_area_struct *vma_modify(struct vma_merge_struct *vmg) { struct vm_area_struct *vma = vmg->middle; + unsigned long start = vmg->start; + unsigned long end = vmg->end; struct vm_area_struct *merged; /* First, try to merge. */ merged = vma_merge_existing_range(vmg); if (merged) return merged; + if (vmg_nomem(vmg)) + return ERR_PTR(-ENOMEM); /* Split any preceding portion of the VMA. */ - if (vma->vm_start < vmg->start) { - int err = split_vma(vmg->vmi, vma, vmg->start, 1); + if (vma->vm_start < start) { + int err = split_vma(vmg->vmi, vma, start, 1); if (err) return ERR_PTR(err); } /* Split any trailing portion of the VMA. */ - if (vma->vm_end > vmg->end) { - int err = split_vma(vmg->vmi, vma, vmg->end, 0); + if (vma->vm_end > end) { + int err = split_vma(vmg->vmi, vma, end, 0); if (err) return ERR_PTR(err); -- 2.48.1

3 months, 2 weeks

2
2
0 0

[PATCH AUTOSEL 6.10 01/27] wifi: nl80211: disallow setting special AP channel widths

by Sasha Levin

From: Johannes Berg <johannes.berg(a)intel.com> [ Upstream commit 23daf1b4c91db9b26f8425cc7039cf96d22ccbfe ] Setting the AP channel width is meant for use with the normal 20/40/... MHz channel width progression, and switching around in S1G or narrow channels isn't supported. Disallow that. Reported-by: syzbot+bc0f5b92cc7091f45fb6(a)syzkaller.appspotmail.com Link: https://msgid.link/20240515141600.d4a9590bfe32.I19a32d60097e81b527eafe6b092… Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/wireless/nl80211.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 72c7bf5585816..81d5bf186180f 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -3419,6 +3419,33 @@ static int __nl80211_set_channel(struct cfg80211_registered_device *rdev, if (chandef.chan != cur_chan) return -EBUSY; + /* only allow this for regular channel widths */ + switch (wdev->links[link_id].ap.chandef.width) { + case NL80211_CHAN_WIDTH_20_NOHT: + case NL80211_CHAN_WIDTH_20: + case NL80211_CHAN_WIDTH_40: + case NL80211_CHAN_WIDTH_80: + case NL80211_CHAN_WIDTH_80P80: + case NL80211_CHAN_WIDTH_160: + case NL80211_CHAN_WIDTH_320: + break; + default: + return -EINVAL; + } + + switch (chandef.width) { + case NL80211_CHAN_WIDTH_20_NOHT: + case NL80211_CHAN_WIDTH_20: + case NL80211_CHAN_WIDTH_40: + case NL80211_CHAN_WIDTH_80: + case NL80211_CHAN_WIDTH_80P80: + case NL80211_CHAN_WIDTH_160: + case NL80211_CHAN_WIDTH_320: + break; + default: + return -EINVAL; + } + result = rdev_set_ap_chanwidth(rdev, dev, link_id, &chandef); if (result) -- 2.43.0

3 months, 2 weeks

4
35
0 0

[REGRESSION] Chrome and VSCode breakage with the commit b9b588f22a0c

by Takashi Iwai

Hi, we received a bug report showing the regression on 6.13.1 kernel against 6.13.0. The symptom is that Chrome and VSCode stopped working with Gnome Scaling, as reported on openSUSE Tumbleweed bug tracker https://bugzilla.suse.com/show_bug.cgi?id=1236943 Quoting from there: """ I use the latest TW on Gnome with a 4K display and 150% scaling. Everything has been working fine, but recently both Chrome and VSCode (installed from official non-openSUSE channels) stopped working with Scaling. .... I am using VSCode with: `--enable-features=UseOzonePlatform --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto` and for Chrome, I select `Preferred Ozone platform` == `Wayland`. """ Surprisingly, the bisection pointed to the backport of the commit b9b588f22a0c049a14885399e27625635ae6ef91 ("libfs: Use d_children list to iterate simple_offset directories"). Indeed, the revert of this patch on the latest 6.13.4 was confirmed to fix the issue. Also, the reporter verified that the latest 6.14-rc release is still affected, too. For now I have no concrete idea how the patch could break the behavior of a graphical application like the above. Let us know if you need something for debugging. (Or at easiest, join to the bugzilla entry and ask there; or open another bug report at whatever you like.) BTW, I'll be traveling tomorrow, so my reply will be delayed. thanks, Takashi #regzbot introduced: b9b588f22a0c049a14885399e27625635ae6ef91 #regzbot monitor: https://bugzilla.suse.com/show_bug.cgi?id=1236943

3 months, 2 weeks

1
0
0 0

Please backport "drm: select DRM_KMS_HELPER from DRM_GEM_SHMEM_HELPER" to 6.13.x

by NoisyCoil

Hello. The build (actually, linking) failure described in [1] affects current stable (6.13.4). Could the commit that fixes it in mainline, namely, c40ca9ef7c5c9bbb0d2f7774c87417cc4f1713bf ("drm: select DRM_KMS_HELPER from DRM_GEM_SHMEM_HELPER") be backported to 6.13.x, please? Thank you. [1] https://lore.kernel.org/all/20250121-greedy-flounder-of-abundance-4d2ee8-mk…

3 months, 2 weeks

2
1
0 0

+ mm-abort-vma_modify-on-merge-out-of-memory-failure.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: abort vma_modify() on merge out of memory failure has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-abort-vma_modify-on-merge-out-of-memory-failure.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Subject: mm: abort vma_modify() on merge out of memory failure Date: Sat, 22 Feb 2025 16:19:52 +0000 The remainder of vma_modify() relies upon the vmg state remaining pristine after a merge attempt. Usually this is the case, however in the one edge case scenario of a merge attempt failing not due to the specified range being unmergeable, but rather due to an out of memory error arising when attempting to commit the merge, this assumption becomes untrue. This results in vmg->start, end being modified, and thus the proceeding attempts to split the VMA will be done with invalid start/end values. Thankfully, it is likely practically impossible for us to hit this in reality, as it would require a maple tree node pre-allocation failure that would likely never happen due to it being 'too small to fail', i.e. the kernel would simply keep retrying reclaim until it succeeded. However, this scenario remains theoretically possible, and what we are doing here is wrong so we must correct it. The safest option is, when this scenario occurs, to simply give up the operation. If we cannot allocate memory to merge, then we cannot allocate memory to split either (perhaps moreso!). Any scenario where this would be happening would be under very extreme (likely fatal) memory pressure, so it's best we give up early. So there is no doubt it is appropriate to simply bail out in this scenario. However, in general we must if at all possible never assume VMG state is stable after a merge attempt, since merge operations update VMG fields. As a result, additionally also make this clear by storing start, end in local variables. The issue was reported originally by syzkaller, and by Brad Spengler (via an off-list discussion), and in both instances it manifested as a triggering of the assert: VM_WARN_ON_VMG(start >= end, vmg); In vma_merge_existing_range(). It seems at least one scenario in which this is occurring is one in which the merge being attempted is due to an madvise() across multiple VMAs which looks like this: start end |<------>| |----------|------| | vma | next | |----------|------| When madvise_walk_vmas() is invoked, we first find vma in the above (determining prev to be equal to vma as we are offset into vma), and then enter the loop. We determine the end of vma that forms part of the range we are madvise()'ing by setting 'tmp' to this value: /* Here vma->vm_start <= start < (end|vma->vm_end) */ tmp = vma->vm_end; We then invoke the madvise() operation via visit(), letting prev get updated to point to vma as part of the operation: /* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */ error = visit(vma, &prev, start, tmp, arg); Where the visit() function pointer in this instance is madvise_vma_behavior(). As observed in syzkaller reports, it is ultimately madvise_update_vma() that is invoked, calling vma_modify_flags_name() and vma_modify() in turn. Then, in vma_modify(), we attempt the merge: merged = vma_merge_existing_range(vmg); if (merged) return merged; We invoke this with vmg->start, end set to start, tmp as such: start tmp |<--->| |----------|------| | vma | next | |----------|------| We find ourselves in the merge right scenario, but the one in which we cannot remove the middle (we are offset into vma). Here we have a special case where vmg->start, end get set to perhaps unintuitive values - we intended to shrink the middle VMA and expand the next. This means vmg->start, end are set to... vma->vm_start, start. Now the commit_merge() fails, and vmg->start, end are left like this. This means we return to the rest of vma_modify() with vmg->start, end (here denoted as start', end') set as: start' end' |<-->| |----------|------| | vma | next | |----------|------| So we now erroneously try to split accordingly. This is where the unfortunate stuff begins. We start with: /* Split any preceding portion of the VMA. */ if (vma->vm_start < vmg->start) { ... } This doesn't trigger as we are no longer offset into vma at the start. But then we invoke: /* Split any trailing portion of the VMA. */ if (vma->vm_end > vmg->end) { ... } Which does get invoked. This leaves us with: start' end' |<-->| |----|-----|------| | vma| new | next | |----|-----|------| We then return ultimately to madvise_walk_vmas(). Here 'new' is unknown, and putting back the values known in this function we are faced with: start tmp end | | | |----|-----|------| | vma| new | next | |----|-----|------| prev Then: start = tmp; So: start end | | |----|-----|------| | vma| new | next | |----|-----|------| prev The following code does not cause anything to happen: if (prev && start < prev->vm_end) start = prev->vm_end; if (start >= end) break; And then we invoke: if (prev) vma = find_vma(mm, prev->vm_end); Which is where a problem occurs - we don't know about 'new' so we essentially look for the vma after prev, which is new, whereas we actually intended to discover next! So we end up with: start end | | |----|-----|------| |prev| vma | next | |----|-----|------| And we have successfully bypassed all of the checks madvise_walk_vmas() has to ensure early exit should we end up moving out of range. We loop around, and hit: /* Here vma->vm_start <= start < (end|vma->vm_end) */ tmp = vma->vm_end; Oh dear. Now we have: tmp start end | | |----|-----|------| |prev| vma | next | |----|-----|------| We then invoke: /* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */ error = visit(vma, &prev, start, tmp, arg); Where start == tmp. That is, a zero range. This is not good. We invoke visit() which is madvise_vma_behavior() which does not check the range (for good reason, it assumes all checks have been done before it was called), which in turn finally calls madvise_update_vma(). The madvise_update_vma() function calls vma_modify_flags_name() in turn, which ultimately invokes vma_modify() with... start == end. vma_modify() calls vma_merge_existing_range() and finally we hit: VM_WARN_ON_VMG(start >= end, vmg); Which triggers, as start == end. While it might be useful to add some CONFIG_DEBUG_VM asserts in these instances to catch this kind of error, since we have just eliminated any possibility of that happening, we will add such asserts separately as to reduce churn and aid backporting. Link: https://lkml.kernel.org/r/20250222161952.41957-1-lorenzo.stoakes@oracle.com Fixes: 2f1c6611b0a8 ("mm: introduce vma_merge_struct and abstract vma_merge(),vma_modify()") Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Tested-by: Brad Spengler <brad.spengler(a)opensrcsec.com> Reported-by: Brad Spengler <brad.spengler(a)opensrcsec.com> Reported-by: syzbot+46423ed8fa1f1148c6e4(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-mm/6774c98f.050a0220.25abdd.0991.GAE@google.c… Cc: Jann Horn <jannh(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vma.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/mm/vma.c~mm-abort-vma_modify-on-merge-out-of-memory-failure +++ a/mm/vma.c @@ -1509,24 +1509,28 @@ int do_vmi_munmap(struct vma_iterator *v static struct vm_area_struct *vma_modify(struct vma_merge_struct *vmg) { struct vm_area_struct *vma = vmg->vma; + unsigned long start = vmg->start; + unsigned long end = vmg->end; struct vm_area_struct *merged; /* First, try to merge. */ merged = vma_merge_existing_range(vmg); if (merged) return merged; + if (vmg_nomem(vmg)) + return ERR_PTR(-ENOMEM); /* Split any preceding portion of the VMA. */ - if (vma->vm_start < vmg->start) { - int err = split_vma(vmg->vmi, vma, vmg->start, 1); + if (vma->vm_start < start) { + int err = split_vma(vmg->vmi, vma, start, 1); if (err) return ERR_PTR(err); } /* Split any trailing portion of the VMA. */ - if (vma->vm_end > vmg->end) { - int err = split_vma(vmg->vmi, vma, vmg->end, 0); + if (vma->vm_end > end) { + int err = split_vma(vmg->vmi, vma, end, 0); if (err) return ERR_PTR(err); _ Patches currently in -mm which might be from lorenzo.stoakes(a)oracle.com are mm-abort-vma_modify-on-merge-out-of-memory-failure.patch mm-simplify-vma-merge-structure-and-expand-comments.patch mm-further-refactor-commit_merge.patch mm-eliminate-adj_start-parameter-from-commit_merge.patch mm-make-vmg-target-consistent-and-further-simplify-commit_merge.patch mm-completely-abstract-unnecessary-adj_start-calculation.patch mm-madvise-split-out-mmap-locking-operations-for-madvise-fix.patch mm-use-read-write_once-for-vma-vm_flags-on-migrate-mprotect.patch mm-refactor-rmap_walk_file-to-separate-out-traversal-logic.patch mm-provide-mapping_wrprotect_range-function.patch fb_defio-do-not-use-deprecated-page-mapping-index-fields.patch fb_defio-do-not-use-deprecated-page-mapping-index-fields-fix.patch mm-allow-guard-regions-in-file-backed-and-read-only-mappings.patch selftests-mm-rename-guard-pages-to-guard-regions.patch tools-selftests-expand-all-guard-region-tests-to-file-backed.patch tools-selftests-add-file-shmem-backed-mapping-guard-region-tests.patch

3 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025