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

[PATCH AUTOSEL 6.17-5.10] platform/x86: huawei-wmi: add keys for HONOR models

by Sasha Levin

From: Jia Ston <ston.jia(a)outlook.com> [ Upstream commit 5c72329716d0858621021193330594d5d26bf44d ] HONOR MagicBook X16/X14 models produced in 2025 cannot use the Print Screen and YOYO keys properly, with the system reporting them as unknown key presses (codes: 0x028b and 0x028e). To resolve this, a key_entry is added for both the HONOR Print Screen key and the HONOR YOYO key, ensuring they function correctly on these models. Signed-off-by: Ston Jia <ston.jia(a)outlook.com> Link: https://patch.msgid.link/20251029051804.220111-1-ston.jia@outlook.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ### Comprehensive Analysis 1. **Commit Message and Issue Analysis** The commit addresses a functional hardware defect on HONOR MagicBook X16/X14 laptops (2025 models). The "Print Screen" and "YOYO" keys do not generate input events, instead triggering "Unknown key pressed" warning logs with scancodes `0x028b` and `0x028e`. This means users cannot use these hardware features, which constitutes a real-world bug for owners of these devices. 2. **Code Review and Mechanism** The fix is a surgical addition to the `huawei_wmi_keymap` array in `drivers/platform/x86/huawei-wmi.c`. - **Mechanism:** The driver uses `sparse_keymap_entry_from_scancode` to translate WMI events into input events. Without these entries, the lookup fails, and the driver drops the event. - **Change:** Two lines are added: ```c { KE_KEY, 0x28b, { KEY_NOTIFICATION_CENTER } }, { KE_KEY, 0x28e, { KEY_PRINT } }, ``` - **Dependencies:** `KEY_NOTIFICATION_CENTER` was introduced in Linux 5.10. This patch is suitable for stable trees 5.10, 5.15, 6.1, and 6.6 without modification. Older LTS versions (4.19, 5.4) would require a minor adjustment (using a different keycode or backporting the definition), but the patch remains conceptually valid for them. 3. **Stable Kernel Rules Assessment** - **Exception Category:** This commit falls squarely under the **"QUIRKS and WORKAROUNDS"** and **"TRIVIAL SUBSYSTEM-SPECIFIC ADDITIONS"** exceptions defined in stable kernel rules. Adding keymap entries is functionally identical to adding PCI/USB IDs: it enables hardware that is currently present but non-functional. - **Feature vs. Fix:** While the commit says "add keys," it is fixing broken hardware support. The keys physically exist but do not work; enabling them is a fix, not a new software feature. - **New Hardware on Stable:** While the hardware is from 2025, it is common for users to run Long Term Support (LTS) kernels (e.g., Ubuntu LTS, RHEL, or community LTS kernels like 6.6.y) on new hardware. Refusing to backport hardware enablement forces these users to run bleeding-edge kernels or suffer broken functionality. 4. **Risk vs. Benefit** - **Regression Risk:** **Negligible.** The change adds data to a static array. It only affects the handling of two specific scancodes (`0x28b`, `0x28e`) which previously resulted in an error log. It cannot affect existing key mappings or other hardware. - **Benefit:** Restores functionality for the "Print Screen" key (essential for workflows) and the specific "YOYO" key on supported laptops. 5. **Conclusion** Although the commit lacks a "Cc: stable" tag, it meets all objective criteria for a stable backport. It is an obviously correct, low-risk, hardware-enabling fix that fits the "Quirks" exception. It should be included to ensure this hardware works correctly on supported LTS releases. ### TODO Items - No further investigation required. **YES** drivers/platform/x86/huawei-wmi.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/platform/x86/huawei-wmi.c b/drivers/platform/x86/huawei-wmi.c index c3772df34679f..8a4c54089ace3 100644 --- a/drivers/platform/x86/huawei-wmi.c +++ b/drivers/platform/x86/huawei-wmi.c @@ -81,6 +81,10 @@ static const struct key_entry huawei_wmi_keymap[] = { { KE_KEY, 0x289, { KEY_WLAN } }, // Huawei |M| key { KE_KEY, 0x28a, { KEY_CONFIG } }, + // HONOR YOYO key + { KE_KEY, 0x28b, { KEY_NOTIFICATION_CENTER } }, + // HONOR print screen + { KE_KEY, 0x28e, { KEY_PRINT } }, // Keyboard backlit { KE_IGNORE, 0x293, { KEY_KBDILLUMTOGGLE } }, { KE_IGNORE, 0x294, { KEY_KBDILLUMUP } }, -- 2.51.0

2 days, 15 hours

1
20
0 0

[PATCH] ksmbd: vfs: fix race on m_flags in vfs_cache

by Qianchang Zhao

ksmbd maintains delete-on-close and pending-delete state in ksmbd_inode->m_flags. In vfs_cache.c this field is accessed under inconsistent locking: some paths read and modify m_flags under ci->m_lock while others do so without taking the lock at all. Examples: - ksmbd_query_inode_status() and __ksmbd_inode_close() use ci->m_lock when checking or updating m_flags. - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close() used to read and modify m_flags without ci->m_lock. This creates a potential data race on m_flags when multiple threads open, close and delete the same file concurrently. In the worst case delete-on-close and pending-delete bits can be lost or observed in an inconsistent state, leading to confusing delete semantics (files that stay on disk after delete-on-close, or files that disappear while still in use). Fix it by: - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock after dropping inode_hash_lock. - Adding ci->m_lock protection to all helpers that read or modify m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()). - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(), and moving the actual unlink/xattr removal outside the lock. This unifies the locking around m_flags and removes the data race while preserving the existing delete-on-close behaviour. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qianchang Zhao <pioooooooooip(a)gmail.com> --- fs/smb/server/vfs_cache.c | 114 +++++++++++++++++++++++++++++--------- 1 file changed, 87 insertions(+), 27 deletions(-) diff --git a/fs/smb/server/vfs_cache.c b/fs/smb/server/vfs_cache.c index dfed6fce8..b44e0d618 100644 --- a/fs/smb/server/vfs_cache.c +++ b/fs/smb/server/vfs_cache.c @@ -112,40 +112,88 @@ int ksmbd_query_inode_status(struct dentry *dentry) read_lock(&inode_hash_lock); ci = __ksmbd_inode_lookup(dentry); - if (ci) { - ret = KSMBD_INODE_STATUS_OK; - if (ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)) - ret = KSMBD_INODE_STATUS_PENDING_DELETE; - atomic_dec(&ci->m_count); - } read_unlock(&inode_hash_lock); + if (!ci) + return ret; + down_read(&ci->m_lock); + if (ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)) + ret = KSMBD_INODE_STATUS_PENDING_DELETE; + else + ret = KSMBD_INODE_STATUS_OK; + up_read(&ci->m_lock); + + atomic_dec(&ci->m_count); return ret; } bool ksmbd_inode_pending_delete(struct ksmbd_file *fp) { - return (fp->f_ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)); + struct ksmbd_inode *ci; + bool ret; + + if (!fp) + return false; + + ci = fp->f_ci; + if (!ci) + return false; + + down_read(&ci->m_lock); + ret = ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS); + up_read(&ci->m_lock); + + return ret; } void ksmbd_set_inode_pending_delete(struct ksmbd_file *fp) { - fp->f_ci->m_flags |= S_DEL_PENDING; + struct ksmbd_inode *ci; + + if (!fp) + return; + + ci = fp->f_ci; + if (!ci) + return; + + down_write(&ci->m_lock); + ci->m_flags |= S_DEL_PENDING; + up_write(&ci->m_lock); } void ksmbd_clear_inode_pending_delete(struct ksmbd_file *fp) { - fp->f_ci->m_flags &= ~S_DEL_PENDING; + struct ksmbd_inode *ci; + + if (!fp) + return; + + ci = fp->f_ci; + if (!ci) + return; + + down_write(&ci->m_lock); + ci->m_flags &= ~S_DEL_PENDING; + up_write(&ci->m_lock); } -void ksmbd_fd_set_delete_on_close(struct ksmbd_file *fp, - int file_info) +void ksmbd_fd_set_delete_on_close(struct ksmbd_file *fp, int file_info) { - if (ksmbd_stream_fd(fp)) { - fp->f_ci->m_flags |= S_DEL_ON_CLS_STREAM; + struct ksmbd_inode *ci; + + if (!fp) + return; + + ci = fp->f_ci; + if (!ci) return; - } - fp->f_ci->m_flags |= S_DEL_ON_CLS; + down_write(&ci->m_lock); + if (ksmbd_stream_fd(fp)) + ci->m_flags |= S_DEL_ON_CLS_STREAM; + else + ci->m_flags |= S_DEL_ON_CLS; + up_write(&ci->m_lock); } static void ksmbd_inode_hash(struct ksmbd_inode *ci) @@ -255,29 +303,41 @@ static void __ksmbd_inode_close(struct ksmbd_file *fp) struct ksmbd_inode *ci = fp->f_ci; int err; struct file *filp; + bool remove_stream_xattr = false; + bool do_unlink = false; filp = fp->filp; - if (ksmbd_stream_fd(fp) && (ci->m_flags & S_DEL_ON_CLS_STREAM)) { - ci->m_flags &= ~S_DEL_ON_CLS_STREAM; - err = ksmbd_vfs_remove_xattr(file_mnt_idmap(filp), - &filp->f_path, - fp->stream.name, - true); - if (err) - pr_err("remove xattr failed : %s\n", - fp->stream.name); + + if (ksmbd_stream_fd(fp)) { + down_write(&ci->m_lock); + if (ci->m_flags & S_DEL_ON_CLS_STREAM) { + ci->m_flags &= ~S_DEL_ON_CLS_STREAM; + remove_stream_xattr = true; + } + up_write(&ci->m_lock); + + if (remove_stream_xattr) { + err = ksmbd_vfs_remove_xattr(file_mnt_idmap(filp), + &filp->f_path, + fp->stream.name, + true); + if (err) + pr_err("remove xattr failed : %s\n", + fp->stream.name); + } } if (atomic_dec_and_test(&ci->m_count)) { down_write(&ci->m_lock); if (ci->m_flags & (S_DEL_ON_CLS | S_DEL_PENDING)) { ci->m_flags &= ~(S_DEL_ON_CLS | S_DEL_PENDING); - up_write(&ci->m_lock); - ksmbd_vfs_unlink(filp); - down_write(&ci->m_lock); + do_unlink = true; } up_write(&ci->m_lock); + if (do_unlink) + ksmbd_vfs_unlink(filp); + ksmbd_inode_free(ci); } } -- 2.34.1

2 days, 15 hours

2
1
0 0

LPO 94914 Monday, November 24, 2025 at 08:03:35 AM

by Gusikowski Inc

Dear Stable, I hope this message finds you well. I am reaching out to follow up regarding the products listed in the attached document, as I am currently gathering the necessary information to move forward with our evaluation and procurement process. Your insights and clarification will be greatly appreciated. To better understand your offerings, could you please provide more detailed information on the following: Pricing structure for each product, including any volume discounts or tiered pricing options. Availability and stock levels, especially for high-demand items or products with known lead times. Technical specifications, features, and product variations, so we can accurately assess compatibility with our needs. Current promotions, special offers, or bundled packages that may apply to this order. Shipping and logistics details, including available carriers, estimated delivery timelines, and any additional fees we should be aware of. If there are catalogs, brochures, or updated product sheets available, please feel free to include them as well. Any additional insight you can share regarding after-sales support, warranty terms, or return policies would also be helpful as we work toward a final decision. Due to the timelines of our internal review, I would greatly appreciate your prompt response at your earliest convenience. Your assistance plays a vital role in helping us move forward efficiently and confidently. Thank you again for your time, cooperation, and support. I look forward to hearing from you soon and continuing our discussion. Warm regards, Olive Bailey Head of Procurement

2 days, 16 hours

1
0
0 0

Supply Inquiry for Mexico 2026 FIFA

by Valeria R Elena

Dear Sir, I'm one of the registered and authorized International procurement consultants of the Mexico 2026 FIFA world cup. The government of Mexico through the Mexico 2026 FIFA World Cup Local Organizing Committee has approved a massive procurement of your products for nationwide distribution to Airports facilities, offices, stadiums, Hostels, Hotels, Shops, etc as part of their national and regional sensitization programs towards the hosting of the FIFA world cup 2026. The packaging of the products will be customized with the Mexico 2026 Logo. The Local Organizing Committee is looking for a capable company to handle the supply under a bidding process. I wish to know if your company will be interested to participate in this project so that we could discuss our possible collaboration to ensure a successful bidding. More details would be provided upon hearing from you. Best regards, Best Regards, Dr. Ms Valeria R Elena Green Palms México Ltd Mexico City La Ciudad de los Palacios

2 days, 17 hours

1
0
0 0

FAILED: patch "[PATCH] fs/proc: fix uaf in proc_readdir_de()" 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 895b4c0c79b092d732544011c3cecaf7322c36a1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112019-mantra-unwind-1db7@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 895b4c0c79b092d732544011c3cecaf7322c36a1 Mon Sep 17 00:00:00 2001 From: Wei Yang <albinwyang(a)tencent.com> Date: Sat, 25 Oct 2025 10:42:33 +0800 Subject: [PATCH] fs/proc: fix uaf in proc_readdir_de() Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2) Link: https://lkml.kernel.org/r/20251025024233.158363-1-albin_yang@163.com Signed-off-by: Wei Yang <albinwyang(a)tencent.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Cc: wangzijie <wangzijie1(a)honor.com> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/fs/proc/generic.c b/fs/proc/generic.c index 176281112273..501889856461 100644 --- a/fs/proc/generic.c +++ b/fs/proc/generic.c @@ -698,6 +698,12 @@ void pde_put(struct proc_dir_entry *pde) } } +static void pde_erase(struct proc_dir_entry *pde, struct proc_dir_entry *parent) +{ + rb_erase(&pde->subdir_node, &parent->subdir); + RB_CLEAR_NODE(&pde->subdir_node); +} + /* * Remove a /proc entry and free it if it's not currently in use. */ @@ -720,7 +726,7 @@ void remove_proc_entry(const char *name, struct proc_dir_entry *parent) WARN(1, "removing permanent /proc entry '%s'", de->name); de = NULL; } else { - rb_erase(&de->subdir_node, &parent->subdir); + pde_erase(de, parent); if (S_ISDIR(de->mode)) parent->nlink--; } @@ -764,7 +770,7 @@ int remove_proc_subtree(const char *name, struct proc_dir_entry *parent) root->parent->name, root->name); return -EINVAL; } - rb_erase(&root->subdir_node, &parent->subdir); + pde_erase(root, parent); de = root; while (1) { @@ -776,7 +782,7 @@ int remove_proc_subtree(const char *name, struct proc_dir_entry *parent) next->parent->name, next->name); return -EINVAL; } - rb_erase(&next->subdir_node, &de->subdir); + pde_erase(next, de); de = next; continue; }

2 days, 21 hours

3
2
0 0

[PATCH 5.4.y] fs/proc: fix uaf in proc_readdir_de()

by albin_yang＠163.com

From: Wei Yang <albinwyang(a)tencent.com> commit 895b4c0c79b092d732544011c3cecaf7322c36a1 upstream. Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2) Link: https://lkml.kernel.org/r/20251025024233.158363-1-albin_yang@163.com Signed-off-by: Wei Yang <albinwyang(a)tencent.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Cc: wangzijie <wangzijie1(a)honor.com> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/generic.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/fs/proc/generic.c b/fs/proc/generic.c index 372b4dad4863..c4a7d96787f3 100644 --- a/fs/proc/generic.c +++ b/fs/proc/generic.c @@ -671,6 +671,12 @@ void pde_put(struct proc_dir_entry *pde) } } +static void pde_erase(struct proc_dir_entry *pde, struct proc_dir_entry *parent) +{ + rb_erase(&pde->subdir_node, &parent->subdir); + RB_CLEAR_NODE(&pde->subdir_node); +} + /* * Remove a /proc entry and free it if it's not currently in use. */ @@ -689,7 +695,7 @@ void remove_proc_entry(const char *name, struct proc_dir_entry *parent) de = pde_subdir_find(parent, fn, len); if (de) { - rb_erase(&de->subdir_node, &parent->subdir); + pde_erase(de, parent); if (S_ISDIR(de->mode)) { parent->nlink--; } @@ -727,13 +733,13 @@ int remove_proc_subtree(const char *name, struct proc_dir_entry *parent) write_unlock(&proc_subdir_lock); return -ENOENT; } - rb_erase(&root->subdir_node, &parent->subdir); + pde_erase(root, parent); de = root; while (1) { next = pde_subdir_first(de); if (next) { - rb_erase(&next->subdir_node, &de->subdir); + pde_erase(next, de); de = next; continue; } -- 2.43.7

2 days, 21 hours

1
0
0 0

[PATCH] nvmem: apple-spmi-nvmem: wrap regmap calls to satisfy CFI

by Jens Reidel

The Apple SPMI NVMEM driver previously cast regmap_bulk_read/write to void * when assigning them to nvmem_config's reg_read/reg_write function pointers. This cast breaks the expected function signature of nvmem_reg_read_t and nvmem_reg_write_t. With CFI enabled, indirect calls through these pointers fail: CFI failure at nvmem_reg_write+0x194/0x1e4 (target: regmap_bulk_write+0x0/0x2c8; expected type: 0x83a189c3) ... Call trace: nvmem_reg_write+0x194/0x1e4 (P) __nvmem_cell_entry_write+0x298/0x2e8 nvmem_cell_write+0x24/0x34 macsmc_reboot_probe+0x1dc/0x454 [macsmc_reboot] ... Introduce thin wrapper functions with the correct nvmem function pointer types to satisfy the CFI checks. Fixes: fe91c24a551c ("nvmem: Add apple-spmi-nvmem driver") Signed-off-by: Jens Reidel <adrian(a)mainlining.org> Reported-by: Clayton Craft <craftyguy(a)postmarketos.org> Tested-by: Clayton Craft <craftyguy(a)postmarketos.org> Cc: stable(a)vger.kernel.org --- drivers/nvmem/apple-spmi-nvmem.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/drivers/nvmem/apple-spmi-nvmem.c b/drivers/nvmem/apple-spmi-nvmem.c index 88614005d5ce1dc2d1cafcb89ac66d8376ffcc96..7acb0c07d6abe9e9984908f5ea2f4e2e9c10bb06 100644 --- a/drivers/nvmem/apple-spmi-nvmem.c +++ b/drivers/nvmem/apple-spmi-nvmem.c @@ -18,6 +18,22 @@ static const struct regmap_config apple_spmi_regmap_config = { .max_register = 0xffff, }; +static int apple_spmi_nvmem_read(void *priv, unsigned int offset, void *val, + size_t bytes) +{ + struct regmap *map = priv; + + return regmap_bulk_read(map, offset, val, bytes); +} + +static int apple_spmi_nvmem_write(void *priv, unsigned int offset, void *val, + size_t bytes) +{ + struct regmap *map = priv; + + return regmap_bulk_write(map, offset, val, bytes); +} + static int apple_spmi_nvmem_probe(struct spmi_device *sdev) { struct regmap *regmap; @@ -28,8 +44,8 @@ static int apple_spmi_nvmem_probe(struct spmi_device *sdev) .word_size = 1, .stride = 1, .size = 0xffff, - .reg_read = (void *)regmap_bulk_read, - .reg_write = (void *)regmap_bulk_write, + .reg_read = apple_spmi_nvmem_read, + .reg_write = apple_spmi_nvmem_write, }; regmap = devm_regmap_init_spmi_ext(sdev, &apple_spmi_regmap_config); --- base-commit: 0c1c7a6a83feaf2cf182c52983ffe330ffb50280 change-id: 20251118-apple-spmi-nvmem-cfi-6037c1abfd12 Best regards, -- Jens Reidel <adrian(a)mainlining.org>

3 days, 1 hour

2
1
0 0

[REGRESSION] nfs: Large amounts of GETATTR calls after file renaming on v5.10.241

by Ahmed, Aaron

Hi, We have had customers report a regression on kernels versions 5.10.241 and above in which file renaming causes large amounts of GETATTR calls to made due to inode revalidation. This regression was pinpointed via bisected to commit 7378c7adf31d ("NFS: Don't set NFS_INO_REVAL_PAGECACHE in the inode cache validity") which is a backport of 36a9346c2252 (“NFS: Don't set NFS_INO_REVAL_PAGECACHE in the inode cache validity”). We were able to reproduce It with this script: REPRO_PATH=/mnt/efs/repro do_read() { for x in {1..50} do cat $1 > /dev/null done grep GETATTR /proc/self/mountstats } echo foo > $REPRO_PATH/bar echo "After create, before read:" grep GETATTR /proc/self/mountstats echo "First read:" do_read $REPRO_PATH/bar echo "Sleeping 5s, reading again (should look the same):" sleep 5 do_read $REPRO_PATH/bar mv $REPRO_PATH/bar $REPRO_PATH/baz echo "Moved file, reading again:" do_read $REPRO_PATH/baz echo "Immediately performing another set of reads:" do_read $REPRO_PATH/baz echo "Cleanup, removing test file" rm $REPRO_PATH/baz which performs a few read/writes. On kernels without the regression the number of GETATTR calls remains the same while on affected kernels the amount increases after reading renamed file. This original commit comes from a series of patches providing attribute revalidation updates [1]. However, many of these patches are missing in v.5.10.241+. Specifically, 13c0b082b6a9 (“NFS: Replace use of NFS_INO_REVAL_PAGECACHE when checking cache validity”) seems like a prerequisite patch and would help remedy the regression. #regzbot introduced: 7378c7adf31d Thanks, Aaron Ahmed [1] https://lore.kernel.org/all/20210414134353.11860-1-trondmy@kernel.org/ Signed-off-by: Aaron Ahmed <aarnhahmd(a)amazon.com>

3 days, 6 hours

3
4
0 0

FAILED: patch "[PATCH] selftests: mptcp: join: endpoints: longer transfer" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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.6.y git checkout FETCH_HEAD git cherry-pick -x 6457595db9870298ee30b6d75287b8548e33fe19 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112027-clench-amazingly-fc3f@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6457595db9870298ee30b6d75287b8548e33fe19 Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 10 Nov 2025 19:23:42 +0100 Subject: [PATCH] selftests: mptcp: join: endpoints: longer transfer In rare cases, when the test environment is very slow, some userspace tests can fail because some expected events have not been seen. Because the tests are expecting a long on-going connection, and they are not waiting for the end of the transfer, it is fine to make the connection longer. This connection will be killed at the end, after the verifications, so making it longer doesn't change anything, apart from avoid it to end before the end of the verifications To play it safe, all endpoints tests not waiting for the end of the transfer are now sharing a longer file (128KB) at slow speed. Fixes: 69c6ce7b6eca ("selftests: mptcp: add implicit endpoint test case") Cc: stable(a)vger.kernel.org Fixes: e274f7154008 ("selftests: mptcp: add subflow limits test-cases") Fixes: b5e2fb832f48 ("selftests: mptcp: add explicit test case for remove/readd") Fixes: e06959e9eebd ("selftests: mptcp: join: test for flush/re-add endpoints") Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-3-a4332c71… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index 9ed9ec7202d6..97af8d89ac5c 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -3943,7 +3943,7 @@ endpoint_tests() pm_nl_set_limits $ns1 2 2 pm_nl_set_limits $ns2 2 2 pm_nl_add_endpoint $ns1 10.0.2.1 flags signal - { speed=slow \ + { test_linkfail=128 speed=slow \ run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null local tests_pid=$! @@ -3970,7 +3970,7 @@ endpoint_tests() pm_nl_set_limits $ns2 0 3 pm_nl_add_endpoint $ns2 10.0.1.2 id 1 dev ns2eth1 flags subflow pm_nl_add_endpoint $ns2 10.0.2.2 id 2 dev ns2eth2 flags subflow - { test_linkfail=4 speed=5 \ + { test_linkfail=128 speed=5 \ run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null local tests_pid=$! @@ -4048,7 +4048,7 @@ endpoint_tests() # broadcast IP: no packet for this address will be received on ns1 pm_nl_add_endpoint $ns1 224.0.0.1 id 2 flags signal pm_nl_add_endpoint $ns1 10.0.1.1 id 42 flags signal - { test_linkfail=4 speed=5 \ + { test_linkfail=128 speed=5 \ run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null local tests_pid=$! @@ -4121,7 +4121,7 @@ endpoint_tests() # broadcast IP: no packet for this address will be received on ns1 pm_nl_add_endpoint $ns1 224.0.0.1 id 2 flags signal pm_nl_add_endpoint $ns2 10.0.3.2 id 3 flags subflow - { test_linkfail=4 speed=20 \ + { test_linkfail=128 speed=20 \ run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null local tests_pid=$!

3 days, 6 hours

2
1
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

3 days, 11 hours

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror