- Linux-stable-mirror - lists.linaro.org

[PATCH 6.6.y] smb: client: support kvec iterators in async read path

by Henrique Carvalho

commit 3ee1a1fc39819906f04d6c62c180e760cd3a689d upstream. Add cifs_limit_kvec_subset() and select the appropriate limiter in cifs_send_async_read() to handle kvec iterators in async read path, fixing the EIO bug when running executables in cifs shares mounted with nolease. This patch -- or equivalent patch, does not exist upstream, as the upstream code has suffered considerable API changes. The affected path is currently handled by netfs lib and located under netfs/direct_read.c. Reproducer: $ mount.cifs //server/share /mnt -o nolease $ cat - > /mnt/test.sh <<EOL echo hallo EOL $ chmod +x /mnt/test.sh $ /mnt/test.sh bash: /mnt/test.sh: /bin/bash: Defekter Interpreter: Eingabe-/Ausgabefehler $ rm -f /mnt/test.sh Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Reported-by: Laura Kerner <laura.kerner(a)ichaus.de> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1245449 Signed-off-by: Henrique Carvalho <henrique.carvalho(a)suse.com> --- fs/smb/client/file.c | 46 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) diff --git a/fs/smb/client/file.c b/fs/smb/client/file.c index d883ed75022c..4878c74bae6f 100644 --- a/fs/smb/client/file.c +++ b/fs/smb/client/file.c @@ -3527,6 +3527,42 @@ static size_t cifs_limit_bvec_subset(const struct iov_iter *iter, size_t max_siz return span; } +static size_t cifs_limit_kvec_subset(const struct iov_iter *iter, size_t max_size, + size_t max_segs, unsigned int *_nsegs) +{ + const struct kvec *kvecs = iter->kvec; + unsigned int nkv = iter->nr_segs, ix = 0, nsegs = 0; + size_t len, span = 0, n = iter->count; + size_t skip = iter->iov_offset; + + if (WARN_ON(!iov_iter_is_kvec(iter)) || n == 0) + return 0; + + while (n && ix < nkv && skip) { + len = kvecs[ix].iov_len; + if (skip < len) + break; + skip -= len; + n -= len; + ix++; + } + + while (n && ix < nkv) { + len = min3(n, kvecs[ix].iov_len - skip, max_size); + span += len; + max_size -= len; + nsegs++; + ix++; + if (max_size == 0 || nsegs >= max_segs) + break; + skip = 0; + n -= len; + } + + *_nsegs = nsegs; + return span; +} + static int cifs_write_from_iter(loff_t fpos, size_t len, struct iov_iter *from, struct cifsFileInfo *open_file, @@ -4079,6 +4115,13 @@ cifs_send_async_read(loff_t fpos, size_t len, struct cifsFileInfo *open_file, int rc; pid_t pid; struct TCP_Server_Info *server; + size_t (*limit_iov_subset)(const struct iov_iter *iter, size_t max_size, + size_t max_segs, unsigned int *_nsegs); + + if (iov_iter_is_kvec(&ctx->iter)) + limit_iov_subset = cifs_limit_kvec_subset; + else + limit_iov_subset = cifs_limit_bvec_subset; server = cifs_pick_channel(tlink_tcon(open_file->tlink)->ses); @@ -4113,8 +4156,7 @@ cifs_send_async_read(loff_t fpos, size_t len, struct cifsFileInfo *open_file, max_len = min_t(size_t, len, rsize); - cur_len = cifs_limit_bvec_subset(&ctx->iter, max_len, - max_segs, &nsegs); + cur_len = limit_iov_subset(&ctx->iter, max_len, max_segs, &nsegs); cifs_dbg(FYI, "read-to-iter len=%zx/%zx nsegs=%u/%lu/%u\n", cur_len, max_len, nsegs, ctx->iter.nr_segs, max_segs); if (cur_len == 0) { -- 2.47.0

1 day, 9 hours

5
6
0 0

[PATCH v3] drm/tilcdc: Fix removal actions in case of failed probe

by Kory Maincent

From: "Kory Maincent (TI.com)" <kory.maincent(a)bootlin.com> The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag. Cc: stable(a)vger.kernel.org Fixes: 3c4babae3c4a ("drm: Call drm_atomic_helper_shutdown() at shutdown/remove time for misc drivers") Signed-off-by: Kory Maincent (TI.com) <kory.maincent(a)bootlin.com> --- I'm working on removing the usage of deprecated functions as well as general improvements to this driver, but it will take some time so for now this is a simple fix to a functional bug. Change in v3: - Rewrite the failed probe clean up path using goto - Remove the is_registered flag Change in v2: - Add missing cc: stable tag - Add Swamil reviewed-by --- drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 53 ++++++++++++++++++---------- drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 +- 3 files changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c index 5718d9d83a49f..52c95131af5af 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c @@ -586,7 +586,7 @@ static void tilcdc_crtc_recover_work(struct work_struct *work) drm_modeset_unlock(&crtc->mutex); } -static void tilcdc_crtc_destroy(struct drm_crtc *crtc) +void tilcdc_crtc_destroy(struct drm_crtc *crtc) { struct tilcdc_drm_private *priv = crtc->dev->dev_private; diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 7caec4d38ddf0..2a88cce445b8f 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c @@ -172,8 +172,7 @@ static void tilcdc_fini(struct drm_device *dev) if (priv->crtc) tilcdc_crtc_shutdown(priv->crtc); - if (priv->is_registered) - drm_dev_unregister(dev); + drm_dev_unregister(dev); drm_kms_helper_poll_fini(dev); drm_atomic_helper_shutdown(dev); @@ -220,21 +219,21 @@ static int tilcdc_init(const struct drm_driver *ddrv, struct device *dev) priv->wq = alloc_ordered_workqueue("tilcdc", 0); if (!priv->wq) { ret = -ENOMEM; - goto init_failed; + goto put_drm; } priv->mmio = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(priv->mmio)) { dev_err(dev, "failed to request / ioremap\n"); ret = PTR_ERR(priv->mmio); - goto init_failed; + goto free_wq; } priv->clk = clk_get(dev, "fck"); if (IS_ERR(priv->clk)) { dev_err(dev, "failed to get functional clock\n"); ret = -ENODEV; - goto init_failed; + goto free_wq; } pm_runtime_enable(dev); @@ -313,7 +312,7 @@ static int tilcdc_init(const struct drm_driver *ddrv, struct device *dev) ret = tilcdc_crtc_create(ddev); if (ret < 0) { dev_err(dev, "failed to create crtc\n"); - goto init_failed; + goto disable_pm; } modeset_init(ddev); @@ -324,46 +323,46 @@ static int tilcdc_init(const struct drm_driver *ddrv, struct device *dev) if (ret) { dev_err(dev, "failed to register cpufreq notifier\n"); priv->freq_transition.notifier_call = NULL; - goto init_failed; + goto destroy_crtc; } #endif if (priv->is_componentized) { ret = component_bind_all(dev, ddev); if (ret < 0) - goto init_failed; + goto unregister_cpufreq_notif; ret = tilcdc_add_component_encoder(ddev); if (ret < 0) - goto init_failed; + goto unbind_component; } else { ret = tilcdc_attach_external_device(ddev); if (ret) - goto init_failed; + goto unregister_cpufreq_notif; } if (!priv->external_connector && ((priv->num_encoders == 0) || (priv->num_connectors == 0))) { dev_err(dev, "no encoders/connectors found\n"); ret = -EPROBE_DEFER; - goto init_failed; + goto unbind_component; } ret = drm_vblank_init(ddev, 1); if (ret < 0) { dev_err(dev, "failed to initialize vblank\n"); - goto init_failed; + goto unbind_component; } ret = platform_get_irq(pdev, 0); if (ret < 0) - goto init_failed; + goto unbind_component; priv->irq = ret; ret = tilcdc_irq_install(ddev, priv->irq); if (ret < 0) { dev_err(dev, "failed to install IRQ handler\n"); - goto init_failed; + goto unbind_component; } drm_mode_config_reset(ddev); @@ -372,16 +371,34 @@ static int tilcdc_init(const struct drm_driver *ddrv, struct device *dev) ret = drm_dev_register(ddev, 0); if (ret) - goto init_failed; - priv->is_registered = true; + goto stop_poll; drm_client_setup_with_color_mode(ddev, bpp); return 0; -init_failed: - tilcdc_fini(ddev); +stop_poll: + drm_kms_helper_poll_fini(ddev); + tilcdc_irq_uninstall(ddev); +unbind_component: + if (priv->is_componentized) + component_unbind_all(dev, ddev); +unregister_cpufreq_notif: +#ifdef CONFIG_CPU_FREQ + cpufreq_unregister_notifier(&priv->freq_transition, + CPUFREQ_TRANSITION_NOTIFIER); +#endif +destroy_crtc: + tilcdc_crtc_destroy(priv->crtc); +disable_pm: + pm_runtime_disable(dev); + clk_put(priv->clk); +free_wq: + destroy_workqueue(priv->wq); +put_drm: platform_set_drvdata(pdev, NULL); + ddev->dev_private = NULL; + drm_dev_put(ddev); return ret; } diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h b/drivers/gpu/drm/tilcdc/tilcdc_drv.h index b818448c83f61..58b276f82a669 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h @@ -82,7 +82,6 @@ struct tilcdc_drm_private { struct drm_encoder *external_encoder; struct drm_connector *external_connector; - bool is_registered; bool is_componentized; bool irq_enabled; }; @@ -164,6 +163,7 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc, void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc *crtc, bool simulate_vesa_sync); void tilcdc_crtc_shutdown(struct drm_crtc *crtc); +void tilcdc_crtc_destroy(struct drm_crtc *crtc); int tilcdc_crtc_update_fb(struct drm_crtc *crtc, struct drm_framebuffer *fb, struct drm_pending_vblank_event *event); -- 2.43.0

1 day, 9 hours

3
4
0 0

Great Original Shirts

by Spencer

1 day, 10 hours

1
0
0 0

[REGRESSION 6.12.y] hyper-v: BUG: kernel NULL pointer dereference, address: 00000000000000a0: RIP: 0010:hv_uio_channel_cb+0xd/0x20 [uio_hv_generic]

by Salvatore Bonaccorso

Peter Morrow reported in Debian a regression, reported in https://bugs.debian.org/1120602 . The regression was seen after updating, to 6.12.57-1 in Debian, but details on the offending commit follows. His report was as follows: > Dear Maintainer, > > I'm seeing a kernel crash quite soon after boot on a debian trixie based > system running 6.12.57+deb13-amd64, unfortunately the kernel panics before > I can access the system to gather more information. Thus I'll provide details > of the system using a previously known good version. The panic is happening > 100% of the time unfortunately. I have access to the serial console however > so can enable any required verbose logging during boot if necessary. > > Crucially the crash is not seen with kernel version 6.12.41+deb13-amd64 with the > same userspace. We had pinned to that version until very recently to in order > to work around https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109676 > > I'm running a dpdk application here (VPP) on Azure, VM form factor is a > "Standard DS3 v2 (4 vcpus, 14 GiB memory)". > > The only relevant upstream commit in this area (as far as I can see) is: > > https://lore.kernel.org/linux-hyperv/1bb599ee-fe28-409d-b430-2fc086268936@l… > > The comment regarding avoiding races at start adds a bit more weight behind this > hunch, though it's only a hunch as I am most definitely nowhere near an expert > in this area. > > -- Package-specific info: > > [ 19.625535] BUG: kernel NULL pointer dereference, address: 00000000000000a0 > [ 19.628874] #PF: supervisor read access in kernel mode > [ 19.630841] #PF: error_code(0x0000) - not-present page > [ 19.632788] PGD 0 P4D 0 > [ 19.633905] Oops: Oops: 0000 [#1] PREEMPT SMP PTI > [ 19.635586] CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.12.57+deb13-amd64 #1 Debian 6.12.57-1 > [ 19.640216] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 > [ 19.644514] RIP: 0010:hv_uio_channel_cb+0xd/0x20 [uio_hv_generic] > [ 19.646994] Code: 02 00 00 5b 5d e9 53 98 69 e9 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 47 10 <48> 8b b8 a0 00 00 00 f0 83 44 24 fc 00 e9 51 6f fa ff 90 90 90 90 > [ 19.654377] RSP: 0018:ffffb15ac01a4fa8 EFLAGS: 00010046 > [ 19.656385] RAX: 0000000000000000 RBX: 0000000000000015 RCX: 0000000000000015 > [ 19.659240] RDX: 0000000000000001 RSI: ffffffffffffffff RDI: ffff8ff69c759400 > [ 19.662168] RBP: ffff8ff548790200 R08: ffff8ff548790200 R09: 00fca75150b080e9 > [ 19.665239] R10: 0000000000000000 R11: ffffb15ac01a4ff8 R12: ffff8ff871dc1480 > [ 19.668193] R13: ffff8ff69c759400 R14: ffff8ff69c7596a0 R15: ffffffffc106e160 > [ 19.671106] FS: 0000000000000000(0000) GS:ffff8ff871d80000(0000) knlGS:0000000000000000 > [ 19.674281] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 19.676533] CR2: 00000000000000a0 CR3: 0000000100ba6003 CR4: 00000000003706f0 > [ 19.679385] Call Trace: > [ 19.680361] <IRQ> > [ 19.681181] vmbus_isr+0x1a5/0x210 [hv_vmbus] > [ 19.682916] __sysvec_hyperv_callback+0x32/0x60 > [ 19.684991] sysvec_hyperv_callback+0x6c/0x90 > [ 19.686665] </IRQ> > [ 19.687509] <TASK> > [ 19.688366] asm_sysvec_hyperv_callback+0x1a/0x20 > [ 19.690262] RIP: 0010:pv_native_safe_halt+0xf/0x20 > [ 19.692067] Code: 09 e9 c5 08 01 00 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d e5 3b 31 00 fb f4 <c3> cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 > [ 19.699119] RSP: 0018:ffffb15ac0103ed8 EFLAGS: 00000246 > [ 19.701412] RAX: 0000000000000003 RBX: ffff8ff5403b1fc0 RCX: ffff8ff54c64ce30 > [ 19.704328] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 000000000001f894 > [ 19.706910] RBP: 0000000000000003 R08: 000000000bb760d9 R09: 00fca75150b080e9 > [ 19.709762] R10: 0000000000000003 R11: 0000000000000001 R12: 0000000000000000 > [ 19.712510] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > [ 19.715173] default_idle+0x9/0x20 > [ 19.716846] default_idle_call+0x29/0x100 > [ 19.718623] do_idle+0x1fe/0x240 > [ 19.720045] cpu_startup_entry+0x29/0x30 > [ 19.721595] start_secondary+0x11e/0x140 > [ 19.723080] common_startup_64+0x13e/0x141 > [ 19.725222] </TASK> > [ 19.726387] Modules linked in: isofs cdrom uio_hv_generic uio binfmt_misc intel_rapl_msr intel_rapl_common intel_uncore_frequency_common isst_if_mbox_msr isst_if_common rpcrdma skx_edac_common nfit sunrpc libnvdimm crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 sha256_ssse3 rdma_ucm ib_iser sha1_ssse3 rdma_cm aesni_intel iw_cm gf128mul crypto_simd libiscsi cryptd ib_umad ib_ipoib scsi_transport_iscsi ib_cm rapl sg hv_utils hv_balloon evdev pcspkr joydev mpls_router ip_tunnel ramoops configfs pstore_blk efi_pstore pstore_zone nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs ip_tables x_tables autofs4 overlay squashfs dm_verity dm_bufio reed_solomon dm_mod loop ext4 crc16 mbcache jbd2 crc32c_generic mlx5_ib ib_uverbs ib_core mlx5_core mlxfw pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper sd_mod drm_kms_helper hv_storvsc scsi_transport_fc drm scsi_mod hid_generic hid_hyperv hid serio_raw hv_netvsc hyperv_keyboard scsi_common hv_vmbus > [ 19.726466] crc32_pclmul crc32c_intel > [ 19.765771] CR2: 00000000000000a0 > [ 19.767524] ---[ end trace 0000000000000000 ]--- > [ 19.800433] RIP: 0010:hv_uio_channel_cb+0xd/0x20 [uio_hv_generic] > [ 19.803170] Code: 02 00 00 5b 5d e9 53 98 69 e9 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 47 10 <48> 8b b8 a0 00 00 00 f0 83 44 24 fc 00 e9 51 6f fa ff 90 90 90 90 > [ 19.811041] RSP: 0018:ffffb15ac01a4fa8 EFLAGS: 00010046 > [ 19.813466] RAX: 0000000000000000 RBX: 0000000000000015 RCX: 0000000000000015 > [ 19.816504] RDX: 0000000000000001 RSI: ffffffffffffffff RDI: ffff8ff69c759400 > [ 19.819484] RBP: ffff8ff548790200 R08: ffff8ff548790200 R09: 00fca75150b080e9 > [ 19.822625] R10: 0000000000000000 R11: ffffb15ac01a4ff8 R12: ffff8ff871dc1480 > [ 19.825569] R13: ffff8ff69c759400 R14: ffff8ff69c7596a0 R15: ffffffffc106e160 > [ 19.828804] FS: 0000000000000000(0000) GS:ffff8ff871d80000(0000) knlGS:0000000000000000 > [ 19.832214] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 19.834709] CR2: 00000000000000a0 CR3: 0000000100ba6003 CR4: 00000000003706f0 > [ 19.837976] Kernel panic - not syncing: Fatal exception in interrupt > [ 19.841825] Kernel Offset: 0x28a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > [ 19.896620] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- > > > lspci output: > > Collected from a system that is not crashing (6.12.41+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.41-1 (2025-08-12) x86_64 GNU/Linux)... > > $ sudo lspci -v > 2f22:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] (rev 80) > Subsystem: Mellanox Technologies Device 0190 > Physical Slot: 3 > Flags: bus master, fast devsel, latency 0, NUMA node 0 > Memory at fe0100000 (64-bit, prefetchable) [size=1M] > Capabilities: [60] Express Endpoint, IntMsgNum 0 > Capabilities: [9c] MSI-X: Enable+ Count=8 Masked- > Kernel driver in use: mlx5_core > Kernel modules: mlx5_core > > 52f7:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] (rev 80) > Subsystem: Mellanox Technologies Device 0190 > Physical Slot: 2 > Flags: bus master, fast devsel, latency 0, NUMA node 0 > Memory at fe0000000 (64-bit, prefetchable) [size=1M] > Capabilities: [60] Express Endpoint, IntMsgNum 0 > Capabilities: [9c] MSI-X: Enable+ Count=8 Masked- > Kernel driver in use: mlx5_core > Kernel modules: mlx5_core > > 7852:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] (rev 80) > Subsystem: Mellanox Technologies Device 0190 > Physical Slot: 4 > Flags: bus master, fast devsel, latency 0, NUMA node 0 > Memory at fe0200000 (64-bit, prefetchable) [size=1M] > Capabilities: [60] Express Endpoint, IntMsgNum 0 > Capabilities: [9c] MSI-X: Enable+ Count=8 Masked- > Kernel driver in use: mlx5_core > Kernel modules: mlx5_core > > dmidecode output: > > $ sudo dmidecode > # dmidecode 3.6 > Getting SMBIOS data from sysfs. > SMBIOS 3.1.0 present. > Table at 0x3FF82000. > > Handle 0x0000, DMI type 0, 26 bytes > BIOS Information > Vendor: Microsoft Corporation > Version: Hyper-V UEFI Release v4.1 > Release Date: 05/13/2024 > ROM Size: 64 kB > Characteristics: > BIOS characteristics not supported > ACPI is supported > Targeted content distribution is supported > UEFI is supported > System is a virtual machine > BIOS Revision: 4.1 > > Handle 0x0001, DMI type 1, 27 bytes > System Information > Manufacturer: Microsoft Corporation > Product Name: Virtual Machine > Version: Hyper-V UEFI Release v4.1 > Serial Number: 0000-0010-5437-9499-5225-4477-46 > UUID: 925315af-4af4-4d42-915a-1516b5a1fe5c > Wake-up Type: Power Switch > SKU Number: None > Family: Virtual Machine > > Handle 0x0002, DMI type 3, 24 bytes > Chassis Information > Manufacturer: Microsoft Corporation > Type: Desktop > Lock: Not Present > Version: Hyper-V UEFI Release v4.1 > Serial Number: 2466-9316-1078-9783-6078-7718-80 > Asset Tag: 7783-7084-3265-9085-8269-3286-77 > Boot-up State: Safe > Power Supply State: Safe > Thermal State: Safe > Security Status: Unknown > OEM Information: 0x00000000 > Height: Unspecified > Number Of Power Cords: Unspecified > Contained Elements: 0 > SKU Number: Virtual Machine > > Handle 0x0003, DMI type 2, 17 bytes > Base Board Information > Manufacturer: Microsoft Corporation > Product Name: Virtual Machine > Version: Hyper-V UEFI Release v4.1 > Serial Number: 0000-0010-4737-0707-0684-2660-76 > Asset Tag: None > Features: > Board is a hosting board > Location In Chassis: Virtual Machine > Chassis Handle: 0x0002 > Type: Motherboard > Contained Object Handles: 0 > > Handle 0x0004, DMI type 4, 48 bytes > Processor Information > Socket Designation: None > Type: Central Processor > Family: Unknown > Manufacturer: None > ID: 00 00 00 00 00 00 00 00 > Version: None > Voltage: Unknown > External Clock: Unknown > Max Speed: Unknown > Current Speed: Unknown > Status: Unpopulated > Upgrade: Other > L1 Cache Handle: Not Provided > L2 Cache Handle: Not Provided > L3 Cache Handle: Not Provided > Serial Number: None > Asset Tag: None > Part Number: None > Core Count: 4 > Core Enabled: 4 > Thread Count: 1 > Characteristics: None > > Handle 0x0005, DMI type 11, 5 bytes > OEM Strings > String 1: [MS_VM_CERT/SHA1/9b80ca0d5dd061ec9da4e494f4c3fd1196270c22] > String 2: None > String 3: To be filled by OEM > > Handle 0x0006, DMI type 16, 23 bytes > Physical Memory Array > Location: System Board Or Motherboard > Use: System Memory > Error Correction Type: None > Maximum Capacity: 0 bytes > Error Information Handle: Not Provided > Number Of Devices: 3 > > Handle 0x0007, DMI type 17, 92 bytes > Memory Device > Array Handle: 0x0006 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 26 MB > Form Factor: Unknown > Set: None > Locator: M0001 > Bank Locator: None > Type: Unknown > Type Detail: Unknown > Speed: Unknown > Manufacturer: Microsoft Corporation > Serial Number: None > Asset Tag: None > Part Number: None > Rank: Unknown > Configured Memory Speed: Unknown > Minimum Voltage: Unknown > Maximum Voltage: Unknown > Configured Voltage: Unknown > Memory Technology: <OUT OF SPEC> > Memory Operating Mode Capability: None > Firmware Version: Not Specified > Module Manufacturer ID: Unknown > Module Product ID: Unknown > Memory Subsystem Controller Manufacturer ID: Unknown > Memory Subsystem Controller Product ID: Unknown > Non-Volatile Size: None > Volatile Size: None > Cache Size: None > Logical Size: None > > Handle 0x0008, DMI type 19, 31 bytes > Memory Array Mapped Address > Starting Address: 0x00000000000 > Ending Address: 0x00001A003FF > Range Size: 26625 kB > Physical Array Handle: 0x0006 > Partition Width: 0 > > Handle 0x0009, DMI type 20, 35 bytes > Memory Device Mapped Address > Starting Address: 0x00000000000 > Ending Address: 0x00001A003FF > Range Size: 26625 kB > Physical Device Handle: 0x0007 > Memory Array Mapped Address Handle: 0x0008 > Partition Row Position: Unknown > > Handle 0x000A, DMI type 17, 92 bytes > Memory Device > Array Handle: 0x0006 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 948 MB > Form Factor: Unknown > Set: None > Locator: M0002 > Bank Locator: None > Type: Unknown > Type Detail: Unknown > Speed: Unknown > Manufacturer: Microsoft Corporation > Serial Number: None > Asset Tag: None > Part Number: None > Rank: Unknown > Configured Memory Speed: Unknown > Minimum Voltage: Unknown > Maximum Voltage: Unknown > Configured Voltage: Unknown > Memory Technology: <OUT OF SPEC> > Memory Operating Mode Capability: None > Firmware Version: Not Specified > Module Manufacturer ID: Unknown > Module Product ID: Unknown > Memory Subsystem Controller Manufacturer ID: Unknown > Memory Subsystem Controller Product ID: Unknown > Non-Volatile Size: None > Volatile Size: None > Cache Size: None > Logical Size: None > > Handle 0x000B, DMI type 19, 31 bytes > Memory Array Mapped Address > Starting Address: 0x00004C00000 > Ending Address: 0x000400003FF > Range Size: 970753 kB > Physical Array Handle: 0x0006 > Partition Width: 0 > > Handle 0x000C, DMI type 20, 35 bytes > Memory Device Mapped Address > Starting Address: 0x00004C00000 > Ending Address: 0x000400003FF > Range Size: 970753 kB > Physical Device Handle: 0x000A > Memory Array Mapped Address Handle: 0x000B > Partition Row Position: Unknown > > Handle 0x000D, DMI type 17, 92 bytes > Memory Device > Array Handle: 0x0006 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 13 GB > Form Factor: Unknown > Set: None > Locator: M0003 > Bank Locator: None > Type: Unknown > Type Detail: Unknown > Speed: Unknown > Manufacturer: Microsoft Corporation > Serial Number: None > Asset Tag: None > Part Number: None > Rank: Unknown > Configured Memory Speed: Unknown > Minimum Voltage: Unknown > Maximum Voltage: Unknown > Configured Voltage: Unknown > Memory Technology: <OUT OF SPEC> > Memory Operating Mode Capability: None > Firmware Version: Not Specified > Module Manufacturer ID: Unknown > Module Product ID: Unknown > Memory Subsystem Controller Manufacturer ID: Unknown > Memory Subsystem Controller Product ID: Unknown > Non-Volatile Size: None > Volatile Size: None > Cache Size: None > Logical Size: None > > Handle 0x000E, DMI type 19, 31 bytes > Memory Array Mapped Address > Starting Address: 0x00100000000 > Ending Address: 0x004400003FF > Range Size: 13 GB > Physical Array Handle: 0x0006 > Partition Width: 0 > > Handle 0x000F, DMI type 20, 35 bytes > Memory Device Mapped Address > Starting Address: 0x00100000000 > Ending Address: 0x004400003FF > Range Size: 13 GB > Physical Device Handle: 0x000D > Memory Array Mapped Address Handle: 0x000E > Partition Row Position: Unknown > > Handle 0x0010, DMI type 32, 11 bytes > System Boot Information > Status: No errors detected > > Handle 0xFEFF, DMI type 127, 4 bytes > End Of Table The offending commit appers to be the backport of b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of interrupt mask") for 6.12.y. Peter confirmed that reverting this commit on top of 6.12.57-1 as packaged in Debian resolves indeed the issue. Interestingly the issue is *not* seen with 6.17.7 based kernel in Debian. #regzbot introduced: 37bd91f22794dc05436130d6983302cb90ecfe7e #regzbot monitor: https://bugs.debian.org/1120602 Thank you already! Regards, Salvatore

1 day, 10 hours

3
6
0 0

[PATCH printk v2 0/2] Fix reported suspend failures

by John Ogness

This is v2 of a series to address multiple reports [0][1] (+ 2 offlist) of suspend failing when NBCON console drivers are in use. With the help of NXP and NVIDIA we were able to isolate the problem and verify the fix. v1 is here [2]. The first NBCON drivers appeared in 6.13, so currently there is no LTS kernel that requires this series. But it should go into 6.17.x and 6.18. The changes since v1: - For printk_trigger_flush() add support for all flush types that are available. This will prevent printk_trigger_flush() from trying to inappropriately queue irq_work after this series is applied. - Add WARN_ON_ONCE() to the printk irq_work queueing functions in case they are called when irq_work is blocked. There should never be (and currently are no) such callers, but these functions are externally available. John Ogness [0] https://lore.kernel.org/lkml/80b020fc-c18a-4da4-b222-16da1cab2f4c@nvidia.com [1] https://lore.kernel.org/lkml/DB9PR04MB8429E7DDF2D93C2695DE401D92C4A@DB9PR04… [2] https://lore.kernel.org/lkml/20251111144328.887159-1-john.ogness@linutronix… John Ogness (2): printk: Allow printk_trigger_flush() to flush all types printk: Avoid scheduling irq_work on suspend kernel/printk/internal.h | 8 ++-- kernel/printk/nbcon.c | 9 ++++- kernel/printk/printk.c | 81 ++++++++++++++++++++++++++++++++-------- 3 files changed, 78 insertions(+), 20 deletions(-) base-commit: e9a6fb0bcdd7609be6969112f3fbfcce3b1d4a7c -- 2.47.3

1 day, 10 hours

6
14
0 0

FAILED: patch "[PATCH] xfs: fix various problems in xfs_atomic_write_cow_iomap_begin" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.17.y git checkout FETCH_HEAD git cherry-pick -x 8d7bba1e8314013ecc817a91624104ceb9352ddc # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110942-language-suspect-13bc@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8d7bba1e8314013ecc817a91624104ceb9352ddc Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" <djwong(a)kernel.org> Date: Tue, 4 Nov 2025 16:15:38 -0800 Subject: [PATCH] xfs: fix various problems in xfs_atomic_write_cow_iomap_begin I think there are several things wrong with this function: A) xfs_bmapi_write can return a much larger unwritten mapping than what the caller asked for. We convert part of that range to written, but return the entire written mapping to iomap even though that's inaccurate. B) The arguments to xfs_reflink_convert_cow_locked are wrong -- an unwritten mapping could be *smaller* than the write range (or even the hole range). In this case, we convert too much file range to written state because we then return a smaller mapping to iomap. C) It doesn't handle delalloc mappings. This I covered in the patch that I already sent to the list. D) Reassigning count_fsb to handle the hole means that if the second cmap lookup attempt succeeds (due to racing with someone else) we trim the mapping more than is strictly necessary. The changing meaning of count_fsb makes this harder to notice. E) The tracepoint is kinda wrong because @length is mutated. That makes it harder to chase the data flows through this function because you can't just grep on the pos/bytecount strings. F) We don't actually check that the br_state = XFS_EXT_NORM assignment is accurate, i.e that the cow fork actually contains a written mapping for the range we're interested in G) Somewhat inadequate documentation of why we need to xfs_trim_extent so aggressively in this function. H) Not sure why xfs_iomap_end_fsb is used here, the vfs already clamped the write range to s_maxbytes. Fix these issues, and then the atomic writes regressions in generic/760, generic/617, generic/091, generic/263, and generic/521 all go away for me. Cc: stable(a)vger.kernel.org # v6.16 Fixes: bd1d2c21d5d249 ("xfs: add xfs_atomic_write_cow_iomap_begin()") Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: John Garry <john.g.garry(a)oracle.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 788bfdce608a..490e12cb99be 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -1091,6 +1091,29 @@ const struct iomap_ops xfs_zoned_direct_write_iomap_ops = { }; #endif /* CONFIG_XFS_RT */ +#ifdef DEBUG +static void +xfs_check_atomic_cow_conversion( + struct xfs_inode *ip, + xfs_fileoff_t offset_fsb, + xfs_filblks_t count_fsb, + const struct xfs_bmbt_irec *cmap) +{ + struct xfs_iext_cursor icur; + struct xfs_bmbt_irec cmap2 = { }; + + if (xfs_iext_lookup_extent(ip, ip->i_cowfp, offset_fsb, &icur, &cmap2)) + xfs_trim_extent(&cmap2, offset_fsb, count_fsb); + + ASSERT(cmap2.br_startoff == cmap->br_startoff); + ASSERT(cmap2.br_blockcount == cmap->br_blockcount); + ASSERT(cmap2.br_startblock == cmap->br_startblock); + ASSERT(cmap2.br_state == cmap->br_state); +} +#else +# define xfs_check_atomic_cow_conversion(...) ((void)0) +#endif + static int xfs_atomic_write_cow_iomap_begin( struct inode *inode, @@ -1102,9 +1125,10 @@ xfs_atomic_write_cow_iomap_begin( { struct xfs_inode *ip = XFS_I(inode); struct xfs_mount *mp = ip->i_mount; - const xfs_fileoff_t offset_fsb = XFS_B_TO_FSBT(mp, offset); - xfs_fileoff_t end_fsb = xfs_iomap_end_fsb(mp, offset, length); - xfs_filblks_t count_fsb = end_fsb - offset_fsb; + const xfs_fileoff_t offset_fsb = XFS_B_TO_FSBT(mp, offset); + const xfs_fileoff_t end_fsb = XFS_B_TO_FSB(mp, offset + length); + const xfs_filblks_t count_fsb = end_fsb - offset_fsb; + xfs_filblks_t hole_count_fsb; int nmaps = 1; xfs_filblks_t resaligned; struct xfs_bmbt_irec cmap; @@ -1143,14 +1167,20 @@ xfs_atomic_write_cow_iomap_begin( if (cmap.br_startoff <= offset_fsb) { if (isnullstartblock(cmap.br_startblock)) goto convert_delay; + + /* + * cmap could extend outside the write range due to previous + * speculative preallocations. We must trim cmap to the write + * range because the cow fork treats written mappings to mean + * "write in progress". + */ xfs_trim_extent(&cmap, offset_fsb, count_fsb); goto found; } - end_fsb = cmap.br_startoff; - count_fsb = end_fsb - offset_fsb; + hole_count_fsb = cmap.br_startoff - offset_fsb; - resaligned = xfs_aligned_fsb_count(offset_fsb, count_fsb, + resaligned = xfs_aligned_fsb_count(offset_fsb, hole_count_fsb, xfs_get_cowextsz_hint(ip)); xfs_iunlock(ip, XFS_ILOCK_EXCL); @@ -1186,7 +1216,7 @@ xfs_atomic_write_cow_iomap_begin( * atomic writes to that same range will be aligned (and don't require * this COW-based method). */ - error = xfs_bmapi_write(tp, ip, offset_fsb, count_fsb, + error = xfs_bmapi_write(tp, ip, offset_fsb, hole_count_fsb, XFS_BMAPI_COWFORK | XFS_BMAPI_PREALLOC | XFS_BMAPI_EXTSZALIGN, 0, &cmap, &nmaps); if (error) { @@ -1199,17 +1229,26 @@ xfs_atomic_write_cow_iomap_begin( if (error) goto out_unlock; + /* + * cmap could map more blocks than the range we passed into bmapi_write + * because of EXTSZALIGN or adjacent pre-existing unwritten mappings + * that were merged. Trim cmap to the original write range so that we + * don't convert more than we were asked to do for this write. + */ + xfs_trim_extent(&cmap, offset_fsb, count_fsb); + found: if (cmap.br_state != XFS_EXT_NORM) { - error = xfs_reflink_convert_cow_locked(ip, offset_fsb, - count_fsb); + error = xfs_reflink_convert_cow_locked(ip, cmap.br_startoff, + cmap.br_blockcount); if (error) goto out_unlock; cmap.br_state = XFS_EXT_NORM; + xfs_check_atomic_cow_conversion(ip, offset_fsb, count_fsb, + &cmap); } - length = XFS_FSB_TO_B(mp, cmap.br_startoff + cmap.br_blockcount); - trace_xfs_iomap_found(ip, offset, length - offset, XFS_COW_FORK, &cmap); + trace_xfs_iomap_found(ip, offset, length, XFS_COW_FORK, &cmap); seq = xfs_iomap_inode_sequence(ip, IOMAP_F_SHARED); xfs_iunlock(ip, XFS_ILOCK_EXCL); return xfs_bmbt_to_iomap(ip, iomap, &cmap, flags, IOMAP_F_SHARED, seq);

1 day, 10 hours

3
4
0 0

FAILED: patch "[PATCH] scripts/decode_stacktrace.sh: fix build ID and PC source" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.17.y git checkout FETCH_HEAD git cherry-pick -x 7d9f7d390f6af3a29614e81e802e2b9c238eb7b2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112031-catalyze-sleep-ba6e@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7d9f7d390f6af3a29614e81e802e2b9c238eb7b2 Mon Sep 17 00:00:00 2001 From: Carlos Llamas <cmllamas(a)google.com> Date: Thu, 30 Oct 2025 01:03:33 +0000 Subject: [PATCH] scripts/decode_stacktrace.sh: fix build ID and PC source parsing Support for parsing PC source info in stacktraces (e.g. '(P)') was added in commit 2bff77c665ed ("scripts/decode_stacktrace.sh: fix decoding of lines with an additional info"). However, this logic was placed after the build ID processing. This incorrect order fails to parse lines containing both elements, e.g.: drm_gem_mmap_obj+0x114/0x200 [drm 03d0564e0529947d67bb2008c3548be77279fd27] (P) This patch fixes the problem by extracting the PC source info first and then processing the module build ID. With this change, the line above is now properly parsed as such: drm_gem_mmap_obj (./include/linux/mmap_lock.h:212 ./include/linux/mm.h:811 drivers/gpu/drm/drm_gem.c:1177) drm (P) While here, also add a brief explanation the build ID section. Link: https://lkml.kernel.org/r/20251030010347.2731925-1-cmllamas@google.com Fixes: 2bff77c665ed ("scripts/decode_stacktrace.sh: fix decoding of lines with an additional info") Signed-off-by: Carlos Llamas <cmllamas(a)google.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Reviewed-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> Cc: Breno Leitao <leitao(a)debian.org> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Marc Rutland <mark.rutland(a)arm.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Matthieu Baerts <matttbe(a)kernel.org> Cc: Miroslav Benes <mbenes(a)suse.cz> Cc: Puranjay Mohan <puranjay(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh index c73cb802a0a3..8d01b741de62 100755 --- a/scripts/decode_stacktrace.sh +++ b/scripts/decode_stacktrace.sh @@ -277,12 +277,6 @@ handle_line() { fi done - if [[ ${words[$last]} =~ ^[0-9a-f]+\] ]]; then - words[$last-1]="${words[$last-1]} ${words[$last]}" - unset words[$last] spaces[$last] - last=$(( $last - 1 )) - fi - # Extract info after the symbol if present. E.g.: # func_name+0x54/0x80 (P) # ^^^ @@ -295,6 +289,14 @@ handle_line() { last=$(( $last - 1 )) fi + # Join module name with its build id if present, as these were + # split during tokenization (e.g. "[module" and "modbuildid]"). + if [[ ${words[$last]} =~ ^[0-9a-f]+\] ]]; then + words[$last-1]="${words[$last-1]} ${words[$last]}" + unset words[$last] spaces[$last] + last=$(( $last - 1 )) + fi + if [[ ${words[$last]} =~ \[([^]]+)\] ]]; then module=${words[$last]} # some traces format is "(%pS)", which like "(foo+0x0/0x1 [bar])"

1 day, 10 hours

3
2
0 0

[PATCH] x86/mce: Handle AMD threshold interrupt storms

by Avadhut Naik

From: Smita Koralahalli <Smita.KoralahalliChannabasappa(a)amd.com> Extend the logic of handling CMCI storms to AMD threshold interrupts. Rely on the similar approach as of Intel's CMCI to mitigate storms per CPU and per bank. But, unlike CMCI, do not set thresholds and reduce interrupt rate on a storm. Rather, disable the interrupt on the corresponding CPU and bank. Re-enable back the interrupts if enough consecutive polls of the bank show no corrected errors (30, as programmed by Intel). Turning off the threshold interrupts would be a better solution on AMD systems as other error severities will still be handled even if the threshold interrupts are disabled. Also, AMD systems currently allow banks to be managed by both polling and interrupts. So don't modify the polling banks set after a storm ends. [Tony: Small tweak because mce_handle_storm() isn't a pointer now] [Yazen: Rebase and simplify] Stable backport notes: 1. Currently, when a Machine check interrupt storm is detected, the bank's corresponding bit in mce_poll_banks per-CPU variable is cleared by cmci_storm_end(). As a result, on AMD's SMCA systems, errors injected or encountered after the storm subsides are not logged since polling on that bank has been disabled. Polling banks set on AMD systems should not be modified when a storm subsides. 2. This patch is a snippet from the CMCI storm handling patch (link below) that has been accepted into tip for v6.19. While backporting the patch would have been the preferred way, the same cannot be undertaken since its part of a larger set. As such, this fix will be temporary. When the original patch and its set is integrated into stable, this patch should be reverted. Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa(a)amd.com> Signed-off-by: Tony Luck <tony.luck(a)intel.com> Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Link: https://lore.kernel.org/20251104-wip-mca-updates-v8-0-66c8eacf67b9@amd.com Signed-off-by: Avadhut Naik <avadhut.naik(a)amd.com> --- This is somewhat of a new scenario for me. Not really sure about the procedure. Hence, haven't modified the commit message and removed the tags. If required, will rework both. Also, while this issue can be encountered on AMD systems using v6.8 and later stable kernels, we would specifically prefer for this fix to be backported to v6.12 since its LTS. --- arch/x86/kernel/cpu/mce/threshold.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/mce/threshold.c b/arch/x86/kernel/cpu/mce/threshold.c index f4a007616468..61eaa1774931 100644 --- a/arch/x86/kernel/cpu/mce/threshold.c +++ b/arch/x86/kernel/cpu/mce/threshold.c @@ -85,7 +85,8 @@ void cmci_storm_end(unsigned int bank) { struct mca_storm_desc *storm = this_cpu_ptr(&storm_desc); - __clear_bit(bank, this_cpu_ptr(mce_poll_banks)); + if (!mce_flags.amd_threshold) + __clear_bit(bank, this_cpu_ptr(mce_poll_banks)); storm->banks[bank].history = 0; storm->banks[bank].in_storm_mode = false; base-commit: 8b690556d8fe074b4f9835075050fba3fb180e93 -- 2.43.0

1 day, 10 hours

5
8
0 0

[PATCH v2] iommu/amd: Relay __modify_irte_ga() error in modify_irte_ga()

by Jinhui Guo

The return type of __modify_irte_ga() is int, but modify_irte_ga() treats it as a bool. Casting the int to bool discards the error code. To fix the issue, change the type of ret to int in modify_irte_ga(). Fixes: 57cdb720eaa5 ("iommu/amd: Do not flush IRTE when only updating isRun and destination fields") Cc: stable(a)vger.kernel.org Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> Reviewed-by: Ankit Soni <Ankit.Soni(a)amd.com> --- v1: https://lore.kernel.org/all/20251120154725.435-1-guojinhui.liam@bytedance.c… Changelog in v1 -> v2 (suggested by Ankit Soni) - Trim subject line to the recommanded length drivers/iommu/amd/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index 2e1865daa1ce..a38304f1a8df 100644 --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -3354,7 +3354,7 @@ static int __modify_irte_ga(struct amd_iommu *iommu, u16 devid, int index, static int modify_irte_ga(struct amd_iommu *iommu, u16 devid, int index, struct irte_ga *irte) { - bool ret; + int ret; ret = __modify_irte_ga(iommu, devid, index, irte); if (ret) -- 2.20.1

1 day, 12 hours

2
1
0 0

[PATCH] iommu/amd: Propagate the error code returned by __modify_irte_ga() in modify_irte_ga()

by Jinhui Guo

The return type of __modify_irte_ga() is int, but modify_irte_ga() treats it as a bool. Casting the int to bool discards the error code. To fix the issue, change the type of ret to int in modify_irte_ga(). Fixes: 57cdb720eaa5 ("iommu/amd: Do not flush IRTE when only updating isRun and destination fields") Cc: stable(a)vger.kernel.org Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> --- drivers/iommu/amd/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index 2e1865daa1ce..a38304f1a8df 100644 --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -3354,7 +3354,7 @@ static int __modify_irte_ga(struct amd_iommu *iommu, u16 devid, int index, static int modify_irte_ga(struct amd_iommu *iommu, u16 devid, int index, struct irte_ga *irte) { - bool ret; + int ret; ret = __modify_irte_ga(iommu, devid, index, irte); if (ret) -- 2.20.1

1 day, 12 hours

3
2
0 0

FAILED: patch "[PATCH] eventpoll: Replace rwlock with spinlock" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 0c43094f8cc9d3d99d835c0ac9c4fe1ccc62babd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101616-causal-numerator-0c1e@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0c43094f8cc9d3d99d835c0ac9c4fe1ccc62babd Mon Sep 17 00:00:00 2001 From: Nam Cao <namcao(a)linutronix.de> Date: Tue, 15 Jul 2025 14:46:34 +0200 Subject: [PATCH] eventpoll: Replace rwlock with spinlock The ready event list of an epoll object is protected by read-write semaphore: - The consumer (waiter) acquires the write lock and takes items. - the producer (waker) takes the read lock and adds items. The point of this design is enabling epoll to scale well with large number of producers, as multiple producers can hold the read lock at the same time. Unfortunately, this implementation may cause scheduling priority inversion problem. Suppose the consumer has higher scheduling priority than the producer. The consumer needs to acquire the write lock, but may be blocked by the producer holding the read lock. Since read-write semaphore does not support priority-boosting for the readers (even with CONFIG_PREEMPT_RT=y), we have a case of priority inversion: a higher priority consumer is blocked by a lower priority producer. This problem was reported in [1]. Furthermore, this could also cause stall problem, as described in [2]. Fix this problem by replacing rwlock with spinlock. This reduces the event bandwidth, as the producers now have to contend with each other for the spinlock. According to the benchmark from https://github.com/rouming/test-tools/blob/master/stress-epoll.c: On 12 x86 CPUs: Before After Diff threads events/ms events/ms 8 7162 4956 -31% 16 8733 5383 -38% 32 7968 5572 -30% 64 10652 5739 -46% 128 11236 5931 -47% On 4 riscv CPUs: Before After Diff threads events/ms events/ms 8 2958 2833 -4% 16 3323 3097 -7% 32 3451 3240 -6% 64 3554 3178 -11% 128 3601 3235 -10% Although the numbers look bad, it should be noted that this benchmark creates multiple threads who do nothing except constantly generating new epoll events, thus contention on the spinlock is high. For real workload, the event rate is likely much lower, and the performance drop is not as bad. Using another benchmark (perf bench epoll wait) where spinlock contention is lower, improvement is even observed on x86: On 12 x86 CPUs: Before: Averaged 110279 operations/sec (+- 1.09%), total secs = 8 After: Averaged 114577 operations/sec (+- 2.25%), total secs = 8 On 4 riscv CPUs: Before: Averaged 175767 operations/sec (+- 0.62%), total secs = 8 After: Averaged 167396 operations/sec (+- 0.23%), total secs = 8 In conclusion, no one is likely to be upset over this change. After all, spinlock was used originally for years, and the commit which converted to rwlock didn't mention a real workload, just that the benchmark numbers are nice. This patch is not exactly the revert of commit a218cc491420 ("epoll: use rwlock in order to reduce ep_poll_callback() contention"), because git revert conflicts in some places which are not obvious on the resolution. This patch is intended to be backported, therefore go with the obvious approach: - Replace rwlock_t with spinlock_t one to one - Delete list_add_tail_lockless() and chain_epi_lockless(). These were introduced to allow producers to concurrently add items to the list. But now that spinlock no longer allows producers to touch the event list concurrently, these two functions are not necessary anymore. Fixes: a218cc491420 ("epoll: use rwlock in order to reduce ep_poll_callback() contention") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Link: https://lore.kernel.org/ec92458ea357ec503c737ead0f10b2c6e4c37d47.1752581388… Tested-by: K Prateek Nayak <kprateek.nayak(a)amd.com> Cc: stable(a)vger.kernel.org Reported-by: Frederic Weisbecker <frederic(a)kernel.org> Closes: https://lore.kernel.org/linux-rt-users/20210825132754.GA895675@lothringen/ [1] Reported-by: Valentin Schneider <vschneid(a)redhat.com> Closes: https://lore.kernel.org/linux-rt-users/xhsmhttqvnall.mognet@vschneid.remote… [2] Signed-off-by: Christian Brauner <brauner(a)kernel.org> diff --git a/fs/eventpoll.c b/fs/eventpoll.c index b22d6f819f78..ee7c4b683ec3 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -46,10 +46,10 @@ * * 1) epnested_mutex (mutex) * 2) ep->mtx (mutex) - * 3) ep->lock (rwlock) + * 3) ep->lock (spinlock) * * The acquire order is the one listed above, from 1 to 3. - * We need a rwlock (ep->lock) because we manipulate objects + * We need a spinlock (ep->lock) because we manipulate objects * from inside the poll callback, that might be triggered from * a wake_up() that in turn might be called from IRQ context. * So we can't sleep inside the poll callback and hence we need @@ -195,7 +195,7 @@ struct eventpoll { struct list_head rdllist; /* Lock which protects rdllist and ovflist */ - rwlock_t lock; + spinlock_t lock; /* RB tree root used to store monitored fd structs */ struct rb_root_cached rbr; @@ -741,10 +741,10 @@ static void ep_start_scan(struct eventpoll *ep, struct list_head *txlist) * in a lockless way. */ lockdep_assert_irqs_enabled(); - write_lock_irq(&ep->lock); + spin_lock_irq(&ep->lock); list_splice_init(&ep->rdllist, txlist); WRITE_ONCE(ep->ovflist, NULL); - write_unlock_irq(&ep->lock); + spin_unlock_irq(&ep->lock); } static void ep_done_scan(struct eventpoll *ep, @@ -752,7 +752,7 @@ static void ep_done_scan(struct eventpoll *ep, { struct epitem *epi, *nepi; - write_lock_irq(&ep->lock); + spin_lock_irq(&ep->lock); /* * During the time we spent inside the "sproc" callback, some * other events might have been queued by the poll callback. @@ -793,7 +793,7 @@ static void ep_done_scan(struct eventpoll *ep, wake_up(&ep->wq); } - write_unlock_irq(&ep->lock); + spin_unlock_irq(&ep->lock); } static void ep_get(struct eventpoll *ep) @@ -868,10 +868,10 @@ static bool __ep_remove(struct eventpoll *ep, struct epitem *epi, bool force) rb_erase_cached(&epi->rbn, &ep->rbr); - write_lock_irq(&ep->lock); + spin_lock_irq(&ep->lock); if (ep_is_linked(epi)) list_del_init(&epi->rdllink); - write_unlock_irq(&ep->lock); + spin_unlock_irq(&ep->lock); wakeup_source_unregister(ep_wakeup_source(epi)); /* @@ -1152,7 +1152,7 @@ static int ep_alloc(struct eventpoll **pep) return -ENOMEM; mutex_init(&ep->mtx); - rwlock_init(&ep->lock); + spin_lock_init(&ep->lock); init_waitqueue_head(&ep->wq); init_waitqueue_head(&ep->poll_wait); INIT_LIST_HEAD(&ep->rdllist); @@ -1239,100 +1239,10 @@ struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd, } #endif /* CONFIG_KCMP */ -/* - * Adds a new entry to the tail of the list in a lockless way, i.e. - * multiple CPUs are allowed to call this function concurrently. - * - * Beware: it is necessary to prevent any other modifications of the - * existing list until all changes are completed, in other words - * concurrent list_add_tail_lockless() calls should be protected - * with a read lock, where write lock acts as a barrier which - * makes sure all list_add_tail_lockless() calls are fully - * completed. - * - * Also an element can be locklessly added to the list only in one - * direction i.e. either to the tail or to the head, otherwise - * concurrent access will corrupt the list. - * - * Return: %false if element has been already added to the list, %true - * otherwise. - */ -static inline bool list_add_tail_lockless(struct list_head *new, - struct list_head *head) -{ - struct list_head *prev; - - /* - * This is simple 'new->next = head' operation, but cmpxchg() - * is used in order to detect that same element has been just - * added to the list from another CPU: the winner observes - * new->next == new. - */ - if (!try_cmpxchg(&new->next, &new, head)) - return false; - - /* - * Initially ->next of a new element must be updated with the head - * (we are inserting to the tail) and only then pointers are atomically - * exchanged. XCHG guarantees memory ordering, thus ->next should be - * updated before pointers are actually swapped and pointers are - * swapped before prev->next is updated. - */ - - prev = xchg(&head->prev, new); - - /* - * It is safe to modify prev->next and new->prev, because a new element - * is added only to the tail and new->next is updated before XCHG. - */ - - prev->next = new; - new->prev = prev; - - return true; -} - -/* - * Chains a new epi entry to the tail of the ep->ovflist in a lockless way, - * i.e. multiple CPUs are allowed to call this function concurrently. - * - * Return: %false if epi element has been already chained, %true otherwise. - */ -static inline bool chain_epi_lockless(struct epitem *epi) -{ - struct eventpoll *ep = epi->ep; - - /* Fast preliminary check */ - if (epi->next != EP_UNACTIVE_PTR) - return false; - - /* Check that the same epi has not been just chained from another CPU */ - if (cmpxchg(&epi->next, EP_UNACTIVE_PTR, NULL) != EP_UNACTIVE_PTR) - return false; - - /* Atomically exchange tail */ - epi->next = xchg(&ep->ovflist, epi); - - return true; -} - /* * This is the callback that is passed to the wait queue wakeup * mechanism. It is called by the stored file descriptors when they * have events to report. - * - * This callback takes a read lock in order not to contend with concurrent - * events from another file descriptor, thus all modifications to ->rdllist - * or ->ovflist are lockless. Read lock is paired with the write lock from - * ep_start/done_scan(), which stops all list modifications and guarantees - * that lists state is seen correctly. - * - * Another thing worth to mention is that ep_poll_callback() can be called - * concurrently for the same @epi from different CPUs if poll table was inited - * with several wait queues entries. Plural wakeup from different CPUs of a - * single wait queue is serialized by wq.lock, but the case when multiple wait - * queues are used should be detected accordingly. This is detected using - * cmpxchg() operation. */ static int ep_poll_callback(wait_queue_entry_t *wait, unsigned mode, int sync, void *key) { @@ -1343,7 +1253,7 @@ static int ep_poll_callback(wait_queue_entry_t *wait, unsigned mode, int sync, v unsigned long flags; int ewake = 0; - read_lock_irqsave(&ep->lock, flags); + spin_lock_irqsave(&ep->lock, flags); ep_set_busy_poll_napi_id(epi); @@ -1372,12 +1282,15 @@ static int ep_poll_callback(wait_queue_entry_t *wait, unsigned mode, int sync, v * chained in ep->ovflist and requeued later on. */ if (READ_ONCE(ep->ovflist) != EP_UNACTIVE_PTR) { - if (chain_epi_lockless(epi)) + if (epi->next == EP_UNACTIVE_PTR) { + epi->next = READ_ONCE(ep->ovflist); + WRITE_ONCE(ep->ovflist, epi); ep_pm_stay_awake_rcu(epi); + } } else if (!ep_is_linked(epi)) { /* In the usual case, add event to ready list. */ - if (list_add_tail_lockless(&epi->rdllink, &ep->rdllist)) - ep_pm_stay_awake_rcu(epi); + list_add_tail(&epi->rdllink, &ep->rdllist); + ep_pm_stay_awake_rcu(epi); } /* @@ -1410,7 +1323,7 @@ static int ep_poll_callback(wait_queue_entry_t *wait, unsigned mode, int sync, v pwake++; out_unlock: - read_unlock_irqrestore(&ep->lock, flags); + spin_unlock_irqrestore(&ep->lock, flags); /* We have to call this outside the lock */ if (pwake) @@ -1745,7 +1658,7 @@ static int ep_insert(struct eventpoll *ep, const struct epoll_event *event, } /* We have to drop the new item inside our item list to keep track of it */ - write_lock_irq(&ep->lock); + spin_lock_irq(&ep->lock); /* record NAPI ID of new item if present */ ep_set_busy_poll_napi_id(epi); @@ -1762,7 +1675,7 @@ static int ep_insert(struct eventpoll *ep, const struct epoll_event *event, pwake++; } - write_unlock_irq(&ep->lock); + spin_unlock_irq(&ep->lock); /* We have to call this outside the lock */ if (pwake) @@ -1826,7 +1739,7 @@ static int ep_modify(struct eventpoll *ep, struct epitem *epi, * list, push it inside. */ if (ep_item_poll(epi, &pt, 1)) { - write_lock_irq(&ep->lock); + spin_lock_irq(&ep->lock); if (!ep_is_linked(epi)) { list_add_tail(&epi->rdllink, &ep->rdllist); ep_pm_stay_awake(epi); @@ -1837,7 +1750,7 @@ static int ep_modify(struct eventpoll *ep, struct epitem *epi, if (waitqueue_active(&ep->poll_wait)) pwake++; } - write_unlock_irq(&ep->lock); + spin_unlock_irq(&ep->lock); } /* We have to call this outside the lock */ @@ -2089,7 +2002,7 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, init_wait(&wait); wait.func = ep_autoremove_wake_function; - write_lock_irq(&ep->lock); + spin_lock_irq(&ep->lock); /* * Barrierless variant, waitqueue_active() is called under * the same lock on wakeup ep_poll_callback() side, so it @@ -2108,7 +2021,7 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, if (!eavail) __add_wait_queue_exclusive(&ep->wq, &wait); - write_unlock_irq(&ep->lock); + spin_unlock_irq(&ep->lock); if (!eavail) timed_out = !ep_schedule_timeout(to) || @@ -2124,7 +2037,7 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, eavail = 1; if (!list_empty_careful(&wait.entry)) { - write_lock_irq(&ep->lock); + spin_lock_irq(&ep->lock); /* * If the thread timed out and is not on the wait queue, * it means that the thread was woken up after its @@ -2135,7 +2048,7 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, if (timed_out) eavail = list_empty(&wait.entry); __remove_wait_queue(&ep->wq, &wait); - write_unlock_irq(&ep->lock); + spin_unlock_irq(&ep->lock); } } }

1 day, 12 hours

2
1
0 0

Re: stable 6.6: commit "sched/cpufreq: Rework schedutil governor performance estimation' causes a regression

by Sergey Senozhatsky

On (25/11/21 12:55), Sergey Senozhatsky wrote: > Hi Christian, > > On (25/11/20 10:15), Christian Loehle wrote: > > On 11/20/25 04:45, Sergey Senozhatsky wrote: > > > Hi, > > > > > > We are observing a performance regression on one of our arm64 boards. > > > We tracked it down to the linux-6.6.y commit ada8d7fa0ad4 ("sched/cpufreq: > > > Rework schedutil governor performance estimation"). > > > > > > UI speedometer benchmark: > > > w/commit: 395 +/-38 > > > w/o commit: 439 +/-14 > > > > > > > Hi Sergey, > > Would be nice to get some details. What board? > > It's an MT8196 chromebook. > > > What do the OPPs look like? > > How do I find that out? > > > Does this system use uclamp during the benchmark? How? > > How do I find that out? > > > Given how large the stddev given by speedometer (version 3?) itself is, can we get the > > stats of a few runs? > > v2.1 > > w/o patch w/ patch > 440 +/-30 406 +/-11 > 440 +/-14 413 +/-16 > 444 +/-12 403 +/-14 > 442 +/-12 412 +/-15 > > > Maybe traces of cpu_frequency for both w/ and w/o? > > trace-cmd record -e power:cpu_frequency attached. > > "base" is with ada8d7fa0ad4 > "revert" is ada8d7fa0ad4 reverted. Am getting failed delivery notifications. I guess attaching those as text files wasn't a good idea after all. Vincent, Christian, did you receive that email?

1 day, 13 hours

2
1
0 0

[PATCH] drm/amdgpu: Fix error handling in amdgpu_atpx_detect

by Ma Ke

amdgpu_atpx_detect() uses pci_get_class() in two while loops to iterate through VGA and OTHER display class PCI devices. Each call to pci_get_class() increments the reference count of the returned PCI device. However, after the loops complete, there are no corresponding pci_dev_put() to decrement these reference counts. Add pci_dev_put() after each while loop to release reference counts held by the last devices found in each class. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 5d30ed3c2c74 ("Revert "drm/amdgpu: simplify ATPX detection"") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c index 3893e6fc2f03..9eb776a2e8bb 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c @@ -617,6 +617,9 @@ static bool amdgpu_atpx_detect(void) amdgpu_atpx_get_quirks(pdev); } + pci_dev_put(pdev); + pdev = NULL; + while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_OTHER << 8, pdev)) != NULL) { vga_count++; @@ -627,6 +630,8 @@ static bool amdgpu_atpx_detect(void) amdgpu_atpx_get_quirks(pdev); } + pci_dev_put(pdev); + if (has_atpx && vga_count == 2) { acpi_get_name(amdgpu_atpx_priv.atpx.handle, ACPI_FULL_PATHNAME, &buffer); pr_info("vga_switcheroo: detected switching method %s handle\n", -- 2.17.1

1 day, 13 hours

2
1
0 0

Cost-effective PCB

by sales09＠found-pcb.com

Dear Manager, I am Windy from Found Printed circuits board, which is a professional PCB manufacturer in China. Learned that you are specializing in PCB, you might want to get some supplier sources from China and we would be one of your good options. Please find our profile highlights as following: 1. Products range PCB up to 14 layers, Aluminum PCB, High Frequency Board, Carbon Board, Rigid-flex Board…… Material range: FR-4 (130TG-180TG), CEM1, Rogers, Aluminum Based…… Technology Capability: Min. 3mil/3mil Trace/space, 4 mil Smallest Drill Size…… 2. Qualified System ISO 9001 ISO 14001 TS 16949 UL：E361831 3. Excellent customer service and quick response. We can send you quotes and inquiry responses in two hours or less. If you want to know more details, pls feel free to contact me. Kindly send us gerber for quotation. Thanks for your time! Best Regards Windy Shenzhen Found Printed Circuit Board Co., Ltd TEL:+86-0755-36521149 FAX:+86-0755-29603824 Website: www.found-pcb.com

1 day, 13 hours

1
0
0 0

[PATCH 6.6.y] net: stmmac: Fix accessing freed irq affinity_hint

by Rajani Kantha

From: Qingfang Deng <dqfext(a)gmail.com> [ Upstream commit c60d101a226f18e9a8f01bb4c6ca2b47dfcb15ef ] The cpumask should not be a local variable, since its pointer is saved to irq_desc and may be accessed from procfs. To fix it, use the persistent mask cpumask_of(cpu#). Cc: stable(a)vger.kernel.org Fixes: 8deec94c6040 ("net: stmmac: set IRQ affinity hint for multi MSI vectors") Signed-off-by: Qingfang Deng <dqfext(a)gmail.com> Reviewed-by: Jacob Keller <jacob.e.keller(a)intel.com> Link: https://patch.msgid.link/20250318032424.112067-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Rajani Kantha <681739313(a)139.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index f3155d69a013..aded4fb61345 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -3516,7 +3516,6 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev) { struct stmmac_priv *priv = netdev_priv(dev); enum request_irq_err irq_err; - cpumask_t cpu_mask; int irq_idx = 0; char *int_name; int ret; @@ -3628,9 +3627,8 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev) irq_idx = i; goto irq_error; } - cpumask_clear(&cpu_mask); - cpumask_set_cpu(i % num_online_cpus(), &cpu_mask); - irq_set_affinity_hint(priv->rx_irq[i], &cpu_mask); + irq_set_affinity_hint(priv->rx_irq[i], + cpumask_of(i % num_online_cpus())); } /* Request Tx MSI irq */ @@ -3653,9 +3651,8 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev) irq_idx = i; goto irq_error; } - cpumask_clear(&cpu_mask); - cpumask_set_cpu(i % num_online_cpus(), &cpu_mask); - irq_set_affinity_hint(priv->tx_irq[i], &cpu_mask); + irq_set_affinity_hint(priv->tx_irq[i], + cpumask_of(i % num_online_cpus())); } return 0; -- 2.17.1

1 day, 14 hours

1
0
0 0

FAILED: patch "[PATCH] KVM: VMX: Fix check for valid GVA on an EPT violation" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x d0164c161923ac303bd843e04ebe95cfd03c6e19 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112016-chatter-plutonium-baf8@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d0164c161923ac303bd843e04ebe95cfd03c6e19 Mon Sep 17 00:00:00 2001 From: Sukrit Bhatnagar <Sukrit.Bhatnagar(a)sony.com> Date: Thu, 6 Nov 2025 14:28:51 +0900 Subject: [PATCH] KVM: VMX: Fix check for valid GVA on an EPT violation On an EPT violation, bit 7 of the exit qualification is set if the guest linear-address is valid. The derived page fault error code should not be checked for this bit. Fixes: f3009482512e ("KVM: VMX: Set PFERR_GUEST_{FINAL,PAGE}_MASK if and only if the GVA is valid") Cc: stable(a)vger.kernel.org Signed-off-by: Sukrit Bhatnagar <Sukrit.Bhatnagar(a)sony.com> Reviewed-by: Xiaoyao Li <xiaoyao.li(a)intel.com> Link: https://patch.msgid.link/20251106052853.3071088-1-Sukrit.Bhatnagar@sony.com Signed-off-by: Sean Christopherson <seanjc(a)google.com> diff --git a/arch/x86/kvm/vmx/common.h b/arch/x86/kvm/vmx/common.h index bc5ece76533a..412d0829d7a2 100644 --- a/arch/x86/kvm/vmx/common.h +++ b/arch/x86/kvm/vmx/common.h @@ -98,7 +98,7 @@ static inline int __vmx_handle_ept_violation(struct kvm_vcpu *vcpu, gpa_t gpa, error_code |= (exit_qualification & EPT_VIOLATION_PROT_MASK) ? PFERR_PRESENT_MASK : 0; - if (error_code & EPT_VIOLATION_GVA_IS_VALID) + if (exit_qualification & EPT_VIOLATION_GVA_IS_VALID) error_code |= (exit_qualification & EPT_VIOLATION_GVA_TRANSLATED) ? PFERR_GUEST_FINAL_MASK : PFERR_GUEST_PAGE_MASK;

1 day, 14 hours

3
3
0 0

[PATCH] net: dsa: microchip: fix mdio parent bus reference leak

by Ma Ke

In ksz_mdio_register(), when of_mdio_find_bus() is called to get the parent MDIO bus, it increments the reference count of the underlying device. However, the reference are not released in error paths or during switch teardown, causing a reference leak. Add put_device() in the error path of ksz_mdio_register() and ksz_teardown() to release the parent bus. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 9afaf0eec2ab ("net: dsa: microchip: Refactor MDIO handling for side MDIO access") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/net/dsa/microchip/ksz_common.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c index 933ae8dc6337..49c0420a6df8 100644 --- a/drivers/net/dsa/microchip/ksz_common.c +++ b/drivers/net/dsa/microchip/ksz_common.c @@ -2795,6 +2795,11 @@ static int ksz_mdio_register(struct ksz_device *dev) } put_mdio_node: + if (ret && dev->parent_mdio_bus) { + put_device(&dev->parent_mdio_bus->dev); + dev->parent_mdio_bus = NULL; + } + of_node_put(mdio_np); of_node_put(parent_bus_node); @@ -3110,6 +3115,11 @@ static void ksz_teardown(struct dsa_switch *ds) ksz_irq_free(&dev->girq); } + if (dev->parent_mdio_bus) { + put_device(&dev->parent_mdio_bus->dev); + dev->parent_mdio_bus = NULL; + } + if (dev->dev_ops->teardown) dev->dev_ops->teardown(ds); } -- 2.17.1

1 day, 14 hours

2
1
0 0

Bounce probe for stable@vger.kernel.org (no action required)

by stable+owner＠vger.kernel.org

Greetings! This is the mlmmj program managing the <stable(a)vger.kernel.org> mailing list. Your mail host rejected some of the messages we tried to deliver. This usually happens if we have accepted a spam message, but your mail server refused to take it from us (because it's spam). This automated probe is just a test to make sure that there are no other problems with mail delivery to your account. No action is required on your part -- if you are seeing this message, that means everything is normal. (In fact, you can add "Subject: Bounce probe" to your filters to avoid seeing this message in the future.) For internal tracking purposes, here is the list of bounced messages: - 195455 - 195456

1 day, 16 hours

1
0
0 0

[PATCH 6.6.y] f2fs: fix to avoid overflow while left shift operation

by Rajani Kantha

From: Chao Yu <chao(a)kernel.org> [ Upstream commit 0fe1c6bec54ea68ed8c987b3890f2296364e77bb ] Should cast type of folio->index from pgoff_t to loff_t to avoid overflow while left shift operation. Fixes: 3265d3db1f16 ("f2fs: support partial truncation on compressed inode") Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> [ Modification: Using rpages[i]->index instead of folio->index due to it was changed since commit:1cda5bc0b2fe ("f2fs: Use a folio in f2fs_truncate_partial_cluster()") on 6.14 ] Signed-off-by: Rajani Kantha <681739313(a)139.com> --- fs/f2fs/compress.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c index e962de4ecaa2..c3b2f78ca4e3 100644 --- a/fs/f2fs/compress.c +++ b/fs/f2fs/compress.c @@ -1209,7 +1209,7 @@ int f2fs_truncate_partial_cluster(struct inode *inode, u64 from, bool lock) int i; for (i = cluster_size - 1; i >= 0; i--) { - loff_t start = rpages[i]->index << PAGE_SHIFT; + loff_t start = (loff_t)rpages[i]->index << PAGE_SHIFT; if (from <= start) { zero_user_segment(rpages[i], 0, PAGE_SIZE); -- 2.17.1

1 day, 16 hours

1
0
0 0

[PATCH v2] usb: dwc3: gadget: Prevent EPs resource conflict during StartTransfer

by Selvarasu Ganesan

The below “No resource for ep” warning appears when a StartTransfer command is issued for bulk or interrupt endpoints in `dwc3_gadget_ep_enable` while a previous StartTransfer on the same endpoint is still in progress. The gadget functions drivers can invoke `usb_ep_enable` (which triggers a new StartTransfer command) before the earlier transfer has completed. Because the previous StartTransfer is still active, `dwc3_gadget_ep_disable` can skip the required `EndTransfer` due to `DWC3_EP_DELAY_STOP`, leading to the endpoint resources are busy for previous StartTransfer and warning ("No resource for ep") from dwc3 driver. To resolve this, a check is added to `dwc3_gadget_ep_enable` that checks the `DWC3_EP_TRANSFER_STARTED` flag before issuing a new StartTransfer. By preventing a second StartTransfer on an already busy endpoint, the resource conflict is eliminated, the warning disappears, and potential kernel panics caused by `panic_on_warn` are avoided. ------------[ cut here ]------------ dwc3 13200000.dwc3: No resource for ep1out WARNING: CPU: 0 PID: 700 at drivers/usb/dwc3/gadget.c:398 dwc3_send_gadget_ep_cmd+0x2f8/0x76c Call trace: dwc3_send_gadget_ep_cmd+0x2f8/0x76c __dwc3_gadget_ep_enable+0x490/0x7c0 dwc3_gadget_ep_enable+0x6c/0xe4 usb_ep_enable+0x5c/0x15c mp_eth_stop+0xd4/0x11c __dev_close_many+0x160/0x1c8 __dev_change_flags+0xfc/0x220 dev_change_flags+0x24/0x70 devinet_ioctl+0x434/0x524 inet_ioctl+0xa8/0x224 sock_do_ioctl+0x74/0x128 sock_ioctl+0x3bc/0x468 __arm64_sys_ioctl+0xa8/0xe4 invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x38/0x88 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac Fixes: a97ea994605e ("usb: dwc3: gadget: offset Start Transfer latency for bulk EPs") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- Changes in v2: - Removed change-id. - Updated commit message. Link to v1: https://lore.kernel.org/linux-usb/20251117152812.622-1-selvarasu.g@samsung.… --- drivers/usb/dwc3/gadget.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 1f67fb6aead5..8d3caa71ea12 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -963,8 +963,9 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action) * Issue StartTransfer here with no-op TRB so we can always rely on No * Response Update Transfer command. */ - if (usb_endpoint_xfer_bulk(desc) || - usb_endpoint_xfer_int(desc)) { + if ((usb_endpoint_xfer_bulk(desc) || + usb_endpoint_xfer_int(desc)) && + !(dep->flags & DWC3_EP_TRANSFER_STARTED)) { struct dwc3_gadget_ep_cmd_params params; struct dwc3_trb *trb; dma_addr_t trb_dma; -- 2.34.1

1 day, 17 hours

3
10
0 0

stable 6.6: commit "sched/cpufreq: Rework schedutil governor performance estimation' causes a regression

by Sergey Senozhatsky

Hi, We are observing a performance regression on one of our arm64 boards. We tracked it down to the linux-6.6.y commit ada8d7fa0ad4 ("sched/cpufreq: Rework schedutil governor performance estimation"). UI speedometer benchmark: w/commit: 395 +/-38 w/o commit: 439 +/-14

1 day, 17 hours

3
3
0 0

FAILED: patch "[PATCH] mm/mm_init: fix hash table order logging in" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 0d6c356dd6547adac2b06b461528e3573f52d953 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112032-parted-progeny-cd9e@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0d6c356dd6547adac2b06b461528e3573f52d953 Mon Sep 17 00:00:00 2001 From: "Isaac J. Manjarres" <isaacmanjarres(a)google.com> Date: Tue, 28 Oct 2025 12:10:12 -0700 Subject: [PATCH] mm/mm_init: fix hash table order logging in alloc_large_system_hash() When emitting the order of the allocation for a hash table, alloc_large_system_hash() unconditionally subtracts PAGE_SHIFT from log base 2 of the allocation size. This is not correct if the allocation size is smaller than a page, and yields a negative value for the order as seen below: TCP established hash table entries: 32 (order: -4, 256 bytes, linear) TCP bind hash table entries: 32 (order: -2, 1024 bytes, linear) Use get_order() to compute the order when emitting the hash table information to correctly handle cases where the allocation size is smaller than a page: TCP established hash table entries: 32 (order: 0, 256 bytes, linear) TCP bind hash table entries: 32 (order: 0, 1024 bytes, linear) Link: https://lkml.kernel.org/r/20251028191020.413002-1-isaacmanjarres@google.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com> Reviewed-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/mm_init.c b/mm/mm_init.c index 3db2dea7db4c..7712d887b696 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -2469,7 +2469,7 @@ void *__init alloc_large_system_hash(const char *tablename, panic("Failed to allocate %s hash table\n", tablename); pr_info("%s hash table entries: %ld (order: %d, %lu bytes, %s)\n", - tablename, 1UL << log2qty, ilog2(size) - PAGE_SHIFT, size, + tablename, 1UL << log2qty, get_order(size), size, virt ? (huge ? "vmalloc hugepage" : "vmalloc") : "linear"); if (_hash_shift)

1 day, 17 hours

4
5
0 0

[PATCH] NFC: Fix error handling in nfc_genl_dump_targets

by Ma Ke

nfc_genl_dump_targets() increments the device reference count via nfc_get_device() but fails to decrement it properly. nfc_get_device() calls class_find_device() which internally calls get_device() to increment the reference count. No corresponding put_device() is made to decrement the reference count. Add proper reference count decrementing using nfc_put_device() when the dump operation completes or encounters an error, ensuring balanced reference counting. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 4d12b8b129f1 ("NFC: add nfc generic netlink interface") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- net/nfc/netlink.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c index a18e2c503da6..9ae138ee91dd 100644 --- a/net/nfc/netlink.c +++ b/net/nfc/netlink.c @@ -159,6 +159,11 @@ static int nfc_genl_dump_targets(struct sk_buff *skb, cb->args[0] = i; + if (rc < 0 || i >= dev->n_targets) { + nfc_put_device(dev); + cb->args[1] = 0; + } + return skb->len; } -- 2.17.1

1 day, 17 hours

1
0
0 0

FAILED: patch "[PATCH] net: netpoll: fix incorrect refcount handling causing" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112011-candied-surrogate-885f@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 Mon Sep 17 00:00:00 2001 From: Breno Leitao <leitao(a)debian.org> Date: Fri, 7 Nov 2025 06:03:37 -0800 Subject: [PATCH] net: netpoll: fix incorrect refcount handling causing incorrect cleanup commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior. Cc: <stable(a)vger.kernel.org> # 3.17.x Cc: Jay Vosburgh <jv(a)jvosburgh.net> Fixes: efa95b01da18 ("netpoll: fix use after free") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20251107-netconsole_torture-v10-1-749227b55f63@deb… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/core/netpoll.c b/net/core/netpoll.c index c85f740065fc..331764845e8f 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -811,6 +811,10 @@ static void __netpoll_cleanup(struct netpoll *np) if (!npinfo) return; + /* At this point, there is a single npinfo instance per netdevice, and + * its refcnt tracks how many netpoll structures are linked to it. We + * only perform npinfo cleanup when the refcnt decrements to zero. + */ if (refcount_dec_and_test(&npinfo->refcnt)) { const struct net_device_ops *ops; @@ -820,8 +824,7 @@ static void __netpoll_cleanup(struct netpoll *np) RCU_INIT_POINTER(np->dev->npinfo, NULL); call_rcu(&npinfo->rcu, rcu_cleanup_netpoll_info); - } else - RCU_INIT_POINTER(np->dev->npinfo, NULL); + } skb_pool_flush(np); }

1 day, 18 hours

2
1
0 0

FAILED: patch "[PATCH] ASoC: da7213: Use component driver suspend/resume" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.17.y git checkout FETCH_HEAD git cherry-pick -x 249d96b492efb7a773296ab2c62179918301c146 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112057-rubble-coleslaw-6ad1@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 249d96b492efb7a773296ab2c62179918301c146 Mon Sep 17 00:00:00 2001 From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> Date: Tue, 4 Nov 2025 13:49:14 +0200 Subject: [PATCH] ASoC: da7213: Use component driver suspend/resume Since snd_soc_suspend() is invoked through snd_soc_pm_ops->suspend(), and snd_soc_pm_ops is associated with the soc_driver (defined in sound/soc/soc-core.c), and there is no parent-child relationship between the soc_driver and the DA7213 codec driver, the power management subsystem does not enforce a specific suspend/resume order between the DA7213 driver and the soc_driver. Because of this, the different codec component functionalities, called from snd_soc_resume() to reconfigure various functions, can race with the DA7213 struct dev_pm_ops::resume function, leading to misapplied configuration. This occasionally results in clipped sound. Fix this by dropping the struct dev_pm_ops::{suspend, resume} and use instead struct snd_soc_component_driver::{suspend, resume}. This ensures the proper configuration sequence is handled by the ASoC subsystem. Cc: stable(a)vger.kernel.org Fixes: 431e040065c8 ("ASoC: da7213: Add suspend to RAM support") Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> Link: https://patch.msgid.link/20251104114914.2060603-1-claudiu.beznea.uj@bp.rene… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/codecs/da7213.c b/sound/soc/codecs/da7213.c index ae89260ca215..3420011da444 100644 --- a/sound/soc/codecs/da7213.c +++ b/sound/soc/codecs/da7213.c @@ -2124,11 +2124,50 @@ static int da7213_probe(struct snd_soc_component *component) return 0; } +static int da7213_runtime_suspend(struct device *dev) +{ + struct da7213_priv *da7213 = dev_get_drvdata(dev); + + regcache_cache_only(da7213->regmap, true); + regcache_mark_dirty(da7213->regmap); + regulator_bulk_disable(DA7213_NUM_SUPPLIES, da7213->supplies); + + return 0; +} + +static int da7213_runtime_resume(struct device *dev) +{ + struct da7213_priv *da7213 = dev_get_drvdata(dev); + int ret; + + ret = regulator_bulk_enable(DA7213_NUM_SUPPLIES, da7213->supplies); + if (ret < 0) + return ret; + regcache_cache_only(da7213->regmap, false); + return regcache_sync(da7213->regmap); +} + +static int da7213_suspend(struct snd_soc_component *component) +{ + struct da7213_priv *da7213 = snd_soc_component_get_drvdata(component); + + return da7213_runtime_suspend(da7213->dev); +} + +static int da7213_resume(struct snd_soc_component *component) +{ + struct da7213_priv *da7213 = snd_soc_component_get_drvdata(component); + + return da7213_runtime_resume(da7213->dev); +} + static const struct snd_soc_component_driver soc_component_dev_da7213 = { .probe = da7213_probe, .set_bias_level = da7213_set_bias_level, .controls = da7213_snd_controls, .num_controls = ARRAY_SIZE(da7213_snd_controls), + .suspend = da7213_suspend, + .resume = da7213_resume, .dapm_widgets = da7213_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(da7213_dapm_widgets), .dapm_routes = da7213_audio_map, @@ -2175,6 +2214,8 @@ static int da7213_i2c_probe(struct i2c_client *i2c) if (!da7213->fin_min_rate) return -EINVAL; + da7213->dev = &i2c->dev; + i2c_set_clientdata(i2c, da7213); /* Get required supplies */ @@ -2224,31 +2265,9 @@ static void da7213_i2c_remove(struct i2c_client *i2c) pm_runtime_disable(&i2c->dev); } -static int da7213_runtime_suspend(struct device *dev) -{ - struct da7213_priv *da7213 = dev_get_drvdata(dev); - - regcache_cache_only(da7213->regmap, true); - regcache_mark_dirty(da7213->regmap); - regulator_bulk_disable(DA7213_NUM_SUPPLIES, da7213->supplies); - - return 0; -} - -static int da7213_runtime_resume(struct device *dev) -{ - struct da7213_priv *da7213 = dev_get_drvdata(dev); - int ret; - - ret = regulator_bulk_enable(DA7213_NUM_SUPPLIES, da7213->supplies); - if (ret < 0) - return ret; - regcache_cache_only(da7213->regmap, false); - return regcache_sync(da7213->regmap); -} - -static DEFINE_RUNTIME_DEV_PM_OPS(da7213_pm, da7213_runtime_suspend, - da7213_runtime_resume, NULL); +static const struct dev_pm_ops da7213_pm = { + RUNTIME_PM_OPS(da7213_runtime_suspend, da7213_runtime_resume, NULL) +}; static const struct i2c_device_id da7213_i2c_id[] = { { "da7213" }, diff --git a/sound/soc/codecs/da7213.h b/sound/soc/codecs/da7213.h index b9ab791d6b88..29cbf0eb6124 100644 --- a/sound/soc/codecs/da7213.h +++ b/sound/soc/codecs/da7213.h @@ -595,6 +595,7 @@ enum da7213_supplies { /* Codec private data */ struct da7213_priv { struct regmap *regmap; + struct device *dev; struct mutex ctrl_lock; struct regulator_bulk_data supplies[DA7213_NUM_SUPPLIES]; struct clk *mclk;

1 day, 18 hours

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror