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

[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>

1 week, 6 days

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>

1 week, 6 days

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=$!

1 week, 6 days

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

2 weeks

3
2
0 0

IAA Mobility 2025 Attendees Contacts!

by Grace Taylor

Hi, Great news — the final verified attendee list of the IAA Mobility 2025 is now available. This exclusive database includes 501,847 high-value contacts, complete with all last-minute registrations and walk-ins. For a short time, we’re offering an exclusive 30% discount, making this the perfect opportunity to strengthen your pipeline and accelerate your outreach. If you want to review the full details, simply reply “Send the Price” and I’ll send everything over immediately. Your list will be delivered within 48 hours. Don’t miss out on this limited offer — happy to assist you in getting started. Kind regards, Grace Taylor Sr. Demand Generation If you’d prefer not to receive these updates, reply “No.”

2 weeks

1
0
0 0

[PATCH v3] powerpc, mm: Fix mprotect on book3s 32-bit

by Dave Vasilevsky

On 32-bit book3s with hash-MMUs, tlb_flush() was a no-op. This was unnoticed because all uses until recently were for unmaps, and thus handled by __tlb_remove_tlb_entry(). After commit 4a18419f71cd ("mm/mprotect: use mmu_gather") in kernel 5.19, tlb_gather_mmu() started being used for mprotect as well. This caused mprotect to simply not work on these machines: int *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); *ptr = 1; // force HPTE to be created mprotect(ptr, 4096, PROT_READ); *ptr = 2; // should segfault, but succeeds Fixed by making tlb_flush() actually flush TLB pages. This finally agrees with the behaviour of boot3s64's tlb_flush(). Fixes: 4a18419f71cd ("mm/mprotect: use mmu_gather") Cc: stable(a)vger.kernel.org Reviewed-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list(a)gmail.com> Signed-off-by: Dave Vasilevsky <dave(a)vasilevsky.ca> --- Changes in v3: - Fix formatting - Link to v2: https://lore.kernel.org/r/20251111-vasi-mprotect-g3-v2-1-881c94afbc42@vasil… Changes in v2: - Flush entire TLB if full mm is requested. - Link to v1: https://lore.kernel.org/r/20251027-vasi-mprotect-g3-v1-1-3c5187085f9a@vasil… --- arch/powerpc/include/asm/book3s/32/tlbflush.h | 5 ++++- arch/powerpc/mm/book3s32/tlb.c | 9 +++++++++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/book3s/32/tlbflush.h b/arch/powerpc/include/asm/book3s/32/tlbflush.h index e43534da5207aa3b0cb3c07b78e29b833c141f3f..4be2200a3c7e1e8307f5ce1f1d5d28047429c106 100644 --- a/arch/powerpc/include/asm/book3s/32/tlbflush.h +++ b/arch/powerpc/include/asm/book3s/32/tlbflush.h @@ -11,6 +11,7 @@ void hash__flush_tlb_mm(struct mm_struct *mm); void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr); void hash__flush_range(struct mm_struct *mm, unsigned long start, unsigned long end); +void hash__flush_gather(struct mmu_gather *tlb); #ifdef CONFIG_SMP void _tlbie(unsigned long address); @@ -29,7 +30,9 @@ void _tlbia(void); static inline void tlb_flush(struct mmu_gather *tlb) { /* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ - if (!mmu_has_feature(MMU_FTR_HPTE_TABLE)) + if (mmu_has_feature(MMU_FTR_HPTE_TABLE)) + hash__flush_gather(tlb); + else _tlbia(); } diff --git a/arch/powerpc/mm/book3s32/tlb.c b/arch/powerpc/mm/book3s32/tlb.c index 9ad6b56bfec96e989b96f027d075ad5812500854..e54a7b0112322e5818d80facd2e3c7722e6dd520 100644 --- a/arch/powerpc/mm/book3s32/tlb.c +++ b/arch/powerpc/mm/book3s32/tlb.c @@ -105,3 +105,12 @@ void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr) flush_hash_pages(mm->context.id, vmaddr, pmd_val(*pmd), 1); } EXPORT_SYMBOL(hash__flush_tlb_page); + +void hash__flush_gather(struct mmu_gather *tlb) +{ + if (tlb->fullmm || tlb->need_flush_all) + hash__flush_tlb_mm(tlb->mm); + else + hash__flush_range(tlb->mm, tlb->start, tlb->end); +} +EXPORT_SYMBOL(hash__flush_gather); --- base-commit: 24172e0d79900908cf5ebf366600616d29c9b417 change-id: 20251027-vasi-mprotect-g3-f8f5278d4140 Best regards, -- Dave Vasilevsky <dave(a)vasilevsky.ca>

2 weeks

2
1
0 0

[PATCH] net: dsa: Fix error handling in dsa_port_parse_of

by Ma Ke

When of_find_net_device_by_node() successfully acquires a reference to a network device but the subsequent call to dsa_port_parse_cpu() fails, dsa_port_parse_of() returns without releasing the reference count on the network device. of_find_net_device_by_node() increments the reference count of the returned structure, which should be balanced with a corresponding put_device() when the reference is no longer needed. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 6ca80638b90c ("net: dsa: Use conduit and user terms") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- net/dsa/dsa.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c index 5b01a0e43ebe..632e0d716d62 100644 --- a/net/dsa/dsa.c +++ b/net/dsa/dsa.c @@ -1246,6 +1246,7 @@ static int dsa_port_parse_of(struct dsa_port *dp, struct device_node *dn) struct device_node *ethernet = of_parse_phandle(dn, "ethernet", 0); const char *name = of_get_property(dn, "label", NULL); bool link = of_property_read_bool(dn, "link"); + int err; dp->dn = dn; @@ -1259,7 +1260,13 @@ static int dsa_port_parse_of(struct dsa_port *dp, struct device_node *dn) return -EPROBE_DEFER; user_protocol = of_get_property(dn, "dsa-tag-protocol", NULL); - return dsa_port_parse_cpu(dp, conduit, user_protocol); + err = dsa_port_parse_cpu(dp, conduit, user_protocol); + if (err) { + put_device(conduit); + return err; + } + + return 0; } if (link) -- 2.17.1

2 weeks

5
5
0 0

[PATCH v2] mm/memfd: fix information leak in hugetlb folios

by Deepanshu Kartikey

When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd. Reported-by: syzbot+f64019ba229e3a5c411b(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/20251112031631.2315651-1-kartikey406@gmail.com/ [v1] Closes: https://syzkaller.appspot.com/bug?extid=f64019ba229e3a5c411b Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios") Cc: stable(a)vger.kernel.org Suggested-by: Oscar Salvador <osalvador(a)suse.de> Suggested-by: David Hildenbrand <david(a)redhat.com> Tested-by: syzbot+f64019ba229e3a5c411b(a)syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> --- v1 -> v2: - Use folio_zero_user() instead of folio_zero_range() (optimized for huge pages) - Add folio_mark_uptodate() before adding to page cache - Add hugetlb_fault_mutex locking around hugetlb_add_to_page_cache() - Add Fixes: tag and Cc: stable for backporting - Add Suggested-by: tags for Oscar and David --- mm/memfd.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/mm/memfd.c b/mm/memfd.c index 1d109c1acf21..d32eef58d154 100644 --- a/mm/memfd.c +++ b/mm/memfd.c @@ -96,9 +96,36 @@ struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx) NULL, gfp_mask); if (folio) { + u32 hash; + + /* + * Zero the folio to prevent information leaks to userspace. + * Use folio_zero_user() which is optimized for huge/gigantic + * pages. Pass 0 as addr_hint since this is not a faulting path + * and we don't have a user virtual address yet. + */ + folio_zero_user(folio, 0); + + /* + * Mark the folio uptodate before adding to page cache, + * as required by filemap.c and other hugetlb paths. + */ + __folio_mark_uptodate(folio); + + /* + * Serialize hugepage allocation and instantiation to prevent + * races with concurrent allocations, as required by all other + * callers of hugetlb_add_to_page_cache(). + */ + hash = hugetlb_fault_mutex_hash(memfd->f_mapping, idx); + mutex_lock(&hugetlb_fault_mutex_table[hash]); + err = hugetlb_add_to_page_cache(folio, memfd->f_mapping, idx); + + mutex_unlock(&hugetlb_fault_mutex_table[hash]); + if (err) { folio_put(folio); goto err_unresv; -- 2.43.0

2 weeks

4
4
0 0

[tip: timers/urgent] timers: Fix NULL function pointer race in timer_shutdown_sync()

by tip-bot2 for Yipeng Zou

The following commit has been merged into the timers/urgent branch of tip: Commit-ID: 20739af07383e6eb1ec59dcd70b72ebfa9ac362c Gitweb: https://git.kernel.org/tip/20739af07383e6eb1ec59dcd70b72ebfa9ac362c Author: Yipeng Zou <zouyipeng(a)huawei.com> AuthorDate: Sat, 22 Nov 2025 09:39:42 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Sat, 22 Nov 2025 22:55:26 +01:00 timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running. Fixes: 0cc04e80458a ("timers: Add shutdown mechanism to the internal functions") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251122093942.301559-1-zouyipeng@huawei.com --- kernel/time/timer.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 553fa46..d5ebb1d 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1458,10 +1458,11 @@ static int __try_to_del_timer_sync(struct timer_list *timer, bool shutdown) base = lock_timer_base(timer, &flags); - if (base->running_timer != timer) + if (base->running_timer != timer) { ret = detach_if_pending(timer, base, true); - if (shutdown) - timer->function = NULL; + if (shutdown) + timer->function = NULL; + } raw_spin_unlock_irqrestore(&base->lock, flags);

2 weeks

1
0
0 0

Urgent Financial Management Opportunity.

by Dr. Malik

2 weeks, 1 day

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror