December 2024 - Linux-stable-mirror

[merged mm-hotfixes-stable] mm-reinstate-ability-to-map-write-sealed-memfd-mappings-read-only.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: reinstate ability to map write-sealed memfd mappings read-only has been removed from the -mm tree. Its filename was mm-reinstate-ability-to-map-write-sealed-memfd-mappings-read-only.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Subject: mm: reinstate ability to map write-sealed memfd mappings read-only Date: Thu, 28 Nov 2024 15:06:17 +0000 Patch series "mm: reinstate ability to map write-sealed memfd mappings read-only". In commit 158978945f31 ("mm: perform the mapping_map_writable() check after call_mmap()") (and preceding changes in the same series) it became possible to mmap() F_SEAL_WRITE sealed memfd mappings read-only. Commit 5de195060b2e ("mm: resolve faulty mmap_region() error path behaviour") unintentionally undid this logic by moving the mapping_map_writable() check before the shmem_mmap() hook is invoked, thereby regressing this change. This series reworks how we both permit write-sealed mappings being mapped read-only and disallow mprotect() from undoing the write-seal, fixing this regression. We also add a regression test to ensure that we do not accidentally regress this in future. Thanks to Julian Orth for reporting this regression. This patch (of 2): In commit 158978945f31 ("mm: perform the mapping_map_writable() check after call_mmap()") (and preceding changes in the same series) it became possible to mmap() F_SEAL_WRITE sealed memfd mappings read-only. This was previously unnecessarily disallowed, despite the man page documentation indicating that it would be, thereby limiting the usefulness of F_SEAL_WRITE logic. We fixed this by adapting logic that existed for the F_SEAL_FUTURE_WRITE seal (one which disallows future writes to the memfd) to also be used for F_SEAL_WRITE. For background - the F_SEAL_FUTURE_WRITE seal clears VM_MAYWRITE for a read-only mapping to disallow mprotect() from overriding the seal - an operation performed by seal_check_write(), invoked from shmem_mmap(), the f_op->mmap() hook used by shmem mappings. By extending this to F_SEAL_WRITE and critically - checking mapping_map_writable() to determine if we may map the memfd AFTER we invoke shmem_mmap() - the desired logic becomes possible. This is because mapping_map_writable() explicitly checks for VM_MAYWRITE, which we will have cleared. Commit 5de195060b2e ("mm: resolve faulty mmap_region() error path behaviour") unintentionally undid this logic by moving the mapping_map_writable() check before the shmem_mmap() hook is invoked, thereby regressing this change. We reinstate this functionality by moving the check out of shmem_mmap() and instead performing it in do_mmap() at the point at which VMA flags are being determined, which seems in any case to be a more appropriate place in which to make this determination. In order to achieve this we rework memfd seal logic to allow us access to this information using existing logic and eliminate the clearing of VM_MAYWRITE from seal_check_write() which we are performing in do_mmap() instead. Link: https://lkml.kernel.org/r/99fc35d2c62bd2e05571cf60d9f8b843c56069e0.17328047… Fixes: 5de195060b2e ("mm: resolve faulty mmap_region() error path behaviour") Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Reported-by: Julian Orth <ju.orth(a)gmail.com> Closes: https://lore.kernel.org/all/CAHijbEUMhvJTN9Xw1GmbM266FXXv=U7s4L_Jem5x3AaPZx… Cc: Jann Horn <jannh(a)google.com> Cc: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/memfd.h | 14 +++++++++ include/linux/mm.h | 58 +++++++++++++++++++++++++++------------- mm/memfd.c | 2 - mm/mmap.c | 4 ++ 4 files changed, 59 insertions(+), 19 deletions(-) --- a/include/linux/memfd.h~mm-reinstate-ability-to-map-write-sealed-memfd-mappings-read-only +++ a/include/linux/memfd.h @@ -7,6 +7,7 @@ #ifdef CONFIG_MEMFD_CREATE extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int arg); struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx); +unsigned int *memfd_file_seals_ptr(struct file *file); #else static inline long memfd_fcntl(struct file *f, unsigned int c, unsigned int a) { @@ -16,6 +17,19 @@ static inline struct folio *memfd_alloc_ { return ERR_PTR(-EINVAL); } + +static inline unsigned int *memfd_file_seals_ptr(struct file *file) +{ + return NULL; +} #endif +/* Retrieve memfd seals associated with the file, if any. */ +static inline unsigned int memfd_file_seals(struct file *file) +{ + unsigned int *sealsp = memfd_file_seals_ptr(file); + + return sealsp ? *sealsp : 0; +} + #endif /* __LINUX_MEMFD_H */ --- a/include/linux/mm.h~mm-reinstate-ability-to-map-write-sealed-memfd-mappings-read-only +++ a/include/linux/mm.h @@ -4101,6 +4101,37 @@ void mem_dump_obj(void *object); static inline void mem_dump_obj(void *object) {} #endif +static inline bool is_write_sealed(int seals) +{ + return seals & (F_SEAL_WRITE | F_SEAL_FUTURE_WRITE); +} + +/** + * is_readonly_sealed - Checks whether write-sealed but mapped read-only, + * in which case writes should be disallowing moving + * forwards. + * @seals: the seals to check + * @vm_flags: the VMA flags to check + * + * Returns whether readonly sealed, in which case writess should be disallowed + * going forward. + */ +static inline bool is_readonly_sealed(int seals, vm_flags_t vm_flags) +{ + /* + * Since an F_SEAL_[FUTURE_]WRITE sealed memfd can be mapped as + * MAP_SHARED and read-only, take care to not allow mprotect to + * revert protections on such mappings. Do this only for shared + * mappings. For private mappings, don't need to mask + * VM_MAYWRITE as we still want them to be COW-writable. + */ + if (is_write_sealed(seals) && + ((vm_flags & (VM_SHARED | VM_WRITE)) == VM_SHARED)) + return true; + + return false; +} + /** * seal_check_write - Check for F_SEAL_WRITE or F_SEAL_FUTURE_WRITE flags and * handle them. @@ -4112,24 +4143,15 @@ static inline void mem_dump_obj(void *ob */ static inline int seal_check_write(int seals, struct vm_area_struct *vma) { - if (seals & (F_SEAL_WRITE | F_SEAL_FUTURE_WRITE)) { - /* - * New PROT_WRITE and MAP_SHARED mmaps are not allowed when - * write seals are active. - */ - if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE)) - return -EPERM; - - /* - * Since an F_SEAL_[FUTURE_]WRITE sealed memfd can be mapped as - * MAP_SHARED and read-only, take care to not allow mprotect to - * revert protections on such mappings. Do this only for shared - * mappings. For private mappings, don't need to mask - * VM_MAYWRITE as we still want them to be COW-writable. - */ - if (vma->vm_flags & VM_SHARED) - vm_flags_clear(vma, VM_MAYWRITE); - } + if (!is_write_sealed(seals)) + return 0; + + /* + * New PROT_WRITE and MAP_SHARED mmaps are not allowed when + * write seals are active. + */ + if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE)) + return -EPERM; return 0; } --- a/mm/memfd.c~mm-reinstate-ability-to-map-write-sealed-memfd-mappings-read-only +++ a/mm/memfd.c @@ -170,7 +170,7 @@ static int memfd_wait_for_pins(struct ad return error; } -static unsigned int *memfd_file_seals_ptr(struct file *file) +unsigned int *memfd_file_seals_ptr(struct file *file) { if (shmem_file(file)) return &SHMEM_I(file_inode(file))->seals; --- a/mm/mmap.c~mm-reinstate-ability-to-map-write-sealed-memfd-mappings-read-only +++ a/mm/mmap.c @@ -47,6 +47,7 @@ #include <linux/oom.h> #include <linux/sched/mm.h> #include <linux/ksm.h> +#include <linux/memfd.h> #include <linux/uaccess.h> #include <asm/cacheflush.h> @@ -368,6 +369,7 @@ unsigned long do_mmap(struct file *file, if (file) { struct inode *inode = file_inode(file); + unsigned int seals = memfd_file_seals(file); unsigned long flags_mask; if (!file_mmap_ok(file, inode, pgoff, len)) @@ -408,6 +410,8 @@ unsigned long do_mmap(struct file *file, vm_flags |= VM_SHARED | VM_MAYSHARE; if (!(file->f_mode & FMODE_WRITE)) vm_flags &= ~(VM_MAYWRITE | VM_SHARED); + else if (is_readonly_sealed(seals, vm_flags)) + vm_flags &= ~VM_MAYWRITE; fallthrough; case MAP_PRIVATE: if (!(file->f_mode & FMODE_READ)) _ Patches currently in -mm which might be from lorenzo.stoakes(a)oracle.com are mm-vma-move-brk-internals-to-mm-vmac.patch mm-vma-move-brk-internals-to-mm-vmac-fix.patch mm-vma-move-unmapped_area-internals-to-mm-vmac.patch mm-abstract-get_arg_page-stack-expansion-and-mmap-read-lock.patch mm-vma-move-stack-expansion-logic-to-mm-vmac.patch mm-vma-move-__vm_munmap-to-mm-vmac.patch selftests-mm-add-fork-cow-guard-page-test.patch mm-enforce-__must_check-on-vma-merge-and-split.patch mm-perform-all-memfd-seal-checks-in-a-single-place.patch mm-perform-all-memfd-seal-checks-in-a-single-place-fix.patch maintainers-update-memory-mapping-section.patch mm-assert-mmap-write-lock-held-on-do_mmap-mmap_region.patch mm-add-comments-to-do_mmap-mmap_region-and-vm_mmap.patch tools-testing-add-simple-__mmap_region-userland-test.patch

7 months, 4 weeks

1
0
0 0

[folded-merged] maple_tree-reload-mas-before-the-second-call-for-mas_empty_area-fix.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: maple_tree: fix mas_alloc_cyclic() second search has been removed from the -mm tree. Its filename was maple_tree-reload-mas-before-the-second-call-for-mas_empty_area-fix.patch This patch was dropped because it was folded into maple_tree-reload-mas-before-the-second-call-for-mas_empty_area.patch ------------------------------------------------------ From: "Liam R. Howlett" <Liam.Howlett(a)Oracle.com> Subject: maple_tree: fix mas_alloc_cyclic() second search Date: Mon, 16 Dec 2024 14:01:12 -0500 The first search may leave the maple state in an error state. Reset the maple state before the second search so that the search has a chance of executing correctly after an exhausted first search. Link: https://lore.kernel.org/all/20241216060600.287B4C4CED0@smtp.kernel.org/ Link: https://lkml.kernel.org/r/20241216190113.1226145-2-Liam.Howlett@oracle.com Fixes: 9b6713cc7522 ("maple_tree: Add mtree_alloc_cyclic()") Signed-off-by: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Chuck Lever <chuck.lever(a)oracle.com> says: Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/maple_tree.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/lib/maple_tree.c~maple_tree-reload-mas-before-the-second-call-for-mas_empty_area-fix +++ a/lib/maple_tree.c @@ -4346,7 +4346,6 @@ int mas_alloc_cyclic(struct ma_state *ma { unsigned long min = range_lo; int ret = 0; - struct ma_state m = *mas; range_lo = max(min, *next); ret = mas_empty_area(mas, range_lo, range_hi, 1); @@ -4355,7 +4354,7 @@ int mas_alloc_cyclic(struct ma_state *ma ret = 1; } if (ret < 0 && range_lo > min) { - *mas = m; + mas_reset(mas); ret = mas_empty_area(mas, min, range_hi, 1); if (ret == 0) ret = 1; _ Patches currently in -mm which might be from Liam.Howlett(a)Oracle.com are maple_tree-reload-mas-before-the-second-call-for-mas_empty_area.patch test_maple_tree-test-exhausted-upper-limit-of-mtree_alloc_cyclic.patch

7 months, 4 weeks

1
0
0 0

[PATCH net] gve: trigger RX NAPI instead of TX NAPI in gve_xsk_wakeup

by Praveen Kaligineedi

From: Joshua Washington <joshwash(a)google.com> Commit ba0925c34e0f ("gve: process XSK TX descriptors as part of RX NAPI") moved XSK TX processing to be part of the RX NAPI. However, that commit did not include triggering the RX NAPI in gve_xsk_wakeup. This is necessary because the TX NAPI only processes TX completions, meaning that a TX wakeup would not actually trigger XSK descriptor processing. Also, the branch on XDP_WAKEUP_TX was supposed to have been removed, as the NAPI should be scheduled whether the wakeup is for RX or TX. Fixes: ba0925c34e0f ("gve: process XSK TX descriptors as part of RX NAPI") Cc: stable(a)vger.kernel.org Signed-off-by: Joshua Washington <joshwash(a)google.com> Signed-off-by: Praveen Kaligineedi <pkaligineedi(a)google.com> --- drivers/net/ethernet/google/gve/gve_main.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c index 09fb7f16f73e..8a8f6ab12a98 100644 --- a/drivers/net/ethernet/google/gve/gve_main.c +++ b/drivers/net/ethernet/google/gve/gve_main.c @@ -1714,7 +1714,7 @@ static int gve_xsk_pool_disable(struct net_device *dev, static int gve_xsk_wakeup(struct net_device *dev, u32 queue_id, u32 flags) { struct gve_priv *priv = netdev_priv(dev); - int tx_queue_id = gve_xdp_tx_queue_id(priv, queue_id); + struct napi_struct *napi; if (!gve_get_napi_enabled(priv)) return -ENETDOWN; @@ -1722,19 +1722,12 @@ static int gve_xsk_wakeup(struct net_device *dev, u32 queue_id, u32 flags) if (queue_id >= priv->rx_cfg.num_queues || !priv->xdp_prog) return -EINVAL; - if (flags & XDP_WAKEUP_TX) { - struct gve_tx_ring *tx = &priv->tx[tx_queue_id]; - struct napi_struct *napi = - &priv->ntfy_blocks[tx->ntfy_id].napi; - - if (!napi_if_scheduled_mark_missed(napi)) { - /* Call local_bh_enable to trigger SoftIRQ processing */ - local_bh_disable(); - napi_schedule(napi); - local_bh_enable(); - } - - tx->xdp_xsk_wakeup++; + napi = &priv->ntfy_blocks[gve_rx_idx_to_ntfy(priv, queue_id)].napi; + if (!napi_if_scheduled_mark_missed(napi)) { + /* Call local_bh_enable to trigger SoftIRQ processing */ + local_bh_disable(); + napi_schedule(napi); + local_bh_enable(); } return 0; -- 2.47.1.613.gc27f4b7a9f-goog

7 months, 4 weeks

2
1
0 0

btrfs: lsblk multiple mount point issue on LTS 6.6

by Mike Pagano

Greg, A Gentoo user found an issue with btrfs where: "... upstream commit a5d74fa24752 ("btrfs: avoid unnecessary device path update for the same device") breaks 6.6 LTS kernel behavior where previously lsblk can properly show multiple mount points of the same btrfs" There's a revert on the bug report [1]. The fix by the author can be found on linux-btrfs [2] [1] https://bugs.gentoo.org/947126 [2] https://lore.kernel.org/linux-btrfs/30aefd8b4e8c1f0c5051630b106a1ff3570d28e… Mike -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpagano(a)gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137&op=index

7 months, 4 weeks

2
1
0 0

[PATCH v2 1/2] fs/proc: do_task_stat: Fix ESP not readable during coredump

by Nam Cao

The field "eip" (instruction pointer) and "esp" (stack pointer) of a task can be read from /proc/PID/stat. These fields can be interesting for coredump. However, these fields were disabled by commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in /proc/PID/stat"), because it is generally unsafe to do so. But it is safe for a coredumping process, and therefore exceptions were made: - for a coredumping thread by commit fd7d56270b52 ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping"). - for all other threads in a coredumping process by commit cb8f381f1613 ("fs/proc/array.c: allow reporting eip/esp for all coredumping threads"). The above two commits check the PF_DUMPCORE flag to determine a coredump thread and the PF_EXITING flag for the other threads. Unfortunately, commit 92307383082d ("coredump: Don't perform any cleanups before dumping core") moved coredump to happen earlier and before PF_EXITING is set. Thus, checking PF_EXITING is no longer the correct way to determine threads in a coredumping process. Instead of PF_EXITING, use PF_POSTCOREDUMP to determine the other threads. Checking of PF_EXITING was added for coredumping, so it probably can now be removed. But it doesn't hurt to keep. Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping core") Cc: stable(a)vger.kernel.org Cc: Eric W. Biederman <ebiederm(a)xmission.com> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Signed-off-by: Nam Cao <namcao(a)linutronix.de> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index 55ed3510d2bb..d6a0369caa93 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -500,7 +500,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, * a program is not able to use ptrace(2) in that case. It is * safe because the task has stopped executing permanently. */ - if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE))) { + if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE|PF_POSTCOREDUMP))) { if (try_get_task_stack(task)) { eip = KSTK_EIP(task); esp = KSTK_ESP(task); -- 2.39.5

7 months, 4 weeks

2
1
0 0

Re: [PATCH 6.12 000/114] 6.12.8-rc1 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

7 months, 4 weeks

1
0
0 0

Re: Patch "watchdog: s3c2410_wdt: add support for exynosautov920 SoC" has been added to the 6.12-stable tree

by Krzysztof Kozlowski

On 28/12/2024 15:20, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > watchdog: s3c2410_wdt: add support for exynosautov920 SoC > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > watchdog-s3c2410_wdt-add-support-for-exynosautov920-.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. This is a new device support, depending on several other pieces like syscon support, Exynos PMU and of course arm64/boot/dts patches. It really relies on the rest of SoC support and alone is useless. This is way beyond simple quirks thus I believe it does not meet stable criteria at all. Based on that I recommend to drop this patch from stable backports. Best regards, Krzysztof

7 months, 4 weeks

2
1
0 0

[PATCH stable 5.15] net:dsa:fix the dsa_ptr null pointer dereference

by jiang.kun2＠zte.com.cn

From: Peilin He<he.peilin(a)zte.com.cn> Upstream commit 6c24a03a61a2 ("net: dsa: improve shutdown sequence") Issue ===== Repeatedly accessing the DSA Ethernet controller via the ethtool command, followed by a system reboot, may trigger a DSA null pointer dereference, causing a kernel panic and preventing the system from rebooting properly. This can lead to data loss or denial-of-service, resulting in serious consequences. The following is the panic log: [ 172.523467] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 [ 172.706923] Call trace: [ 172.709371] dsa_master_get_sset_count+0x24/0xa4 [ 172.714000] ethtool_get_drvinfo+0x8c/0x210 [ 172.718193] dev_ethtool+0x780/0x2120 [ 172.721863] dev_ioctl+0x1b0/0x580 [ 172.725273] sock_do_ioctl+0xc0/0x100 [ 172.728944] sock_ioctl+0x130/0x3c0 [ 172.732440] __arm64_sys_ioctl+0xb4/0x100 [ 172.736460] invoke_syscall+0x50/0x120 [ 172.740219] el0_svc_common.constprop.0+0x4c/0xf4 [ 172.744936] do_el0_svc+0x2c/0xa0 [ 172.748257] el0_svc+0x20/0x60 [ 172.751318] el0t_64_sync_handler+0xe8/0x114 [ 172.755599] el0t_64_sync+0x180/0x184 [ 172.759271] Code: a90153f3 2a0103f4 a9025bf5 f9418015 (f94012b6) [ 172.765383] ---[ end trace 0000000000000002 ]--- Root Cause ========== Based on analysis of the Linux 5.15 stable version, the function dsa_master_get_sset_count() accesses members of the structure pointed to by cpu_dp without checking for a null pointer. If cpu_dp is a null pointer, this will cause a kernel panic. static int dsa_master_get_sset_count(struct net_device *dev, int sset) { struct dsa_port *cpu_dp = dev->dsa_ptr; const struct ethtool_ops *ops = cpu_dp->orig_ethtool_ops; struct dsa_switch *ds = cpu_dp->ds; ... } dev->dsa_ptr is set to NULL in the dsa_switch_shutdown() or dsa_master_teardown() functions. When the DSA module unloads, dsa_master_ethtool_teardown(dev) restores the original copy of the DSA device's ethtool_ops using "dev->ethtool_ops = cpu_dp->orig_ethtool_ops;" before setting dev->dsa_ptr to NULL. This ensures that ethtool_ops remains accessible after DSA unloads. However, dsa_switch_shutdown does not restore the original copy of the DSA device's ethtool_ops, potentially leading to a null pointer dereference of dsa_ptr and causing a system panic. Essentially, when we set master->dsa_ptr to NULL, we need to ensure that no user ports are making requests to the DSA driver. Solution ======== The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. Fixes: ee534378f005 ("net: dsa: fix panic when DSA master device unbinds on shutdown") Suggested-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Signed-off-by: Peilin He <he.peilin(a)zte.com.cn> Reviewed-by: xu xin <xu.xin16(a)zte.com.cn> Signed-off-by: Kun Jiang <jiang.kun2(a)zte.com.cn> Cc: Fan Yu <fan.yu9(a)zte.com.cn> Cc: Yutan Qiu <qiu.yutan(a)zte.com.cn> Cc: Yaxin Wang <wang.yaxin(a)zte.com.cn> Cc: tuqiang <tu.qiang35(a)zte.com.cn> Cc: Yang Yang <yang.yang29(a)zte.com.cn> Cc: ye xingchen <ye.xingchen(a)zte.com.cn> Cc: Yunkai Zhang <zhang.yunkai(a)zte.com.cn> --- net/dsa/dsa2.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c index 543834e31298..bf384b30ec0a 100644 --- a/net/dsa/dsa2.c +++ b/net/dsa/dsa2.c @@ -1656,6 +1656,7 @@ EXPORT_SYMBOL_GPL(dsa_unregister_switch); void dsa_switch_shutdown(struct dsa_switch *ds) { struct net_device *master, *slave_dev; + LIST_HEAD(close_list); struct dsa_port *dp; mutex_lock(&dsa2_mutex); @@ -1665,6 +1666,11 @@ void dsa_switch_shutdown(struct dsa_switch *ds) rtnl_lock(); + dsa_switch_for_each_cpu_port(dp, ds) + list_add(&dp->master->close_list, &close_list); + + dev_close_many(&close_list, true); + list_for_each_entry(dp, &ds->dst->ports, list) { if (dp->ds != ds) continue; @@ -1675,6 +1681,7 @@ void dsa_switch_shutdown(struct dsa_switch *ds) master = dp->cpu_dp->master; slave_dev = dp->slave; + netif_device_detach(slave_dev); netdev_upper_dev_unlink(master, slave_dev); } -- 2.25.1

7 months, 4 weeks

2
1
0 0

[PATCH 6/6] nvmem: core: improve range check for nvmem_cell_write()

by srinivas.kandagatla＠linaro.org

From: Jennifer Berringer <jberring(a)redhat.com> When __nvmem_cell_entry_write() is called for an nvmem cell that does not need bit shifting, it requires that the len parameter exactly matches the nvmem cell size. However, when the nvmem cell has a nonzero bit_offset, it was skipping this check. Accepting values of len larger than the cell size results in nvmem_cell_prepare_write_buffer() trying to write past the end of a heap buffer that it allocates. Add a check to avoid that problem and instead return -EINVAL when len doesn't match the number of bits expected by the nvmem cell when bit_offset is nonzero. This check uses cell->nbits in order to allow providing the smaller size to cells that are shifted into another byte by bit_offset. For example, a cell with nbits=8 and nonzero bit_offset would have bytes=2 but should accept a 1-byte write here, although no current callers depend on this. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Cc: stable(a)vger.kernel.org Signed-off-by: Jennifer Berringer <jberring(a)redhat.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- drivers/nvmem/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index d6494dfc20a7..845540b57e68 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -1790,6 +1790,8 @@ static int __nvmem_cell_entry_write(struct nvmem_cell_entry *cell, void *buf, si return -EINVAL; if (cell->bit_offset || cell->nbits) { + if (len != BITS_TO_BYTES(cell->nbits) && len != cell->bytes) + return -EINVAL; buf = nvmem_cell_prepare_write_buffer(cell, buf, len); if (IS_ERR(buf)) return PTR_ERR(buf); -- 2.25.1

7 months, 4 weeks

1
0
0 0

[PATCH 5/6] nvmem: qcom-spmi-sdam: Set size in struct nvmem_config

by srinivas.kandagatla＠linaro.org

From: Luca Weiss <luca.weiss(a)fairphone.com> Let the nvmem core know what size the SDAM is, most notably this fixes the size of /sys/bus/nvmem/devices/spmi_sdam*/nvmem being '0' and makes user space work with that file. ~ # hexdump -C -s 64 /sys/bus/nvmem/devices/spmi_sdam2/nvmem 00000040 02 01 00 00 04 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 Fixes: 40ce9798794f ("nvmem: add QTI SDAM driver") Cc: stable(a)vger.kernel.org Signed-off-by: Luca Weiss <luca.weiss(a)fairphone.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy(a)linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- drivers/nvmem/qcom-spmi-sdam.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/nvmem/qcom-spmi-sdam.c b/drivers/nvmem/qcom-spmi-sdam.c index 9aa8f42faa4c..4f1cca6eab71 100644 --- a/drivers/nvmem/qcom-spmi-sdam.c +++ b/drivers/nvmem/qcom-spmi-sdam.c @@ -144,6 +144,7 @@ static int sdam_probe(struct platform_device *pdev) sdam->sdam_config.owner = THIS_MODULE; sdam->sdam_config.add_legacy_fixed_of_cells = true; sdam->sdam_config.stride = 1; + sdam->sdam_config.size = sdam->size; sdam->sdam_config.word_size = 1; sdam->sdam_config.reg_read = sdam_read; sdam->sdam_config.reg_write = sdam_write; -- 2.25.1

7 months, 4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024