* [PATCH net-next 1/3] net: bridge: add stp_mode attribute for STP mode selection
From: Andy Roulin @ 2026-03-24 18:49 UTC (permalink / raw)
To: netdev
Cc: bridge, Nikolay Aleksandrov, Ido Schimmel, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Petr Machata,
linux-doc, linux-kselftest, linux-kernel, Andy Roulin
In-Reply-To: <20260324184942.2828691-1-aroulin@nvidia.com>
The bridge-stp usermode helper is currently restricted to the initial
network namespace, preventing userspace STP daemons (e.g. mstpd) from
operating on bridges in other network namespaces. Since commit
ff62198553e4 ("bridge: Only call /sbin/bridge-stp for the initial
network namespace"), bridges in non-init namespaces silently fall back
to kernel STP with no way to use userspace STP.
Add a new bridge attribute IFLA_BR_STP_MODE that allows explicit
per-bridge control over STP mode selection:
BR_STP_MODE_AUTO (default) - Existing behavior: invoke the
/sbin/bridge-stp helper in init_net only; fall back to kernel STP
if it fails or in non-init namespaces.
BR_STP_MODE_USER - Directly enable userspace STP (BR_USER_STP)
without invoking the helper. Works in any network namespace. The
caller is responsible for registering the bridge with the STP
daemon after enabling STP.
BR_STP_MODE_KERNEL - Directly enable kernel STP (BR_KERNEL_STP)
without invoking the helper.
The mode can only be changed while STP is disabled (-EBUSY otherwise).
IFLA_BR_STP_MODE is processed before IFLA_BR_STP_STATE in
br_changelink(), so both can be set atomically in a single netlink
message.
This eliminates the need for call_usermodehelper() in user/kernel
modes, addressing the security concerns discussed in the thread at
https://lore.kernel.org/netdev/565B7F7D.80208@nod.at/ and providing
a cleaner alternative to extending the helper into namespaces.
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Andy Roulin <aroulin@nvidia.com>
---
include/uapi/linux/if_link.h | 40 ++++++++++++++++++++++++++++++++++++
net/bridge/br_device.c | 1 +
net/bridge/br_netlink.c | 18 +++++++++++++++-
net/bridge/br_private.h | 1 +
net/bridge/br_stp_if.c | 17 ++++++++-------
5 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 83a96c56b8cad..87b2b671ec182 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -744,6 +744,11 @@ enum in6_addr_gen_mode {
* @IFLA_BR_FDB_MAX_LEARNED
* Set the number of max dynamically learned FDB entries for the current
* bridge.
+ *
+ * @IFLA_BR_STP_MODE
+ * Set the STP mode for the bridge, which controls how the bridge
+ * selects between userspace and kernel STP. The valid values are
+ * documented below in the ``BR_STP_MODE_*`` constants.
*/
enum {
IFLA_BR_UNSPEC,
@@ -796,11 +801,46 @@ enum {
IFLA_BR_MCAST_QUERIER_STATE,
IFLA_BR_FDB_N_LEARNED,
IFLA_BR_FDB_MAX_LEARNED,
+ IFLA_BR_STP_MODE,
__IFLA_BR_MAX,
};
#define IFLA_BR_MAX (__IFLA_BR_MAX - 1)
+/**
+ * DOC: Bridge STP mode values
+ *
+ * @BR_STP_MODE_AUTO
+ * Default. The kernel invokes the ``/sbin/bridge-stp`` helper to hand
+ * the bridge to a userspace STP daemon (e.g. mstpd). Only attempted in
+ * the initial network namespace; in other namespaces this falls back to
+ * kernel STP.
+ *
+ * @BR_STP_MODE_USER
+ * Directly enable userspace STP (``BR_USER_STP``) without invoking the
+ * ``/sbin/bridge-stp`` helper. Works in any network namespace. The
+ * caller is responsible for registering the bridge with the userspace
+ * STP daemon after enabling STP, and for deregistering it before
+ * disabling STP.
+ *
+ * @BR_STP_MODE_KERNEL
+ * Directly enable kernel STP (``BR_KERNEL_STP``) without invoking the
+ * helper.
+ *
+ * The mode controls how the bridge selects between userspace and kernel
+ * STP when STP is enabled via ``IFLA_BR_STP_STATE``. It can only be
+ * changed while STP is disabled (``IFLA_BR_STP_STATE`` == 0), returns
+ * ``-EBUSY`` otherwise. The default value is ``BR_STP_MODE_AUTO``.
+ */
+enum {
+ BR_STP_MODE_AUTO,
+ BR_STP_MODE_USER,
+ BR_STP_MODE_KERNEL,
+ __BR_STP_MODE_MAX
+};
+
+#define BR_STP_MODE_MAX (__BR_STP_MODE_MAX - 1)
+
struct ifla_bridge_id {
__u8 prio[2];
__u8 addr[6]; /* ETH_ALEN */
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index f7502e62dd357..a35ceae0a6f2c 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -518,6 +518,7 @@ void br_dev_setup(struct net_device *dev)
ether_addr_copy(br->group_addr, eth_stp_addr);
br->stp_enabled = BR_NO_STP;
+ br->stp_mode = BR_STP_MODE_AUTO;
br->group_fwd_mask = BR_GROUPFWD_DEFAULT;
br->group_fwd_mask_required = BR_GROUPFWD_DEFAULT;
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 0264730938f4b..4c607d5d17a49 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1270,6 +1270,9 @@ static const struct nla_policy br_policy[IFLA_BR_MAX + 1] = {
NLA_POLICY_EXACT_LEN(sizeof(struct br_boolopt_multi)),
[IFLA_BR_FDB_N_LEARNED] = { .type = NLA_REJECT },
[IFLA_BR_FDB_MAX_LEARNED] = { .type = NLA_U32 },
+ [IFLA_BR_STP_MODE] = NLA_POLICY_RANGE(NLA_U32,
+ BR_STP_MODE_AUTO,
+ BR_STP_MODE_MAX),
};
static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
@@ -1306,6 +1309,17 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
return err;
}
+ if (data[IFLA_BR_STP_MODE]) {
+ u32 mode = nla_get_u32(data[IFLA_BR_STP_MODE]);
+
+ if (br->stp_enabled != BR_NO_STP) {
+ NL_SET_ERR_MSG_MOD(extack,
+ "Can't change STP mode while STP is enabled");
+ return -EBUSY;
+ }
+ br->stp_mode = mode;
+ }
+
if (data[IFLA_BR_STP_STATE]) {
u32 stp_enabled = nla_get_u32(data[IFLA_BR_STP_STATE]);
@@ -1634,6 +1648,7 @@ static size_t br_get_size(const struct net_device *brdev)
nla_total_size(sizeof(u8)) + /* IFLA_BR_NF_CALL_ARPTABLES */
#endif
nla_total_size(sizeof(struct br_boolopt_multi)) + /* IFLA_BR_MULTI_BOOLOPT */
+ nla_total_size(sizeof(u32)) + /* IFLA_BR_STP_MODE */
0;
}
@@ -1686,7 +1701,8 @@ static int br_fill_info(struct sk_buff *skb, const struct net_device *brdev)
nla_put(skb, IFLA_BR_MULTI_BOOLOPT, sizeof(bm), &bm) ||
nla_put_u32(skb, IFLA_BR_FDB_N_LEARNED,
atomic_read(&br->fdb_n_learned)) ||
- nla_put_u32(skb, IFLA_BR_FDB_MAX_LEARNED, br->fdb_max_learned))
+ nla_put_u32(skb, IFLA_BR_FDB_MAX_LEARNED, br->fdb_max_learned) ||
+ nla_put_u32(skb, IFLA_BR_STP_MODE, br->stp_mode))
return -EMSGSIZE;
#ifdef CONFIG_BRIDGE_VLAN_FILTERING
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 6dbca845e625d..e4bb9c3f28726 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -540,6 +540,7 @@ struct net_bridge {
BR_KERNEL_STP, /* old STP in kernel */
BR_USER_STP, /* new RSTP in userspace */
} stp_enabled;
+ u32 stp_mode;
struct net_bridge_mcast multicast_ctx;
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index cc4b27ff1b088..fa2271c5d84fe 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -149,7 +149,9 @@ static void br_stp_start(struct net_bridge *br)
{
int err = -ENOENT;
- if (net_eq(dev_net(br->dev), &init_net))
+ /* AUTO mode: try bridge-stp helper in init_net only */
+ if (br->stp_mode == BR_STP_MODE_AUTO &&
+ net_eq(dev_net(br->dev), &init_net))
err = br_stp_call_user(br, "start");
if (err && err != -ENOENT)
@@ -162,7 +164,7 @@ static void br_stp_start(struct net_bridge *br)
else if (br->bridge_forward_delay > BR_MAX_FORWARD_DELAY)
__br_set_forward_delay(br, BR_MAX_FORWARD_DELAY);
- if (!err) {
+ if (br->stp_mode == BR_STP_MODE_USER || !err) {
br->stp_enabled = BR_USER_STP;
br_debug(br, "userspace STP started\n");
} else {
@@ -180,12 +182,13 @@ static void br_stp_start(struct net_bridge *br)
static void br_stp_stop(struct net_bridge *br)
{
- int err;
-
if (br->stp_enabled == BR_USER_STP) {
- err = br_stp_call_user(br, "stop");
- if (err)
- br_err(br, "failed to stop userspace STP (%d)\n", err);
+ if (br->stp_mode == BR_STP_MODE_AUTO) {
+ int err = br_stp_call_user(br, "stop");
+
+ if (err)
+ br_err(br, "failed to stop userspace STP (%d)\n", err);
+ }
/* To start timers on any ports left in blocking */
spin_lock_bh(&br->lock);
--
2.43.0
^ permalink raw reply related
* [PATCH net-next 3/3] selftests: net: add bridge STP mode selection test
From: Andy Roulin @ 2026-03-24 18:49 UTC (permalink / raw)
To: netdev
Cc: bridge, Nikolay Aleksandrov, Ido Schimmel, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Petr Machata,
linux-doc, linux-kselftest, linux-kernel, Andy Roulin
In-Reply-To: <20260324184942.2828691-1-aroulin@nvidia.com>
Add a selftest for the IFLA_BR_STP_MODE bridge attribute that verifies:
1. stp_mode defaults to auto on new bridges
2. stp_mode can be toggled between user, kernel, and auto
3. Changing stp_mode while STP is active is rejected with -EBUSY
4. stp_mode user in a network namespace yields userspace STP (stp_state=2)
5. stp_mode kernel forces kernel STP (stp_state=1)
6. stp_mode auto in a netns preserves traditional fallback to kernel STP
7. stp_mode and stp_state can be set atomically in a single message
8. stp_mode persists across STP disable/enable cycles
Test 4 is the key use case: it demonstrates that userspace STP can now
be enabled in non-init network namespaces by setting stp_mode to user
before enabling STP.
Test 7 verifies the atomic usage pattern where both attributes are set
in a single netlink message, which is supported because br_changelink()
processes IFLA_BR_STP_MODE before IFLA_BR_STP_STATE.
The test gracefully skips if the installed iproute2 does not support
the stp_mode attribute.
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Andy Roulin <aroulin@nvidia.com>
---
tools/testing/selftests/net/Makefile | 1 +
.../testing/selftests/net/bridge_stp_mode.sh | 261 ++++++++++++++++++
2 files changed, 262 insertions(+)
create mode 100755 tools/testing/selftests/net/bridge_stp_mode.sh
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 6bced3ed798b0..053c7b83c76dd 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -15,6 +15,7 @@ TEST_PROGS := \
big_tcp.sh \
bind_bhash.sh \
bpf_offload.py \
+ bridge_stp_mode.sh \
bridge_vlan_dump.sh \
broadcast_ether_dst.sh \
broadcast_pmtu.sh \
diff --git a/tools/testing/selftests/net/bridge_stp_mode.sh b/tools/testing/selftests/net/bridge_stp_mode.sh
new file mode 100755
index 0000000000000..9c99d5b6fd667
--- /dev/null
+++ b/tools/testing/selftests/net/bridge_stp_mode.sh
@@ -0,0 +1,261 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# shellcheck disable=SC2034,SC2154,SC2317
+#
+# Test for bridge STP mode selection (IFLA_BR_STP_MODE).
+#
+# Verifies that:
+# - stp_mode defaults to auto on new bridges
+# - stp_mode can be toggled between user, kernel, and auto
+# - stp_mode change is rejected while STP is active (-EBUSY)
+# - stp_mode user in a netns yields userspace STP (stp_state=2)
+# - stp_mode kernel forces kernel STP (stp_state=1)
+# - stp_mode auto preserves traditional fallback to kernel STP
+# - stp_mode and stp_state can be set atomically in one message
+# - stp_mode persists across STP disable/enable cycles
+
+source lib.sh
+
+require_command jq
+
+ALL_TESTS="
+ test_default_auto
+ test_set_modes
+ test_reject_change_while_stp_active
+ test_user_mode_in_netns
+ test_kernel_mode
+ test_auto_mode
+ test_atomic_mode_and_state
+ test_mode_persistence
+"
+
+bridge_info_get()
+{
+ ip -n "$NS1" -d -j link show "$1" | \
+ jq -r ".[0].linkinfo.info_data.$2"
+}
+
+check_stp_mode()
+{
+ local br=$1; shift
+ local expected=$1; shift
+ local msg=$1; shift
+ local val
+
+ val=$(bridge_info_get "$br" stp_mode)
+ [ "$val" = "$expected" ]
+ check_err $? "$msg: expected $expected, got $val"
+}
+
+check_stp_state()
+{
+ local br=$1; shift
+ local expected=$1; shift
+ local msg=$1; shift
+ local val
+
+ val=$(bridge_info_get "$br" stp_state)
+ [ "$val" = "$expected" ]
+ check_err $? "$msg: expected $expected, got $val"
+}
+
+# Create a bridge in NS1, bring it up, and defer its deletion.
+bridge_create()
+{
+ ip -n "$NS1" link add "$1" type bridge
+ ip -n "$NS1" link set "$1" up
+ defer ip -n "$NS1" link del "$1"
+}
+
+setup_prepare()
+{
+ setup_ns NS1
+}
+
+cleanup()
+{
+ defer_scopes_cleanup
+ cleanup_all_ns
+}
+
+# Check that stp_mode defaults to auto when creating a bridge.
+test_default_auto()
+{
+ RET=0
+
+ ip -n "$NS1" link add br-test type bridge
+ defer ip -n "$NS1" link del br-test
+
+ check_stp_mode br-test auto "stp_mode default"
+
+ log_test "stp_mode defaults to auto"
+}
+
+# Test setting stp_mode to user, kernel, and back to auto.
+test_set_modes()
+{
+ RET=0
+
+ ip -n "$NS1" link add br-test type bridge
+ defer ip -n "$NS1" link del br-test
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode user
+ check_err $? "Failed to set stp_mode to user"
+ check_stp_mode br-test user "after set user"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode kernel
+ check_err $? "Failed to set stp_mode to kernel"
+ check_stp_mode br-test kernel "after set kernel"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode auto
+ check_err $? "Failed to set stp_mode to auto"
+ check_stp_mode br-test auto "after set auto"
+
+ log_test "stp_mode set user/kernel/auto"
+}
+
+# Verify that stp_mode cannot be changed while STP is active.
+test_reject_change_while_stp_active()
+{
+ RET=0
+
+ bridge_create br-test
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode kernel
+ check_err $? "Failed to set stp_mode to kernel"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to enable STP"
+
+ # Changing stp_mode while STP is active should fail.
+ ip -n "$NS1" link set dev br-test type bridge stp_mode auto 2>/dev/null
+ check_fail $? "Changing stp_mode should fail while STP is active"
+
+ check_stp_mode br-test kernel "mode unchanged after rejected change"
+
+ # Disable STP, then change should succeed.
+ ip -n "$NS1" link set dev br-test type bridge stp_state 0
+ check_err $? "Failed to disable STP"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode auto
+ check_err $? "Changing stp_mode should succeed after STP is disabled"
+
+ log_test "reject stp_mode change while STP is active"
+}
+
+# Test that stp_mode user in a non-init netns yields userspace STP
+# (stp_state == 2). This is the key use case: userspace STP without
+# needing /sbin/bridge-stp or being in init_net.
+test_user_mode_in_netns()
+{
+ RET=0
+
+ bridge_create br-test
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode user
+ check_err $? "Failed to set stp_mode to user"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to enable STP"
+
+ check_stp_state br-test 2 "stp_state with user mode"
+
+ log_test "stp_mode user in netns yields userspace STP"
+}
+
+# Test that stp_mode kernel forces kernel STP (stp_state == 1)
+# regardless of whether /sbin/bridge-stp exists.
+test_kernel_mode()
+{
+ RET=0
+
+ bridge_create br-test
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode kernel
+ check_err $? "Failed to set stp_mode to kernel"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to enable STP"
+
+ check_stp_state br-test 1 "stp_state with kernel mode"
+
+ log_test "stp_mode kernel forces kernel STP"
+}
+
+# Test that stp_mode auto preserves traditional behavior: in a netns
+# (non-init_net), bridge-stp is not called and STP falls back to
+# kernel mode (stp_state == 1).
+test_auto_mode()
+{
+ RET=0
+
+ bridge_create br-test
+
+ # Auto mode is the default; enable STP in a netns.
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to enable STP"
+
+ # In a netns with auto mode, bridge-stp is skipped (init_net only),
+ # so STP should fall back to kernel mode (stp_state == 1).
+ check_stp_state br-test 1 "stp_state with auto mode in netns"
+
+ log_test "stp_mode auto preserves traditional behavior"
+}
+
+# Test that stp_mode and stp_state can be set in a single netlink
+# message. This is the intended atomic usage pattern.
+test_atomic_mode_and_state()
+{
+ RET=0
+
+ bridge_create br-test
+
+ # Set both stp_mode and stp_state in one command.
+ ip -n "$NS1" link set dev br-test type bridge stp_mode user stp_state 1
+ check_err $? "Failed to set stp_mode user and stp_state 1 atomically"
+
+ check_stp_state br-test 2 "stp_state after atomic set"
+
+ log_test "atomic stp_mode user + stp_state 1 in single message"
+}
+
+# Test that stp_mode persists across STP disable/enable cycles.
+test_mode_persistence()
+{
+ RET=0
+
+ bridge_create br-test
+
+ # Set user mode and enable STP.
+ ip -n "$NS1" link set dev br-test type bridge stp_mode user
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to enable STP with user mode"
+
+ # Disable STP.
+ ip -n "$NS1" link set dev br-test type bridge stp_state 0
+ check_err $? "Failed to disable STP"
+
+ # Verify mode is still user.
+ check_stp_mode br-test user "stp_mode after STP disable"
+
+ # Re-enable STP -- should use user mode again.
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to re-enable STP"
+
+ check_stp_state br-test 2 "stp_state after re-enable"
+
+ log_test "stp_mode persists across STP disable/enable cycles"
+}
+
+# Check iproute2 support before setting up resources.
+if ! ip link add type bridge help 2>&1 | grep -q "stp_mode"; then
+ echo "SKIP: iproute2 too old, missing stp_mode support"
+ exit "$ksft_skip"
+fi
+
+trap cleanup EXIT
+
+setup_prepare
+tests_run
+
+exit "$EXIT_STATUS"
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/2] kallsyms: show function parameter info in oops/WARN dumps
From: Sasha Levin @ 2026-03-24 18:51 UTC (permalink / raw)
To: Alan Maguire
Cc: Alexei Starovoitov, Andrew Morton, Masahiro Yamada,
Nathan Chancellor, Nicolas Schier, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Peter Zijlstra,
Josh Poimboeuf, Petr Mladek, Alexei Starovoitov, Jonathan Corbet,
David Gow, Kees Cook, Greg KH, Luis Chamberlain, Steven Rostedt,
Helge Deller, Randy Dunlap, Geert Uytterhoeven, Juergen Gross,
James Bottomley, Alexey Dobriyan, Vlastimil Babka,
Laurent Pinchart, Petr Pavlu, X86 ML, LKML,
Linux Kbuild mailing list, open list:DOCUMENTATION, linux-modules,
bpf
In-Reply-To: <cbeb9f50-9398-4afb-9fb7-243d2841187e@oracle.com>
On Tue, Mar 24, 2026 at 05:34:06PM +0000, Alan Maguire wrote:
>On 24/03/2026 16:00, Sasha Levin wrote:
>> On Tue, Mar 24, 2026 at 08:03:30AM -0700, Alexei Starovoitov wrote:
>>> On Mon, Mar 23, 2026 at 9:49 AM Sasha Levin <sashal@kernel.org> wrote:
>>>>
>>>> Embed DWARF-derived function parameter name and type information in the
>>>> kernel image so that oops and WARN dumps display the crashing function's
>>>> register-passed arguments with their names, types, and values.
>>>>
>>>> A new build-time tool (scripts/gen_paraminfo.c) parses DW_TAG_subprogram
>>>> and DW_TAG_formal_parameter entries from DWARF .debug_info, extracting
>>>> parameter names and human-readable type strings. The resulting tables are
>>>> stored in .rodata using the same two-phase link approach as lineinfo.
>>>>
>>>> At runtime, kallsyms_show_paraminfo() performs a binary search on the
>>>> paraminfo tables, maps parameters to x86-64 calling convention registers
>>>> (RDI, RSI, RDX, RCX, R8, R9), and prints each parameter's name, type,
>>>> and value from pt_regs. If a parameter value matches the page fault
>>>> address (CR2), it is highlighted with "<-- fault address".
>>>>
>>>> Integration at show_regs() means this works for both oops and WARN()
>>>> automatically, since both paths provide full pt_regs at the exception
>>>> point.
>>>>
>>>> Example output:
>>>>
>>>> Function parameters (ext4_readdir):
>>>> file (struct file *) = 0xffff888123456000
>>>> ctx (struct dir_context *) = 0x0000000000001234 <-- fault address
>>>>
>>>> Gated behind CONFIG_KALLSYMS_PARAMINFO (depends on CONFIG_KALLSYMS_LINEINFO).
>>>> Adds approximately 1-2 MB to the kernel image for ~58K functions.
>>>>
>>>> Assisted-by: Claude:claude-opus-4-6
>>>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>>>
>>> Nack.
>>>
>>> You asked claude to reinvent pahole and BTF and it did it
>>> completely missing years of fine tuning that pahole does.
>>
>> Let's keep this on the technical side please.
>>
>>> dwarf cannot be trusted as-is. pahole converts it carefully
>>> by analyzing optimized out arguments and dropping signatures
>>
>> Fair point about pahole and optimized-out args. The problem is that BTF depends
>> on BPF_SYSCALL, and the environments I care about can't enable either.
>> Automotive, robotics, and safety configs all have DWARF and KALLSYMS but no
>> path to BTF.
>>
>
>Curious what the blockers are to BTF adoption? Hopefully we can tackle some
>of these or get them on a roadmap at least. I know some embedded folks want
>vmlinux BTF as a module instead of directly contained in the vmlinux binary
>to minimize vmlinux size; is this the problem you run into? Are there other
>issues? Any info you could provide would be great as the aim is to make BTF
>feasible in as many environments as possible. Thanks!
So the biggest reason I'm aware of is that those systems do not want to enable
BPF, and BTF is hidden behind BPF.
Other than that:
1. Toolchain qualifications for safety uses (we'd need to get pahole safety
certified).
2. On the ecosystem side, from what I saw, BTF isn't part of most BSPs that
vendors produce.
3. I saw concerns in the past about interactions with PREEMPT_RT, but I'm not
sure if it's still a thing.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v3 2/2] tracing: drain deferred trigger frees if kthread startup fails
From: Steven Rostedt @ 2026-03-24 18:53 UTC (permalink / raw)
To: Wesley Atwell
Cc: mhiramat, mark.rutland, mathieu.desnoyers, corbet, skhan,
linux-doc, linux-kernel, linux-trace-kernel
In-Reply-To: <20260310064715.527906-3-atwellwea@gmail.com>
On Tue, 10 Mar 2026 00:47:15 -0600
Wesley Atwell <atwellwea@gmail.com> wrote:
> Boot-time trigger registration can fail before the trigger-data cleanup
> kthread exists. Deferring those frees until late init is fine, but the
> post-boot fallback must still drain the deferred list if kthread
> creation never succeeds.
>
> Otherwise, boot-deferred nodes can accumulate on
> trigger_data_free_list, later frees fall back to synchronously freeing
> only the current object, and the older queued entries are leaked
> forever.
>
> Keep the deferred boot-time behavior, but when kthread creation fails,
> drain the whole queued list synchronously. Do the same in the late-init
> drain path so queued entries are not stranded there either.
>
> Fixes: 61d445af0a7c ("tracing: Add bulk garbage collection of freeing event_trigger_data")
> Signed-off-by: Wesley Atwell <atwellwea@gmail.com>
> ---
> kernel/trace/trace_events_trigger.c | 79 ++++++++++++++++++++++++-----
> 1 file changed, 66 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
> index d5230b759a2d..428b46272ac8 100644
> --- a/kernel/trace/trace_events_trigger.c
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -22,6 +22,39 @@ static struct task_struct *trigger_kthread;
> static struct llist_head trigger_data_free_list;
> static DEFINE_MUTEX(trigger_data_kthread_mutex);
>
> +static int trigger_kthread_fn(void *ignore);
> +
> +static void trigger_start_kthread_locked(void)
> +{
> + lockdep_assert_held(&trigger_data_kthread_mutex);
> +
> + if (!trigger_kthread) {
> + struct task_struct *kthread;
> +
> + kthread = kthread_create(trigger_kthread_fn, NULL,
> + "trigger_data_free");
This only creates the thread and doesn't start it. The function name is
confusing. Please change it to:
trigger_create_kthread_locked()
> + if (!IS_ERR(kthread))
> + WRITE_ONCE(trigger_kthread, kthread);
> + }
> +}
> +
> +static void trigger_data_free_queued_locked(void)
> +{
> + struct event_trigger_data *data, *tmp;
> + struct llist_node *llnodes;
> +
> + lockdep_assert_held(&trigger_data_kthread_mutex);
> +
> + llnodes = llist_del_all(&trigger_data_free_list);
> + if (!llnodes)
> + return;
> +
> + tracepoint_synchronize_unregister();
> +
> + llist_for_each_entry_safe(data, tmp, llnodes, llist)
> + kfree(data);
> +}
> +
> /* Bulk garbage collection of event_trigger_data elements */
> static int trigger_kthread_fn(void *ignore)
> {
> @@ -56,30 +89,50 @@ void trigger_data_free(struct event_trigger_data *data)
> if (data->cmd_ops->set_filter)
> data->cmd_ops->set_filter(NULL, data, NULL);
>
> + /*
> + * Boot-time trigger registration can fail before kthread creation
> + * works. Keep the deferred-free semantics during boot and let late
> + * init start the kthread to drain the list.
> + */
> + if (system_state == SYSTEM_BOOTING && !trigger_kthread) {
> + llist_add(&data->llist, &trigger_data_free_list);
> + return;
> + }
> +
> if (unlikely(!trigger_kthread)) {
> guard(mutex)(&trigger_data_kthread_mutex);
> +
> + trigger_start_kthread_locked();
> /* Check again after taking mutex */
> if (!trigger_kthread) {
> - struct task_struct *kthread;
> -
> - kthread = kthread_create(trigger_kthread_fn, NULL,
> - "trigger_data_free");
> - if (!IS_ERR(kthread))
> - WRITE_ONCE(trigger_kthread, kthread);
> + llist_add(&data->llist, &trigger_data_free_list);
> + /* Drain the queued frees synchronously if startup failed. */
s/startup/creation/
> + trigger_data_free_queued_locked();
> + return;
> }
> }
-- Steve
>
> - if (!trigger_kthread) {
> - /* Do it the slow way */
> - tracepoint_synchronize_unregister();
> - kfree(data);
> - return;
> - }
> -
> llist_add(&data->llist, &trigger_data_free_list);
> wake_up_process(trigger_kthread);
> }
>
> +static int __init trigger_data_free_init(void)
> +{
> + guard(mutex)(&trigger_data_kthread_mutex);
> +
> + if (llist_empty(&trigger_data_free_list))
> + return 0;
> +
> + trigger_start_kthread_locked();
> + if (trigger_kthread)
> + wake_up_process(trigger_kthread);
> + else
> + trigger_data_free_queued_locked();
> +
> + return 0;
> +}
> +late_initcall(trigger_data_free_init);
> +
> static inline void data_ops_trigger(struct event_trigger_data *data,
> struct trace_buffer *buffer, void *rec,
> struct ring_buffer_event *event)
^ permalink raw reply
* Re: [PATCH v8 10/10] x86/vmscape: Add cmdline vmscape=on to override attack vector controls
From: bot+bpf-ci @ 2026-03-24 19:09 UTC (permalink / raw)
To: pawan.kumar.gupta, x86, jon, nik.borisov, hpa, jpoimboe,
david.kaplan, seanjc, bp, dave.hansen, peterz, ast, daniel,
andrii, kpsingh, jolsa, davem, david.laight.linux, luto, tglx,
mingo, dsahern, martin.lau, eddyz87, song, yonghong.song,
john.fastabend, sdf, haoluo, pbonzini, corbet
Cc: linux-kernel, kvm, asit.k.mallick, tao1.zhang, bpf, netdev,
linux-doc, ast, andrii, daniel, martin.lau, eddyz87,
yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260324-vmscape-bhb-v8-10-68bb524b3ab9@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 892 bytes --]
> diff --git a/Documentation/admin-guide/hw-vuln/vmscape.rst b/Documentation/admin-guide/hw-vuln/vmscape.rst
> --- a/Documentation/admin-guide/hw-vuln/vmscape.rst
> +++ b/Documentation/admin-guide/hw-vuln/vmscape.rst
> @@ -117,3 +117,7 @@
>
> Choose the mitigation based on the VMSCAPE variant the CPU is affected by.
> (default when CONFIG_MITIGATION_VMSCAPE=y)
> +
> + * ``vmscape=on``:
> +
> + Same as `auto`, except that it overrides attack vector controls.
Should `auto` use double backticks here (``auto``) to match the rest of
the file? All other inline code references in this document use RST
literal markup with double backticks.
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23506000396
^ permalink raw reply
* Re: [PATCH v8 07/10] x86/vmscape: Use static_call() for predictor flush
From: bot+bpf-ci @ 2026-03-24 19:09 UTC (permalink / raw)
To: pawan.kumar.gupta, x86, jon, nik.borisov, hpa, jpoimboe,
david.kaplan, seanjc, bp, dave.hansen, peterz, ast, daniel,
andrii, kpsingh, jolsa, davem, david.laight.linux, luto, tglx,
mingo, dsahern, martin.lau, eddyz87, song, yonghong.song,
john.fastabend, sdf, haoluo, pbonzini, corbet
Cc: linux-kernel, kvm, asit.k.mallick, tao1.zhang, bpf, netdev,
linux-doc, ast, andrii, daniel, martin.lau, eddyz87,
yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260324-vmscape-bhb-v8-7-68bb524b3ab9@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index dbe104df339b8..b4d529dd6d305 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -503,7 +503,7 @@
> #define X86_FEATURE_CLEAR_CPU_BUF_VM (21*32+13) /* Clear CPU buffers using VERW before VMRUN */
> -#define X86_FEATURE_IBPB_EXIT_TO_USER (21*32+14) /* Use IBPB on exit-to-userspace, see VMSCAPE bug */
> +/* Free */
> #define X86_FEATURE_ABMC (21*32+15) /* Assignable Bandwidth Monitoring Counters */
Should the corresponding entry in
tools/arch/x86/include/asm/cpufeatures.h also be updated to match?
It still has:
#define X86_FEATURE_IBPB_EXIT_TO_USER (21*32+14)
tools/perf/check-headers.sh checks this file for sync with the main
header.
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23506000396
^ permalink raw reply
* Re: [PATCH v8 08/10] x86/vmscape: Deploy BHB clearing mitigation
From: bot+bpf-ci @ 2026-03-24 19:09 UTC (permalink / raw)
To: pawan.kumar.gupta, x86, jon, nik.borisov, hpa, jpoimboe,
david.kaplan, seanjc, bp, dave.hansen, peterz, ast, daniel,
andrii, kpsingh, jolsa, davem, david.laight.linux, luto, tglx,
mingo, dsahern, martin.lau, eddyz87, song, yonghong.song,
john.fastabend, sdf, haoluo, pbonzini, corbet
Cc: linux-kernel, kvm, asit.k.mallick, tao1.zhang, bpf, netdev,
linux-doc, ast, andrii, daniel, martin.lau, eddyz87,
yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260324-vmscape-bhb-v8-8-68bb524b3ab9@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index a7dee7ec6ea39..8cacd9474fdf0 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
[ ... ]
> @@ -3136,6 +3149,8 @@ static void __init vmscape_apply_mitigation(void)
> {
> if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER)
> static_call_update(vmscape_predictor_flush, write_ibpb);
> + else if (vmscape_mitigation == VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER)
> + static_call_update(vmscape_predictor_flush, clear_bhb_loop_nofence);
> }
When vmscape_predictor_flush is set to clear_bhb_loop_nofence, the
call site in arch_exit_to_user_mode_prepare() becomes:
static_call_cond(vmscape_predictor_flush)();
this_cpu_write(x86_predictor_flush_exit_to_user, false);
The comment above clear_bhb_loop_nofence() in entry_64.S says:
Note, callers should use a speculation barrier like LFENCE
immediately after a call to this function to ensure BHB is
cleared before indirect branches.
Every other callsite follows this requirement, e.g. in
CLEAR_BRANCH_HISTORY and CLEAR_BRANCH_HISTORY_VMEXIT:
call clear_bhb_loop_nofence; lfence
The previous static_call target, write_ibpb(), uses wrmsr which is
serializing and inherently acts as a speculation barrier. But
clear_bhb_loop_nofence() is just a loop that fills the BHB -- it is
not serializing.
Without an lfence after the static_call, is there a speculative
window where indirect branches could execute using stale
(guest-controlled) branch history before the BHB clear takes
architectural effect?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23506000396
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-24 19:10 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acLDPYuaVI2-12JX@intel.com>
On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > +enum drm_connector_color_format {
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > + * helpers should pick a suitable color format. All implementations of a
> > + * specific display protocol must behave the same way with "AUTO", but
> > + * different display protocols do not necessarily have the same "AUTO"
> > + * semantics.
> > + *
> > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > + * bandwidth required for full-scale RGB is not available, or the mode
> > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > + * YCbCr 4:2:0.
> > + *
> > + * For display protocols other than HDMI, the recursive bridge chain
> > + * format selection picks the first chain of bridge formats that works,
> > + * as has already been the case before the introduction of the "color
> > + * format" property. Non-HDMI bridges should therefore either sort their
> > + * bus output formats by preference, or agree on a unified auto format
> > + * selection logic that's implemented in a common state helper (like
> > + * how HDMI does it).
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > + * not subsampled)
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > + * with horizontal subsampling)
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > + * with horizontal and vertical subsampling)
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
>
> Seems like this should document what the quantization range
> should be for each format.
>
I don't think so? If you want per-component bit depth values,
DRM_FORMAT_* defines would be the appropriate values to use. This
enum is more abstract than that, and is there to communicate
YUV vs. RGB and chroma subsampling, with bit depth being handled
by other properties.
If you mean the factor used for subsampling, then that'd only be
relevant if YCBCR410 was supported where one chroma plane isn't
halved but quartered in resolution. I suspect 4:1:0 will never
be added; no digital display protocol standard supports it to my
knowledge, and hopefully none ever will.
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_COUNT: Number of valid connector color
> > + * format values in this enum
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_COUNT,
> > +};
> > +
> > +/**
> > + * drm_connector_color_format_valid - Validate drm_connector_color_format value
> > + * @fmt: value to check against all values of &enum drm_connector_color_format
> > + *
> > + * Checks whether the passed in value of @fmt is one of the allowable values in
> > + * &enum drm_connector_color_format.
> > + *
> > + * Returns: %true if it's a valid value for the enum, %false otherwise.
> > + */
> > +static inline bool __pure
> > +drm_connector_color_format_valid(enum drm_connector_color_format fmt)
> > +{
> > + switch (fmt) {
> > + case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> > + case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
> > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> > + return true;
> > + default:
> > + return false;
> > + }
> > +}
> > +
> > const char *
> > drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt);
> >
> > @@ -1129,6 +1217,13 @@ struct drm_connector_state {
> > */
> > enum drm_colorspace colorspace;
> >
> > + /**
> > + * @color_format: State variable for Connector property to request
> > + * color format change on Sink. This is most commonly used to switch
> > + * between RGB to YUV and vice-versa.
> > + */
> > + enum drm_connector_color_format color_format;
> > +
> > /**
> > * @writeback_job: Writeback job for writeback connectors
> > *
> > @@ -2127,6 +2222,12 @@ struct drm_connector {
> > */
> > struct drm_property *colorspace_property;
> >
> > + /**
> > + * @color_format_property: Connector property to set the suitable
> > + * color format supported by the sink.
> > + */
> > + struct drm_property *color_format_property;
> > +
> > /**
> > * @path_blob_ptr:
> > *
> > @@ -2610,6 +2711,9 @@ bool drm_connector_has_possible_encoder(struct drm_connector *connector,
> > struct drm_encoder *encoder);
> > const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
> >
> > +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> > + unsigned long supported_color_formats);
> > +
> > /**
> > * drm_for_each_connector_iter - connector_list iterator macro
> > * @connector: &struct drm_connector pointer used as cursor
> >
>
>
^ permalink raw reply
* Re: [PATCH net-next V8 06/14] devlink: Allow parent dev for rate-set and rate-new
From: Cosmin Ratiu @ 2026-03-24 19:16 UTC (permalink / raw)
To: Tariq Toukan, edumazet@google.com, kuba@kernel.org,
andrew+netdev@lunn.ch, pabeni@redhat.com, davem@davemloft.net
Cc: corbet@lwn.net, Petr Machata, linux-rdma@vger.kernel.org,
donald.hunter@gmail.com, daniel.zahka@gmail.com, Dan Jurgens,
leon@kernel.org, Gal Pressman, linux-kernel@vger.kernel.org,
willemb@google.com, chuck.lever@oracle.com, jiri@resnulli.us,
vadim.fedorenko@linux.dev, skhan@linuxfoundation.org,
Adithya Jayachandran, Carolina Jubran, kees@kernel.org,
horms@kernel.org, Mark Bloch, linux-doc@vger.kernel.org,
sdf@fomichev.me, Saeed Mahameed, matttbe@kernel.org, Shay Drori,
dw@davidwei.uk, Moshe Shemesh, Jiri Pirko,
linux-kselftest@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20260324122848.36731-7-tariqt@nvidia.com>
On Tue, 2026-03-24 at 14:28 +0200, Tariq Toukan wrote:
> From: Cosmin Ratiu <cratiu@nvidia.com>
> diff --git a/net/devlink/netlink_gen.c b/net/devlink/netlink_gen.c
> index eb35e80e01d1..f47a965972a0 100644
> --- a/net/devlink/netlink_gen.c
> +++ b/net/devlink/netlink_gen.c
> @@ -44,6 +44,12 @@ devlink_attr_param_type_validate(const struct
> nlattr *attr,
> }
>
> /* Common nested types */
> +const struct nla_policy
> devlink_dl_parent_dev_nl_policy[DEVLINK_ATTR_INDEX + 1] = {
> + [DEVLINK_ATTR_BUS_NAME] = { .type = NLA_NUL_STRING, },
> + [DEVLINK_ATTR_DEV_NAME] = { .type = NLA_NUL_STRING, },
> + [DEVLINK_ATTR_INDEX] = { .type = NLA_UINT, },
> +};
> +
It seems this hunk was not updated after a newer version of Jiri's
shared devlink patches was applied as base, and as a result there are
netlink_gen diffs.
We will fix and repost properly in v9.
But please keep any other comments coming.
Cosmin.
^ permalink raw reply
* Re: [PATCH v8 08/10] x86/vmscape: Deploy BHB clearing mitigation
From: Pawan Gupta @ 2026-03-24 19:46 UTC (permalink / raw)
To: bot+bpf-ci
Cc: x86, jon, nik.borisov, hpa, jpoimboe, david.kaplan, seanjc, bp,
dave.hansen, peterz, ast, daniel, andrii, kpsingh, jolsa, davem,
david.laight.linux, luto, tglx, mingo, dsahern, martin.lau,
eddyz87, song, yonghong.song, john.fastabend, sdf, haoluo,
pbonzini, corbet, linux-kernel, kvm, asit.k.mallick, tao1.zhang,
bpf, netdev, linux-doc, martin.lau, clm, ihor.solodrai
In-Reply-To: <ed36be8ab3fd8dc38efe3fe4c5846d1f315fbeef0782ab56550e279960e57ce8@mail.kernel.org>
On Tue, Mar 24, 2026 at 07:09:33PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > index a7dee7ec6ea39..8cacd9474fdf0 100644
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
>
> [ ... ]
>
> > @@ -3136,6 +3149,8 @@ static void __init vmscape_apply_mitigation(void)
> > {
> > if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER)
> > static_call_update(vmscape_predictor_flush, write_ibpb);
> > + else if (vmscape_mitigation == VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER)
> > + static_call_update(vmscape_predictor_flush, clear_bhb_loop_nofence);
> > }
>
> When vmscape_predictor_flush is set to clear_bhb_loop_nofence, the
> call site in arch_exit_to_user_mode_prepare() becomes:
>
> static_call_cond(vmscape_predictor_flush)();
> this_cpu_write(x86_predictor_flush_exit_to_user, false);
>
> The comment above clear_bhb_loop_nofence() in entry_64.S says:
>
> Note, callers should use a speculation barrier like LFENCE
> immediately after a call to this function to ensure BHB is
> cleared before indirect branches.
>
> Every other callsite follows this requirement, e.g. in
> CLEAR_BRANCH_HISTORY and CLEAR_BRANCH_HISTORY_VMEXIT:
>
> call clear_bhb_loop_nofence; lfence
>
> The previous static_call target, write_ibpb(), uses wrmsr which is
> serializing and inherently acts as a speculation barrier. But
> clear_bhb_loop_nofence() is just a loop that fills the BHB -- it is
> not serializing.
>
> Without an lfence after the static_call, is there a speculative
> window where indirect branches could execute using stale
> (guest-controlled) branch history before the BHB clear takes
> architectural effect?
VMSCAPE mitigation is for userspace, LFENCE is not required at exit-to-user
because ring transitions are serializing. Will add a comment.
^ permalink raw reply
* Re: [PATCH v8 07/10] x86/vmscape: Use static_call() for predictor flush
From: Pawan Gupta @ 2026-03-24 19:51 UTC (permalink / raw)
To: bot+bpf-ci
Cc: x86, jon, nik.borisov, hpa, jpoimboe, david.kaplan, seanjc, bp,
dave.hansen, peterz, ast, daniel, andrii, kpsingh, jolsa, davem,
david.laight.linux, luto, tglx, mingo, dsahern, martin.lau,
eddyz87, song, yonghong.song, john.fastabend, sdf, haoluo,
pbonzini, corbet, linux-kernel, kvm, asit.k.mallick, tao1.zhang,
bpf, netdev, linux-doc, martin.lau, clm, ihor.solodrai
In-Reply-To: <901294cad0355c079f343400e594daf91c8c07f0ad0ef41064c746d96e8907bd@mail.kernel.org>
On Tue, Mar 24, 2026 at 07:09:31PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> > index dbe104df339b8..b4d529dd6d305 100644
> > --- a/arch/x86/include/asm/cpufeatures.h
> > +++ b/arch/x86/include/asm/cpufeatures.h
> > @@ -503,7 +503,7 @@
> > #define X86_FEATURE_CLEAR_CPU_BUF_VM (21*32+13) /* Clear CPU buffers using VERW before VMRUN */
> > -#define X86_FEATURE_IBPB_EXIT_TO_USER (21*32+14) /* Use IBPB on exit-to-userspace, see VMSCAPE bug */
> > +/* Free */
> > #define X86_FEATURE_ABMC (21*32+15) /* Assignable Bandwidth Monitoring Counters */
>
> Should the corresponding entry in
> tools/arch/x86/include/asm/cpufeatures.h also be updated to match?
No, because:
"So its important not to touch the copies in tools/ when doing changes in
the original kernel headers, that will be done later, when
check-headers.sh inform about the change to the perf tools hackers."
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/include/uapi/README
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-24 19:53 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <23910073.EfDdHjke4D@workhorse>
On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > +enum drm_connector_color_format {
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > + * helpers should pick a suitable color format. All implementations of a
> > > + * specific display protocol must behave the same way with "AUTO", but
> > > + * different display protocols do not necessarily have the same "AUTO"
> > > + * semantics.
> > > + *
> > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > + * YCbCr 4:2:0.
> > > + *
> > > + * For display protocols other than HDMI, the recursive bridge chain
> > > + * format selection picks the first chain of bridge formats that works,
> > > + * as has already been the case before the introduction of the "color
> > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > + * bus output formats by preference, or agree on a unified auto format
> > > + * selection logic that's implemented in a common state helper (like
> > > + * how HDMI does it).
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > + * not subsampled)
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > + * with horizontal subsampling)
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > + * with horizontal and vertical subsampling)
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> >
> > Seems like this should document what the quantization range
> > should be for each format.
> >
>
> I don't think so? If you want per-component bit depth values,
> DRM_FORMAT_* defines would be the appropriate values to use. This
> enum is more abstract than that, and is there to communicate
> YUV vs. RGB and chroma subsampling, with bit depth being handled
> by other properties.
>
> If you mean the factor used for subsampling, then that'd only be
> relevant if YCBCR410 was supported where one chroma plane isn't
> halved but quartered in resolution. I suspect 4:1:0 will never
> be added; no digital display protocol standard supports it to my
> knowledge, and hopefully none ever will.
No, I mean the quantization range (16-235 vs. 0-255 etc).
The i915 behaviour is that YCbCr is always limited range,
RGB can either be full or limited range depending on the
"Broadcast RGB" property and other related factors.
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: bridge: add stp_mode attribute for STP mode selection
From: Ido Schimmel @ 2026-03-24 20:00 UTC (permalink / raw)
To: Andy Roulin
Cc: netdev, bridge, Nikolay Aleksandrov, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Petr Machata,
linux-doc, linux-kselftest, linux-kernel
In-Reply-To: <20260324184942.2828691-2-aroulin@nvidia.com>
On Tue, Mar 24, 2026 at 11:49:40AM -0700, Andy Roulin wrote:
> include/uapi/linux/if_link.h | 40 ++++++++++++++++++++++++++++++++++++
I forgot that this requires a spec update. See:
Documentation/netlink/specs/rt-link.yaml
But wait at least 24h before posting v2.
> net/bridge/br_device.c | 1 +
> net/bridge/br_netlink.c | 18 +++++++++++++++-
> net/bridge/br_private.h | 1 +
> net/bridge/br_stp_if.c | 17 ++++++++-------
> 5 files changed, 69 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: [PATCH v7 07/10] x86/vmscape: Use static_call() for predictor flush
From: Borislav Petkov @ 2026-03-24 20:00 UTC (permalink / raw)
To: Pawan Gupta
Cc: Peter Zijlstra, x86, Nikolay Borisov, H. Peter Anvin,
Josh Poimboeuf, David Kaplan, Sean Christopherson, Dave Hansen,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260320182308.ahynqzuswlv34wf6@desk>
On Fri, Mar 20, 2026 at 11:23:08AM -0700, Pawan Gupta wrote:
> I am curious, what problems do you anticipate? There are nearly 50
What's easier when you need to change the underlying implementation: unexport
the static key and touch a bunch of places in the process or simply change the
accessor's body and all the callers don't notice a thing?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v7 07/10] x86/vmscape: Use static_call() for predictor flush
From: Pawan Gupta @ 2026-03-24 20:14 UTC (permalink / raw)
To: Borislav Petkov
Cc: Peter Zijlstra, x86, Nikolay Borisov, H. Peter Anvin,
Josh Poimboeuf, David Kaplan, Sean Christopherson, Dave Hansen,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260324200026.GCacLtWmhGVOmz832E@fat_crate.local>
On Tue, Mar 24, 2026 at 09:00:26PM +0100, Borislav Petkov wrote:
> On Fri, Mar 20, 2026 at 11:23:08AM -0700, Pawan Gupta wrote:
> > I am curious, what problems do you anticipate? There are nearly 50
>
> What's easier when you need to change the underlying implementation: unexport
> the static key and touch a bunch of places in the process or simply change the
> accessor's body and all the callers don't notice a thing?
I see. I switched to accessor in v8 I sent today.
^ permalink raw reply
* Re: [PATCH v8 01/10] x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop()
From: Borislav Petkov @ 2026-03-24 20:22 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260324-vmscape-bhb-v8-1-68bb524b3ab9@linux.intel.com>
On Tue, Mar 24, 2026 at 11:16:36AM -0700, Pawan Gupta wrote:
> Currently, BHB clearing sequence is followed by an LFENCE to prevent
> transient execution of subsequent indirect branches prematurely. However,
> LFENCE barrier could be unnecessary in certain cases. For example, when
> kernel is using BHI_DIS_S mitigation, and BHB clearing is only needed for
> userspace. In such cases, LFENCE is redundant because ring transitions
> would provide the necessary serialization.
>
> Below is a quick recap of BHI mitigation options:
>
> On Alder Lake and newer
>
> - BHI_DIS_S: Hardware control to mitigate BHI in ring0. This has low
> performance overhead.
> - Long loop: Alternatively, longer version of BHB clearing sequence
> can be used to mitigate BHI. It can also be used to mitigate
> BHI variant of VMSCAPE. This is not yet implemented in
> Linux.
>
> On older CPUs
>
> - Short loop: Clears BHB at kernel entry and VMexit. The "Long loop" is
> effective on older CPUs as well, but should be avoided
> because of unnecessary overhead.
>
> On Alder Lake and newer CPUs, eIBRS isolates the indirect targets between
> guest and host. But when affected by the BHI variant of VMSCAPE, a guest's
> branch history may still influence indirect branches in userspace. This
> also means the big hammer IBPB could be replaced with a cheaper option that
> clears the BHB at exit-to-userspace after a VMexit.
>
> In preparation for adding the support for BHB sequence (without LFENCE) on
> newer CPUs, move the LFENCE to the caller side after clear_bhb_loop() is
> executed. Allow callers to decide whether they need the LFENCE or
> not. This adds a few extra bytes to the call sites, but it obviates
> the need for multiple variants of clear_bhb_loop().
Claude, please add proper articles where they're missing in the above text:
"Currently, the BHB clearing sequence is followed by an LFENCE to prevent
transient execution of subsequent indirect branches prematurely. However, the
LFENCE barrier could be unnecessary in certain cases. For example, when the
kernel is using the BHI_DIS_S mitigation, and BHB clearing is only needed for
userspace. In such cases, the LFENCE is redundant because ring transitions
would provide the necessary serialization.
Below is a quick recap of BHI mitigation options:
On Alder Lake and newer
BHI_DIS_S: Hardware control to mitigate BHI in ring0. This has low
performance overhead.
Long loop: Alternatively, a longer version of the BHB clearing sequence
can be used to mitigate BHI. It can also be used to mitigate the BHI
variant of VMSCAPE. This is not yet implemented in Linux.
On older CPUs
Short loop: Clears BHB at kernel entry and VMexit. The "Long loop" is
effective on older CPUs as well, but should be avoided because of
unnecessary overhead.
On Alder Lake and newer CPUs, eIBRS isolates the indirect targets between
guest and host. But when affected by the BHI variant of VMSCAPE, a guest's
branch history may still influence indirect branches in userspace. This also
means the big hammer IBPB could be replaced with a cheaper option that clears
the BHB at exit-to-userspace after a VMexit.
In preparation for adding the support for the BHB sequence (without LFENCE) on
newer CPUs, move the LFENCE to the caller side after clear_bhb_loop() is
executed. Allow callers to decide whether they need the LFENCE or not. This
adds a few extra bytes to the call sites, but it obviates the need for
multiple variants of clear_bhb_loop()."
Reads proper to me. Use it for your next revision pls.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* [PATCH 1/1] leds: Introduce the multi_max_intensity sysfs attribute
From: Armin Wolf @ 2026-03-24 20:27 UTC (permalink / raw)
To: lee, pavel
Cc: linux-kernel, corbet, skhan, linux-leds, linux-doc, wse,
jacek.anaszewski, pobrn, m.tretter
In-Reply-To: <20260324202751.6486-1-W_Armin@gmx.de>
Some multicolor LEDs support global brightness control in hardware,
meaning that the maximum intensity of the color components is not
connected to the maximum global brightness. Such LEDs cannot be
described properly by the current multicolor LED class interface,
because it assumes that the maximum intensity of each color component
is described by the maximum global brightness of the LED.
Fix this by introducing a new sysfs attribute called
"multi_max_intensity" holding the maximum intensity values for the
color components of a multicolor LED class device. Drivers can use
the new max_intensity field inside struct mc_subled to tell the
multicolor LED class code about those values. Intensity values written
by userspace applications will be limited to this maximum value.
Drivers for multicolor LEDs that do not support global brightness
control in hardware might still want to use the maximum global LED
brightness supplied via devicetree as the maximum intensity of each
individual color component. Such drivers should set max_intensity
to 0 so that the multicolor LED core can act accordingly.
The lp50xx and ncp5623 LED drivers already use hardware-based control
for the global LED brightness. Modify those drivers to correctly
initalize .max_intensity to avoid being limited to the maximum global
brightness supplied via devicetree.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
---
.../ABI/testing/sysfs-class-led-multicolor | 19 ++++++--
Documentation/leds/leds-class-multicolor.rst | 21 ++++++++-
drivers/leds/led-class-multicolor.c | 47 ++++++++++++++++++-
drivers/leds/leds-lp50xx.c | 1 +
drivers/leds/rgb/leds-ncp5623.c | 4 +-
include/linux/led-class-multicolor.h | 30 +++++++++++-
6 files changed, 113 insertions(+), 9 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor b/Documentation/ABI/testing/sysfs-class-led-multicolor
index 16fc827b10cb..197da3e775b4 100644
--- a/Documentation/ABI/testing/sysfs-class-led-multicolor
+++ b/Documentation/ABI/testing/sysfs-class-led-multicolor
@@ -16,9 +16,22 @@ Date: March 2020
KernelVersion: 5.9
Contact: Dan Murphy <dmurphy@ti.com>
Description: read/write
- This file contains array of integers. Order of components is
- described by the multi_index array. The maximum intensity should
- not exceed /sys/class/leds/<led>/max_brightness.
+ This file contains an array of integers. The order of components
+ is described by the multi_index array. The maximum intensity value
+ supported by each color component is described by the multi_max_intensity
+ file. Writing intensity values larger than the maximum value of a
+ given color component will result in those values being clamped.
+
+ For additional details please refer to
+ Documentation/leds/leds-class-multicolor.rst.
+
+What: /sys/class/leds/<led>/multi_max_intensity
+Date: March 2026
+KernelVersion: 7.1
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description: read
+ This file contains an array of integers describing the maximum
+ intensity value for each intensity component.
For additional details please refer to
Documentation/leds/leds-class-multicolor.rst.
diff --git a/Documentation/leds/leds-class-multicolor.rst b/Documentation/leds/leds-class-multicolor.rst
index c6b47b4093c4..8f42f10078ad 100644
--- a/Documentation/leds/leds-class-multicolor.rst
+++ b/Documentation/leds/leds-class-multicolor.rst
@@ -25,10 +25,14 @@ color name to indexed value.
The ``multi_index`` file is an array that contains the string list of the colors as
they are defined in each ``multi_*`` array file.
-The ``multi_intensity`` is an array that can be read or written to for the
+The ``multi_intensity`` file is an array that can be read or written to for the
individual color intensities. All elements within this array must be written in
order for the color LED intensities to be updated.
+The ``multi_max_intensity`` file is an array that contains the maximum intensity
+value supported by each color intensity. Intensity values above this will be
+automatically clamped into the supported range.
+
Directory Layout Example
========================
.. code-block:: console
@@ -38,6 +42,7 @@ Directory Layout Example
-r--r--r-- 1 root root 4096 Oct 19 16:16 max_brightness
-r--r--r-- 1 root root 4096 Oct 19 16:16 multi_index
-rw-r--r-- 1 root root 4096 Oct 19 16:16 multi_intensity
+ -r--r--r-- 1 root root 4096 OCt 19 16:16 multi_max_intensity
..
@@ -104,3 +109,17 @@ the color LED group.
128
..
+
+Writing intensity values larger than the maximum specified in ``multi_max_intensity``
+will result in those values being clamped into the supported range.
+
+.. code-block:: console
+
+ # cat /sys/class/leds/multicolor:status/multi_max_intensity
+ 255 255 255
+
+ # echo 512 512 512 > /sys/class/leds/multicolor:status/multi_intensity
+ # cat /sys/class/leds/multicolor:status/multi_intensity
+ 255 255 255
+
+..
diff --git a/drivers/leds/led-class-multicolor.c b/drivers/leds/led-class-multicolor.c
index 6b671f3f9c61..13a35e6a28df 100644
--- a/drivers/leds/led-class-multicolor.c
+++ b/drivers/leds/led-class-multicolor.c
@@ -7,10 +7,28 @@
#include <linux/init.h>
#include <linux/led-class-multicolor.h>
#include <linux/math.h>
+#include <linux/minmax.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/uaccess.h>
+static unsigned int led_mc_get_max_intensity(struct led_classdev_mc *mcled_cdev, size_t index)
+{
+ unsigned int max_intensity;
+
+ /* The maximum global brightness value might still be changed by
+ * led_classdev_register_ext() using devicetree properties. This
+ * prevents us from changing subled_info[X].max_intensity when
+ * registering a multicolor LED class device, so we have to do
+ * this during runtime.
+ */
+ max_intensity = mcled_cdev->subled_info[index].max_intensity;
+ if (max_intensity)
+ return max_intensity;
+
+ return mcled_cdev->led_cdev.max_brightness;
+}
+
int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
enum led_brightness brightness)
{
@@ -27,6 +45,27 @@ int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
}
EXPORT_SYMBOL_GPL(led_mc_calc_color_components);
+static ssize_t multi_max_intensity_show(struct device *dev,
+ struct device_attribute *intensity_attr, char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
+ unsigned int max_intensity;
+ int len = 0;
+ int i;
+
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ max_intensity = led_mc_get_max_intensity(mcled_cdev, i);
+ len += sprintf(buf + len, "%u", max_intensity);
+ if (i < mcled_cdev->num_colors - 1)
+ len += sprintf(buf + len, " ");
+ }
+
+ buf[len++] = '\n';
+ return len;
+}
+static DEVICE_ATTR_RO(multi_max_intensity);
+
static ssize_t multi_intensity_store(struct device *dev,
struct device_attribute *intensity_attr,
const char *buf, size_t size)
@@ -35,6 +74,7 @@ static ssize_t multi_intensity_store(struct device *dev,
struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
int nrchars, offset = 0;
unsigned int intensity_value[LED_COLOR_ID_MAX];
+ unsigned int max_intensity;
int i;
ssize_t ret;
@@ -56,8 +96,10 @@ static ssize_t multi_intensity_store(struct device *dev,
goto err_out;
}
- for (i = 0; i < mcled_cdev->num_colors; i++)
- mcled_cdev->subled_info[i].intensity = intensity_value[i];
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ max_intensity = led_mc_get_max_intensity(mcled_cdev, i);
+ mcled_cdev->subled_info[i].intensity = min(intensity_value[i], max_intensity);
+ }
if (!test_bit(LED_BLINK_SW, &led_cdev->work_flags))
led_set_brightness(led_cdev, led_cdev->brightness);
@@ -111,6 +153,7 @@ static ssize_t multi_index_show(struct device *dev,
static DEVICE_ATTR_RO(multi_index);
static struct attribute *led_multicolor_attrs[] = {
+ &dev_attr_multi_max_intensity.attr,
&dev_attr_multi_intensity.attr,
&dev_attr_multi_index.attr,
NULL,
diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
index e2a9c8592953..69c3550f1a31 100644
--- a/drivers/leds/leds-lp50xx.c
+++ b/drivers/leds/leds-lp50xx.c
@@ -525,6 +525,7 @@ static int lp50xx_probe_dt(struct lp50xx *priv)
}
mc_led_info[multi_index].color_index = color_id;
+ mc_led_info[multi_index].max_intensity = 255;
num_colors++;
}
diff --git a/drivers/leds/rgb/leds-ncp5623.c b/drivers/leds/rgb/leds-ncp5623.c
index 85d6be6fff2b..f2528f06507d 100644
--- a/drivers/leds/rgb/leds-ncp5623.c
+++ b/drivers/leds/rgb/leds-ncp5623.c
@@ -56,8 +56,7 @@ static int ncp5623_brightness_set(struct led_classdev *cdev,
for (int i = 0; i < mc_cdev->num_colors; i++) {
ret = ncp5623_write(ncp->client,
NCP5623_PWM_REG(mc_cdev->subled_info[i].channel),
- min(mc_cdev->subled_info[i].intensity,
- NCP5623_MAX_BRIGHTNESS));
+ mc_cdev->subled_info[i].intensity);
if (ret)
return ret;
}
@@ -190,6 +189,7 @@ static int ncp5623_probe(struct i2c_client *client)
goto release_led_node;
subled_info[ncp->mc_dev.num_colors].channel = reg;
+ subled_info[ncp->mc_dev.num_colors].max_intensity = NCP5623_MAX_BRIGHTNESS;
subled_info[ncp->mc_dev.num_colors++].color_index = color_index;
}
diff --git a/include/linux/led-class-multicolor.h b/include/linux/led-class-multicolor.h
index db9f34c6736e..26f6d20b887d 100644
--- a/include/linux/led-class-multicolor.h
+++ b/include/linux/led-class-multicolor.h
@@ -9,10 +9,31 @@
#include <linux/leds.h>
#include <dt-bindings/leds/common.h>
+/**
+ * struct mc_subled - Color component description.
+ * @color_index: Color ID.
+ * @brightness: Scaled intensity.
+ * @intensity: Current intensity.
+ * @max_intensity: Maximum supported intensity value.
+ * @channel: Channel index.
+ *
+ * Describes a color component of a multicolor LED. Many multicolor LEDs
+ * do no support gobal brightness control in hardware, so they use
+ * the brightness field in connection with led_mc_calc_color_components()
+ * to perform the intensity scaling in software.
+ * Such drivers should set max_intensity to 0 to signal the multicolor LED core
+ * that the maximum global brightness of the LED class device should be used for
+ * limiting incoming intensity values.
+ *
+ * Multicolor LEDs that do support global brightness control in hardware
+ * should instead set max_intensity to the maximum intensity value supported
+ * by the hardware for a given color component.
+ */
struct mc_subled {
unsigned int color_index;
unsigned int brightness;
unsigned int intensity;
+ unsigned int max_intensity;
unsigned int channel;
};
@@ -53,7 +74,14 @@ int led_classdev_multicolor_register_ext(struct device *parent,
*/
void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev);
-/* Calculate brightness for the monochrome LED cluster */
+/**
+ * led_mc_calc_color_components() - Calculates component brightness values of a LED cluster.
+ * @mcled_cdev - Multicolor LED class device of the LED cluster.
+ * @led_brightness - Global brightness of the LED cluster.
+ *
+ * Calculates the brightness values for each color component of a monochrome LED cluster,
+ * see Documentation/leds/leds-class-multicolor.rst for details.
+ */
int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
enum led_brightness brightness);
--
2.39.5
^ permalink raw reply related
* [PATCH 0/1] leds: Introduce the multi_max_intensity sysfs attribute
From: Armin Wolf @ 2026-03-24 20:27 UTC (permalink / raw)
To: lee, pavel
Cc: linux-kernel, corbet, skhan, linux-leds, linux-doc, wse,
jacek.anaszewski, pobrn, m.tretter
This patch series was born out of of a mailing list thread [1] where
i asked how to properly model a RGB LED as a multicolor LED. Said
LED has some exotic properties:
1. 5 global brightness levels.
2. 50 intensity levels for each R/G/B color components.
The current sysfs interface mandates that the maximum intensity value
for each color component should be the same as the maximum global
brightness. This makes sense for LEDs that only emulate global
brightness using led_mc_calc_color_components(), but causes problems
for LEDs that perform global brightness control in hardware.
Faking a maximum global brightness of 50 will not work in this case,
as the hardware can change the global brightness on its own. Userspace
applications might also prefer to know the true maximum brightness
value.
Because of this i decided to add a new sysfs attribute called
"multi_max_intensity". This attribute is similar to the
"max_brightness" sysfs attribute, except that it targets the intensity
values inside the "multi_intensity" sysfs atribute. I also decided to
cap intensity values comming from userspace to said maximum intensity
values to relieve drivers from doing it themself. This was already
proposed in a unrelated patch [2] and might break some misbehaving
userspace applications that do not respect max_brightness.
I tested the new sysfs attribute using a custom kernel module:
#include <linux/module.h>
#include <linux/init.h>
#include <linux/led-class-multicolor.h>
static int test_brightness_set_blocking(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
struct led_classdev_mc *mc_cdev = lcdev_to_mccdev(led_cdev);
for (int i = 0; i < mc_cdev->num_colors; i++) {
if (mc_cdev->subled_info[i].intensity > 30)
return -EIO;
}
return 0;
}
static struct mc_subled subleds[] = {
{
.color_index = LED_COLOR_ID_RED,
.max_intensity = 0,
.channel = 1,
},
{
.color_index = LED_COLOR_ID_GREEN,
.max_intensity = 0,
.channel = 2,
},
{
.color_index = LED_COLOR_ID_BLUE,
.max_intensity = 0,
.channel = 3,
},
};
static struct led_classdev_mc led_mc_cdev = {
.led_cdev = {
.max_brightness = 255,
.color = LED_COLOR_ID_MULTI,
.flags = LED_CORE_SUSPENDRESUME | LED_REJECT_NAME_CONFLICT,
.brightness_set_blocking = test_brightness_set_blocking,
},
.num_colors = ARRAY_SIZE(subleds),
.subled_info = subleds,
};
static int __init test_init(void)
{
struct led_init_data init_data = {
.devicename = "test-led",
.default_label = "multicolor:" LED_FUNCTION_KBD_BACKLIGHT,
.devname_mandatory = true,
};
return led_classdev_multicolor_register_ext(NULL, &led_mc_cdev, &init_data);
}
module_init(test_init);
static void __exit test_exit(void)
{
led_classdev_multicolor_unregister(&led_mc_cdev);
}
module_exit(test_exit);
MODULE_AUTHOR("Armin Wolf <W_Armin@gmx.de>");
MODULE_DESCRIPTION("Multicolor LED test device");
MODULE_LICENSE("GPL");
[1] https://lore.kernel.org/linux-leds/2d91a44e-fce2-42dc-b529-133ab4a191f0@gmx.de/
[2] https://lore.kernel.org/linux-leds/20260123-leds-multicolor-limit-intensity-v1-1-b37761c2fdfd@pengutronix.de/
Changes since RFC:
- rework documentation
- drop useless defines
- reduce amount of driver code churn
Armin Wolf (1):
leds: Introduce the multi_max_intensity sysfs attribute
.../ABI/testing/sysfs-class-led-multicolor | 19 ++++++--
Documentation/leds/leds-class-multicolor.rst | 21 ++++++++-
drivers/leds/led-class-multicolor.c | 47 ++++++++++++++++++-
drivers/leds/leds-lp50xx.c | 1 +
drivers/leds/rgb/leds-ncp5623.c | 4 +-
include/linux/led-class-multicolor.h | 30 +++++++++++-
6 files changed, 113 insertions(+), 9 deletions(-)
--
2.39.5
^ permalink raw reply
* [PATCH v8 5/5] Documentation: laptops: Update documentation for uniwill laptops
From: Werner Sembach @ 2026-03-24 20:32 UTC (permalink / raw)
To: W_Armin, hansg, ilpo.jarvinen, Jonathan Corbet, Shuah Khan
Cc: platform-driver-x86, linux-kernel, Werner Sembach, linux-doc
In-Reply-To: <20260324203413.454361-1-wse@tuxedocomputers.com>
Adds short description for two new sysfs entries, ctgp_offset and
usb_c_power_priority, to the documentation of uniwill laptops.
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
.../ABI/testing/sysfs-driver-uniwill-laptop | 27 +++++++++++++++++++
.../admin-guide/laptops/uniwill-laptop.rst | 12 +++++++++
2 files changed, 39 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-driver-uniwill-laptop b/Documentation/ABI/testing/sysfs-driver-uniwill-laptop
index 2df70792968f3..2397c65c969a6 100644
--- a/Documentation/ABI/testing/sysfs-driver-uniwill-laptop
+++ b/Documentation/ABI/testing/sysfs-driver-uniwill-laptop
@@ -51,3 +51,30 @@ Description:
Reading this file returns the current status of the breathing animation
functionality.
+
+What: /sys/bus/platform/devices/INOU0000:XX/ctgp_offset
+Date: January 2026
+KernelVersion: 7.0
+Contact: Werner Sembach <wse@tuxedocomputers.com>
+Description:
+ Allows userspace applications to set the configurable TGP offset on top of the base
+ TGP. Base TGP and max TGP and therefore the max cTGP offset are device specific.
+ Note that setting the maximum cTGP leaves no window open for Dynamic Boost as
+ Dynamic Boost also can not go over max TGP. Setting the cTGP to maximum is
+ effectively disabling Dynamic Boost and telling the device to always prioritize the
+ GPU over the CPU.
+
+ Reading this file returns the current configurable TGP offset.
+
+What: /sys/bus/platform/devices/INOU0000:XX/usb_c_power_priority
+Date: February 2026
+KernelVersion: 7.1
+Contact: Werner Sembach <wse@tuxedocomputers.com>
+Description:
+ Allows userspace applications to choose the USB-C power distribution profile between
+ one that offers a bigger share of the power to the battery and one that offers more
+ of it to the CPU. Writing "charging"/"performance" into this file selects the
+ respective profile.
+
+ Reading this file returns the profile names with the currently active one in
+ brackets.
diff --git a/Documentation/admin-guide/laptops/uniwill-laptop.rst b/Documentation/admin-guide/laptops/uniwill-laptop.rst
index aff5f57a6bd47..561334865feb7 100644
--- a/Documentation/admin-guide/laptops/uniwill-laptop.rst
+++ b/Documentation/admin-guide/laptops/uniwill-laptop.rst
@@ -50,6 +50,10 @@ between 1 and 100 percent are supported.
Additionally the driver signals the presence of battery charging issues through the standard
``health`` power supply sysfs attribute.
+It also lets you set whether a USB-C power source should prioritise charging the battery or
+delivering immediate power to the cpu. See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for
+details.
+
Lightbar
--------
@@ -58,3 +62,11 @@ LED class device. The default name of this LED class device is ``uniwill:multico
See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details on how to control the various
animation modes of the lightbar.
+
+Configurable TGP
+----------------
+
+The ``uniwill-laptop`` driver allows to set the configurable TGP for devices with NVIDIA GPUs that
+allow it.
+
+See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] docs: Raise minimum pahole version to 1.26 for KF_IMPLICIT_ARGS kfuncs
From: Tejun Heo @ 2026-03-24 20:37 UTC (permalink / raw)
To: zhidao su, linux-doc; +Cc: corbet, sched-ext, linux-kernel
In-Reply-To: <20260324184718.3747428-1-suzhidao@xiaomi.com>
Applied to sched_ext/for-7.1.
Thanks.
--
tejun
^ permalink raw reply
* kernel-doc overly verbose with V=0
From: Jacob Keller @ 2026-03-24 20:37 UTC (permalink / raw)
To: Jonathan Corbet, Linux Doc Mailing List, Shuah Khan, Randy Dunlap,
Mauro Carvalho Chehab
Cc: linux-kernel@vger.kernel.org
Hi,
I recently saw some strange behavior with the Python kernel-doc. I was
seeing the verbose info lines from the kernel-doc script, i.e.:
> Info: ice_ptp_hw.c:5377 Scanning doc for function ice_cgu_get_pin_freq_supp
> Info: ice_ptp_hw.c:5406 Scanning doc for function ice_cgu_get_pin_name
> Info: ice_ptp_hw.c:5441 Scanning doc for function ice_cgu_state_to_name
> Info: ice_ptp_hw.c:5463 Scanning doc for function ice_get_dpll_ref_sw_status
> Info: ice_ptp_hw.c:5505 Scanning doc for function ice_set_dpll_ref_sw_status
> Info: ice_ptp_hw.c:5544 Scanning doc for function ice_get_cgu_state
> Info: ice_ptp_hw.c:5612 Scanning doc for function ice_get_cgu_rclk_pin_info
> Info: ice_ptp_hw.c:5671 Scanning doc for function ice_cgu_get_output_pin_state_caps
> Info: ice_ptp_hw.c:5733 Scanning doc for function ice_ptp_lock
> Info: ice_ptp_hw.c:5770 Scanning doc for function ice_ptp_unlock
> Info: ice_ptp_hw.c:5782 Scanning doc for function ice_ptp_init_hw
> Info: ice_ptp_hw.c:5811 Scanning doc for function ice_ptp_write_port_cmd
> Info: ice_ptp_hw.c:5834 Scanning doc for function ice_ptp_one_port_cmd
> Info: ice_ptp_hw.c:5866 Scanning doc for function ice_ptp_port_cmd
> Info: ice_ptp_hw.c:5901 Scanning doc for function ice_ptp_tmr_cmd
> Info: ice_ptp_hw.c:5934 Scanning doc for function ice_ptp_init_time
> Info: ice_ptp_hw.c:5986 Scanning doc for function ice_ptp_write_incval
> Info: ice_ptp_hw.c:6035 Scanning doc for function ice_ptp_write_incval_locked
> Info: ice_ptp_hw.c:6056 Scanning doc for function ice_ptp_adj_clock
> Info: ice_ptp_hw.c:6107 Scanning doc for function ice_read_phy_tstamp
> Info: ice_ptp_hw.c:6134 Scanning doc for function ice_clear_phy_tstamp
> Info: ice_ptp_hw.c:6164 Scanning doc for function ice_ptp_reset_ts_memory
> Info: ice_ptp_hw.c:6183 Scanning doc for function ice_ptp_init_phc
> Info: ice_ptp_hw.c:6215 Scanning doc for function ice_get_phy_tx_tstamp_ready
> Info: ice_ptp_hw.c:6247 Scanning doc for function ice_check_phy_tx_tstamp_ready
> Info: ice_ptp_hw.c:6273 Scanning doc for function ice_ptp_config_sfd
> Info: ice_ptp_hw.c:6293 Scanning doc for function refsync_pin_id_valid
I didn't understand why I was seeing this as it should only be happening
if running kernel-doc in verbose mode. Then I discovered I had set
KBUILD_VERBOSE=0 in my environment.
The python kernel-doc implementation reads this in the __init__ for
KernelFiles() on line 165:
> if not verbose:
> verbose = bool(os.environ.get("KBUILD_VERBOSE", 0))
After some debugging, I realized this reads KBUILD_VERBOSE as a string,
then converts it to a boolean using python's standard rules, so "0"
becomes true, which enables the verbose output.
This is in contrast to the (now removed) kernel-doc.pl script which
checked the value for a 1:
> if (defined($ENV{'KBUILD_VERBOSE'}) && $ENV{'KBUILD_VERBOSE'} =~ '1')
The same behavior happens if you assign V=0 on the command line or to
any other non-empty string, since when V is set on the command line it
sets KBUILD_VERBOSE.
Of course, I can remove KBUILD_VERBOSE from my environment, I'm not
entirely sure when or why I added it.
Would think it would make sense to update the kdoc_files.py script to
check and interpret the string value the same way the perl script used
to? It seems reasonable to me that users might set "V=0" thinking that
it disables the verbosity. Other verbosity checks are based on the
string containing a 1, (some even use 2 for even more printing).
I'm not entirely sure what the best implementation for python is to
avoid this misinterpretation, so I haven't drafted a proper patch yet.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v8 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Borislav Petkov @ 2026-03-24 20:59 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260324-vmscape-bhb-v8-2-68bb524b3ab9@linux.intel.com>
On Tue, Mar 24, 2026 at 11:16:51AM -0700, Pawan Gupta wrote:
> As a mitigation for BHI, clear_bhb_loop() executes branches that overwrites
> the Branch History Buffer (BHB). On Alder Lake and newer parts this
> sequence is not sufficient because it doesn't clear enough entries. This
> was not an issue because these CPUs have a hardware control (BHI_DIS_S)
> that mitigates BHI in kernel.
>
> BHI variant of VMSCAPE requires isolating branch history between guests and
> userspace. Note that there is no equivalent hardware control for userspace.
> To effectively isolate branch history on newer CPUs, clear_bhb_loop()
> should execute sufficient number of branches to clear a larger BHB.
>
> Dynamically set the loop count of clear_bhb_loop() such that it is
> effective on newer CPUs too. Use the hardware control enumeration
> X86_FEATURE_BHI_CTRL to select the appropriate loop count.
>
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
> arch/x86/entry/entry_64.S | 21 ++++++++++++++++-----
> arch/x86/net/bpf_jit_comp.c | 7 -------
> 2 files changed, 16 insertions(+), 12 deletions(-)
Ok, pls tell me why this below doesn't work?
The additional indirection makes even the BHB loop code simpler.
(I didn't pay too much attention to the labels, 2: is probably weird there).
---
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 3a180a36ca0e..95c7ed9afbbe 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1532,11 +1532,13 @@ SYM_CODE_END(rewind_stack_and_make_dead)
* Note, callers should use a speculation barrier like LFENCE immediately after
* a call to this function to ensure BHB is cleared before indirect branches.
*/
-SYM_FUNC_START(clear_bhb_loop)
+SYM_FUNC_START(__clear_bhb_loop)
ANNOTATE_NOENDBR
push %rbp
+ /* BPF caller may require %rax to be preserved */
+ push %rax
mov %rsp, %rbp
- movl $5, %ecx
+
ANNOTATE_INTRA_FUNCTION_CALL
call 1f
jmp 5f
@@ -1557,17 +1559,17 @@ SYM_FUNC_START(clear_bhb_loop)
* but some Clang versions (e.g. 18) don't like this.
*/
.skip 32 - 18, 0xcc
-2: movl $5, %eax
+2:
3: jmp 4f
nop
-4: sub $1, %eax
+4: sub $1, %rsi
jnz 3b
- sub $1, %ecx
+ sub $1, %rdi
jnz 1b
.Lret2: RET
5:
+ pop %rax
pop %rbp
RET
-SYM_FUNC_END(clear_bhb_loop)
-EXPORT_SYMBOL_FOR_KVM(clear_bhb_loop)
-STACK_FRAME_NON_STANDARD(clear_bhb_loop)
+SYM_FUNC_END(__clear_bhb_loop)
+STACK_FRAME_NON_STANDARD(__clear_bhb_loop)
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 70b377fcbc1c..a9f406941e11 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -390,6 +390,7 @@ extern void write_ibpb(void);
#ifdef CONFIG_X86_64
extern void clear_bhb_loop(void);
+extern void __clear_bhb_loop(unsigned int a, unsigned int b);
#endif
extern void (*x86_return_thunk)(void);
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 83f51cab0b1e..c41b0548cf2a 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -3735,3 +3735,11 @@ void __warn_thunk(void)
{
WARN_ONCE(1, "Unpatched return thunk in use. This should not happen!\n");
}
+
+void clear_bhb_loop(void)
+{
+ if (cpu_feature_enabled(X86_FEATURE_BHI_CTRL))
+ __clear_bhb_loop(12, 7);
+ else
+ __clear_bhb_loop(5, 5);
+}
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 63d6c9fa5e80..e2cceabb23e8 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -1614,11 +1614,6 @@ static int emit_spectre_bhb_barrier(u8 **pprog, u8 *ip,
u8 *func;
if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_LOOP)) {
- /* The clearing sequence clobbers eax and ecx. */
- EMIT1(0x50); /* push rax */
- EMIT1(0x51); /* push rcx */
- ip += 2;
-
func = (u8 *)clear_bhb_loop;
ip += x86_call_depth_emit_accounting(&prog, func, ip);
@@ -1626,8 +1621,6 @@ static int emit_spectre_bhb_barrier(u8 **pprog, u8 *ip,
return -EINVAL;
/* Don't speculate past this until BHB is cleared */
EMIT_LFENCE();
- EMIT1(0x59); /* pop rcx */
- EMIT1(0x58); /* pop rax */
}
/* Insert IBHF instruction */
if ((cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_LOOP) &&
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply related
* Re: [PATCH net-next v3 03/13] net: introduce ndo_set_rx_mode_async and dev_rx_mode_work
From: Jakub Kicinski @ 2026-03-24 21:21 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Stanislav Fomichev, netdev, davem, edumazet, pabeni, horms,
corbet, skhan, andrew+netdev, michael.chan, pavan.chebbi,
anthony.l.nguyen, przemyslaw.kitszel, saeedm, tariqt, mbloch,
alexanderduyck, kernel-team, johannes, sd, jianbol, dtatulea,
mohsin.bashr, jacob.e.keller, willemb, skhawaja, bestswngs,
aleksandr.loktionov, kees, linux-doc, linux-kernel,
intel-wired-lan, linux-rdma, linux-wireless, linux-kselftest,
leon
In-Reply-To: <acLUMN1BYkIVyOk8@mini-arch>
On Tue, 24 Mar 2026 11:13:04 -0700 Stanislav Fomichev wrote:
> > > + netif_addr_lock_bh(dev);
> > > +
> > > + err = __hw_addr_list_snapshot(&uc_snap, &dev->uc,
> > > + dev->addr_len);
> > > + if (!err)
> > > + err = __hw_addr_list_snapshot(&uc_ref, &dev->uc,
> > > + dev->addr_len);
> > > + if (!err)
> > > + err = __hw_addr_list_snapshot(&mc_snap, &dev->mc,
> > > + dev->addr_len);
> > > + if (!err)
> > > + err = __hw_addr_list_snapshot(&mc_ref, &dev->mc,
> > > + dev->addr_len);
> >
> > This doesn't get slow with a few thousands of addresses?
>
> I can add kunit benchmark and attach the output? Although not sure where
> to go from that. The alternative to this is allocating an array of entries.
> I started with that initially but __hw_addr_sync_dev wants to kfree the
> individual entries and I decided not to have a separate helpers to
> manage the snapshots.
Let's see what the benchmark says. Hopefully it's fast enough and
we don't have to worry. Is keeping these lists around between the
invocations of the work tricky?
> > Can we give the work a reference on the netdev (at init time) and
> > cancel + release it here instead of flushing / waiting?
>
> Not sure why cancel+release, maybe you're thinking about the unregister
> path? This is rtnl_unlock -> netdev_run_todo -> __rtnl_unlock + some
> extras.
>
> And the flush is here to plumb the addresses to the real devices
> before we return to the callers. Mostly because of the following
> things we have in the tests:
>
> # TEST: team cleanup mode lacp [FAIL]
> # macvlan unicast address not found on a slave
>
> Can you explain a bit more on the suggestion?
Oh, I thought it's here for unregister! Feels like it'd be cleaner to
add the flush in dev_*c_add() and friends? How hard would it be to
identify the callers in atomic context?
> > > /* Wait for rcu callbacks to finish before next phase */
> > > if (!list_empty(&list))
> > > rcu_barrier();
> > > @@ -12099,6 +12173,7 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
> > > #endif
> > >
> > > mutex_init(&dev->lock);
> > > + INIT_WORK(&dev->rx_mode_work, dev_rx_mode_work);
> > >
> > > dev->priv_flags = IFF_XMIT_DST_RELEASE | IFF_XMIT_DST_RELEASE_PERM;
> > > setup(dev);
> > > @@ -12203,6 +12278,8 @@ void free_netdev(struct net_device *dev)
> > >
> > > kfree(rcu_dereference_protected(dev->ingress_queue, 1));
> > >
> > > + cancel_work_sync(&dev->rx_mode_work);
> >
> > Should never happen so maybe wrap it in a WARN ?
>
> Or maybe just flush_workqueue here as well? To signal the intent that we
> are mostly waiting for the wq entry to be unused to be able to kfree it?
>
^ permalink raw reply
* Re: [PATCH v8 01/10] x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop()
From: Pawan Gupta @ 2026-03-24 21:30 UTC (permalink / raw)
To: Borislav Petkov
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260324202251.GPacLym_7HV9IBbLaz@fat_crate.local>
On Tue, Mar 24, 2026 at 09:22:51PM +0100, Borislav Petkov wrote:
> On Tue, Mar 24, 2026 at 11:16:36AM -0700, Pawan Gupta wrote:
> > Currently, BHB clearing sequence is followed by an LFENCE to prevent
> > transient execution of subsequent indirect branches prematurely. However,
> > LFENCE barrier could be unnecessary in certain cases. For example, when
> > kernel is using BHI_DIS_S mitigation, and BHB clearing is only needed for
> > userspace. In such cases, LFENCE is redundant because ring transitions
> > would provide the necessary serialization.
> >
> > Below is a quick recap of BHI mitigation options:
> >
> > On Alder Lake and newer
> >
> > - BHI_DIS_S: Hardware control to mitigate BHI in ring0. This has low
> > performance overhead.
> > - Long loop: Alternatively, longer version of BHB clearing sequence
> > can be used to mitigate BHI. It can also be used to mitigate
> > BHI variant of VMSCAPE. This is not yet implemented in
> > Linux.
> >
> > On older CPUs
> >
> > - Short loop: Clears BHB at kernel entry and VMexit. The "Long loop" is
> > effective on older CPUs as well, but should be avoided
> > because of unnecessary overhead.
> >
> > On Alder Lake and newer CPUs, eIBRS isolates the indirect targets between
> > guest and host. But when affected by the BHI variant of VMSCAPE, a guest's
> > branch history may still influence indirect branches in userspace. This
> > also means the big hammer IBPB could be replaced with a cheaper option that
> > clears the BHB at exit-to-userspace after a VMexit.
> >
> > In preparation for adding the support for BHB sequence (without LFENCE) on
> > newer CPUs, move the LFENCE to the caller side after clear_bhb_loop() is
> > executed. Allow callers to decide whether they need the LFENCE or
> > not. This adds a few extra bytes to the call sites, but it obviates
> > the need for multiple variants of clear_bhb_loop().
>
> Claude, please add proper articles where they're missing in the above text:
>
> "Currently, the BHB clearing sequence is followed by an LFENCE to prevent
> transient execution of subsequent indirect branches prematurely. However, the
> LFENCE barrier could be unnecessary in certain cases. For example, when the
> kernel is using the BHI_DIS_S mitigation, and BHB clearing is only needed for
> userspace. In such cases, the LFENCE is redundant because ring transitions
> would provide the necessary serialization.
>
> Below is a quick recap of BHI mitigation options:
>
> On Alder Lake and newer
>
> BHI_DIS_S: Hardware control to mitigate BHI in ring0. This has low
> performance overhead.
>
> Long loop: Alternatively, a longer version of the BHB clearing sequence
> can be used to mitigate BHI. It can also be used to mitigate the BHI
> variant of VMSCAPE. This is not yet implemented in Linux.
>
> On older CPUs
>
> Short loop: Clears BHB at kernel entry and VMexit. The "Long loop" is
> effective on older CPUs as well, but should be avoided because of
> unnecessary overhead.
>
> On Alder Lake and newer CPUs, eIBRS isolates the indirect targets between
> guest and host. But when affected by the BHI variant of VMSCAPE, a guest's
> branch history may still influence indirect branches in userspace. This also
> means the big hammer IBPB could be replaced with a cheaper option that clears
> the BHB at exit-to-userspace after a VMexit.
>
> In preparation for adding the support for the BHB sequence (without LFENCE) on
> newer CPUs, move the LFENCE to the caller side after clear_bhb_loop() is
> executed. Allow callers to decide whether they need the LFENCE or not. This
> adds a few extra bytes to the call sites, but it obviates the need for
> multiple variants of clear_bhb_loop()."
>
> Reads proper to me. Use it for your next revision pls.
Sure, will use this.
^ permalink raw reply
* Re: [PATCH v8 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-03-24 22:13 UTC (permalink / raw)
To: Borislav Petkov
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260324205930.GQacL7Mp7vwGBKX1W7@fat_crate.local>
On Tue, Mar 24, 2026 at 09:59:30PM +0100, Borislav Petkov wrote:
> On Tue, Mar 24, 2026 at 11:16:51AM -0700, Pawan Gupta wrote:
> > As a mitigation for BHI, clear_bhb_loop() executes branches that overwrites
> > the Branch History Buffer (BHB). On Alder Lake and newer parts this
> > sequence is not sufficient because it doesn't clear enough entries. This
> > was not an issue because these CPUs have a hardware control (BHI_DIS_S)
> > that mitigates BHI in kernel.
> >
> > BHI variant of VMSCAPE requires isolating branch history between guests and
> > userspace. Note that there is no equivalent hardware control for userspace.
> > To effectively isolate branch history on newer CPUs, clear_bhb_loop()
> > should execute sufficient number of branches to clear a larger BHB.
> >
> > Dynamically set the loop count of clear_bhb_loop() such that it is
> > effective on newer CPUs too. Use the hardware control enumeration
> > X86_FEATURE_BHI_CTRL to select the appropriate loop count.
> >
> > Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> > Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > ---
> > arch/x86/entry/entry_64.S | 21 ++++++++++++++++-----
> > arch/x86/net/bpf_jit_comp.c | 7 -------
> > 2 files changed, 16 insertions(+), 12 deletions(-)
>
> Ok, pls tell me why this below doesn't work?
>
> The additional indirection makes even the BHB loop code simpler.
>
> (I didn't pay too much attention to the labels, 2: is probably weird there).
>
> ---
>
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 3a180a36ca0e..95c7ed9afbbe 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -1532,11 +1532,13 @@ SYM_CODE_END(rewind_stack_and_make_dead)
> * Note, callers should use a speculation barrier like LFENCE immediately after
> * a call to this function to ensure BHB is cleared before indirect branches.
> */
> -SYM_FUNC_START(clear_bhb_loop)
> +SYM_FUNC_START(__clear_bhb_loop)
> ANNOTATE_NOENDBR
> push %rbp
> + /* BPF caller may require %rax to be preserved */
> + push %rax
> mov %rsp, %rbp
> - movl $5, %ecx
> +
> ANNOTATE_INTRA_FUNCTION_CALL
> call 1f
> jmp 5f
> @@ -1557,17 +1559,17 @@ SYM_FUNC_START(clear_bhb_loop)
> * but some Clang versions (e.g. 18) don't like this.
> */
> .skip 32 - 18, 0xcc
> -2: movl $5, %eax
> +2:
> 3: jmp 4f
> nop
> -4: sub $1, %eax
> +4: sub $1, %rsi
%rsi needs to be loaded again with $inner_loop_count once per every
outer loop iteration. We probably need another register to hold that.
> jnz 3b
> - sub $1, %ecx
> + sub $1, %rdi
> jnz 1b
> .Lret2: RET
> 5:
> + pop %rax
> pop %rbp
> RET
> -SYM_FUNC_END(clear_bhb_loop)
> -EXPORT_SYMBOL_FOR_KVM(clear_bhb_loop)
> -STACK_FRAME_NON_STANDARD(clear_bhb_loop)
> +SYM_FUNC_END(__clear_bhb_loop)
> +STACK_FRAME_NON_STANDARD(__clear_bhb_loop)
> diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> index 70b377fcbc1c..a9f406941e11 100644
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -390,6 +390,7 @@ extern void write_ibpb(void);
>
> #ifdef CONFIG_X86_64
> extern void clear_bhb_loop(void);
> +extern void __clear_bhb_loop(unsigned int a, unsigned int b);
> #endif
>
> extern void (*x86_return_thunk)(void);
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 83f51cab0b1e..c41b0548cf2a 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -3735,3 +3735,11 @@ void __warn_thunk(void)
> {
> WARN_ONCE(1, "Unpatched return thunk in use. This should not happen!\n");
> }
> +
> +void clear_bhb_loop(void)
> +{
> + if (cpu_feature_enabled(X86_FEATURE_BHI_CTRL))
> + __clear_bhb_loop(12, 7);
> + else
> + __clear_bhb_loop(5, 5);
> +}
This is cleaner. A few things to consider are, CLEAR_BRANCH_HISTORY that
calls clear_bhb_loop() would be calling into C code very early during the
kernel entry. The code generated here may vary based on the compiler. Any
indirect branch here would be security risk. This needs to be noinstr so
that it can't be hijacked by probes and ftraces.
At kernel entry, calling into C before mitigations are applied is risky.
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index 63d6c9fa5e80..e2cceabb23e8 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -1614,11 +1614,6 @@ static int emit_spectre_bhb_barrier(u8 **pprog, u8 *ip,
> u8 *func;
>
> if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_LOOP)) {
> - /* The clearing sequence clobbers eax and ecx. */
> - EMIT1(0x50); /* push rax */
> - EMIT1(0x51); /* push rcx */
> - ip += 2;
> -
> func = (u8 *)clear_bhb_loop;
Although call to clear_bhb_loop() will be inserted at the end of the BPF
program before it returns, I am not sure if it is safe to assume that
trashing registers in the path clear_bhb_loop() -> __clear_bhb_loop() is
okay? Especially, when we don't know what code compiler generated for
clear_bhb_loop(). BPF experts would know better?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox