February 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] perf/x86/intel: Fix ARCH_PERFMON_NUM_COUNTER_LEAF" 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 47a973fd75639fe80d59f9e1860113bb2a0b112b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025021817-pull-grievance-de31@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 47a973fd75639fe80d59f9e1860113bb2a0b112b Mon Sep 17 00:00:00 2001 From: Kan Liang <kan.liang(a)linux.intel.com> Date: Wed, 29 Jan 2025 07:48:19 -0800 Subject: [PATCH] perf/x86/intel: Fix ARCH_PERFMON_NUM_COUNTER_LEAF The EAX of the CPUID Leaf 023H enumerates the mask of valid sub-leaves. To tell the availability of the sub-leaf 1 (enumerate the counter mask), perf should check the bit 1 (0x2) of EAS, rather than bit 0 (0x1). The error is not user-visible on bare metal. Because the sub-leaf 0 and the sub-leaf 1 are always available. However, it may bring issues in a virtualization environment when a VMM only enumerates the sub-leaf 0. Introduce the cpuid35_e?x to replace the macros, which makes the implementation style consistent. Fixes: eb467aaac21e ("perf/x86/intel: Support Architectural PerfMon Extension leaf") Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: stable(a)vger.kernel.org Link: https://lkml.kernel.org/r/20250129154820.3755948-3-kan.liang@linux.intel.com diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 966f7832497d..f3d5b718f93f 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4905,20 +4905,22 @@ static inline bool intel_pmu_broken_perf_cap(void) static void update_pmu_cap(struct x86_hybrid_pmu *pmu) { - unsigned int sub_bitmaps, eax, ebx, ecx, edx; + unsigned int cntr, fixed_cntr, ecx, edx; + union cpuid35_eax eax; + union cpuid35_ebx ebx; - cpuid(ARCH_PERFMON_EXT_LEAF, &sub_bitmaps, &ebx, &ecx, &edx); + cpuid(ARCH_PERFMON_EXT_LEAF, &eax.full, &ebx.full, &ecx, &edx); - if (ebx & ARCH_PERFMON_EXT_UMASK2) + if (ebx.split.umask2) pmu->config_mask |= ARCH_PERFMON_EVENTSEL_UMASK2; - if (ebx & ARCH_PERFMON_EXT_EQ) + if (ebx.split.eq) pmu->config_mask |= ARCH_PERFMON_EVENTSEL_EQ; - if (sub_bitmaps & ARCH_PERFMON_NUM_COUNTER_LEAF_BIT) { + if (eax.split.cntr_subleaf) { cpuid_count(ARCH_PERFMON_EXT_LEAF, ARCH_PERFMON_NUM_COUNTER_LEAF, - &eax, &ebx, &ecx, &edx); - pmu->cntr_mask64 = eax; - pmu->fixed_cntr_mask64 = ebx; + &cntr, &fixed_cntr, &ecx, &edx); + pmu->cntr_mask64 = cntr; + pmu->fixed_cntr_mask64 = fixed_cntr; } if (!intel_pmu_broken_perf_cap()) { diff --git a/arch/x86/include/asm/perf_event.h b/arch/x86/include/asm/perf_event.h index 1ac79f361645..0ba8d20f2d1d 100644 --- a/arch/x86/include/asm/perf_event.h +++ b/arch/x86/include/asm/perf_event.h @@ -188,11 +188,33 @@ union cpuid10_edx { * detection/enumeration details: */ #define ARCH_PERFMON_EXT_LEAF 0x00000023 -#define ARCH_PERFMON_EXT_UMASK2 0x1 -#define ARCH_PERFMON_EXT_EQ 0x2 -#define ARCH_PERFMON_NUM_COUNTER_LEAF_BIT 0x1 #define ARCH_PERFMON_NUM_COUNTER_LEAF 0x1 +union cpuid35_eax { + struct { + unsigned int leaf0:1; + /* Counters Sub-Leaf */ + unsigned int cntr_subleaf:1; + /* Auto Counter Reload Sub-Leaf */ + unsigned int acr_subleaf:1; + /* Events Sub-Leaf */ + unsigned int events_subleaf:1; + unsigned int reserved:28; + } split; + unsigned int full; +}; + +union cpuid35_ebx { + struct { + /* UnitMask2 Supported */ + unsigned int umask2:1; + /* EQ-bit Supported */ + unsigned int eq:1; + unsigned int reserved:30; + } split; + unsigned int full; +}; + /* * Intel Architectural LBR CPUID detection/enumeration details: */

1 week, 4 days

4
5
0 0

Apply 3 commits for 6.13.y

by Miguel Ojeda

Hi Greg, Sasha, Please consider applying the following commits for 6.13.y: 27c7518e7f1c ("rust: finish using custom FFI integer types") 1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`") 9b98be76855f ("rust: cleanup unnecessary casts") They should apply cleanly. This backports the custom FFI integer types, which in turn solves a build failure under `CONFIG_RUST_FW_LOADER_ABSTRACTIONS=y`. I will have to send something similar to 6.12.y, but it requires more commits -- I may do the `alloc` backport first we discussed the other day. Thanks! Cheers, Miguel

1 week, 4 days

3
2
0 0

FTBFS: Rust firmware abstractions in current stable (6.13.4) on arm64 with rustc 1.85.0

by NoisyCoil

Hi! The Rust firmware abstractions FTBFS on arm64 and current stable (6.13.4) when compiled with rustc 1.85.0: ``` RUSTC L rust/kernel.o error[E0308]: mismatched types --> rust/kernel/firmware.rs:20:14 | 20 | Self(bindings::request_firmware) | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item | | | arguments to this function are incorrect | = note: expected fn pointer `unsafe extern "C" fn(_, *const i8, _) -> _` found fn item `unsafe extern "C" fn(_, *const u8, _) -> _ {request_firmware}` note: tuple struct defined here --> rust/kernel/firmware.rs:14:8 | 14 | struct FwFunc( | ^^^^^^ error[E0308]: mismatched types --> rust/kernel/firmware.rs:24:14 | 24 | Self(bindings::firmware_request_nowarn) | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item | | | arguments to this function are incorrect | = note: expected fn pointer `unsafe extern "C" fn(_, *const i8, _) -> _` found fn item `unsafe extern "C" fn(_, *const u8, _) -> _ {firmware_request_nowarn}` note: tuple struct defined here --> rust/kernel/firmware.rs:14:8 | 14 | struct FwFunc( | ^^^^^^ error[E0308]: mismatched types --> rust/kernel/firmware.rs:64:45 | 64 | let ret = unsafe { func.0(pfw as _, name.as_char_ptr(), dev.as_raw()) }; | ------ ^^^^^^^^^^^^^^^^^^ expected `*const i8`, found `*const u8` | | | arguments to this function are incorrect | = note: expected raw pointer `*const i8` found raw pointer `*const u8` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. ``` This is because rustc 1.85 (now stable) switched core::ffi::c_char from i8 to u8 on arm64 and other platforms [1], and because current stable still uses rustc's core's instead of the custom ffi integer types like 6.14 will. Looking for other i8's in *.rs files tells me only the QR code panic screen should be affected in addition to the firmware abstractions, and that was already reported in [2]. A simple fix would be to switch i8 to u8 in `struct FwFunc`, but that breaks rustc <= 1.84 so I guess a more robust solution is needed. Cheers! [1] https://github.com/rust-lang/rust/pull/132975 [2] https://lore.kernel.org/all/20250120124531.2581448-1-linkmauve@linkmauve.fr/

1 week, 4 days

2
2
0 0

[PATCH] ARM: add KEEP() keyword to ARM_VECTORS

by Christian Eggers

Without this, the vectors are removed if LD_DEAD_CODE_DATA_ELIMINATION is enabled. At startup, the CPU (silently) hangs in the undefined instruction exception as soon as the first timer interrupt arrives. On my setup, the system also boots fine without the 2nd and 3rd KEEP() statements, so I cannot tell whether these are actually required. Fixes: ed0f94102251 ("ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Eggers <ceggers(a)arri.de> --- arch/arm/include/asm/vmlinux.lds.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/include/asm/vmlinux.lds.h b/arch/arm/include/asm/vmlinux.lds.h index d60f6e83a9f7..f2ff79f740ab 100644 --- a/arch/arm/include/asm/vmlinux.lds.h +++ b/arch/arm/include/asm/vmlinux.lds.h @@ -125,13 +125,13 @@ __vectors_lma = .; \ OVERLAY 0xffff0000 : NOCROSSREFS AT(__vectors_lma) { \ .vectors { \ - *(.vectors) \ + KEEP(*(.vectors)) \ } \ .vectors.bhb.loop8 { \ - *(.vectors.bhb.loop8) \ + KEEP(*(.vectors.bhb.loop8)) \ } \ .vectors.bhb.bpiall { \ - *(.vectors.bhb.bpiall) \ + KEEP(*(.vectors.bhb.bpiall)) \ } \ } \ ARM_LMA(__vectors, .vectors); \ -- 2.44.1

1 week, 4 days

2
1
0 0

[PATCH 0/2] A couple of build fixes for x86 when using GCC 15

by Nathan Chancellor

Hi all, GCC 15 changed the default C standard version from gnu17 to gnu23, which reveals a few places in the kernel where a C standard version was not set, resulting in build failures because bool, true, and false are reserved keywords in C23 [1][2]. Update these places to use the same C standard version as the rest of the kernel, gnu11. [1]: https://lore.kernel.org/4OAhbllK7x4QJGpZjkYjtBYNLd_2whHx9oFiuZcGwtVR4hIzvdu… [2]: https://lore.kernel.org/Z4467umXR2PZ0M1H@tucnak/ --- Nathan Chancellor (2): x86/boot: Use '-std=gnu11' to fix build with GCC 15 efi: libstub: Use '-std=gnu11' to fix build with GCC 15 arch/x86/boot/compressed/Makefile | 1 + drivers/firmware/efi/libstub/Makefile | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) --- base-commit: ffd294d346d185b70e28b1a28abe367bbfe53c04 change-id: 20250121-x86-use-std-consistently-gcc-15-f95146e0050f Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

1 week, 5 days

5
8
0 0

Quick Response-Integrated Systems Europe 2025 Visitors Leads!

by Grace Green

Hi, Just following up on my previous email regarding the visitor list. Let me know your thoughts, and I'd be happy to provide more details. Best regards, Grace Subject: Integrated Systems Europe 2025! Hi, Would you like to get the latest list of exhibitors and attendees for Integrated Systems Europe 2025? This comprehensive list includes last-minute registrants as well. Event Details: Location: Fira Barcelona Gran Via, Barcelona, Spain Exhibitors: 1,460 Attendees: 73,891 Available Data Fields: Individual Email Address, Phone Number, Contact Name, Job Title, Company Name, Website, Physical Address, and more. Let me know if you're interested in the attendees list, exhibitors list, or both! I’d be happy to share pricing and additional details. Looking forward to your response! Best regards, Grace Green Sr. Demand Generation P.S. If you’d prefer not to receive updates, simply reply with “NO.”

1 week, 5 days

1
0
0 0

FAILED: patch "[PATCH] batman-adv: Drop unmanaged ELP metric worker" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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.10.y git checkout FETCH_HEAD git cherry-pick -x 8c8ecc98f5c65947b0070a24bac11e12e47cc65d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025021841-atrium-settle-8b58@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8c8ecc98f5c65947b0070a24bac11e12e47cc65d Mon Sep 17 00:00:00 2001 From: Sven Eckelmann <sven(a)narfation.org> Date: Mon, 20 Jan 2025 00:06:11 +0100 Subject: [PATCH] batman-adv: Drop unmanaged ELP metric worker The ELP worker needs to calculate new metric values for all neighbors "reachable" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context. Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses. Directly canceling the metric worker also has various problems: * cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish. * iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers) The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by: * creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context * only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held) Cc: stable(a)vger.kernel.org Fixes: c833484e5f38 ("batman-adv: ELP - compute the metric based on the estimated throughput") Signed-off-by: Sven Eckelmann <sven(a)narfation.org> Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de> diff --git a/net/batman-adv/bat_v.c b/net/batman-adv/bat_v.c index ac11f1f08db0..d35479c465e2 100644 --- a/net/batman-adv/bat_v.c +++ b/net/batman-adv/bat_v.c @@ -113,8 +113,6 @@ static void batadv_v_hardif_neigh_init(struct batadv_hardif_neigh_node *hardif_neigh) { ewma_throughput_init(&hardif_neigh->bat_v.throughput); - INIT_WORK(&hardif_neigh->bat_v.metric_work, - batadv_v_elp_throughput_metric_update); } /** diff --git a/net/batman-adv/bat_v_elp.c b/net/batman-adv/bat_v_elp.c index 65e52de52bcd..b065578b4436 100644 --- a/net/batman-adv/bat_v_elp.c +++ b/net/batman-adv/bat_v_elp.c @@ -18,6 +18,7 @@ #include <linux/if_ether.h> #include <linux/jiffies.h> #include <linux/kref.h> +#include <linux/list.h> #include <linux/minmax.h> #include <linux/netdevice.h> #include <linux/nl80211.h> @@ -26,6 +27,7 @@ #include <linux/rcupdate.h> #include <linux/rtnetlink.h> #include <linux/skbuff.h> +#include <linux/slab.h> #include <linux/stddef.h> #include <linux/string.h> #include <linux/types.h> @@ -41,6 +43,18 @@ #include "routing.h" #include "send.h" +/** + * struct batadv_v_metric_queue_entry - list of hardif neighbors which require + * and metric update + */ +struct batadv_v_metric_queue_entry { + /** @hardif_neigh: hardif neighbor scheduled for metric update */ + struct batadv_hardif_neigh_node *hardif_neigh; + + /** @list: list node for metric_queue */ + struct list_head list; +}; + /** * batadv_v_elp_start_timer() - restart timer for ELP periodic work * @hard_iface: the interface for which the timer has to be reset @@ -137,10 +151,17 @@ static bool batadv_v_elp_get_throughput(struct batadv_hardif_neigh_node *neigh, goto default_throughput; } + /* only use rtnl_trylock because the elp worker will be cancelled while + * the rntl_lock is held. the cancel_delayed_work_sync() would otherwise + * wait forever when the elp work_item was started and it is then also + * trying to rtnl_lock + */ + if (!rtnl_trylock()) + return false; + /* if not a wifi interface, check if this device provides data via * ethtool (e.g. an Ethernet adapter) */ - rtnl_lock(); ret = __ethtool_get_link_ksettings(hard_iface->net_dev, &link_settings); rtnl_unlock(); if (ret == 0) { @@ -175,31 +196,19 @@ static bool batadv_v_elp_get_throughput(struct batadv_hardif_neigh_node *neigh, /** * batadv_v_elp_throughput_metric_update() - worker updating the throughput * metric of a single hop neighbour - * @work: the work queue item + * @neigh: the neighbour to probe */ -void batadv_v_elp_throughput_metric_update(struct work_struct *work) +static void +batadv_v_elp_throughput_metric_update(struct batadv_hardif_neigh_node *neigh) { - struct batadv_hardif_neigh_node_bat_v *neigh_bat_v; - struct batadv_hardif_neigh_node *neigh; u32 throughput; bool valid; - neigh_bat_v = container_of(work, struct batadv_hardif_neigh_node_bat_v, - metric_work); - neigh = container_of(neigh_bat_v, struct batadv_hardif_neigh_node, - bat_v); - valid = batadv_v_elp_get_throughput(neigh, &throughput); if (!valid) - goto put_neigh; + return; ewma_throughput_add(&neigh->bat_v.throughput, throughput); - -put_neigh: - /* decrement refcounter to balance increment performed before scheduling - * this task - */ - batadv_hardif_neigh_put(neigh); } /** @@ -273,14 +282,16 @@ batadv_v_elp_wifi_neigh_probe(struct batadv_hardif_neigh_node *neigh) */ static void batadv_v_elp_periodic_work(struct work_struct *work) { + struct batadv_v_metric_queue_entry *metric_entry; + struct batadv_v_metric_queue_entry *metric_safe; struct batadv_hardif_neigh_node *hardif_neigh; struct batadv_hard_iface *hard_iface; struct batadv_hard_iface_bat_v *bat_v; struct batadv_elp_packet *elp_packet; + struct list_head metric_queue; struct batadv_priv *bat_priv; struct sk_buff *skb; u32 elp_interval; - bool ret; bat_v = container_of(work, struct batadv_hard_iface_bat_v, elp_wq.work); hard_iface = container_of(bat_v, struct batadv_hard_iface, bat_v); @@ -316,6 +327,8 @@ static void batadv_v_elp_periodic_work(struct work_struct *work) atomic_inc(&hard_iface->bat_v.elp_seqno); + INIT_LIST_HEAD(&metric_queue); + /* The throughput metric is updated on each sent packet. This way, if a * node is dead and no longer sends packets, batman-adv is still able to * react timely to its death. @@ -340,16 +353,28 @@ static void batadv_v_elp_periodic_work(struct work_struct *work) /* Reading the estimated throughput from cfg80211 is a task that * may sleep and that is not allowed in an rcu protected - * context. Therefore schedule a task for that. + * context. Therefore add it to metric_queue and process it + * outside rcu protected context. */ - ret = queue_work(batadv_event_workqueue, - &hardif_neigh->bat_v.metric_work); - - if (!ret) + metric_entry = kzalloc(sizeof(*metric_entry), GFP_ATOMIC); + if (!metric_entry) { batadv_hardif_neigh_put(hardif_neigh); + continue; + } + + metric_entry->hardif_neigh = hardif_neigh; + list_add(&metric_entry->list, &metric_queue); } rcu_read_unlock(); + list_for_each_entry_safe(metric_entry, metric_safe, &metric_queue, list) { + batadv_v_elp_throughput_metric_update(metric_entry->hardif_neigh); + + batadv_hardif_neigh_put(metric_entry->hardif_neigh); + list_del(&metric_entry->list); + kfree(metric_entry); + } + restart_timer: batadv_v_elp_start_timer(hard_iface); out: diff --git a/net/batman-adv/bat_v_elp.h b/net/batman-adv/bat_v_elp.h index 9e2740195fa2..c9cb0a307100 100644 --- a/net/batman-adv/bat_v_elp.h +++ b/net/batman-adv/bat_v_elp.h @@ -10,7 +10,6 @@ #include "main.h" #include <linux/skbuff.h> -#include <linux/workqueue.h> int batadv_v_elp_iface_enable(struct batadv_hard_iface *hard_iface); void batadv_v_elp_iface_disable(struct batadv_hard_iface *hard_iface); @@ -19,6 +18,5 @@ void batadv_v_elp_iface_activate(struct batadv_hard_iface *primary_iface, void batadv_v_elp_primary_iface_set(struct batadv_hard_iface *primary_iface); int batadv_v_elp_packet_recv(struct sk_buff *skb, struct batadv_hard_iface *if_incoming); -void batadv_v_elp_throughput_metric_update(struct work_struct *work); #endif /* _NET_BATMAN_ADV_BAT_V_ELP_H_ */ diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h index 04f6398b3a40..85a50096f5b2 100644 --- a/net/batman-adv/types.h +++ b/net/batman-adv/types.h @@ -596,9 +596,6 @@ struct batadv_hardif_neigh_node_bat_v { * neighbor */ unsigned long last_unicast_tx; - - /** @metric_work: work queue callback item for metric update */ - struct work_struct metric_work; }; /**

1 week, 5 days

3
6
0 0

[to-be-updated] panic-call-panic-handlers-before-panic_other_cpus_shutdown.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: panic: call panic handlers before panic_other_cpus_shutdown() has been removed from the -mm tree. Its filename was panic-call-panic-handlers-before-panic_other_cpus_shutdown.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Subject: panic: call panic handlers before panic_other_cpus_shutdown() Date: Fri, 21 Feb 2025 16:30:52 -0500 Since the panic handlers may require certain cpus to be online to panic gracefully, we should call them before turning off SMP. Without this re-ordering, on Hyper-V hv_panic_vmbus_unload() times out, because the vmbus channel is bound to VMBUS_CONNECT_CPU and unless the crashing cpu is the same as VMBUS_CONNECT_CPU, VMBUS_CONNECT_CPU will be offlined by crash_smp_send_stop() before the vmbus channel can be deconstructed. Link: https://lkml.kernel.org/r/20250221213055.133849-1-hamzamahfooz@linux.micros… Signed-off-by: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Baoquan he <bhe(a)redhat.com> Cc: Dexuan Cui <decui(a)microsoft.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Haiyang Zhang <haiyangz(a)microsoft.com> Cc: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: John Ogness <john.ogness(a)linutronix.de> Cc: Petr Mladek <pmladek(a)suse.com> Cc: Ryo Takakura <takakura(a)valinux.co.jp> Cc: Wei Liu <wei.liu(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/panic.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/kernel/panic.c~panic-call-panic-handlers-before-panic_other_cpus_shutdown +++ a/kernel/panic.c @@ -372,16 +372,16 @@ void panic(const char *fmt, ...) if (!_crash_kexec_post_notifiers) __crash_kexec(NULL); - panic_other_cpus_shutdown(_crash_kexec_post_notifiers); - - printk_legacy_allow_panic_sync(); - /* * Run any panic handlers, including those that might need to * add information to the kmsg dump output. */ atomic_notifier_call_chain(&panic_notifier_list, 0, buf); + panic_other_cpus_shutdown(_crash_kexec_post_notifiers); + + printk_legacy_allow_panic_sync(); + panic_print_sys_info(false); kmsg_dump_desc(KMSG_DUMP_PANIC, buf); _ Patches currently in -mm which might be from hamzamahfooz(a)linux.microsoft.com are

1 week, 5 days

1
0
0 0

+ panic-call-panic-handlers-before-panic_other_cpus_shutdown.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: panic: call panic handlers before panic_other_cpus_shutdown() has been added to the -mm mm-nonmm-unstable branch. Its filename is panic-call-panic-handlers-before-panic_other_cpus_shutdown.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-nonmm-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: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Subject: panic: call panic handlers before panic_other_cpus_shutdown() Date: Fri, 21 Feb 2025 16:30:52 -0500 Since the panic handlers may require certain cpus to be online to panic gracefully, we should call them before turning off SMP. Without this re-ordering, on Hyper-V hv_panic_vmbus_unload() times out, because the vmbus channel is bound to VMBUS_CONNECT_CPU and unless the crashing cpu is the same as VMBUS_CONNECT_CPU, VMBUS_CONNECT_CPU will be offlined by crash_smp_send_stop() before the vmbus channel can be deconstructed. Link: https://lkml.kernel.org/r/20250221213055.133849-1-hamzamahfooz@linux.micros… Signed-off-by: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Baoquan he <bhe(a)redhat.com> Cc: Dexuan Cui <decui(a)microsoft.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Haiyang Zhang <haiyangz(a)microsoft.com> Cc: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: John Ogness <john.ogness(a)linutronix.de> Cc: Petr Mladek <pmladek(a)suse.com> Cc: Ryo Takakura <takakura(a)valinux.co.jp> Cc: Wei Liu <wei.liu(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/panic.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/kernel/panic.c~panic-call-panic-handlers-before-panic_other_cpus_shutdown +++ a/kernel/panic.c @@ -372,16 +372,16 @@ void panic(const char *fmt, ...) if (!_crash_kexec_post_notifiers) __crash_kexec(NULL); - panic_other_cpus_shutdown(_crash_kexec_post_notifiers); - - printk_legacy_allow_panic_sync(); - /* * Run any panic handlers, including those that might need to * add information to the kmsg dump output. */ atomic_notifier_call_chain(&panic_notifier_list, 0, buf); + panic_other_cpus_shutdown(_crash_kexec_post_notifiers); + + printk_legacy_allow_panic_sync(); + panic_print_sys_info(false); kmsg_dump_desc(KMSG_DUMP_PANIC, buf); _ Patches currently in -mm which might be from hamzamahfooz(a)linux.microsoft.com are panic-call-panic-handlers-before-panic_other_cpus_shutdown.patch

1 week, 5 days

2
1
0 0

[PATCH RESEND net-next] net: stmmac: dwmac-rk: Provide FIFO sizes for DWMAC 1000

by Chen-Yu Tsai

From: Chen-Yu Tsai <wens(a)csie.org> The DWMAC 1000 DMA capabilities register does not provide actual FIFO sizes, nor does the driver really care. If they are not provided via some other means, the driver will work fine, only disallowing changing the MTU setting. The recent commit 8865d22656b4 ("net: stmmac: Specify hardware capability value when FIFO size isn't specified") changed this by requiring the FIFO sizes to be provided, breaking devices that were working just fine. Provide the FIFO sizes through the driver's platform data, to not only fix the breakage, but also enable MTU changes. The FIFO sizes are confirmed to be the same across RK3288, RK3328, RK3399 and PX30, based on their respective manuals. It is likely that Rockchip synthesized their DWMAC 1000 with the same parameters on all their chips that have it. Fixes: eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values") Fixes: 8865d22656b4 ("net: stmmac: Specify hardware capability value when FIFO size isn't specified") Cc: <stable(a)vger.kernel.org> Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> --- (Resending to net-next instead of netdev.) The commit that broke things has already been reverted in netdev. The reason for stable inclusion is not to fix the device breakage (which only broke in v6.14-rc1), but to provide the values so that MTU changes can work in older kernels. drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c index a4dc89e23a68..71a4c4967467 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c @@ -1966,8 +1966,11 @@ static int rk_gmac_probe(struct platform_device *pdev) /* If the stmmac is not already selected as gmac4, * then make sure we fallback to gmac. */ - if (!plat_dat->has_gmac4) + if (!plat_dat->has_gmac4) { plat_dat->has_gmac = true; + plat_dat->rx_fifo_size = 4096; + plat_dat->tx_fifo_size = 2048; + } plat_dat->fix_mac_speed = rk_fix_speed; plat_dat->bsp_priv = rk_gmac_setup(pdev, plat_dat, data); -- 2.39.5

1 week, 5 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025