July 2024 - Linux-stable-mirror

[PATCH backport 5.10.y] bpf, sockmap: Fix sk->sk_forward_alloc warn_on in sk_stream_kill_queues

by Wen Gu

From: Wang Yufen <wangyufen(a)huawei.com> [ Upstream commit d8616ee2affcff37c5d315310da557a694a3303d ] During TCP sockmap redirect pressure test, the following warning is triggered: WARNING: CPU: 3 PID: 2145 at net/core/stream.c:205 sk_stream_kill_queues+0xbc/0xd0 CPU: 3 PID: 2145 Comm: iperf Kdump: loaded Tainted: G W 5.10.0+ #9 Call Trace: inet_csk_destroy_sock+0x55/0x110 inet_csk_listen_stop+0xbb/0x380 tcp_close+0x41b/0x480 inet_release+0x42/0x80 __sock_release+0x3d/0xa0 sock_close+0x11/0x20 __fput+0x9d/0x240 task_work_run+0x62/0x90 exit_to_user_mode_prepare+0x110/0x120 syscall_exit_to_user_mode+0x27/0x190 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The reason we observed is that: When the listener is closing, a connection may have completed the three-way handshake but not accepted, and the client has sent some packets. The child sks in accept queue release by inet_child_forget()->inet_csk_destroy_sock(), but psocks of child sks have not released. To fix, add sock_map_destroy to release psocks. Signed-off-by: Wang Yufen <wangyufen(a)huawei.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Acked-by: Jakub Sitnicki <jakub(a)cloudflare.com> Acked-by: John Fastabend <john.fastabend(a)gmail.com> Link: https://lore.kernel.org/bpf/20220524075311.649153-1-wangyufen@huawei.com Stable-dep-of: 8bbabb3fddcd ("bpf, sock_map: Move cancel_work_sync() out of sock lock") Signed-off-by: Sasha Levin <sashal(a)kernel.org> [Conflict in include/linux/bpf.h due to function declaration position and remove non-existed sk_psock_stop helper from sock_map_destroy.] Signed-off-by: Wen Gu <guwen(a)linux.alibaba.com> --- background: Link: https://lore.kernel.org/stable/d11bc7e6-a2c7-445a-8561-3599eafb07b0@linux.a… @stable team: This backport has 2 changes compared to the original patch: - fix conflict due to sock_map_destroy declaration position in include/linux/bpf.h; - remove the non-existed sk_psock_stop helper from sock_map_destroy. This helper is introduced by 799aa7f98d53 ("skmsg: Avoid lock_sock() in sk_psock_backlog()") after v5.10, it is not a fix and hard to backport. Considering that what did in sk_psock_stop is done in sk_psock_drop and neither sock_map_close nor sock_map_unhash in v5.10 introduces sk_psock_stop, I removed it from sock_map_destroy too. I tested it in my environment, the regression was gone. Cc: Wang Yufen <wangyufen(a)huawei.com> @Yufen, if I missed anything, please point it out, thanks! --- include/linux/bpf.h | 1 + include/linux/skmsg.h | 1 + net/core/skmsg.c | 1 + net/core/sock_map.c | 22 ++++++++++++++++++++++ net/ipv4/tcp_bpf.c | 1 + 5 files changed, 26 insertions(+) diff --git a/include/linux/bpf.h b/include/linux/bpf.h index a75faf437e75..340f4fef5b5a 100644 --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -1800,6 +1800,7 @@ int sock_map_get_from_fd(const union bpf_attr *attr, struct bpf_prog *prog); int sock_map_prog_detach(const union bpf_attr *attr, enum bpf_prog_type ptype); int sock_map_update_elem_sys(struct bpf_map *map, void *key, void *value, u64 flags); void sock_map_unhash(struct sock *sk); +void sock_map_destroy(struct sock *sk); void sock_map_close(struct sock *sk, long timeout); #else static inline int sock_map_prog_update(struct bpf_map *map, diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h index 1138dd3071db..e2af013ec05f 100644 --- a/include/linux/skmsg.h +++ b/include/linux/skmsg.h @@ -98,6 +98,7 @@ struct sk_psock { spinlock_t link_lock; refcount_t refcnt; void (*saved_unhash)(struct sock *sk); + void (*saved_destroy)(struct sock *sk); void (*saved_close)(struct sock *sk, long timeout); void (*saved_write_space)(struct sock *sk); struct proto *sk_proto; diff --git a/net/core/skmsg.c b/net/core/skmsg.c index bb4fbc60b272..51792dda1b73 100644 --- a/net/core/skmsg.c +++ b/net/core/skmsg.c @@ -599,6 +599,7 @@ struct sk_psock *sk_psock_init(struct sock *sk, int node) psock->eval = __SK_NONE; psock->sk_proto = prot; psock->saved_unhash = prot->unhash; + psock->saved_destroy = prot->destroy; psock->saved_close = prot->close; psock->saved_write_space = sk->sk_write_space; diff --git a/net/core/sock_map.c b/net/core/sock_map.c index 52e395a189df..d1d0ee2dbfaa 100644 --- a/net/core/sock_map.c +++ b/net/core/sock_map.c @@ -1566,6 +1566,28 @@ void sock_map_unhash(struct sock *sk) saved_unhash(sk); } +void sock_map_destroy(struct sock *sk) +{ + void (*saved_destroy)(struct sock *sk); + struct sk_psock *psock; + + rcu_read_lock(); + psock = sk_psock_get(sk); + if (unlikely(!psock)) { + rcu_read_unlock(); + if (sk->sk_prot->destroy) + sk->sk_prot->destroy(sk); + return; + } + + saved_destroy = psock->saved_destroy; + sock_map_remove_links(sk, psock); + rcu_read_unlock(); + sk_psock_put(sk, psock); + saved_destroy(sk); +} +EXPORT_SYMBOL_GPL(sock_map_destroy); + void sock_map_close(struct sock *sk, long timeout) { void (*saved_close)(struct sock *sk, long timeout); diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c index d0ca1fc325cd..f909e440bb22 100644 --- a/net/ipv4/tcp_bpf.c +++ b/net/ipv4/tcp_bpf.c @@ -582,6 +582,7 @@ static void tcp_bpf_rebuild_protos(struct proto prot[TCP_BPF_NUM_CFGS], struct proto *base) { prot[TCP_BPF_BASE] = *base; + prot[TCP_BPF_BASE].destroy = sock_map_destroy; prot[TCP_BPF_BASE].close = sock_map_close; prot[TCP_BPF_BASE].recvmsg = tcp_bpf_recvmsg; prot[TCP_BPF_BASE].stream_memory_read = tcp_bpf_stream_read; -- 2.32.0.3.g01195cf9f

4 days, 15 hours

1
0
0 0

+ mm-fix-crashes-from-deferred-split-racing-folio-migration.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix crashes from deferred split racing folio migration has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-fix-crashes-from-deferred-split-racing-folio-migration.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: mm: fix crashes from deferred split racing folio migration Date: Tue, 2 Jul 2024 00:40:55 -0700 (PDT) Even on 6.10-rc6, I've been seeing elusive "Bad page state"s (often on flags when freeing, yet the flags shown are not bad: PG_locked had been set and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from deferred_split_scan()'s folio_put(), and a variety of other BUG and WARN symptoms implying double free by deferred split and large folio migration. 6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large folio migration") was right to fix the memcg-dependent locking broken in 85ce2c517ade ("memcontrol: only transfer the memcg data for migration"), but missed a subtlety of deferred_split_scan(): it moves folios to its own local list to work on them without split_queue_lock, during which time folio->_deferred_list is not empty, but even the "right" lock does nothing to secure the folio and the list it is on. Fortunately, deferred_split_scan() is careful to use folio_try_get(): so folio_migrate_mapping() can avoid the race by folio_undo_large_rmappable() while the old folio's reference count is temporarily frozen to 0 - adding such a freeze in the !mapping case too (originally, folio lock and unmapping and no swap cache left an anon folio unreachable, so no freezing was needed there: but the deferred split queue offers a way to reach it). Link: https://lkml.kernel.org/r/29c83d1a-11ca-b6c9-f92e-6ccb322af510@google.com Fixes: 9bcef5973e31 ("mm: memcg: fix split queue list crash when large folio migration") Signed-off-by: Hugh Dickins <hughd(a)google.com> Reviewed-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Barry Song <baohua(a)kernel.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Yang Shi <shy828301(a)gmail.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memcontrol.c | 11 ----------- mm/migrate.c | 13 +++++++++++++ 2 files changed, 13 insertions(+), 11 deletions(-) --- a/mm/memcontrol.c~mm-fix-crashes-from-deferred-split-racing-folio-migration +++ a/mm/memcontrol.c @@ -7823,17 +7823,6 @@ void mem_cgroup_migrate(struct folio *ol /* Transfer the charge and the css ref */ commit_charge(new, memcg); - /* - * If the old folio is a large folio and is in the split queue, it needs - * to be removed from the split queue now, in case getting an incorrect - * split queue in destroy_large_folio() after the memcg of the old folio - * is cleared. - * - * In addition, the old folio is about to be freed after migration, so - * removing from the split queue a bit earlier seems reasonable. - */ - if (folio_test_large(old) && folio_test_large_rmappable(old)) - folio_undo_large_rmappable(old); old->memcg_data = 0; } --- a/mm/migrate.c~mm-fix-crashes-from-deferred-split-racing-folio-migration +++ a/mm/migrate.c @@ -415,6 +415,15 @@ int folio_migrate_mapping(struct address if (folio_ref_count(folio) != expected_count) return -EAGAIN; + /* Take off deferred split queue while frozen and memcg set */ + if (folio_test_large(folio) && + folio_test_large_rmappable(folio)) { + if (!folio_ref_freeze(folio, expected_count)) + return -EAGAIN; + folio_undo_large_rmappable(folio); + folio_ref_unfreeze(folio, expected_count); + } + /* No turning back from here */ newfolio->index = folio->index; newfolio->mapping = folio->mapping; @@ -433,6 +442,10 @@ int folio_migrate_mapping(struct address return -EAGAIN; } + /* Take off deferred split queue while frozen and memcg set */ + if (folio_test_large(folio) && folio_test_large_rmappable(folio)) + folio_undo_large_rmappable(folio); + /* * Now we know that no one else is looking at the folio: * no turning back from here. _ Patches currently in -mm which might be from hughd(a)google.com are mm-fix-crashes-from-deferred-split-racing-folio-migration.patch

4 days, 17 hours

1
0
0 0

[PATCH v1] mm: Fix khugepaged activation policy

by Ryan Roberts

Since the introduction of mTHP, the docuementation has stated that khugepaged would be enabled when any mTHP size is enabled, and disabled when all mTHP sizes are disabled. There are 2 problems with this; 1. this is not what was implemented by the code and 2. this is not the desirable behavior. Desirable behavior is for khugepaged to be enabled when any PMD-sized THP is enabled, anon or file. (Note that file THP is still controlled by the top-level control so we must always consider that, as well as the PMD-size mTHP control for anon). khugepaged only supports collapsing to PMD-sized THP so there is no value in enabling it when PMD-sized THP is disabled. So let's change the code and documentation to reflect this policy. Further, per-size enabled control modification events were not previously forwarded to khugepaged to give it an opportunity to start or stop. Consequently the following was resulting in khugepaged eroneously not being activated: echo never > /sys/kernel/mm/transparent_hugepage/enabled echo always > /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Fixes: 3485b88390b0 ("mm: thp: introduce multi-size THP sysfs interface") Closes: https://lore.kernel.org/linux-mm/7a0bbe69-1e3d-4263-b206-da007791a5c4@redha… Cc: stable(a)vger.kernel.org --- Hi All, Applies on top of today's mm-unstable (9bb8753acdd8). No regressions observed in mm selftests. When fixing this I also noticed that khugepaged doesn't get (and never has been) activated/deactivated by `shmem_enabled=`. I'm not sure if khugepaged knows how to collapse shmem - perhaps it should be activated in this case? Thanks, Ryan Documentation/admin-guide/mm/transhuge.rst | 11 +++++------ include/linux/huge_mm.h | 13 +++++++------ mm/huge_memory.c | 7 +++++++ mm/khugepaged.c | 13 ++++++------- 4 files changed, 25 insertions(+), 19 deletions(-) diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index 709fe10b60f4..fc321d40b8ac 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -202,12 +202,11 @@ PMD-mappable transparent hugepage:: cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size -khugepaged will be automatically started when one or more hugepage -sizes are enabled (either by directly setting "always" or "madvise", -or by setting "inherit" while the top-level enabled is set to "always" -or "madvise"), and it'll be automatically shutdown when the last -hugepage size is disabled (either by directly setting "never", or by -setting "inherit" while the top-level enabled is set to "never"). +khugepaged will be automatically started when PMD-sized THP is enabled +(either of the per-size anon control or the top-level control are set +to "always" or "madvise"), and it'll be automatically shutdown when +PMD-sized THP is disabled (when both the per-size anon control and the +top-level control are "never") Khugepaged controls ------------------- diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index 4d155c7a4792..ce1b47b49cc3 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -128,16 +128,17 @@ static inline bool hugepage_global_always(void) (1<<TRANSPARENT_HUGEPAGE_FLAG); } -static inline bool hugepage_flags_enabled(void) +static inline bool hugepage_pmd_enabled(void) { /* - * We cover both the anon and the file-backed case here; we must return - * true if globally enabled, even when all anon sizes are set to never. - * So we don't need to look at huge_anon_orders_inherit. + * We cover both the anon and the file-backed case here; for + * file-backed, we must return true if globally enabled, regardless of + * the anon pmd size control status. So we don't need to look at + * huge_anon_orders_inherit. */ return hugepage_global_enabled() || - READ_ONCE(huge_anon_orders_always) || - READ_ONCE(huge_anon_orders_madvise); + test_bit(PMD_ORDER, &huge_anon_orders_always) || + test_bit(PMD_ORDER, &huge_anon_orders_madvise); } static inline int highest_order(unsigned long orders) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 251d6932130f..085f5e973231 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -502,6 +502,13 @@ static ssize_t thpsize_enabled_store(struct kobject *kobj, } else ret = -EINVAL; + if (ret > 0) { + int err; + + err = start_stop_khugepaged(); + if (err) + ret = err; + } return ret; } diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 409f67a817f1..708d0e74b61f 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -449,7 +449,7 @@ void khugepaged_enter_vma(struct vm_area_struct *vma, unsigned long vm_flags) { if (!test_bit(MMF_VM_HUGEPAGE, &vma->vm_mm->flags) && - hugepage_flags_enabled()) { + hugepage_pmd_enabled()) { if (thp_vma_allowable_order(vma, vm_flags, TVA_ENFORCE_SYSFS, PMD_ORDER)) __khugepaged_enter(vma->vm_mm); @@ -2462,8 +2462,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result, static int khugepaged_has_work(void) { - return !list_empty(&khugepaged_scan.mm_head) && - hugepage_flags_enabled(); + return !list_empty(&khugepaged_scan.mm_head) && hugepage_pmd_enabled(); } static int khugepaged_wait_event(void) @@ -2536,7 +2535,7 @@ static void khugepaged_wait_work(void) return; } - if (hugepage_flags_enabled()) + if (hugepage_pmd_enabled()) wait_event_freezable(khugepaged_wait, khugepaged_wait_event()); } @@ -2567,7 +2566,7 @@ static void set_recommended_min_free_kbytes(void) int nr_zones = 0; unsigned long recommended_min; - if (!hugepage_flags_enabled()) { + if (!hugepage_pmd_enabled()) { calculate_min_free_kbytes(); goto update_wmarks; } @@ -2617,7 +2616,7 @@ int start_stop_khugepaged(void) int err = 0; mutex_lock(&khugepaged_mutex); - if (hugepage_flags_enabled()) { + if (hugepage_pmd_enabled()) { if (!khugepaged_thread) khugepaged_thread = kthread_run(khugepaged, NULL, "khugepaged"); @@ -2643,7 +2642,7 @@ int start_stop_khugepaged(void) void khugepaged_min_free_kbytes_update(void) { mutex_lock(&khugepaged_mutex); - if (hugepage_flags_enabled() && khugepaged_thread) + if (hugepage_pmd_enabled() && khugepaged_thread) set_recommended_min_free_kbytes(); mutex_unlock(&khugepaged_mutex); } -- 2.43.0

4 days, 21 hours

2
5
0 0

[PATCH v1] arm64: dts: imx8mp: Fix VPU PGC power-domain parents

by Vitor Soares

From: Vitor Soares <vitor.soares(a)toradex.com> On iMX8M Plus QuadLite (VPU-less SoC), the dependency between VPU power domains lead to a deferred probe error during boot: [ 17.140195] imx-pgc imx-pgc-domain.8: failed to command PGC [ 17.147183] platform imx-pgc-domain.11: deferred probe pending: (reason unknown) [ 17.147200] platform imx-pgc-domain.12: deferred probe pending: (reason unknown) [ 17.147207] platform imx-pgc-domain.13: deferred probe pending: (reason unknown) This is incorrect and should be the VPU blk-ctrl controlling these power domains, which is already doing it. After removing the `power-domain` property from the VPU PGC nodes, both iMX8M Plus w/ and w/out VPU boot correctly. However, it breaks the suspend/resume functionality. A fix for this is pending, see Links. Cc: <stable(a)vger.kernel.org> Fixes: df680992dd62 ("arm64: dts: imx8mp: add vpu pgc nodes") Link: https://lore.kernel.org/all/fcd6acc268b8642371cf289149b2b1c3e90c7f45.camel@… Link: https://lore.kernel.org/all/20240418155151.355133-1-ivitro@gmail.com/ Suggested-by: Lucas Stach <l.stach(a)pengutronix.de> Signed-off-by: Vitor Soares <vitor.soares(a)toradex.com> --- arch/arm64/boot/dts/freescale/imx8mp.dtsi | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi index b92abb5a5c53..12548336b736 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi @@ -882,21 +882,18 @@ pgc_vpumix: power-domain@19 { pgc_vpu_g1: power-domain@20 { #power-domain-cells = <0>; - power-domains = <&pgc_vpumix>; reg = <IMX8MP_POWER_DOMAIN_VPU_G1>; clocks = <&clk IMX8MP_CLK_VPU_G1_ROOT>; }; pgc_vpu_g2: power-domain@21 { #power-domain-cells = <0>; - power-domains = <&pgc_vpumix>; reg = <IMX8MP_POWER_DOMAIN_VPU_G2>; clocks = <&clk IMX8MP_CLK_VPU_G2_ROOT>; }; pgc_vpu_vc8000e: power-domain@22 { #power-domain-cells = <0>; - power-domains = <&pgc_vpumix>; reg = <IMX8MP_POWER_DOMAIN_VPU_VC8000E>; clocks = <&clk IMX8MP_CLK_VPU_VC8KE_ROOT>; }; -- 2.34.1

4 days, 22 hours

2
3
0 0

[PATCH] Revert "platform/x86: toshiba_acpi: Add quirk for buttons on Z830"

by Armin Wolf

This reverts commit 10c66da9f87a96572ad92642ae060e827313b11c. The associated patch depends on the availability of the ACPI quickstart button driver, which will be available starting with kernel 6.10. This means that the patch brings no benifit for older kernels. Even worse, it was found out that the patch is buggy, causing regressions for people using older kernels. Fix this by simply reverting the patch from the 6.9 stable tree. Cc: <stable(a)vger.kernel.org> # 6.9.x Reported-by: kemal <kmal(a)cock.li> Signed-off-by: Armin Wolf <W_Armin(a)gmx.de> --- drivers/platform/x86/toshiba_acpi.c | 36 +++-------------------------- 1 file changed, 3 insertions(+), 33 deletions(-) diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c index 16e941449b14..77244c9aa60d 100644 --- a/drivers/platform/x86/toshiba_acpi.c +++ b/drivers/platform/x86/toshiba_acpi.c @@ -57,11 +57,6 @@ module_param(turn_on_panel_on_resume, int, 0644); MODULE_PARM_DESC(turn_on_panel_on_resume, "Call HCI_PANEL_POWER_ON on resume (-1 = auto, 0 = no, 1 = yes"); -static int hci_hotkey_quickstart = -1; -module_param(hci_hotkey_quickstart, int, 0644); -MODULE_PARM_DESC(hci_hotkey_quickstart, - "Call HCI_HOTKEY_EVENT with value 0x5 for quickstart button support (-1 = auto, 0 = no, 1 = yes"); - #define TOSHIBA_WMI_EVENT_GUID "59142400-C6A3-40FA-BADB-8A2652834100" /* Scan code for Fn key on TOS1900 models */ @@ -141,7 +136,6 @@ MODULE_PARM_DESC(hci_hotkey_quickstart, #define HCI_ACCEL_MASK 0x7fff #define HCI_ACCEL_DIRECTION_MASK 0x8000 #define HCI_HOTKEY_DISABLE 0x0b -#define HCI_HOTKEY_ENABLE_QUICKSTART 0x05 #define HCI_HOTKEY_ENABLE 0x09 #define HCI_HOTKEY_SPECIAL_FUNCTIONS 0x10 #define HCI_LCD_BRIGHTNESS_BITS 3 @@ -2737,15 +2731,10 @@ static int toshiba_acpi_enable_hotkeys(struct toshiba_acpi_dev *dev) return -ENODEV; /* - * Enable quickstart buttons if supported. - * * Enable the "Special Functions" mode only if they are * supported and if they are activated. */ - if (hci_hotkey_quickstart) - result = hci_write(dev, HCI_HOTKEY_EVENT, - HCI_HOTKEY_ENABLE_QUICKSTART); - else if (dev->kbd_function_keys_supported && dev->special_functions) + if (dev->kbd_function_keys_supported && dev->special_functions) result = hci_write(dev, HCI_HOTKEY_EVENT, HCI_HOTKEY_SPECIAL_FUNCTIONS); else @@ -3269,14 +3258,7 @@ static const char *find_hci_method(acpi_handle handle) * works. toshiba_acpi_resume() uses HCI_PANEL_POWER_ON to avoid changing * the configured brightness level. */ -#define QUIRK_TURN_ON_PANEL_ON_RESUME BIT(0) -/* - * Some Toshibas use "quickstart" keys. On these, HCI_HOTKEY_EVENT must use - * the value HCI_HOTKEY_ENABLE_QUICKSTART. - */ -#define QUIRK_HCI_HOTKEY_QUICKSTART BIT(1) - -static const struct dmi_system_id toshiba_dmi_quirks[] = { +static const struct dmi_system_id turn_on_panel_on_resume_dmi_ids[] = { { /* Toshiba Portégé R700 */ /* https://bugzilla.kernel.org/show_bug.cgi?id=21012 */ @@ -3284,7 +3266,6 @@ static const struct dmi_system_id toshiba_dmi_quirks[] = { DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R700"), }, - .driver_data = (void *)QUIRK_TURN_ON_PANEL_ON_RESUME, }, { /* Toshiba Satellite/Portégé R830 */ @@ -3294,7 +3275,6 @@ static const struct dmi_system_id toshiba_dmi_quirks[] = { DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), DMI_MATCH(DMI_PRODUCT_NAME, "R830"), }, - .driver_data = (void *)QUIRK_TURN_ON_PANEL_ON_RESUME, }, { /* Toshiba Satellite/Portégé Z830 */ @@ -3302,7 +3282,6 @@ static const struct dmi_system_id toshiba_dmi_quirks[] = { DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), DMI_MATCH(DMI_PRODUCT_NAME, "Z830"), }, - .driver_data = (void *)(QUIRK_TURN_ON_PANEL_ON_RESUME | QUIRK_HCI_HOTKEY_QUICKSTART), }, }; @@ -3311,8 +3290,6 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev) struct toshiba_acpi_dev *dev; const char *hci_method; u32 dummy; - const struct dmi_system_id *dmi_id; - long quirks = 0; int ret = 0; if (toshiba_acpi) @@ -3465,15 +3442,8 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev) } #endif - dmi_id = dmi_first_match(toshiba_dmi_quirks); - if (dmi_id) - quirks = (long)dmi_id->driver_data; - if (turn_on_panel_on_resume == -1) - turn_on_panel_on_resume = !!(quirks & QUIRK_TURN_ON_PANEL_ON_RESUME); - - if (hci_hotkey_quickstart == -1) - hci_hotkey_quickstart = !!(quirks & QUIRK_HCI_HOTKEY_QUICKSTART); + turn_on_panel_on_resume = dmi_check_system(turn_on_panel_on_resume_dmi_ids); toshiba_wwan_available(dev); if (dev->wwan_supported) -- 2.39.2

4 days, 23 hours

2
2
0 0

[PATCH] usb: core: add missing of_node_put() in usb_of_has_devices_or_graph

by Javier Carrasco

The for_each_child_of_node() macro requires an explicit call to of_node_put() on early exits to decrement the child refcount and avoid a memory leak. The child node is not required outsie the loop, and the resource must be released before the function returns. Add the missing of_node_put(). Cc: stable(a)vger.kernel.org Fixes: 82e82130a78b ("usb: core: Set connect_type of ports based on DT node") Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- This bug was found while doing some code analysis, and I could not test it with real hardware. Although the issue and it solution are straightforward, any validation beyond compilation and static analysis is always welcome. --- drivers/usb/core/of.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c index f1a499ee482c..763e4122ed5b 100644 --- a/drivers/usb/core/of.c +++ b/drivers/usb/core/of.c @@ -84,9 +84,12 @@ static bool usb_of_has_devices_or_graph(const struct usb_device *hub) if (of_graph_is_present(np)) return true; - for_each_child_of_node(np, child) - if (of_property_present(child, "reg")) + for_each_child_of_node(np, child) { + if (of_property_present(child, "reg")) { + of_node_put(child); return true; + } + } return false; } --- base-commit: 62c97045b8f720c2eac807a5f38e26c9ed512371 change-id: 20240624-usb_core_of_memleak-79161623b62e Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

5 days

2
1
0 0

[PATCH v3] ACPI: processor_idle: Fix invalid comparison with insertion sort for latency

by Kuan-Wei Chiu

The acpi_cst_latency_cmp comparison function currently used for sorting C-state latencies does not satisfy transitivity, causing incorrect sorting results. Specifically, if there are two valid acpi_processor_cx elements A and B and one invalid element C, it may occur that A < B, A = C, and B = C. Sorting algorithms assume that if A < B and A = C, then C < B, leading to incorrect ordering. Given the small size of the array (<=8), we replace the library sort function with a simple insertion sort that properly ignores invalid elements and sorts valid ones based on latency. This change ensures correct ordering of the C-state latencies. Fixes: 65ea8f2c6e23 ("ACPI: processor idle: Fix up C-state latency if not ordered") Cc: stable(a)vger.kernel.org Reported-by: Julian Sikorski <belegdol(a)gmail.com> Closes: https://lore.kernel.org/lkml/70674dc7-5586-4183-8953-8095567e73df@gmail.com/ Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> --- v2 -> v3: - Remove #include <linux/sort.h> - Cc @stable Note: I only performed a build test and a simple unit test to ensure the latency of valid elements is correctly sorted in the randomly generated data. drivers/acpi/processor_idle.c | 36 ++++++++++++++--------------------- 1 file changed, 14 insertions(+), 22 deletions(-) diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index bd6a7857ce05..17cc81340b4b 100644 --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@ -16,7 +16,6 @@ #include <linux/acpi.h> #include <linux/dmi.h> #include <linux/sched.h> /* need_resched() */ -#include <linux/sort.h> #include <linux/tick.h> #include <linux/cpuidle.h> #include <linux/cpu.h> @@ -386,25 +385,21 @@ static void acpi_processor_power_verify_c3(struct acpi_processor *pr, acpi_write_bit_register(ACPI_BITREG_BUS_MASTER_RLD, 1); } -static int acpi_cst_latency_cmp(const void *a, const void *b) +static void acpi_cst_latency_sort(struct acpi_processor_cx *arr, size_t length) { - const struct acpi_processor_cx *x = a, *y = b; + int i, j, k; - if (!(x->valid && y->valid)) - return 0; - if (x->latency > y->latency) - return 1; - if (x->latency < y->latency) - return -1; - return 0; -} -static void acpi_cst_latency_swap(void *a, void *b, int n) -{ - struct acpi_processor_cx *x = a, *y = b; - - if (!(x->valid && y->valid)) - return; - swap(x->latency, y->latency); + for (i = 1; i < length; i++) { + if (!arr[i].valid) + continue; + for (j = i - 1, k = i; j >= 0; j--) { + if (!arr[j].valid) + continue; + if (arr[j].latency > arr[k].latency) + swap(arr[j].latency, arr[k].latency); + k = j; + } + } } static int acpi_processor_power_verify(struct acpi_processor *pr) @@ -449,10 +444,7 @@ static int acpi_processor_power_verify(struct acpi_processor *pr) if (buggy_latency) { pr_notice("FW issue: working around C-state latencies out of order\n"); - sort(&pr->power.states[1], max_cstate, - sizeof(struct acpi_processor_cx), - acpi_cst_latency_cmp, - acpi_cst_latency_swap); + acpi_cst_latency_sort(&pr->power.states[1], max_cstate); } lapic_timer_propagate_broadcast(pr); -- 2.34.1

5 days

4
5
0 0

Re: [PATCH 6.9 000/222] 6.9.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>

5 days

1
0
0 0

[PATCH v2] dt-bindings: thermal: correct thermal zone node name limit

by Krzysztof Kozlowski

Linux kernel uses thermal zone node name during registering thermal zones and has a hard-coded limit of 20 characters, including terminating NUL byte. The bindings expect node names to finish with '-thermal' which is eight bytes long, thus we have only 11 characters for the reset of the node name (thus 10 for the pattern after leading fixed character). Reported-by: Rob Herring <robh(a)kernel.org> Closes: https://lore.kernel.org/all/CAL_JsqKogbT_4DPd1n94xqeHaU_J8ve5K09WOyVsRX3jxx… Fixes: 1202a442a31f ("dt-bindings: thermal: Add yaml bindings for thermal zones") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Changes in v2: 1. Shorten the pattern and mention source of size requirement (Rob). --- Documentation/devicetree/bindings/thermal/thermal-zones.yaml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml index 68398e7e8655..606b80965a44 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml @@ -49,7 +49,10 @@ properties: to take when the temperature crosses those thresholds. patternProperties: - "^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$": + # Node name is limited in size due to Linux kernel requirements - 19 + # characters in total (see THERMAL_NAME_LENGTH, including terminating NUL + # byte): + "^[a-zA-Z][a-zA-Z0-9\\-]{1,10}-thermal$": type: object description: Each thermal zone node contains information about how frequently it -- 2.43.0

5 days, 2 hours

2
1
0 0

[PATCH v1 2/5] devres: Fix memory leakage caused by driver API devm_free_percpu()

by Zijun Hu

It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu(). Fixes: ff86aae3b411 ("devres: add devm_alloc_percpu()") Cc: stable(a)vger.kernel.org Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- Previous discussion link: https://lore.kernel.org/lkml/1718804281-1796-1-git-send-email-quic_zijuhu@q… drivers/base/devres.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/base/devres.c b/drivers/base/devres.c index ff2247eec43c..8d709dbd4e0c 100644 --- a/drivers/base/devres.c +++ b/drivers/base/devres.c @@ -1225,7 +1225,11 @@ EXPORT_SYMBOL_GPL(__devm_alloc_percpu); */ void devm_free_percpu(struct device *dev, void __percpu *pdata) { - WARN_ON(devres_destroy(dev, devm_percpu_release, devm_percpu_match, + /* + * Use devres_release() to prevent memory leakage as + * devm_free_pages() does. + */ + WARN_ON(devres_release(dev, devm_percpu_release, devm_percpu_match, (__force void *)pdata)); } EXPORT_SYMBOL_GPL(devm_free_percpu); -- 2.34.1

5 days, 4 hours

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2024