February 2025 - Linux-stable-mirror

stable-rc/linux-5.15.y: new build regression: expected ';' at end of declaration in drivers/soc/atmel/...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: expected ';' at end of declaration in drivers/soc/atmel/soc.o (drivers/soc/atmel/soc.c) [logspec:kbuild,kbuild.compiler.error] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:e215ae3b0e6270af8… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:e215ae3b0e6270af8… Log excerpt: drivers/soc/atmel/soc.c:367:24: error: expected ';' at end of declaration 367 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^ | ; 1 error generated. # Builds where the incident occurred: ## defconfig+allmodconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11aa4661a7bc87… #kernelci issue maestro:e215ae3b0e6270af8feaeba47353c1644d7527f8 -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

5 months, 3 weeks

1
0
0 0

stable-rc/linux-5.15.y: new build regression: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ in drivers/soc/atmel/soc.o (drivers/soc/atmel/soc.c) [logspec:kbuild,kbuild.compiler.error] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:a7eccc80a8c5d40b2… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:a7eccc80a8c5d40b2… Log excerpt: drivers/soc/atmel/soc.c:367:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ 367 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ drivers/soc/atmel/soc.c:367:32: error: implicit declaration of function ‘__free’; did you mean ‘kfree’? [-Werror=implicit-function-declaration] 367 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ | kfree drivers/soc/atmel/soc.c:367:39: error: ‘device_node’ undeclared (first use in this function) 367 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~~~~~~ drivers/soc/atmel/soc.c:367:39: note: each undeclared identifier is reported only once for each function it appears in drivers/soc/atmel/soc.c:369:51: error: ‘np’ undeclared (first use in this function); did you mean ‘nop’? 369 | if (!of_match_node(at91_soc_allowed_list, np)) | ^~ | nop AR drivers/clk/mmp/built-in.a cc1: some warnings being treated as errors CC lib/fdt_strerror.o # Builds where the incident occurred: ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11ab8661a7bc87… ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11ac5661a7bc87… ## multi_v5_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11ac1661a7bc87… #kernelci issue maestro:a7eccc80a8c5d40b2934f6b5b061391e2da155c4 -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

5 months, 3 weeks

1
0
0 0

stable-rc/linux-5.10.y: new build regression: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ in drivers/soc/atmel/soc.o (drivers/soc/atmel/soc.c) [logspec:kbuild,kbuild.compiler.error] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:066c374be95fc6671… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:066c374be95fc6671… Log excerpt: drivers/soc/atmel/soc.c:278:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ 278 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ drivers/soc/atmel/soc.c:278:32: error: implicit declaration of function ‘__free’; did you mean ‘kfree’? [-Werror=implicit-function-declaration] 278 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ | kfree drivers/soc/atmel/soc.c:278:39: error: ‘device_node’ undeclared (first use in this function) 278 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~~~~~~ drivers/soc/atmel/soc.c:278:39: note: each undeclared identifier is reported only once for each function it appears in drivers/soc/atmel/soc.c:280:51: error: ‘np’ undeclared (first use in this function); did you mean ‘nop’? 280 | if (!of_match_node(at91_soc_allowed_list, np)) | ^~ | nop cc1: some warnings being treated as errors CC drivers/virtio/virtio.o # Builds where the incident occurred: ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a51661a7bc87… ## multi_v5_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a4d661a7bc87… ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a45661a7bc87… #kernelci issue maestro:066c374be95fc6671e95a97b08ffc502a95454b6 -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

5 months, 3 weeks

1
0
0 0

+ mmmadvisehugetlb-check-for-0-length-range-after-end-address-adjustment.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm,madvise,hugetlb: check for 0-length range after end address adjustment has been added to the -mm mm-hotfixes-unstable branch. Its filename is mmmadvisehugetlb-check-for-0-length-range-after-end-address-adjustment.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: Ricardo Ca��uelo Navarro <rcn(a)igalia.com> Subject: mm,madvise,hugetlb: check for 0-length range after end address adjustment Date: Mon, 3 Feb 2025 08:52:06 +0100 Add a sanity check to madvise_dontneed_free() to address a corner case in madvise where a race condition causes the current vma being processed to be backed by a different page size. During a madvise(MADV_DONTNEED) call on a memory region registered with a userfaultfd, there's a period of time where the process mm lock is temporarily released in order to send a UFFD_EVENT_REMOVE and let userspace handle the event. During this time, the vma covering the current address range may change due to an explicit mmap done concurrently by another thread. If, after that change, the memory region, which was originally backed by 4KB pages, is now backed by hugepages, the end address is rounded down to a hugepage boundary to avoid data loss (see "Fixes" below). This rounding may cause the end address to be truncated to the same address as the start. Make this corner case follow the same semantics as in other similar cases where the requested region has zero length (ie. return 0). This will make madvise_walk_vmas() continue to the next vma in the range (this time holding the process mm lock) which, due to the prev pointer becoming stale because of the vma change, will be the same hugepage-backed vma that was just checked before. The next time madvise_dontneed_free() runs for this vma, if the start address isn't aligned to a hugepage boundary, it'll return -EINVAL, which is also in line with the madvise api. From userspace perspective, madvise() will return EINVAL because the start address isn't aligned according to the new vma alignment requirements (hugepage), even though it was correctly page-aligned when the call was issued. Link: https://lkml.kernel.org/r/20250203075206.1452208-1-rcn@igalia.com Fixes: 8ebe0a5eaaeb ("mm,madvise,hugetlb: fix unexpected data loss with MADV_DONTNEED on hugetlbfs") Signed-off-by: Ricardo Ca��uelo Navarro <rcn(a)igalia.com> Cc: Florent Revest <revest(a)google.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/madvise.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/mm/madvise.c~mmmadvisehugetlb-check-for-0-length-range-after-end-address-adjustment +++ a/mm/madvise.c @@ -933,7 +933,16 @@ static long madvise_dontneed_free(struct */ end = vma->vm_end; } - VM_WARN_ON(start >= end); + /* + * If the memory region between start and end was + * originally backed by 4kB pages and then remapped to + * be backed by hugepages while mmap_lock was dropped, + * the adjustment for hugetlb vma above may have rounded + * end down to the start address. + */ + if (start == end) + return 0; + VM_WARN_ON(start > end); } if (behavior == MADV_DONTNEED || behavior == MADV_DONTNEED_LOCKED) _ Patches currently in -mm which might be from rcn(a)igalia.com are mmmadvisehugetlb-check-for-0-length-range-after-end-address-adjustment.patch

5 months, 3 weeks

1
0
0 0

[PATCH] usb: dwc3: Fix timeout issue during controller enter/exit from halt state

by Selvarasu Ganesan

There is a frequent timeout during controller enter/exit from halt state after toggling the run_stop bit by SW. This timeout occurs when performing frequent role switches between host and device, causing device enumeration issues due to the timeout. This issue was not present when USB2 suspend PHY was disabled by passing the SNPS quirks (snps,dis_u2_susphy_quirk and snps,dis_enblslpm_quirk) from the DTS. However, there is a requirement to enable USB2 suspend PHY by setting of GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY bits when controller starts in gadget or host mode results in the timeout issue. This commit addresses this timeout issue by ensuring that the bits GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY are cleared before starting the dwc3_gadget_run_stop sequence and restoring them after the dwc3_gadget_run_stop sequence is completed. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- drivers/usb/dwc3/gadget.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index d27af65eb08a..4a158f703d64 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2629,10 +2629,25 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on) { u32 reg; u32 timeout = 2000; + u32 saved_config = 0; if (pm_runtime_suspended(dwc->dev)) return 0; + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); + if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) { + saved_config |= DWC3_GUSB2PHYCFG_SUSPHY; + reg &= ~DWC3_GUSB2PHYCFG_SUSPHY; + } + + if (reg & DWC3_GUSB2PHYCFG_ENBLSLPM) { + saved_config |= DWC3_GUSB2PHYCFG_ENBLSLPM; + reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM; + } + + if (saved_config) + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); if (is_on) { if (DWC3_VER_IS_WITHIN(DWC3, ANY, 187A)) { @@ -2660,6 +2675,12 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on) reg &= DWC3_DSTS_DEVCTRLHLT; } while (--timeout && !(!is_on ^ !reg)); + if (saved_config) { + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); + reg |= saved_config; + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + } + if (!timeout) return -ETIMEDOUT; -- 2.17.1

5 months, 3 weeks

3
4
0 0

[PATCH v2] usb: dwc3: Fix timeout issue during controller enter/exit from halt state

by Selvarasu Ganesan

There is a frequent timeout during controller enter/exit from halt state after toggling the run_stop bit by SW. This timeout occurs when performing frequent role switches between host and device, causing device enumeration issues due to the timeout. This issue was not present when USB2 suspend PHY was disabled by passing the SNPS quirks (snps,dis_u2_susphy_quirk and snps,dis_enblslpm_quirk) from the DTS. However, there is a requirement to enable USB2 suspend PHY by setting of GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY bits when controller starts in gadget or host mode results in the timeout issue. This commit addresses this timeout issue by ensuring that the bits GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY are cleared before starting the dwc3_gadget_run_stop sequence and restoring them after the dwc3_gadget_run_stop sequence is completed. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- Changes in v2: - Added some comments before the changes. - And removed "unlikely" in the condition check. - Link to v1: https://lore.kernel.org/linux-usb/20250131110832.438-1-selvarasu.g@samsung.… --- drivers/usb/dwc3/gadget.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index d27af65eb08a..ddd6b2ce5710 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2629,10 +2629,38 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on) { u32 reg; u32 timeout = 2000; + u32 saved_config = 0; if (pm_runtime_suspended(dwc->dev)) return 0; + /* + * When operating in USB 2.0 speeds (HS/FS), ensure that + * GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY are cleared before starting + * or stopping the controller. This resolves timeout issues that occur + * during frequent role switches between host and device modes. + * + * Save and clear these settings, then restore them after completing the + * controller start or stop sequence. + * + * This solution was discovered through experimentation as it is not + * mentioned in the dwc3 programming guide. It has been tested on an + * Exynos platforms. + */ + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); + if (reg & DWC3_GUSB2PHYCFG_SUSPHY) { + saved_config |= DWC3_GUSB2PHYCFG_SUSPHY; + reg &= ~DWC3_GUSB2PHYCFG_SUSPHY; + } + + if (reg & DWC3_GUSB2PHYCFG_ENBLSLPM) { + saved_config |= DWC3_GUSB2PHYCFG_ENBLSLPM; + reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM; + } + + if (saved_config) + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); if (is_on) { if (DWC3_VER_IS_WITHIN(DWC3, ANY, 187A)) { @@ -2660,6 +2688,12 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on) reg &= DWC3_DSTS_DEVCTRLHLT; } while (--timeout && !(!is_on ^ !reg)); + if (saved_config) { + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); + reg |= saved_config; + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + } + if (!timeout) return -ETIMEDOUT; -- 2.17.1

5 months, 3 weeks

2
1
0 0

[PATCH] jiffies: Cast to unsigned long for secs_to_jiffies() conversion

by Easwar Hariharan

While converting users of msecs_to_jiffies(), lkp reported that some range checks would always be true because of the mismatch between the implied int value of secs_to_jiffies() vs the unsigned long return value of the msecs_to_jiffies() calls it was replacing. Fix this by casting secs_to_jiffies() values as unsigned long. Fixes: b35108a51cf7ba ("jiffies: Define secs_to_jiffies()") CC: stable(a)vger.kernel.org # 6.12+ CC: Andrew Morton <akpm(a)linux-foundation.org> Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501301334.NB6NszQR-lkp@intel.com/ Signed-off-by: Easwar Hariharan <eahariha(a)linux.microsoft.com> --- include/linux/jiffies.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h index ed945f42e064..0ea8c9887429 100644 --- a/include/linux/jiffies.h +++ b/include/linux/jiffies.h @@ -537,7 +537,7 @@ static __always_inline unsigned long msecs_to_jiffies(const unsigned int m) * * Return: jiffies value */ -#define secs_to_jiffies(_secs) ((_secs) * HZ) +#define secs_to_jiffies(_secs) (unsigned long)((_secs) * HZ) extern unsigned long __usecs_to_jiffies(const unsigned int u); #if !(USEC_PER_SEC % HZ) -- 2.43.0

5 months, 3 weeks

4
7
0 0

[PATCH v1] pwm: microchip-core: fix incorrect comparison with max period

by Conor Dooley

From: Conor Dooley <conor.dooley(a)microchip.com> In mchp_core_pwm_apply_locked(), if hw_period_steps is equal to its max, an error is reported and .apply fails. The max value is actually a permitted value however, and so this check can fail where multiple channels are enabled. For example, the first channel to be configured requests a period that sets hw_period_steps to the maximum value, and when a second channel is enabled the driver reads hw_period_steps back from the hardware and finds it to be the maximum possible value, triggering the warning on a permitted value. The value to be avoided is 255 (PERIOD_STEPS_MAX + 1), as that will produce undesired behaviour, so test for greater than, rather than equal to. Fixes: 2bf7ecf7b4ff ("pwm: add microchip soft ip corePWM driver") CC: stable(a)vger.kernel.org Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> --- CC: Conor Dooley <conor.dooley(a)microchip.com> CC: Daire McNamara <daire.mcnamara(a)microchip.com> CC: Uwe Kleine-König <ukleinek(a)kernel.org> CC: Thierry Reding <thierry.reding(a)gmail.com> CC: linux-riscv(a)lists.infradead.org CC: linux-pwm(a)vger.kernel.org CC: linux-kernel(a)vger.kernel.org --- drivers/pwm/pwm-microchip-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/pwm-microchip-core.c b/drivers/pwm/pwm-microchip-core.c index c1f2287b8e97..12821b4bbf97 100644 --- a/drivers/pwm/pwm-microchip-core.c +++ b/drivers/pwm/pwm-microchip-core.c @@ -327,7 +327,7 @@ static int mchp_core_pwm_apply_locked(struct pwm_chip *chip, struct pwm_device * * mchp_core_pwm_calc_period(). * The period is locked and we cannot change this, so we abort. */ - if (hw_period_steps == MCHPCOREPWM_PERIOD_STEPS_MAX) + if (hw_period_steps > MCHPCOREPWM_PERIOD_STEPS_MAX) return -EINVAL; prescale = hw_prescale; -- 2.45.2

5 months, 3 weeks

3
2
0 0

Re: [Fix CVE-2024-50217 in v6.6.y] [PATCH] btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()

by Greg KH

On Mon, Feb 03, 2025 at 06:45:55PM +0000, Shubham Pushpkar -X (spushpka - E INFOCHIPS PRIVATE LIMITED at Cisco) wrote: > Thank you, Greg, for your feedback and for highlighting the importance > of thorough testing. I apologize for any oversight in my previous > submission. I will ensure that all future patches are rigorously > tested before submission. Again, they must be tested AND have a second signed-off-by from someone else in your company when you resend them as proof of this testing by both of you. thanks, greg k-h

5 months, 3 weeks

1
0
0 0

stable/linux-6.13.y: new boot regression: WARNING at lib/refcount.c:25 refcount_warn_saturate+0xc8...

by KernelCI bot

Hello, New boot regression found on stable/linux-6.13.y: WARNING at lib/refcount.c:25 refcount_warn_saturate+0xc8/0x148 [logspec:generic_linux_boot,linux.kernel.warning] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:9027cb3b2181d813a… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:9027cb3b2181d813a… Log excerpt: [ 4.653252] refcount_t: addition on 0; use-after-free. [ 4.653261] WARNING: CPU: 5 PID: 187 at lib/refcount.c:25 refcount_warn_saturate+0xc8/0x148 [ 4.653271] Modules linked in: v4l2_mem2mem pcie_mediatek_gen3(+) mt6359_auxadc mtk_rpmsg joydev videobuf2_dma_contig rpmsg_core elan_i2c lvts_thermal(+) mt6577_auxadc snd_soc_mt8195_afe(+) mtk_svs mtk_scp_ipi snd_sof_utils mtk_wdt btusb btintel btbcm btmtk btrtl uvcvideo videobuf2_vmalloc uvc videobuf2_v4l2 mt8195_mt6359 bluetooth ecdh_generic videobuf2_memops ecc videobuf2_common [ 4.653293] CPU: 5 UID: 0 PID: 187 Comm: (udev-worker) Not tainted 6.13.0 #1 c0bd9fe43a50105c5d4fe2d8da4d493a3771f650 [ 4.653296] Hardware name: Acer Tomato (rev2) board (DT) [ 4.653297] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.653298] pc : refcount_warn_saturate+0xc8/0x148 [ 4.653301] lr : refcount_warn_saturate+0xc8/0x148 [ 4.653303] sp : ffff800080c23620 [ 4.653304] x29: ffff800080c23620 x28: ffffda629c274b18 x27: 0000000000000001 [ 4.653306] x26: ffff800080c23930 x25: ffffda62d3588f10 x24: ffff07808558e7f8 [ 4.653308] x23: 0000000000000000 x22: ffff078081075478 x21: ffff800080c236a8 [ 4.653309] x20: 0000000000000000 x19: ffff078081074078 x18: 00000000ffffffff [ 4.653311] x17: 00000000ffffb060 x16: ffffda62d111f5f8 x15: 612d35393138746d [ 4.653313] x14: ffffda62d37fd750 x13: 0a2e656572662d72 x12: ffffda62d3551950 [ 4.653315] x11: 0000000000000001 x10: 0000000000000001 x9 : ffffda62d0943280 [ 4.653316] x8 : c0000000ffffdfff x7 : ffffda62d34a18b0 x6 : 00000000000affa8 [ 4.653318] x5 : ffffda62d35518f8 x4 : 0000000000000000 x3 : 00000000ffffffff [ 4.653320] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff078088140000 [ 4.653322] Call trace: [ 4.653323] refcount_warn_saturate+0xc8/0x148 (P) [ 4.653326] klist_next+0x180/0x1a8 [ 4.653329] bus_for_each_dev+0x6c/0xe8 [ 4.653334] driver_attach+0x2c/0x40 [ 4.653336] bus_add_driver+0xec/0x218 [ 4.653337] driver_register+0x68/0x138 [ 4.653339] __platform_driver_register+0x2c/0x40 [ 4.653341] mt8195_afe_pcm_driver_init+0x28/0xff8 [snd_soc_mt8195_afe 41f903257dcc6a1560bfbd0ddb4cf7a5b6deb9f1] [ 4.653350] do_one_initcall+0x60/0x320 [ 4.653354] do_init_module+0x68/0x258 [ 4.653357] load_module+0x1cf8/0x1de8 [ 4.653359] init_module_from_file+0x8c/0xd8 [ 4.653361] __arm64_sys_finit_module+0x150/0x338 [ 4.653363] invoke_syscall+0x70/0x100 [ 4.653367] el0_svc_common.constprop.0+0x48/0xf0 [ 4.653370] do_el0_svc+0x24/0x38 [ 4.653372] el0_svc+0x34/0xf0 [ 4.653375] el0t_64_sync_handler+0x10c/0x138 [ 4.653377] el0t_64_sync+0x1b0/0x1b8 # Hardware platforms affected: ## mt8195-cherry-tomato-r2 - Compatibles: google,tomato-rev2 | google,tomato | mediatek,mt8195 - Dashboard: https://staging.dashboard.kernelci.org:9000/test/maestro:67a0b86a661a7bc874… #kernelci issue maestro:9027cb3b2181d813ac566c16982a6748748d7ae7 -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

5 months, 3 weeks

1
0
0 0

[Fix CVE-2024-50217 in v6.6.y] [PATCH] btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()

by Shubham Pushpkar

From: Zhihao Cheng <chengzhihao1(a)huawei.com> commit aec8e6bf839101784f3ef037dcdb9432c3f32343 ("btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()") Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 → loop0 fs_device \ btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device(). Fixes: CVE-2024-50217 Fixes: 142388194191 ("btrfs: do not background blkdev_put()") CC: stable(a)vger.kernel.org # 4.19+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=219408 Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> (cherry picked from commit aec8e6bf839101784f3ef037dcdb9432c3f32343) Signed-off-by: Shubham Pushpkar <spushpka(a)cisco.com> --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index b9a0b26d08e1..ab2412542ce5 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -1176,6 +1176,7 @@ static void btrfs_close_one_device(struct btrfs_device *device) if (device->bdev) { fs_devices->open_devices--; device->bdev = NULL; + device->bdev_file = NULL; } clear_bit(BTRFS_DEV_STATE_WRITEABLE, &device->dev_state); btrfs_destroy_dev_zone_info(device); -- 2.35.6

5 months, 3 weeks

3
2
0 0

[Fix CVE-2024-50217 in v6.6.y] [PATCH] btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()

by Shubham Pushpkar

From: Zhihao Cheng <chengzhihao1(a)huawei.com> commit aec8e6bf839101784f3ef037dcdb9432c3f32343 ("btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()") Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 → loop0 fs_device \ btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device(). Fixes: 142388194191 ("btrfs: do not background blkdev_put()") CC: stable(a)vger.kernel.org # 4.19+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=219408 Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> (cherry picked from commit aec8e6bf839101784f3ef037dcdb9432c3f32343) Signed-off-by: Shubham Pushpkar <spushpka(a)cisco.com> --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index b9a0b26d08e1..ab2412542ce5 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -1176,6 +1176,7 @@ static void btrfs_close_one_device(struct btrfs_device *device) if (device->bdev) { fs_devices->open_devices--; device->bdev = NULL; + device->bdev_file = NULL; } clear_bit(BTRFS_DEV_STATE_WRITEABLE, &device->dev_state); btrfs_destroy_dev_zone_info(device); -- 2.35.6

5 months, 3 weeks

3
2
0 0

[PATCH V2] usb: gadget: udc: renesas_usb3: Fix compiler warning

by guoren＠kernel.org

From: Guo Ren <guoren(a)linux.alibaba.com> drivers/usb/gadget/udc/renesas_usb3.c: In function 'renesas_usb3_probe': drivers/usb/gadget/udc/renesas_usb3.c:2638:73: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 6 [-Wformat-truncation=] 2638 | snprintf(usb3_ep->ep_name, sizeof(usb3_ep->ep_name), "ep%d", i); ^~~~~~~~~~~~~~~~~~~~~~~~ ^~ ^ Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501201409.BIQPtkeB-lkp@intel.com/ Signed-off-by: Guo Ren <guoren(a)linux.alibaba.com> Signed-off-by: Guo Ren <guoren(a)kernel.org> --- drivers/usb/gadget/udc/renesas_usb3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/renesas_usb3.c b/drivers/usb/gadget/udc/renesas_usb3.c index fce5c41d9f29..89b304cf6d03 100644 --- a/drivers/usb/gadget/udc/renesas_usb3.c +++ b/drivers/usb/gadget/udc/renesas_usb3.c @@ -310,7 +310,7 @@ struct renesas_usb3_request { struct list_head queue; }; -#define USB3_EP_NAME_SIZE 8 +#define USB3_EP_NAME_SIZE 16 struct renesas_usb3_ep { struct usb_ep ep; struct renesas_usb3 *usb3; -- 2.40.1

5 months, 3 weeks

2
2
0 0

[PATCH] usb: xhci: Restore Renesas uPD72020x support in xhci-pci

by nb＠tipi-net.de

From: Nicolai Buchwitz <nb(a)tipi-net.de> Before commit 25f51b76f90f1 ("xhci-pci: Make xhci-pci-renesas a proper modular driver"), the xhci-pci driver handled the Renesas uPD72020x USB3 PHY and only utilized features of xhci-pci-renesas when no external firmware EEPROM was attached. This allowed devices with a valid firmware stored in EEPROM to function without requiring xhci-pci-renesas. That commit changed the behavior, making xhci-pci-renesas responsible for handling these devices entirely, even when firmware was already present in EEPROM. As a result, unnecessary warnings about missing firmware files appeared, and more critically, USB functionality broke whens CONFIG_USB_XHCI_PCI_RENESAS was not enabled—despite previously workings without it. Fix this by ensuring that devices are only handed over to xhci-pci-renesas if the config option is enabled. Otherwise, restore the original behavior and handle them as standard xhci-pci devices. Signed-off-by: Nicolai Buchwitz <nb(a)tipi-net.de> Fixes: 25f51b76f90f ("xhci-pci: Make xhci-pci-renesas a proper modular driver") --- drivers/usb/host/xhci-pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 2d1e205c14c60..4ce80d8ac603e 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -654,9 +654,11 @@ int xhci_pci_common_probe(struct pci_dev *dev, const struct pci_device_id *id) EXPORT_SYMBOL_NS_GPL(xhci_pci_common_probe, "xhci"); static const struct pci_device_id pci_ids_reject[] = { +#if IS_ENABLED(CONFIG_USB_XHCI_PCI_RENESAS) /* handled by xhci-pci-renesas */ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, 0x0014) }, { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, 0x0015) }, +#endif { /* end: all zeroes */ } }; -- 2.39.5

5 months, 3 weeks

3
4
0 0

[PATCH 6.1] efivars: Fix "BUG: corrupted list in efivar_entry_remove"

by Alexey Nepomnyashih

Prevent list corruption in efivar_entry_remove() and efivar_entry_list_del_unlock() by verifying that an entry is still in the list (list_empty() == false) before calling list_del(). Also reset the list pointers with INIT_LIST_HEAD() to avoid potential double-removal issues. Ensure robust handling of entries and prevent the kernel BUG observed when list_del() was called on an already-removed entry. Fix https://syzkaller.appspot.com/bug?extid=246ea4feed277471958a Syzkaller report: list_del corruption. prev->next should be ffff0000d86d6828, but was ffff800016216e60. (prev=ffff800016216e60) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:61! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 4299 Comm: syz-executor237 Not tainted 6.1.119-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del_entry_valid+0x13c/0x158 lib/list_debug.c:59 lr : __list_del_entry_valid+0x13c/0x158 lib/list_debug.c:59 Call trace: __list_del_entry_valid+0x13c/0x158 lib/list_debug.c:59 __list_del_entry include/linux/list.h:134 [inline] list_del include/linux/list.h:148 [inline] efivar_entry_remove+0x38/0x110 fs/efivarfs/vars.c:493 efivarfs_destroy+0x20/0x3c fs/efivarfs/super.c:184 efivar_entry_iter+0x94/0xdc fs/efivarfs/vars.c:720 efivarfs_kill_sb+0x58/0x70 fs/efivarfs/super.c:258 deactivate_locked_super+0xac/0x124 fs/super.c:332 deactivate_super+0xf0/0x110 fs/super.c:363 cleanup_mnt+0x394/0x41c fs/namespace.c:1186 __cleanup_mnt+0x20/0x30 fs/namespace.c:1193 task_work_run+0x240/0x2f0 kernel/task_work.c:203 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] do_notify_resume+0x2080/0x2cb8 arch/arm64/kernel/signal.c:1132 prepare_exit_to_user_mode arch/arm64/kernel/entry-common.c:137 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:142 [inline] el0_svc+0x9c/0x168 arch/arm64/kernel/entry-common.c:638 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:585 Reported-by: syzbot+75dc11...(a)syzkaller.appspotmail.com Fixes: 2d82e6227ea1 ("efi: vars: Move efivar caching layer into efivarfs") Cc: stable(a)vger.kernel.org Signed-off-by: Alexey Nepomnyashih <sdl(a)nppct.ru> --- fs/efivarfs/vars.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/efivarfs/vars.c b/fs/efivarfs/vars.c index 13bc60698955..42977138e30b 100644 --- a/fs/efivarfs/vars.c +++ b/fs/efivarfs/vars.c @@ -490,7 +490,10 @@ void __efivar_entry_add(struct efivar_entry *entry, struct list_head *head) */ void efivar_entry_remove(struct efivar_entry *entry) { - list_del(&entry->list); + if (!list_empty(&entry->list)) { + list_del(&entry->list); + INIT_LIST_HEAD(&entry->list); + } } /* @@ -506,7 +509,10 @@ void efivar_entry_remove(struct efivar_entry *entry) */ static void efivar_entry_list_del_unlock(struct efivar_entry *entry) { - list_del(&entry->list); + if (!list_empty(&entry->list)) { + list_del(&entry->list); + INIT_LIST_HEAD(&entry->list); + } efivar_unlock(); } -- 2.43.0

5 months, 3 weeks

2
1
0 0

[PATCH] ftrace: Avoid potential division by zero in function_stat_show()

by Nikolay Kuratov

Cases rec->counter == {0, 1} are checked already. While x * (x - 1) * 1000 = 0 have many solutions greater than 1 for both modulo 2^32 and 2^64, that is not the case for x * (x - 1) = 0, so split division into two. It is not scary in practice because mod 2^64 solutions are huge and minimal mod 2^32 solution is 30-bit number. Cc: stable(a)vger.kernel.org Fixes: e31f7939c1c27 ("ftrace: Avoid potential division by zero in function profiler") Signed-off-by: Nikolay Kuratov <kniv(a)yandex-team.ru> --- kernel/trace/ftrace.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 728ecda6e8d4..e1c05c4c29c2 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -570,12 +570,12 @@ static int function_stat_show(struct seq_file *m, void *v) stddev = rec->counter * rec->time_squared - rec->time * rec->time; + stddev = div64_ul(stddev, rec->counter * (rec->counter - 1)); /* * Divide only 1000 for ns^2 -> us^2 conversion. * trace_print_graph_duration will divide 1000 again. */ - stddev = div64_ul(stddev, - rec->counter * (rec->counter - 1) * 1000); + stddev = div64_ul(stddev, 1000); } trace_seq_init(&s); -- 2.34.1

5 months, 3 weeks

2
1
0 0

[PATCH 01/14] drm/i915/dp: Iterate DSC BPP from high to low on all platforms

by Jani Nikula

Commit 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best compressed bpp") tries to find the best compressed bpp for the link. However, it iterates from max to min bpp on display 13+, and from min to max on other platforms. This presumably leads to minimum compressed bpp always being chosen on display 11-12. Iterate from high to low on all platforms to actually use the best possible compressed bpp. Fixes: 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best compressed bpp") Cc: Ankit Nautiyal <ankit.k.nautiyal(a)intel.com> Cc: Imre Deak <imre.deak(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.7+ Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> --- drivers/gpu/drm/i915/display/intel_dp.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index d1b4fd542a1f..ecf192262eb9 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2073,11 +2073,10 @@ icl_dsc_compute_link_config(struct intel_dp *intel_dp, /* Compressed BPP should be less than the Input DSC bpp */ dsc_max_bpp = min(dsc_max_bpp, output_bpp - 1); - for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp); i++) { - if (valid_dsc_bpp[i] < dsc_min_bpp) + for (i = ARRAY_SIZE(valid_dsc_bpp) - 1; i >= 0; i--) { + if (valid_dsc_bpp[i] < dsc_min_bpp || + valid_dsc_bpp[i] > dsc_max_bpp) continue; - if (valid_dsc_bpp[i] > dsc_max_bpp) - break; ret = dsc_compute_link_config(intel_dp, pipe_config, -- 2.39.5

5 months, 3 weeks

3
3
0 0

Re: [Fix CVE-2024-50217 in v6.6.y] [PATCH] btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()

by Greg KH

On Mon, Feb 03, 2025 at 11:40:11AM +0000, Shubham Pushpkar -X (spushpka - E INFOCHIPS PRIVATE LIMITED at Cisco) wrote: > Hi Greg, > > Thank you for your valuable feedback on my recent patch submission regarding the CVE fix. > > I appreciate your point about the CVE reference in the commit message. I will revise the patch to remove the CVE identifier, as it is indeed managed in the assignment database. > > Regarding the cc list, I apologize for not including everyone involved in the original commit. I will ensure to cc all relevant parties when I resubmit the patch to facilitate better communication and feedback. > > Thank you once again for your guidance. Please let me know if there are any additional changes or considerations I should be aware of. Yes, please always test your patches before sending them out. Because of a lack of testing here, I'm going to have to ask you to get a signed-off-by from another of your coworkers so that we know two people have verified that the change is correct and actually works for any future stuff you submit. thanks, greg k-h

5 months, 3 weeks

1
0
0 0

[PATCH 6.1] drm/amd/display: fix double free issue during amdgpu module unload

by Anastasia Belova

From: Tim Huang <tim.huang(a)amd.com> [ Upstream commit 20b5a8f9f4670a8503aa9fa95ca632e77c6bf55d ] Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] <TASK> [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] </TASK> Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira(a)amd.com> Signed-off-by: Tim Huang <tim.huang(a)amd.com> Reviewed-by: Roman Li <roman.li(a)amd.com> Signed-off-by: Roman Li <roman.li(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> [ Anastasia: link_destruct in drivers/gpu/drm/amd/display/dc/link/link_factory.c from upstream was dc_link_destruct in drivers/gpu/drm/amd/display/dc/core/dc_link.c in 6.1 ] Signed-off-by: Anastasia Belova <abelova(a)astralinux.ru> --- Backport fix for CVE-2024-49989 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index bbaeb6c567d0..f0db2d58fd6b 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -83,7 +83,7 @@ static void dc_link_destruct(struct dc_link *link) if (link->panel_cntl) link->panel_cntl->funcs->destroy(&link->panel_cntl); - if (link->link_enc) { + if (link->link_enc && !link->is_dig_mapping_flexible) { /* Update link encoder resource tracking variables. These are used for * the dynamic assignment of link encoders to streams. Virtual links * are not assigned encoder resources on creation. -- 2.43.0

5 months, 3 weeks

1
0
0 0

[PATCH] x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs

by Jann Horn

On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table: collapse_pte_mapped_thp pmdp_collapse_flush flush_tlb_range The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way. Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn't have much impact: - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI'd to avoid issues with speculative page table walks. - In Hyper-V TLB paravirtualization, again for lazy TLB stuff. The patch "x86/mm: only invalidate final translations with INVLPGB" which is currently under review (see <https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>) would probably be making the impact of this a lot worse. Cc: stable(a)vger.kernel.org Fixes: 016c4d92cd16 ("x86/mm/tlb: Add freed_tables argument to flush_tlb_mm_range") Signed-off-by: Jann Horn <jannh(a)google.com> --- arch/x86/include/asm/tlbflush.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h index 02fc2aa06e9e0ecdba3fe948cafe5892b72e86c0..3da645139748538daac70166618d8ad95116eb74 100644 --- a/arch/x86/include/asm/tlbflush.h +++ b/arch/x86/include/asm/tlbflush.h @@ -242,7 +242,7 @@ void flush_tlb_multi(const struct cpumask *cpumask, flush_tlb_mm_range((vma)->vm_mm, start, end, \ ((vma)->vm_flags & VM_HUGETLB) \ ? huge_page_shift(hstate_vma(vma)) \ - : PAGE_SHIFT, false) + : PAGE_SHIFT, true) extern void flush_tlb_all(void); extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start, --- base-commit: aa135d1d0902c49ed45bec98c61c1b4022652b7e change-id: 20250103-x86-collapse-flush-fix-fa87ac4d5834 -- Jann Horn <jannh(a)google.com>

5 months, 3 weeks

4
6
0 0

Re: Patch "drm/ttm: Add ttm_bo_access" has been added to the 6.12-stable tree

by Christian König

Am 02.02.25 um 05:33 schrieb Sasha Levin: > This is a note to let you know that I've just added the patch titled > > drm/ttm: Add ttm_bo_access > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… This isn't a bug fix but a new feature and therefore shouldn't be backported. Regards, Christian. > > The filename of the patch is: > drm-ttm-add-ttm_bo_access.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 73b922f15552bb5b47cbcca4b4d2b131b89b786d > Author: Matthew Brost <matthew.brost(a)intel.com> > Date: Tue Nov 26 09:46:09 2024 -0800 > > drm/ttm: Add ttm_bo_access > > [ Upstream commit 7d08df5d0bd3d12d14dcec773fcddbe3eed3a8e8 ] > > Non-contiguous VRAM cannot easily be mapped in TTM nor can non-visible > VRAM easily be accessed. Add ttm_bo_access, which is similar to > ttm_bo_vm_access, to access such memory. > > v4: > - Fix checkpatch warnings (CI) > v5: > - Fix checkpatch warnings (CI) > v6: > - Fix kernel doc (Auld) > v7: > - Move ttm_bo_access to ttm_bo_vm.c (Christian) > > Cc: Christian König <christian.koenig(a)amd.com> > Reported-by: Christoph Manszewski <christoph.manszewski(a)intel.com> > Suggested-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> > Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> > Tested-by: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> > Reviewed-by: Matthew Auld <matthew.auld(a)intel.com> > Reviewed-by: Christian König <christian.koenig(a)amd.com> > Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-3-matt… > Stable-dep-of: 5f7bec831f1f ("drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayed") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c > index 4212b8c91dd42..17667ab31ad4c 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c > @@ -405,13 +405,25 @@ static int ttm_bo_vm_access_kmap(struct ttm_buffer_object *bo, > return len; > } > > -int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr, > - void *buf, int len, int write) > +/** > + * ttm_bo_access - Helper to access a buffer object > + * > + * @bo: ttm buffer object > + * @offset: access offset into buffer object > + * @buf: pointer to caller memory to read into or write from > + * @len: length of access > + * @write: write access > + * > + * Utility function to access a buffer object. Useful when buffer object cannot > + * be easily mapped (non-contiguous, non-visible, etc...). Should not directly > + * be exported to user space via a peak / poke interface. > + * > + * Returns: > + * @len if successful, negative error code on failure. > + */ > +int ttm_bo_access(struct ttm_buffer_object *bo, unsigned long offset, > + void *buf, int len, int write) > { > - struct ttm_buffer_object *bo = vma->vm_private_data; > - unsigned long offset = (addr) - vma->vm_start + > - ((vma->vm_pgoff - drm_vma_node_start(&bo->base.vma_node)) > - << PAGE_SHIFT); > int ret; > > if (len < 1 || (offset + len) > bo->base.size) > @@ -429,8 +441,8 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr, > break; > default: > if (bo->bdev->funcs->access_memory) > - ret = bo->bdev->funcs->access_memory( > - bo, offset, buf, len, write); > + ret = bo->bdev->funcs->access_memory > + (bo, offset, buf, len, write); > else > ret = -EIO; > } > @@ -439,6 +451,18 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr, > > return ret; > } > +EXPORT_SYMBOL(ttm_bo_access); > + > +int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr, > + void *buf, int len, int write) > +{ > + struct ttm_buffer_object *bo = vma->vm_private_data; > + unsigned long offset = (addr) - vma->vm_start + > + ((vma->vm_pgoff - drm_vma_node_start(&bo->base.vma_node)) > + << PAGE_SHIFT); > + > + return ttm_bo_access(bo, offset, buf, len, write); > +} > EXPORT_SYMBOL(ttm_bo_vm_access); > > static const struct vm_operations_struct ttm_bo_vm_ops = { > diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h > index 7b56d1ca36d75..e383dee82001e 100644 > --- a/include/drm/ttm/ttm_bo.h > +++ b/include/drm/ttm/ttm_bo.h > @@ -421,6 +421,8 @@ void ttm_bo_unpin(struct ttm_buffer_object *bo); > int ttm_bo_evict_first(struct ttm_device *bdev, > struct ttm_resource_manager *man, > struct ttm_operation_ctx *ctx); > +int ttm_bo_access(struct ttm_buffer_object *bo, unsigned long offset, > + void *buf, int len, int write); > vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo, > struct vm_fault *vmf); > vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,

5 months, 3 weeks

2
2
0 0

[PATCH] Input: ads7846 - fix gpiod allocation

by H. Nikolaus Schaller

commit 767d83361aaa ("Input: ads7846 - Convert to use software nodes") has simplified the code but accidentially converted a devm_gpiod_get() to gpiod_get(). This leaves the gpio reserved on module remove and the driver can no longer be loaded again. Fixes: 767d83361aaa ("Input: ads7846 - Convert to use software nodes") Cc: <stable(a)vger.kernel.org> Signed-off-by: H. Nikolaus Schaller <hns(a)goldelico.com> --- drivers/input/touchscreen/ads7846.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c index 066dc04003fa8..67264c5b49cb4 100644 --- a/drivers/input/touchscreen/ads7846.c +++ b/drivers/input/touchscreen/ads7846.c @@ -1021,7 +1021,7 @@ static int ads7846_setup_pendown(struct spi_device *spi, if (pdata->get_pendown_state) { ts->get_pendown_state = pdata->get_pendown_state; } else { - ts->gpio_pendown = gpiod_get(&spi->dev, "pendown", GPIOD_IN); + ts->gpio_pendown = devm_gpiod_get(&spi->dev, "pendown", GPIOD_IN); if (IS_ERR(ts->gpio_pendown)) { dev_err(&spi->dev, "failed to request pendown GPIO\n"); return PTR_ERR(ts->gpio_pendown); -- 2.47.0

5 months, 3 weeks

2
1
0 0

[PATCH v2] tee: optee: Fix supplicant wait loop

by Sumit Garg

OP-TEE supplicant is a user-space daemon and it's possible for it being hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitetly waiting in an unkillable state. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover. Fixes: 4fb0a5eb364d ("tee: add OP-TEE driver") Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Changes in v2: - Switch to killable wait instead as suggested by Arnd instead of supplicant timeout. It atleast allow the client to wait for supplicant in killable state which in turn allows system to reboot or shutdown gracefully. drivers/tee/optee/supp.c | 32 +++++++------------------------- 1 file changed, 7 insertions(+), 25 deletions(-) diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c index 322a543b8c27..3fbfa9751931 100644 --- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -80,7 +80,6 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_supp *supp = &optee->supp; struct optee_supp_req *req; - bool interruptable; u32 ret; /* @@ -111,36 +110,19 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, /* * Wait for supplicant to process and return result, once we've * returned from wait_for_completion(&req->c) successfully we have - * exclusive access again. + * exclusive access again. Allow the wait to be killable such that + * the wait doesn't turn into an indefinite state if the supplicant + * gets hung for some reason. */ - while (wait_for_completion_interruptible(&req->c)) { - mutex_lock(&supp->mutex); - interruptable = !supp->ctx; - if (interruptable) { - /* - * There's no supplicant available and since the - * supp->mutex currently is held none can - * become available until the mutex released - * again. - * - * Interrupting an RPC to supplicant is only - * allowed as a way of slightly improving the user - * experience in case the supplicant hasn't been - * started yet. During normal operation the supplicant - * will serve all requests in a timely manner and - * interrupting then wouldn't make sense. - */ + if (wait_for_completion_killable(&req->c)) { + if (!mutex_lock_killable(&supp->mutex)) { if (req->in_queue) { list_del(&req->link); req->in_queue = false; } + mutex_unlock(&supp->mutex); } - mutex_unlock(&supp->mutex); - - if (interruptable) { - req->ret = TEEC_ERROR_COMMUNICATION; - break; - } + req->ret = TEEC_ERROR_COMMUNICATION; } ret = req->ret; -- 2.43.0

5 months, 3 weeks

3
5
0 0

[PATCH 6.13 00/25] 6.13.1-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.13.1 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 01 Feb 2025 13:34:42 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.13.1-rc1… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 6.13.1-rc1 Jack Greiner <jack(a)emoss.org> Input: xpad - add support for wooting two he (arm) Matheos Mattsson <matheos.mattsson(a)gmail.com> Input: xpad - add support for Nacon Evol-X Xbox One Controller Leonardo Brondani Schenkel <leonardo(a)schenkel.net> Input: xpad - improve name of 8BitDo controller 2dc8:3106 Pierre-Loup A. Griffais <pgriffais(a)valvesoftware.com> Input: xpad - add QH Electronics VID/PID Nilton Perim Neto <niltonperimneto(a)gmail.com> Input: xpad - add unofficial Xbox 360 wireless receiver clone Mark Pearson <mpearson-lenovo(a)squebb.ca> Input: atkbd - map F23 key to support default copilot shortcut Nicolas Nobelis <nicolas(a)nobelis.eu> Input: xpad - add support for Nacon Pro Compact Jann Horn <jannh(a)google.com> io_uring/rsrc: require cloned buffers to share accounting contexts Jason Gerecke <jason.gerecke(a)wacom.com> HID: wacom: Initialize brightness of LED trigger Hans de Goede <hdegoede(a)redhat.com> wifi: rtl8xxxu: add more missing rtl8192cu USB IDs Lianqin Hu <hulianqin(a)vivo.com> ALSA: usb-audio: Add delay quirk for USB Audio Device Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Revert "usb: gadget: u_serial: Disable ep before setting port to null to fix the crash caused by port being null" Qasim Ijaz <qasdev00(a)gmail.com> USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb() Easwar Hariharan <eahariha(a)linux.microsoft.com> scsi: storvsc: Ratelimit warning logs to prevent VM denial of service Alex Williamson <alex.williamson(a)redhat.com> vfio/platform: check the bounds of read/write syscalls Linus Torvalds <torvalds(a)linux-foundation.org> cachestat: fix page cache statistics permission checking Jiri Kosina <jikos(a)kernel.org> Revert "HID: multitouch: Add support for lenovo Y9000P Touchpad" Jamal Hadi Salim <jhs(a)mojatatu.com> net: sched: fix ets qdisc OOB Indexing Paulo Alcantara <pc(a)manguebit.com> smb: client: handle lack of EA support in smb2_query_path_info() Chuck Lever <chuck.lever(a)oracle.com> libfs: Use d_children list to iterate simple_offset directories Chuck Lever <chuck.lever(a)oracle.com> libfs: Replace simple_offset end-of-directory detection Chuck Lever <chuck.lever(a)oracle.com> Revert "libfs: fix infinite directory reads for offset dir" Chuck Lever <chuck.lever(a)oracle.com> Revert "libfs: Add simple_offset_empty()" Chuck Lever <chuck.lever(a)oracle.com> libfs: Return ENOSPC when the directory offset range is exhausted Andreas Gruenbacher <agruenba(a)redhat.com> gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag ------------- Diffstat: Makefile | 4 +- drivers/hid/hid-ids.h | 1 - drivers/hid/hid-multitouch.c | 8 +- drivers/hid/wacom_sys.c | 24 ++-- drivers/input/joystick/xpad.c | 9 +- drivers/input/keyboard/atkbd.c | 2 +- drivers/net/wireless/realtek/rtl8xxxu/core.c | 20 ++++ drivers/scsi/storvsc_drv.c | 8 +- drivers/usb/gadget/function/u_serial.c | 8 +- drivers/usb/serial/quatech2.c | 2 +- drivers/vfio/platform/vfio_platform_common.c | 10 ++ fs/gfs2/file.c | 1 + fs/libfs.c | 162 +++++++++++++-------------- fs/smb/client/smb2inode.c | 104 ++++++++++++----- include/linux/fs.h | 1 - io_uring/rsrc.c | 7 ++ mm/filemap.c | 17 +++ mm/shmem.c | 4 +- net/sched/sch_ets.c | 2 + sound/usb/quirks.c | 2 + 20 files changed, 251 insertions(+), 145 deletions(-)

5 months, 3 weeks

13
39
0 0

Re: Patch "drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayed" has been added to the 6.12-stable tree

by Thomas Hellström

Hi On Sat, 2025-02-01 at 23:33 -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayed > > to the 6.12-stable tree which can be found at: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > drm-xe-use-ttm_bo_access-in-xe_vm_snapshot_capture_d.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable > tree, > please let <stable(a)vger.kernel.org> know about it. Please avoid including this patch for now. It turned out it needs more dependencies and we will attempt a manual backport later. Thanks, Thomas > > > > commit 7aad4e92ca3782686571792d117b3ffcfe05c65c > Author: Matthew Brost <matthew.brost(a)intel.com> > Date: Tue Nov 26 09:46:13 2024 -0800 > > drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayed > > [ Upstream commit 5f7bec831f1f17c354e4307a12cf79b018296975 ] > > Non-contiguous mapping of BO in VRAM doesn't work, use > ttm_bo_access > instead. > > v2: > - Fix error handling > > Fixes: 0eb2a18a8fad ("drm/xe: Implement VM snapshot support for > BO's and userptr") > Suggested-by: Matthew Auld <matthew.auld(a)intel.com> > Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> > Reviewed-by: Matthew Auld <matthew.auld(a)intel.com> > Link: > https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-7-matt… > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c > index c99380271de62..c8782da3a5c38 100644 > --- a/drivers/gpu/drm/xe/xe_vm.c > +++ b/drivers/gpu/drm/xe/xe_vm.c > @@ -3303,7 +3303,6 @@ void xe_vm_snapshot_capture_delayed(struct > xe_vm_snapshot *snap) > > for (int i = 0; i < snap->num_snaps; i++) { > struct xe_bo *bo = snap->snap[i].bo; > - struct iosys_map src; > int err; > > if (IS_ERR(snap->snap[i].data)) > @@ -3316,16 +3315,12 @@ void xe_vm_snapshot_capture_delayed(struct > xe_vm_snapshot *snap) > } > > if (bo) { > - xe_bo_lock(bo, false); > - err = ttm_bo_vmap(&bo->ttm, &src); > - if (!err) { > - xe_map_memcpy_from(xe_bo_device(bo), > - snap- > >snap[i].data, > - &src, snap- > >snap[i].bo_ofs, > - snap- > >snap[i].len); > - ttm_bo_vunmap(&bo->ttm, &src); > - } > - xe_bo_unlock(bo); > + err = ttm_bo_access(&bo->ttm, snap- > >snap[i].bo_ofs, > + snap->snap[i].data, > snap->snap[i].len, 0); > + if (!(err < 0) && err != snap->snap[i].len) > + err = -EIO; > + else if (!(err < 0)) > + err = 0; > } else { > void __user *userptr = (void __user > *)(size_t)snap->snap[i].bo_ofs; >

5 months, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025