6.13.6-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 129/157 mptcp: always handle address removal under msk socket lock
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
commit f865c24bc55158313d5779fc81116023a6940ca3 upstream.
Syzkaller reported a lockdep splat in the PM control path:
WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088
Indeed the PM can try to send a RM_ADDR over a msk without acquiring first the msk socket lock.
The bugged code-path comes from an early optimization: when there are no subflows, the PM should (usually) not send RM_ADDR notifications.
The above statement is incorrect, as without locks another process could concurrent create a new subflow and cause the RM_ADDR generation.
Additionally the supposed optimization is not very effective even performance-wise, as most mptcp sockets should have at least one
subflow: the MPC one.
Address the issue removing the buggy code path, the existing "slow-path" will handle correctly even the edge case.
--- net/mptcp/pm_netlink.c | 5 ----- 1 file changed, 5 deletions(-)
net/mptcp/pm_netlink.c +0 -5
@@ -1514,11 +1514,6 @@ static int mptcp_nl_remove_subflow_and_sif (mptcp_pm_is_userspace (msk)) goto next; -if (list_empty (&msk->conn_list)) { -mptcp_pm_remove_anno_addr (msk, addr, false); - goto next; - } -lock_sock (sk); remove_subflow =lookup_subflow_by_saddr (&msk->conn_list, addr); mptcp_pm_remove_anno_addr(msk, addr, remove_subflow &&
Greg Kroah-Hartman
maintainerPATCH 130/157 mptcp: reset when MPTCP opts are dropped after join
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit 8668860b0ad32a13fcd6c94a0995b7aa7638c9ef upstream.
Before this patch, if the checksum was not used, the subflow was only reset if map_data_len was != 0. If there were no MPTCP options or an invalid mapping, map_data_len was not set to the data len, and then the subflow was not reset as it should have been, leaving the MPTCP connection in a wrong fallback mode.
This map_data_len condition has been introduced to handle the reception of the infinite mapping. Instead, a new dedicated mapping error could have been returned and treated as a special case. However, the commit 31bf11de146c ("mptcp: introduce MAPPING_BAD_CSUM") has been introduced by Paolo Abeni soon after, and backported later on to stable. It better handle the csum case, and it means the exception for valid_csum_seen in subflow_can_fallback(), plus this one for the infinite mapping in subflow_check_data_avail(), are no longer needed.
In other words, the code can be simplified there: a fallback should only be done if msk->allow_infinite_fallback is set. This boolean is set to false once MPTCP-specific operations acting on the whole MPTCP connection vs the initial path have been done, e.g. a second path has been created, or an MPTCP re-injection -- yes, possible even with a single subflow. The subflow_can_fallback() helper can then be dropped, and replaced by this single condition.
This also makes the code clearer: a fallback should only be done if it is possible to do so.
While at it, no need to set map_data_len to 0 in get_mapping_status() for the infinite mapping case: it will be set to skb->len just after, at the end of subflow_check_data_avail(), and not read in between.
--- net/mptcp/subflow.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-)
net/mptcp/subflow.c +1 -14
@@ -1142,7 +1142,6 @@ static enum mapping_status get_mapping_sif (data_len ==0 ) {pr_debug ("infinite mapping received\n" );MPTCP_INC_STATS (sock_net (ssk),MPTCP_MIB_INFINITEMAPRX ); - subflow->map_data_len =0 ;return MAPPING_INVALID ; }
@@ -1286,18 +1285,6 @@ static void subflow_sched_work_if_closedmptcp_schedule_work (sk); } -static bool subflow_can_fallback (struct mptcp_subflow_context *subflow) -{ -struct mptcp_sock *msk =mptcp_sk (subflow->conn); - -if (subflow->mp_join) -return false; -else if (READ_ONCE (msk->csum_enabled)) -return !subflow->valid_csum_seen; -else -return READ_ONCE (msk->allow_infinite_fallback); -} -static void mptcp_subflow_fail (struct mptcp_sock *msk,struct sock *ssk) {struct mptcp_subflow_context *subflow =mptcp_subflow_ctx (ssk);
@@ -1393,7 +1380,7 @@ fallback:return true; } -if (!subflow_can_fallback (subflow) && subflow->map_data_len) { +if (!READ_ONCE (msk->allow_infinite_fallback)) {/* fatal protocol error, close the socket. * subflow_error_report() will introduce the appropriate barriers */
Greg Kroah-Hartman
maintainerPATCH 131/157 selftests/landlock: Test that MPTCP actions are not restricted
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikhail Ivanov <[email protected]>
commit 3d4033985ff508ef587ca11f1c8361ba57c7e09f upstream.
Extend protocol fixture with test suits for MPTCP protocol. Add CONFIG_MPTCP and CONFIG_MPTCP_IPV6 options in config.
--- tools/testing/selftests/landlock/config | 2 + tools/testing/selftests/landlock/net_test.c | 44 ++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+)
tools/testing/selftests/landlock/config +2 -0
@@ -3,6 +3,8 @@ CONFIG_CGROUP_SCHED=y CONFIG_INET=y CONFIG_IPV6=y CONFIG_KEYS=y +CONFIG_MPTCP=y +CONFIG_MPTCP_IPV6=y CONFIG_NET=y CONFIG_NET_NS=y CONFIG_OVERLAY_FS=y
tools/testing/selftests/landlock/net_test.c +44 -0
68 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 132/157 vmlinux.lds: Ensure that const vars with relocations are mapped R/O
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ard Biesheuvel <[email protected]>
commit 68f3ea7ee199ef77551e090dfef5a49046ea8443 upstream.
In the kernel, there are architectures (x86, arm64) that perform boot-time relocation (for KASLR) without relying on PIE codegen. In this case, all const global objects are emitted into .rodata, including const objects with fields that will be fixed up by the boot-time relocation code. This implies that .rodata (and .text in some cases) need to be writable at boot, but they will usually be mapped read-only as soon as the boot completes.
When using PIE codegen, the compiler will emit const global objects into .data.rel.ro rather than .rodata if the object contains fields that need such fixups at boot-time. This permits the linker to annotate such regions as requiring read-write access only at load time, but not at execution time (in user space), while keeping .rodata truly const (in user space, this is important for reducing the CoW footprint of dynamic executables).
This distinction does not matter for the kernel, but it does imply that const data will end up in writable memory if the .data.rel.ro sections are not treated in a special way, as they will end up in the writable .data segment by default.
So emit .data.rel.ro into the .rodata segment.
--- include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/asm-generic/vmlinux.lds.h +1 -1
@@ -457,7 +457,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined . = ALIGN((align)); \ .rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \ __start_rodata = .; \ - *(.rodata) *(.rodata.*) \ + *(.rodata) *(.rodata.*) *(.data.rel.ro*) \ SCHED_DATA \RO_AFTER_INIT_DATA /* Read only after init */ \ . = ALIGN(8); \
Greg Kroah-Hartman
maintainerPATCH 133/157 rcuref: Plug slowpath race in rcuref_put()
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit b9a49520679e98700d3d89689cc91c08a1c88c1d upstream.
Kernel test robot reported an "imbalanced put" in the rcuref_put() slow path, which turned out to be a false positive. Consider the following race:
ref = 0 (via rcuref_init(ref, 1))
T1 T2
rcuref_put(ref)
-> atomic_add_negative_release(-1, ref) # ref -> 0xffffffff
-> rcuref_put_slowpath(ref)
rcuref_get(ref)
-> atomic_add_negative_relaxed(1, &ref->refcnt)
-> return true; # ref -> 0
rcuref_put(ref)
-> atomic_add_negative_release(-1, ref) # ref -> 0xffffffff
-> rcuref_put_slowpath()
-> cnt = atomic_read(&ref->refcnt); # cnt -> 0xffffffff / RCUREF_NOREF
-> atomic_try_cmpxchg_release(&ref->refcnt, &cnt, RCUREF_DEAD)) # ref -> 0xe0000000 / RCUREF_DEAD
-> return true
-> cnt = atomic_read(&ref->refcnt); # cnt -> 0xe0000000 / RCUREF_DEAD
-> if (cnt > RCUREF_RELEASED) # 0xe0000000 > 0xc0000000
-> WARN_ONCE(cnt >= RCUREF_RELEASED, "rcuref - imbalanced put()")The problem is the additional read in the slow path (after it decremented to RCUREF_NOREF) which can happen after the counter has been marked RCUREF_DEAD.
Prevent this by reusing the return value of the decrement. Now every "final" put uses RCUREF_NOREF in the slow path and attempts the final cmpxchg() to RCUREF_DEAD.
[ bigeasy: Add changelog ]
--- include/linux/rcuref.h | 9 ++++++--- lib/rcuref.c | 5 ++--- 2 files changed, 8 insertions(+), 6 deletions(-)
include/linux/rcuref.h +6 -3
@@ -71,27 +71,30 @@ static inline __must_check bool rcuref_greturn rcuref_get_slowpath (ref); } -extern __must_check bool rcuref_put_slowpath (rcuref_t *ref); +extern __must_check bool rcuref_put_slowpath (rcuref_t *ref,unsigned int cnt);/* * Internal helper. Do not invoke directly. */ static __always_inline __must_check bool __rcuref_put(rcuref_t *ref) { +int cnt; +RCU_LOCKDEP_WARN (!rcu_read_lock_held () &&preemptible (),"suspicious rcuref_put_rcusafe() usage" );/* * Unconditionally decrease the reference count. The saturation and * dead zones provide enough tolerance for this. */ -if (likely (!atomic_add_negative_release (-1 , &ref->refcnt))) + cnt =atomic_sub_return_release (1 , &ref->refcnt); +if (likely (cnt >=0 ))return false;/* * Handle the last reference drop and cases inside the saturation * and dead zones. */ -return rcuref_put_slowpath (ref); +return rcuref_put_slowpath (ref, cnt); }/**
lib/rcuref.c +2 -3
@@ -220,6 +220,7 @@ EXPORT_SYMBOL_GPL(rcuref_get_slowpath);/** * rcuref_put_slowpath - Slowpath of __rcuref_put() * @ref: Pointer to the reference count +* @cnt: The resulting value of the fastpath decrement * * Invoked when the reference count is outside of the valid zone. *
@@ -233,10 +234,8 @@ EXPORT_SYMBOL_GPL(rcuref_get_slowpath);* with a concurrent get()/put() pair. Caller is not allowed to * deconstruct the protected object. */ -bool rcuref_put_slowpath (rcuref_t *ref) +bool rcuref_put_slowpath (rcuref_t *ref,unsigned int cnt) { -unsigned int cnt =atomic_read (&ref->refcnt); -/* Did this drop the last reference? */ if (likely (cnt ==RCUREF_NOREF )) {/*
Greg Kroah-Hartman
maintainerPATCH 134/157 sched/core: Prevent rescheduling when interrupts are disabled
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit 82c387ef7568c0d96a918a5a78d9cad6256cfa15 upstream.
David reported a warning observed while loop testing kexec jump:
Interrupts enabled after irqrouter_resume+0x0/0x50
WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180
The corresponding interrupt flag trace:
hardirqs last enabled at (15573): [<ffffffffa8281b8e>] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [<ffffffffa8281b73>] __up_console_sem+0x63/0x90
That means __up_console_sem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscore_suspend() callbacks woke up a task, which set the NEED_RESCHED flag. A later callback in the resume path invoked cond_resched() which in turn led to the invocation of the scheduler:
__cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180
This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end.
Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time.
The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account.
Cure the problem by adding a corresponding check into cond_resched().
--- kernel/sched/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched/core.c +1 -1
@@ -7278,7 +7278,7 @@ out_unlock:#if !defined(CONFIG_PREEMPTION ) || defined(CONFIG_PREEMPT_DYNAMIC ) int __sched __cond_resched(void) { -if (should_resched (0 )) { +if (should_resched (0 ) && !irqs_disabled ()) {preempt_schedule_common ();return 1 ; }
Greg Kroah-Hartman
maintainerPATCH 135/157 sched_ext: Fix pick_task_scx() picking non-queued tasks when its called without balance()
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit 8fef0a3b17bb258130a4fcbcb5addf94b25e9ec5 upstream.
a6250aa251ea ("sched_ext: Handle cases where pick_task_scx() is called without preceding balance_scx()") added a workaround to handle the cases where pick_task_scx() is called without prececing balance_scx() which is due to a fair class bug where pick_taks_fair() may return NULL after a true return from balance_fair().
The workaround detects when pick_task_scx() is called without preceding balance_scx() and emulates SCX_RQ_BAL_KEEP and triggers kicking to avoid stalling. Unfortunately, the workaround code was testing whether @prev was on SCX to decide whether to keep the task running. This is incorrect as the task may be on SCX but no longer runnable.
This could lead to a non-runnable task to be returned from pick_task_scx() which cause interesting confusions and failures. e.g. A common failure mode is the task ending up with (!on_rq && on_cpu) state which can cause potential wakers to busy loop, which can easily lead to deadlocks.
Fix it by testing whether @prev has SCX_TASK_QUEUED set. This makes @prev_on_scx only used in one place. Open code the usage and improve the comment while at it.
--- kernel/sched/ext.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
kernel/sched/ext.c +7 -4
@@ -3097,7 +3097,6 @@ static struct task_struct *pick_task_scx {struct task_struct *prev = rq->curr;struct task_struct *p; -bool prev_on_scx = prev->sched_class == &ext_sched_class;bool keep_prev = rq->scx.flags &SCX_RQ_BAL_KEEP ;bool kick_idle = false;
@@ -3117,14 +3116,18 @@ static struct task_struct *pick_task_scx* if pick_task_scx() is called without preceding balance_scx(). */ if (unlikely (rq->scx.flags &SCX_RQ_BAL_PENDING )) { -if (prev_on_scx) { +if (prev->scx.flags &SCX_TASK_QUEUED ) { keep_prev = true; }else { keep_prev = false; kick_idle = true; } - }else if (unlikely (keep_prev && !prev_on_scx)) { -/* only allowed during transitions */ + }else if (unlikely (keep_prev && + prev->sched_class != &ext_sched_class)) { +/* +* Can happen while enabling as SCX_RQ_BAL_PENDING assertion is +* conditional on scx_enabled() and may have been skipped. +*/ WARN_ON_ONCE (scx_ops_enable_state () ==SCX_OPS_ENABLED ); keep_prev = false; }
Greg Kroah-Hartman
maintainerPATCH 136/157 selftests/landlock: Test TCP accesses with protocol=IPPROTO_TCP
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikhail Ivanov <[email protected]>
commit f5534d511bcd273720f168386de74af76e148a9b upstream.
Extend protocol_variant structure with protocol field (Cf. socket(2)).
Extend protocol fixture with TCP test suits with protocol=IPPROTO_TCP which can be used as an alias for IPPROTO_IP (=0) in socket(2).
--- tools/testing/selftests/landlock/common.h | 1 tools/testing/selftests/landlock/net_test.c | 80 +++++++++++++++++++++++----- 2 files changed, 67 insertions(+), 14 deletions(-)
tools/testing/selftests/landlock/common.h +1 -0
@@ -234,6 +234,7 @@ enforce_ruleset(struct __test_metadata *struct protocol_variant {int domain;int type; +int protocol; };struct service_fixture {
tools/testing/selftests/landlock/net_test.c +66 -14
135 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 137/157 fuse: revert back to __readahead_folio() for readahead
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joanne Koong <[email protected]>
commit 0c67c37e1710b2a8f61c8a02db95a51fe577e2c1 upstream.
In commit 3eab9d7bc2f4 ("fuse: convert readahead to use folios"), the logic was converted to using the new folio readahead code, which drops the reference on the folio once it is locked, using an inferred reference on the folio. Previously we held a reference on the folio for the entire duration of the readpages call.
This is fine, however for the case for splice pipe responses where we will remove the old folio and splice in the new folio (see fuse_try_move_page()), we assume that there is a reference held on the folio for ap->folios, which is no longer the case.
To fix this, revert back to __readahead_folio() which allows us to hold the reference on the folio for the duration of readpages until either we drop the reference ourselves in fuse_readpages_end() or the reference is dropped after it's replaced in the page cache in the splice case. This will fix the UAF bug that was reported.
--- fs/fuse/dev.c | 6 ++++++ fs/fuse/file.c | 13 +++++++++++-- 2 files changed, 17 insertions(+), 2 deletions(-)
fs/fuse/dev.c +6 -0
@@ -836,6 +836,12 @@ static int fuse_check_folio(struct folioreturn 0 ; } +/* +* Attempt to steal a page from the splice() pipe and move it into the +* pagecache. If successful, the pointer in @pagep will be updated. The +* folio that was originally in @pagep will lose a reference and the new +* folio returned in @pagep will carry a reference. +*/ static int fuse_try_move_page (struct fuse_copy_state *cs,struct page **pagep) {int err;
fs/fuse/file.c +11 -2
@@ -955,8 +955,10 @@ static void fuse_readpages_end(struct fufuse_invalidate_atime (inode); } -for (i =0 ; i < ap->num_folios; i++) +for (i =0 ; i < ap->num_folios; i++) {folio_end_read (ap->folios[i], !err); +folio_put (ap->folios[i]); + }if (ia->ff)fuse_file_put (ia->ff, false);
@@ -1048,7 +1050,14 @@ static void fuse_readahead(struct readah ap = &ia->ap;while (ap->num_folios < cur_pages) { - folio =readahead_folio (rac); +/* +* This returns a folio with a ref held on it. +* The ref needs to be held until the request is +* completed, since the splice case (see +* fuse_try_move_page()) drops the ref after it's +* replaced in the page cache. +*/ + folio =__readahead_folio (rac); ap->folios[ap->num_folios] = folio; ap->descs[ap->num_folios].length =folio_size (folio); ap->num_folios++;
Greg Kroah-Hartman
maintainerPATCH 138/157 dm-integrity: Avoid divide by zero in table status in Inline mode
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Milan Broz <[email protected]>
commit 7fb39882b20c98a9a393c244c86b56ef6933cff8 upstream.
In Inline mode, the journal is unused, and journal_sectors is zero.
Calculating the journal watermark requires dividing by journal_sectors, which should be done only if the journal is configured.
Otherwise, a simple table query (dmsetup table) can cause OOPS.
This bug did not show on some systems, perhaps only due to compiler optimization.
On my 32-bit testing machine, this reliably crashes with the following:
: Oops: divide error: 0000 [#1] PREEMPT SMP
: CPU: 0 UID: 0 PID: 2450 Comm: dmsetup Not tainted 6.14.0-rc2+ #959 : EIP: dm_integrity_status+0x2f8/0xab0 [dm_integrity]
...
--- drivers/md/dm-integrity.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/md/dm-integrity.c +4 -4
@@ -3790,10 +3790,6 @@ static void dm_integrity_status(struct dbreak ;case STATUSTYPE_TABLE : { -__u64 watermark_percentage = (__u64)(ic->journal_entries - ic->free_sectors_threshold) *100 ; - - watermark_percentage += ic->journal_entries /2 ; -do_div (watermark_percentage, ic->journal_entries); arg_count =3 ; arg_count += !!ic->meta_dev; arg_count += ic->sectors_per_block !=1 ;
@@ -3826,6 +3822,10 @@ static void dm_integrity_status(struct dDMEMIT (" interleave_sectors:%u" ,1U << ic->sb->log2_interleave_sectors);DMEMIT (" buffer_sectors:%u" ,1U << ic->log2_buffer_sectors);if (ic->mode =='J' ) { +__u64 watermark_percentage = (__u64)(ic->journal_entries - ic->free_sectors_threshold) *100 ; + + watermark_percentage += ic->journal_entries /2 ; +do_div (watermark_percentage, ic->journal_entries);DMEMIT (" journal_watermark:%u" , (unsigned int )watermark_percentage);DMEMIT (" commit_time:%u" , ic->autocommit_msec); }
Greg Kroah-Hartman
maintainerPATCH 139/157 dm vdo: add missing spin_lock_init
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ken Raeburn <[email protected]>
commit 36e1b81f599a093ec7477e4593e110104adcfb96 upstream.
--- drivers/md/dm-vdo/dedupe.c | 1 + 1 file changed, 1 insertion(+)
drivers/md/dm-vdo/dedupe.c +1 -0
@@ -2178,6 +2178,7 @@ static int initialize_index(struct vdo *vdo_set_dedupe_index_timeout_interval (vdo_dedupe_index_timeout_interval);vdo_set_dedupe_index_min_timer_interval (vdo_dedupe_index_min_timer_interval); +spin_lock_init (&zones->lock);/* * Since we will save up the timeouts that would have been reported but were ratelimited,
Greg Kroah-Hartman
maintainerPATCH 140/157 ima: Reset IMA_NONACTION_RULE_FLAGS after post_setattr
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roberto Sassu <[email protected]>
commit 57a0ef02fefafc4b9603e33a18b669ba5ce59ba3 upstream.
Commit 0d73a55208e9 ("ima: re-introduce own integrity cache lock") mistakenly reverted the performance improvement introduced in commit 42a4c603198f0 ("ima: fix ima_inode_post_setattr"). The unused bit mask was subsequently removed by commit 11c60f23ed13 ("integrity: Remove unused macro IMA_ACTION_RULE_FLAGS").
Restore the performance improvement by introducing the new mask IMA_NONACTION_RULE_FLAGS, equal to IMA_NONACTION_FLAGS without IMA_NEW_FILE, which is not a rule-specific flag.
Finally, reset IMA_NONACTION_RULE_FLAGS instead of IMA_NONACTION_FLAGS in process_measurement(), if the IMA_CHANGE_ATTR atomic flag is set (after file metadata modification).
With this patch, new files for which metadata were modified while they are still open, can be reopened before the last file close (when security.ima is written), since the IMA_NEW_FILE flag is not cleared anymore. Otherwise, appraisal fails because security.ima is missing (files with IMA_NEW_FILE set are an exception).
--- security/integrity/ima/ima.h | 3 +++ security/integrity/ima/ima_main.c | 7 +++++-- 2 files changed, 8 insertions(+), 2 deletions(-)
security/integrity/ima/ima.h +3 -0
@@ -149,6 +149,9 @@ struct ima_kexec_hdr {#define IMA_CHECK_BLACKLIST 0x40000000#define IMA_VERITY_REQUIRED 0x80000000 +/* Exclude non-action flags which are not rule-specific. */ +#define IMA_NONACTION_RULE_FLAGS (IMA_NONACTION_FLAGS & ~IMA_NEW_FILE) +#define IMA_DO_MASK (IMA_MEASURE | IMA_APPRAISE | IMA_AUDIT | \ IMA_HASH | IMA_APPRAISE_SUBMASK)#define IMA_DONE_MASK (IMA_MEASURED | IMA_APPRAISED | IMA_AUDITED | \
security/integrity/ima/ima_main.c +5 -2
@@ -269,10 +269,13 @@ static int process_measurement(struct fimutex_lock (&iint->mutex);if (test_and_clear_bit (IMA_CHANGE_ATTR , &iint->atomic_flags)) -/* reset appraisal flags if ima_inode_post_setattr was called */ +/* +* Reset appraisal flags (action and non-action rule-specific) +* if ima_inode_post_setattr was called. +*/ iint->flags &= ~(IMA_APPRAISE |IMA_APPRAISED |IMA_APPRAISE_SUBMASK |IMA_APPRAISED_SUBMASK | -IMA_NONACTION_FLAGS ); +IMA_NONACTION_RULE_FLAGS );/* * Re-evaulate the file if either the xattr has changed or the
Greg Kroah-Hartman
maintainerPATCH 141/157 scsi: ufs: core: bsg: Fix crash when arpmb command fails
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arthur Simchaev <[email protected]>
commit f27a95845b01e86d67c8b014b4f41bd3327daa63 upstream.
If the device doesn't support arpmb we'll crash due to copying user data in bsg_transport_sg_io_fn().
In the case where ufs_bsg_exec_advanced_rpmb_req() returns an error, do not set the job's reply_len.
Memory crash backtrace:
3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -22
4,1308,531166555,-;Call Trace:
4,1309,531166559,-; <TASK>
4,1310,531166565,-; ? show_regs+0x6d/0x80
4,1311,531166575,-; ? die+0x37/0xa0
4,1312,531166583,-; ? do_trap+0xd4/0xf0
4,1313,531166593,-; ? do_error_trap+0x71/0xb0
4,1314,531166601,-; ? usercopy_abort+0x6c/0x80
4,1315,531166610,-; ? exc_invalid_op+0x52/0x80
4,1316,531166622,-; ? usercopy_abort+0x6c/0x80
4,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x20
4,1318,531166643,-; ? usercopy_abort+0x6c/0x80
4,1319,531166652,-; __check_heap_object+0xe3/0x120
4,1320,531166661,-; check_heap_object+0x185/0x1d0
4,1321,531166670,-; __check_object_size.part.0+0x72/0x150
4,1322,531166679,-; __check_object_size+0x23/0x30
4,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0
--- drivers/ufs/core/ufs_bsg.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/ufs/core/ufs_bsg.c +4 -2
@@ -194,10 +194,12 @@ out:ufshcd_rpm_put_sync (hba);kfree (buff); bsg_reply->result = ret; - job->reply_len = !rpmb ?sizeof (struct ufs_bsg_reply ) :sizeof (struct ufs_rpmb_reply );/* complete the job here only if no error */ -if (ret ==0 ) +if (ret ==0 ) { + job->reply_len = rpmb ?sizeof (struct ufs_rpmb_reply ) : +sizeof (struct ufs_bsg_reply );bsg_job_done (job, ret, bsg_reply->reply_payload_rcv_len); + }return ret; }
Greg Kroah-Hartman
maintainerPATCH 142/157 rseq/selftests: Fix riscv rseq_offset_deref_addv inline asm
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stafford Horne <[email protected]>
commit 713e788c0e07e185fd44dd581f74855ef149722f upstream.
When working on OpenRISC support for restartable sequences I noticed and fixed these two issues with the riscv support bits.
1 The 'inc' argument to RSEQ_ASM_OP_R_DEREF_ADDV was being implicitly
passed to the macro. Fix this by adding 'inc' to the list of macro arguments.
2 The inline asm input constraints for 'inc' and 'off' use "er", The
riscv gcc port does not have an "e" constraint, this looks to be copied from the x86 port. Fix this by just using an "r" constraint.
I have compile tested this only for riscv. However, the same fixes I use in the OpenRISC rseq selftests and everything passes with no issues.
--- tools/testing/selftests/rseq/rseq-riscv-bits.h | 6 +++--- tools/testing/selftests/rseq/rseq-riscv.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-)
tools/testing/selftests/rseq/rseq-riscv-bits.h +3 -3
@@ -243,7 +243,7 @@ int RSEQ_TEMPLATE_IDENTIFIER(rseq_offset#ifdef RSEQ_COMPARE_TWICE RSEQ_ASM_CMP_CPU_ID(cpu_id, current_cpu_id, "%l[error1]")#endif - RSEQ_ASM_OP_R_DEREF_ADDV(ptr, off, 3) + RSEQ_ASM_OP_R_DEREF_ADDV(ptr, off, inc, 3) RSEQ_INJECT_ASM(4)RSEQ_ASM_DEFINE_ABORT (4 , abort) : /* gcc asm goto does not allow outputs */
@@ -251,8 +251,8 @@ int RSEQ_TEMPLATE_IDENTIFIER(rseq_offset [current_cpu_id] "m" (rseq_get_abi()->RSEQ_TEMPLATE_CPU_ID_FIELD), [rseq_cs] "m" (rseq_get_abi()->rseq_cs.arch.ptr), [ptr] "r" (ptr), - [off] "er" (off), - [inc] "er" (inc) + [off] "r" (off), + [inc] "r" (inc) RSEQ_INJECT_INPUT : "memory", RSEQ_ASM_TMP_REG_1RSEQ_INJECT_CLOBBER
tools/testing/selftests/rseq/rseq-riscv.h +1 -1
@@ -158,7 +158,7 @@ do { \"bnez " RSEQ_ASM_TMP_REG_1 ", 222b\n" \ "333:\n" -#define RSEQ_ASM_OP_R_DEREF_ADDV (ptr, off, post_commit_label) \ +#define RSEQ_ASM_OP_R_DEREF_ADDV (ptr, off, inc, post_commit_label) \ "mv " RSEQ_ASM_TMP_REG_1 ", %[" __rseq_str(ptr) "]\n" \ RSEQ_ASM_OP_R_ADD(off) \ REG_L RSEQ_ASM_TMP_REG_1 ", 0(" RSEQ_ASM_TMP_REG_1 ")\n" \
Greg Kroah-Hartman
maintainerPATCH 143/157 riscv/atomic: Do proper sign extension also for unsigned in arch_cmpxchg
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Schwab <[email protected]>
commit 1898300abf3508bca152e65b36cce5bf93d7e63e upstream.
Sign extend also an unsigned compare value to match what lr.w is doing. Otherwise try_cmpxchg may spuriously return true when used on a u32 value that has the sign bit set, as it happens often in inode_set_ctime_current.
Do this in three conversion steps. The first conversion to long is needed to avoid a -Wpointer-to-int-cast warning when arch_cmpxchg is used with a pointer type. Then convert to int and back to long to always sign extend the 32-bit value to 64-bit.
--- arch/riscv/include/asm/cmpxchg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/cmpxchg.h +1 -1
@@ -231,7 +231,7 @@__arch_cmpxchg (".w" ,".w" sc_sfx,".w" cas_sfx, \ sc_prepend, sc_append, \ cas_prepend, cas_append, \ - __ret, __ptr, (long), __old, __new); \ + __ret, __ptr, (long)(int)(long), __old, __new); \break ; \case 8 : \ __arch_cmpxchg(".d", ".d" sc_sfx, ".d" cas_sfx, \
Greg Kroah-Hartman
maintainerPATCH 144/157 riscv/futex: sign extend compare value in atomic cmpxchg
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Schwab <[email protected]>
commit 599c44cd21f4967774e0acf58f734009be4aea9a upstream.
Make sure the compare value in the lr/sc loop is sign extended to match what lr.w does. Fortunately, due to the compiler keeping the register contents sign extended anyway the lack of the explicit extension didn't result in wrong code so far, but this cannot be relied upon.
--- arch/riscv/include/asm/futex.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/futex.h +1 -1
@@ -93,7 +93,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, _ASM_EXTABLE_UACCESS_ERR(1b, 3b, %[r]) \ _ASM_EXTABLE_UACCESS_ERR(2b, 3b, %[r]) \ : [r] "+r" (ret), [v] "=&r" (val), [u] "+m" (*uaddr), [t] "=&r" (tmp) - : [ov] "Jr" (oldval), [nv] "Jr" (newval) + : [ov] "Jr" ((long)(int)oldval), [nv] "Jr" (newval) : "memory"); __disable_user_access();
Greg Kroah-Hartman
maintainerPATCH 145/157 riscv: signal: fix signal frame size
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yong-Xuan Wang <[email protected]>
commit aa49bc2ca8524186ceb0811c23a7f00c3dea6987 upstream.
The signal context of certain RISC-V extensions will be appended after struct __riscv_extra_ext_header, which already includes an empty context header. Therefore, there is no need to preserve a separate hdr for the END of signal context.
--- arch/riscv/kernel/signal.c | 6 ------ 1 file changed, 6 deletions(-)
arch/riscv/kernel/signal.c +0 -6
@@ -215,12 +215,6 @@ static size_t get_rt_frame_size(bool calif (cal_all ||riscv_v_vstate_query (task_pt_regs (current))) total_context_size += riscv_v_sc_size; } -/* -* Preserved a __riscv_ctx_hdr for END signal context header if an -* extension uses __riscv_extra_ext_header -*/ -if (total_context_size) - total_context_size +=sizeof (struct __riscv_ctx_hdr ); frame_size += total_context_size;
Greg Kroah-Hartman
maintainerPATCH 146/157 riscv: cacheinfo: Use of_property_present() for non-boolean properties
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Herring <[email protected]>
commit fb8179ce2996bffaa36a04e2b6262843b01b7565 upstream.
The use of of_property_read_bool() for non-boolean properties is deprecated in favor of of_property_present() when testing for property presence.
--- arch/riscv/kernel/cacheinfo.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
arch/riscv/kernel/cacheinfo.c +6 -6
@@ -108,11 +108,11 @@ int populate_cache_leaves(unsigned int cif (!np)return -ENOENT ; -if (of_property_read_bool (np,"cache-size" )) +if (of_property_present (np,"cache-size" ))ci_leaf_init (this_leaf++,CACHE_TYPE_UNIFIED , level); -if (of_property_read_bool (np,"i-cache-size" )) +if (of_property_present (np,"i-cache-size" ))ci_leaf_init (this_leaf++,CACHE_TYPE_INST , level); -if (of_property_read_bool (np,"d-cache-size" )) +if (of_property_present (np,"d-cache-size" ))ci_leaf_init (this_leaf++,CACHE_TYPE_DATA , level); prev = np;
@@ -125,11 +125,11 @@ int populate_cache_leaves(unsigned int cbreak ;if (level <= levels)break ; -if (of_property_read_bool (np,"cache-size" )) +if (of_property_present (np,"cache-size" ))ci_leaf_init (this_leaf++,CACHE_TYPE_UNIFIED , level); -if (of_property_read_bool (np,"i-cache-size" )) +if (of_property_present (np,"i-cache-size" ))ci_leaf_init (this_leaf++,CACHE_TYPE_INST , level); -if (of_property_read_bool (np,"d-cache-size" )) +if (of_property_present (np,"d-cache-size" ))ci_leaf_init (this_leaf++,CACHE_TYPE_DATA , level); levels = level; }
Greg Kroah-Hartman
maintainerPATCH 147/157 riscv: signal: fix signal_minsigstksz
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yong-Xuan Wang <[email protected]>
commit 564fc8eb6f78e01292ff10801f318feae6153fdd upstream.
The init_rt_signal_env() funciton is called before the alternative patch is applied, so using the alternative-related API to check the availability of an extension within this function doesn't have the intended effect. This patch reorders the init_rt_signal_env() and apply_boot_alternatives() to get the correct signal_minsigstksz.
--- arch/riscv/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/kernel/setup.c +1 -1
@@ -324,8 +324,8 @@ void __init setup_arch(char **cmdline_p)riscv_init_cbo_blocksizes ();riscv_fill_hwcap (); -init_rt_signal_env ();apply_boot_alternatives (); +init_rt_signal_env ();if (IS_ENABLED (CONFIG_RISCV_ISA_ZICBOM ) &&riscv_isa_extension_available (NULL ,ZICBOM ))
Greg Kroah-Hartman
maintainerPATCH 148/157 riscv: cpufeature: use bitmap_equal() instead of memcmp()
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Clément Léger <[email protected]>
commit c6ec1e1b078d8e2ecd075e46db6197a14930a3fc upstream.
Comparison of bitmaps should be done using bitmap_equal(), not memcmp(), use the former one to compare isa bitmaps.
--- arch/riscv/kernel/cpufeature.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/kernel/cpufeature.c +1 -1
@@ -475,7 +475,7 @@ static void __init riscv_resolve_isa(unsif (bit <RISCV_ISA_EXT_BASE ) *this_hwcap |= isa2hwcap[bit]; } - }while (loop &&memcmp (prev_resolved_isa, resolved_isa,sizeof (prev_resolved_isa))); + }while (loop && !bitmap_equal (prev_resolved_isa, resolved_isa,RISCV_ISA_EXT_MAX )); }static void __init match_isa_ext (const char *name,const char *name_end,unsigned long *bitmap)
Greg Kroah-Hartman
maintainerPATCH 149/157 efi: Dont map the entire mokvar table to determine its size
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Jones <[email protected]>
commit 2b90e7ace79774a3540ce569e000388f8d22c9e0 upstream.
Currently, when validating the mokvar table, we (re)map the entire table on each iteration of the loop, adding space as we discover new entries. If the table grows over a certain size, this fails due to limitations of early_memmap(), and we get a failure and traceback:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220 ... Call Trace: <TASK> ? __early_ioremap+0xef/0x220 ? __warn.cold+0x93/0xfa ? __early_ioremap+0xef/0x220 ? report_bug+0xff/0x140 ? early_fixup_exception+0x5d/0xb0 ? early_idt_handler_common+0x2f/0x3a ? __early_ioremap+0xef/0x220 ? efi_mokvar_table_init+0xce/0x1d0 ? setup_arch+0x864/0xc10 ? start_kernel+0x6b/0xa10 ? x86_64_start_reservations+0x24/0x30 ? x86_64_start_kernel+0xed/0xf0 ? common_startup_64+0x13e/0x141 </TASK> ---[ end trace 0000000000000000 ]--- mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.
Mapping the entire structure isn't actually necessary, as we don't ever need more than one entry header mapped at once.
Changes efi_mokvar_table_init() to only map each entry header, not the entire table, when determining the table size. Since we're not mapping any data past the variable name, it also changes the code to enforce that each variable name is NUL terminated, rather than attempting to verify it in place.
--- drivers/firmware/efi/mokvar-table.c | 42 +++++++++++------------------------- 1 file changed, 13 insertions(+), 29 deletions(-)
drivers/firmware/efi/mokvar-table.c +13 -29
@@ -103,9 +103,7 @@ void __init efi_mokvar_table_init(void)void *va =NULL ;unsigned long cur_offset =0 ;unsigned long offset_limit; -unsigned long map_size =0 ;unsigned long map_size_needed =0 ; -unsigned long size;struct efi_mokvar_table_entry *mokvar_entry;int err;
@@ -134,48 +132,34 @@ void __init efi_mokvar_table_init(void)*/ err = -EINVAL ;while (cur_offset +sizeof (*mokvar_entry) <= offset_limit) { - mokvar_entry = va + cur_offset; - map_size_needed = cur_offset +sizeof (*mokvar_entry); -if (map_size_needed > map_size) { -if (va) -early_memunmap (va, map_size); -/* -* Map a little more than the fixed size entry -* header, anticipating some data. It's safe to -* do so as long as we stay within current memory -* descriptor. -*/ - map_size =min (map_size_needed +2 *EFI_PAGE_SIZE , - offset_limit); - va =early_memremap (efi.mokvar_table, map_size); -if (!va) { -pr_err ("Failed to map EFI MOKvar config table pa=0x%lx, size=%lu.\n" , - efi.mokvar_table, map_size); -return ; - } - mokvar_entry = va + cur_offset; +if (va) +early_memunmap (va,sizeof (*mokvar_entry)); + va =early_memremap (efi.mokvar_table + cur_offset,sizeof (*mokvar_entry)); +if (!va) { +pr_err ("Failed to map EFI MOKvar config table pa=0x%lx, size=%zu.\n" , + efi.mokvar_table + cur_offset,sizeof (*mokvar_entry)); +return ; } + mokvar_entry = va;/* Check for last sentinel entry */ if (mokvar_entry->name[0 ] =='\0' ) {if (mokvar_entry->data_size !=0 )break ; err =0 ; + map_size_needed = cur_offset +sizeof (*mokvar_entry);break ; } -/* Sanity check that the name is null terminated */ - size =strnlen (mokvar_entry->name, -sizeof (mokvar_entry->name)); -if (size >=sizeof (mokvar_entry->name)) -break ; +/* Enforce that the name is NUL terminated */ + mokvar_entry->name[sizeof (mokvar_entry->name) -1 ] ='\0' ;/* Advance to the next entry */ - cur_offset = map_size_needed + mokvar_entry->data_size; + cur_offset +=sizeof (*mokvar_entry) + mokvar_entry->data_size; }if (va) -early_memunmap (va, map_size); +early_memunmap (va,sizeof (*mokvar_entry));if (err) {pr_err ("EFI MOKvar config table is not valid\n" );return ;
Greg Kroah-Hartman
maintainerPATCH 150/157 x86/microcode/AMD: Return bool from find_blobs_in_containers()
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikolay Borisov <[email protected]>
commit a85c08aaa665b5436d325f6d7138732a0e1315ce upstream.
Instead of open-coding the check for size/data move it inside the function and make it return a boolean indicating whether data was found or not.
No functional changes.
[ bp: Write @ret in find_blobs_in_containers() only on success. ]
--- arch/x86/kernel/cpu/microcode/amd.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
arch/x86/kernel/cpu/microcode/amd.c +9 -6
@@ -569,14 +569,19 @@ static bool get_builtin_microcode(structreturn false; } -static void __init find_blobs_in_containers (struct cpio_data *ret) +static bool __init find_blobs_in_containers (struct cpio_data *ret) {struct cpio_data cp; +bool found;if (!get_builtin_microcode (&cp)) cp =find_microcode_in_initrd (ucode_path); - *ret = cp; + found = cp.data && cp.size; +if (found) + *ret = cp; + +return found; }void __init load_ucode_amd_bsp (struct early_load_data *ed,unsigned int cpuid_1_eax)
@@ -591,8 +596,7 @@ void __init load_ucode_amd_bsp(struct ea/* Needed in load_microcode_amd() */ ucode_cpu_info[0 ].cpu_sig.sig = cpuid_1_eax; -find_blobs_in_containers (&cp); -if (!(cp.data && cp.size)) +if (!find_blobs_in_containers (&cp))return ;if (early_apply_microcode (ed->old_rev, cp.data, cp.size))
@@ -612,8 +616,7 @@ static int __init save_microcode_in_initif (dis_ucode_ldr || c->x86_vendor !=X86_VENDOR_AMD || c->x86 <0x10 )return 0 ; -find_blobs_in_containers (&cp); -if (!(cp.data && cp.size)) +if (!find_blobs_in_containers (&cp))return -EINVAL ;scan_containers (cp.data, cp.size, &desc);
Greg Kroah-Hartman
maintainerPATCH 151/157 x86/microcode/AMD: Have __apply_microcode_amd() return bool
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Borislav Petkov (AMD)" <[email protected]>
commit 78e0aadbd4c6807a06a9d25bc190fe515d3f3c42 upstream
This is the natural thing to do anyway.
No functional changes.
--- arch/x86/kernel/cpu/microcode/amd.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
arch/x86/kernel/cpu/microcode/amd.c +6 -6
@@ -484,7 +484,7 @@ static void scan_containers(u8 *ucode, s } } -static int __apply_microcode_amd (struct microcode_amd *mc,unsigned int psize) +static bool __apply_microcode_amd (struct microcode_amd *mc,unsigned int psize) {unsigned long p_addr = (unsigned long )&mc->hdr.data_code;u32 rev, dummy;
@@ -508,9 +508,9 @@ static int __apply_microcode_amd(structnative_rdmsr (MSR_AMD64_PATCH_LEVEL , rev, dummy);if (rev != mc->hdr.patch_id) -return -1 ; +return false; -return 0 ; +return true; }/*
@@ -544,7 +544,7 @@ static bool early_apply_microcode(u32 olif (old_rev > mc->hdr.patch_id)return ret; -return !__apply_microcode_amd (mc, desc.psize); +return __apply_microcode_amd (mc, desc.psize); }static bool get_builtin_microcode (struct cpio_data *cp)
@@ -763,7 +763,7 @@ void reload_ucode_amd(unsigned int cpu)rdmsr (MSR_AMD64_PATCH_LEVEL , rev, dummy);if (rev < mc->hdr.patch_id) { -if (!__apply_microcode_amd (mc, p->size)) +if (__apply_microcode_amd (mc, p->size))pr_info_once ("reload revision: 0x%08x\n" , mc->hdr.patch_id); } }
@@ -816,7 +816,7 @@ static enum ucode_state apply_microcode_ goto out; } -if (__apply_microcode_amd (mc_amd, p->size)) { +if (!__apply_microcode_amd (mc_amd, p->size)) {pr_err ("CPU%d: update failed for patch_level=0x%08x\n" , cpu, mc_amd->hdr.patch_id);return UCODE_ERROR ;
Greg Kroah-Hartman
maintainerPATCH 152/157 x86/microcode/AMD: Remove ugly linebreak in __verify_patch_section() signature
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Borislav Petkov (AMD)" <[email protected]>
commit 7103f0589ac220eac3d2b1e8411494b31b883d06 upstream.
No functional changes.
--- arch/x86/kernel/cpu/microcode/amd.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
arch/x86/kernel/cpu/microcode/amd.c +1 -2
@@ -246,8 +246,7 @@ static bool verify_equivalence_table(con* On success, @sh_psize returns the patch size according to the section header, * to the caller. */ -static bool -__verify_patch_section (const u8 *buf,size_t buf_size,u32 *sh_psize) +static bool __verify_patch_section (const u8 *buf,size_t buf_size,u32 *sh_psize) {u32 p_type, p_size;const u32 *hdr;
Greg Kroah-Hartman
maintainerPATCH 153/157 x86/microcode/AMD: Remove unused save_microcode_in_initrd_amd() declarations
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Borislav Petkov (AMD)" <[email protected]>
commit 3ef0740d10b005a45e8ae5b4b7b5d37bfddf63c0 upstream.
Commit
a7939f016720 ("x86/microcode/amd: Cache builtin/initrd microcode early")
renamed it to save_microcode_in_initrd() and made it static. Zap the forgotten declarations.
No functional changes.
--- arch/x86/kernel/cpu/microcode/amd.c | 2 +- arch/x86/kernel/cpu/microcode/internal.h | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-)
arch/x86/kernel/cpu/microcode/amd.c +1 -1
@@ -517,7 +517,7 @@ static bool __apply_microcode_amd(struct* patch container file in initrd, traverse equivalent cpu table, look for a * matching microcode patch, and update, all in initrd memory in place. * When vmalloc() is available for use later -- on 64-bit during first AP load, -* and on 32-bit during save_microcode_in_initrd_amd() -- we can call +* and on 32-bit during save_microcode_in_initrd() -- we can call * load_microcode_amd() to save equivalent cpu table and microcode patches in * kernel heap memory. *
arch/x86/kernel/cpu/microcode/internal.h +0 -2
@@ -100,14 +100,12 @@ extern bool force_minrev;#ifdef CONFIG_CPU_SUP_AMD void load_ucode_amd_bsp (struct early_load_data *ed,unsigned int family);void load_ucode_amd_ap (unsigned int family); -int save_microcode_in_initrd_amd (unsigned int family);void reload_ucode_amd (unsigned int cpu);struct microcode_ops *init_amd_microcode (void );void exit_amd_microcode (void );#else /* CONFIG_CPU_SUP_AMD */ static inline void load_ucode_amd_bsp (struct early_load_data *ed,unsigned int family) { }static inline void load_ucode_amd_ap (unsigned int family) { } -static inline int save_microcode_in_initrd_amd (unsigned int family) {return -EINVAL ; }static inline void reload_ucode_amd (unsigned int cpu) { }static inline struct microcode_ops *init_amd_microcode (void ) {return NULL ; }static inline void exit_amd_microcode (void ) { }
Greg Kroah-Hartman
maintainerPATCH 154/157 x86/microcode/AMD: Merge early_apply_microcode() into its single callsite
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Borislav Petkov (AMD)" <[email protected]>
commit dc15675074dcfd79a2f10a6e39f96b0244961a01 upstream.
No functional changes.
--- arch/x86/kernel/cpu/microcode/amd.c | 60 +++++++++++++++--------------------- 1 file changed, 26 insertions(+), 34 deletions(-)
arch/x86/kernel/cpu/microcode/amd.c +26 -34
@@ -512,39 +512,6 @@ static bool __apply_microcode_amd(structreturn true; } -/* -* Early load occurs before we can vmalloc(). So we look for the microcode -* patch container file in initrd, traverse equivalent cpu table, look for a -* matching microcode patch, and update, all in initrd memory in place. -* When vmalloc() is available for use later -- on 64-bit during first AP load, -* and on 32-bit during save_microcode_in_initrd() -- we can call -* load_microcode_amd() to save equivalent cpu table and microcode patches in -* kernel heap memory. -* -* Returns true if container found (sets @desc), false otherwise. -*/ -static bool early_apply_microcode (u32 old_rev,void *ucode,size_t size) -{ -struct cont_desc desc = {0 }; -struct microcode_amd *mc; -bool ret = false; - -scan_containers (ucode, size, &desc); - - mc = desc.mc; -if (!mc) -return ret; - -/* -* Allow application of the same revision to pick up SMT-specific -* changes even if the revision of the other SMT thread is already -* up-to-date. -*/ -if (old_rev > mc->hdr.patch_id) -return ret; - -return __apply_microcode_amd (mc, desc.psize); -}static bool get_builtin_microcode (struct cpio_data *cp) {
@@ -583,8 +550,19 @@ static bool __init find_blobs_in_containreturn found; } +/* +* Early load occurs before we can vmalloc(). So we look for the microcode +* patch container file in initrd, traverse equivalent cpu table, look for a +* matching microcode patch, and update, all in initrd memory in place. +* When vmalloc() is available for use later -- on 64-bit during first AP load, +* and on 32-bit during save_microcode_in_initrd() -- we can call +* load_microcode_amd() to save equivalent cpu table and microcode patches in +* kernel heap memory. +*/ void __init load_ucode_amd_bsp (struct early_load_data *ed,unsigned int cpuid_1_eax) { +struct cont_desc desc = { }; +struct microcode_amd *mc;struct cpio_data cp = { };u32 dummy;
@@ -598,7 +576,21 @@ void __init load_ucode_amd_bsp(struct eaif (!find_blobs_in_containers (&cp))return ; -if (early_apply_microcode (ed->old_rev, cp.data, cp.size)) +scan_containers (cp.data, cp.size, &desc); + + mc = desc.mc; +if (!mc) +return ; + +/* +* Allow application of the same revision to pick up SMT-specific +* changes even if the revision of the other SMT thread is already +* up-to-date. +*/ +if (ed->old_rev > mc->hdr.patch_id) +return ; + +if (__apply_microcode_amd (mc, desc.psize))native_rdmsr (MSR_AMD64_PATCH_LEVEL , ed->new_rev, dummy); }
Greg Kroah-Hartman
maintainerPATCH 155/157 x86/microcode/AMD: Get rid of the _load_microcode_amd() forward declaration
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Borislav Petkov (AMD)" <[email protected]>
commit b39c387164879eef71886fc93cee5ca7dd7bf500 upstream.
Simply move save_microcode_in_initrd() down.
No functional changes.
--- arch/x86/kernel/cpu/microcode/amd.c | 54 +++++++++++++++++------------------- 1 file changed, 26 insertions(+), 28 deletions(-)
arch/x86/kernel/cpu/microcode/amd.c +26 -28
@@ -594,34 +594,6 @@ void __init load_ucode_amd_bsp(struct eanative_rdmsr (MSR_AMD64_PATCH_LEVEL , ed->new_rev, dummy); } -static enum ucode_state _load_microcode_amd (u8 family,const u8 *data,size_t size); - -static int __init save_microcode_in_initrd (void ) -{ -unsigned int cpuid_1_eax =native_cpuid_eax (1 ); -struct cpuinfo_x86 *c = &boot_cpu_data; -struct cont_desc desc = {0 }; -enum ucode_state ret; -struct cpio_data cp; - -if (dis_ucode_ldr || c->x86_vendor !=X86_VENDOR_AMD || c->x86 <0x10 ) -return 0 ; - -if (!find_blobs_in_containers (&cp)) -return -EINVAL ; - -scan_containers (cp.data, cp.size, &desc); -if (!desc.mc) -return -EINVAL ; - - ret =_load_microcode_amd (x86_family (cpuid_1_eax), desc.data, desc.size); -if (ret >UCODE_UPDATED ) -return -EINVAL ; - -return 0 ; -} -early_initcall (save_microcode_in_initrd); -static inline bool patch_cpus_equivalent (struct ucode_patch *p,struct ucode_patch *n,bool ignore_stepping)
@@ -1005,6 +977,32 @@ static enum ucode_state load_microcode_areturn ret; } +static int __init save_microcode_in_initrd (void ) +{ +unsigned int cpuid_1_eax =native_cpuid_eax (1 ); +struct cpuinfo_x86 *c = &boot_cpu_data; +struct cont_desc desc = {0 }; +enum ucode_state ret; +struct cpio_data cp; + +if (dis_ucode_ldr || c->x86_vendor !=X86_VENDOR_AMD || c->x86 <0x10 ) +return 0 ; + +if (!find_blobs_in_containers (&cp)) +return -EINVAL ; + +scan_containers (cp.data, cp.size, &desc); +if (!desc.mc) +return -EINVAL ; + + ret =_load_microcode_amd (x86_family (cpuid_1_eax), desc.data, desc.size); +if (ret >UCODE_UPDATED ) +return -EINVAL ; + +return 0 ; +} +early_initcall (save_microcode_in_initrd); +/* * AMD microcode firmware naming convention, up to family 15h they are in * the legacy file:
Greg Kroah-Hartman
maintainerPATCH 156/157 x86/microcode/AMD: Add get_patch_level()
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Borislav Petkov (AMD)" <[email protected]>
commit 037e81fb9d2dfe7b31fd97e5f578854e38f09887 upstream.
Put the MSR_AMD64_PATCH_LEVEL reading of the current microcode revision the hw has, into a separate function.
--- arch/x86/kernel/cpu/microcode/amd.c | 46 ++++++++++++++++++------------------ 1 file changed, 24 insertions(+), 22 deletions(-)
arch/x86/kernel/cpu/microcode/amd.c +24 -22
@@ -145,6 +145,15 @@ ucode_path[] __maybe_unused = "kernel/x8*/ static u32 bsp_cpuid_1_eax__ro_after_init ; +static u32 get_patch_level (void ) +{ +u32 rev, dummy__always_unused ; + +native_rdmsr (MSR_AMD64_PATCH_LEVEL , rev, dummy); + +return rev; +} +static union cpuid_1_eax ucode_rev_to_cpuid (unsigned int val) {union zen_patch_rev p;
@@ -483,10 +492,10 @@ static void scan_containers(u8 *ucode, s } } -static bool __apply_microcode_amd (struct microcode_amd *mc,unsigned int psize) +static bool __apply_microcode_amd (struct microcode_amd *mc,u32 *cur_rev, +unsigned int psize) {unsigned long p_addr = (unsigned long )&mc->hdr.data_code; -u32 rev, dummy;native_wrmsrl (MSR_AMD64_PATCH_LOADER , p_addr);
@@ -504,9 +513,8 @@ static bool __apply_microcode_amd(struct }/* verify patch application was successful */ -native_rdmsr (MSR_AMD64_PATCH_LEVEL , rev, dummy); - -if (rev != mc->hdr.patch_id) + *cur_rev =get_patch_level (); +if (*cur_rev != mc->hdr.patch_id)return false;return true;
@@ -564,11 +572,12 @@ void __init load_ucode_amd_bsp(struct eastruct cont_desc desc = { };struct microcode_amd *mc;struct cpio_data cp = { }; -u32 dummy; +u32 rev; bsp_cpuid_1_eax = cpuid_1_eax; -native_rdmsr (MSR_AMD64_PATCH_LEVEL , ed->old_rev, dummy); + rev =get_patch_level (); + ed->old_rev = rev;/* Needed in load_microcode_amd() */ ucode_cpu_info[0 ].cpu_sig.sig = cpuid_1_eax;
@@ -590,8 +599,8 @@ void __init load_ucode_amd_bsp(struct eaif (ed->old_rev > mc->hdr.patch_id)return ; -if (__apply_microcode_amd (mc, desc.psize)) -native_rdmsr (MSR_AMD64_PATCH_LEVEL , ed->new_rev, dummy); +if (__apply_microcode_amd (mc, &rev, desc.psize)) + ed->new_rev = rev; } static inline bool patch_cpus_equivalent(struct ucode_patch *p,
@@ -693,14 +702,9 @@ static void free_cache(void)static struct ucode_patch *find_patch (unsigned int cpu) {struct ucode_cpu_info *uci = ucode_cpu_info + cpu; -u32 rev, dummy__always_unused ;u16 equiv_id =0 ; -/* fetch rev if not populated yet: */ -if (!uci->cpu_sig.rev) { -rdmsr (MSR_AMD64_PATCH_LEVEL , rev, dummy); - uci->cpu_sig.rev = rev; - } + uci->cpu_sig.rev =get_patch_level ();if (x86_family (bsp_cpuid_1_eax) <0x17 ) { equiv_id =find_equiv_id (&equiv_table, uci->cpu_sig.sig);
@@ -723,22 +727,20 @@ void reload_ucode_amd(unsigned int cpu) mc = p->data; -rdmsr (MSR_AMD64_PATCH_LEVEL , rev, dummy); - + rev =get_patch_level ();if (rev < mc->hdr.patch_id) { -if (__apply_microcode_amd (mc, p->size)) -pr_info_once ("reload revision: 0x%08x\n" , mc->hdr.patch_id); +if (__apply_microcode_amd (mc, &rev, p->size)) +pr_info_once ("reload revision: 0x%08x\n" , rev); } }static int collect_cpu_info_amd (int cpu,struct cpu_signature *csig) { -struct cpuinfo_x86 *c = &cpu_data (cpu);struct ucode_cpu_info *uci = ucode_cpu_info + cpu;struct ucode_patch *p; csig->sig =cpuid_eax (0x00000001 ); - csig->rev = c->microcode; + csig->rev =get_patch_level ();/* * a patch could have been loaded early, set uci->mc so that
@@ -779,7 +781,7 @@ static enum ucode_state apply_microcode_ goto out; } -if (!__apply_microcode_amd (mc_amd, p->size)) { +if (!__apply_microcode_amd (mc_amd, &rev, p->size)) {pr_err ("CPU%d: update failed for patch_level=0x%08x\n" , cpu, mc_amd->hdr.patch_id);return UCODE_ERROR ;
Greg Kroah-Hartman
maintainerPATCH 157/157 x86/microcode/AMD: Load only SHA256-checksummed patches
In reply to Greg Kroah-Hartman6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Borislav Petkov (AMD)" <[email protected]>
commit 50cef76d5cb0e199cda19f026842560f6eedc4f7 upstream.
Load patches for which the driver carries a SHA256 checksum of the patch blob.
This can be disabled by adding "microcode.amd_sha_check=off" on the kernel cmdline. But it is highly NOT recommended.
--- arch/x86/Kconfig | 1 arch/x86/kernel/cpu/microcode/amd.c | 111 +++++++ arch/x86/kernel/cpu/microcode/amd_shas.c | 444 +++++++++++++++++++++++++++++++ 3 files changed, 554 insertions(+), 2 deletions(-) create mode 100644 arch/x86/kernel/cpu/microcode/amd_shas.c
arch/x86/Kconfig +1 -0
@@ -1336,6 +1336,7 @@ config X86_REBOOTFIXUPS config MICROCODE def_bool y depends on CPU_SUP_AMD || CPU_SUP_INTEL + select CRYPTO_LIB_SHA256 if CPU_SUP_AMD config MICROCODE_INITRD32 def_bool y
arch/x86/kernel/cpu/microcode/amd.c +109 -2
151 lines not on this page · raw message
arch/x86/kernel/cpu/microcode/amd_shas.c new file +444 -0
444 lines not on this page · raw message
Hi Greg
no regressions here on x86_64 (RKL, Intel 11th Gen. CPU)
Thanks
P.S.
is it necessary to have all cc'ed user informed or should I leave them off ?
Quoted 4 lines · Ronald Warsow
Hi Greg
no regressions here on
x86_64(RKL, Intel 11th Gen. CPU)
Quoted 8 lines
Thanks
Tested-by Ronald Warsow <[email protected]>
P.S.is it necessary to have all cc'ed user informed or should I leave them off ?
Normally, people leave the cc list. It is quite important to keep the cc list at least for failures, so we can debug them together :-).
BR,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.13.6 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
The arm64 defconfig build is broken (KernelCI reported this initially):
/build/stage/linux/arch/arm64/mm/hugetlbpage.c: In function ‘huge_ptep_get_and_clear’:
/build/stage/linux/arch/arm64/mm/hugetlbpage.c:397:35: error: ‘sz’ undeclared (first use in this function); did you mean ‘s8’?
397 | ncontig = num_contig_ptes(sz, &pgsize);
| ^~
| s8/build/stage/linux/arch/arm64/mm/hugetlbpage.c:397:35: note: each undeclared identifier is reported only once for each function it appears in
The same issue affects 6.12.
Greg Kroah-Hartman
maintainerQuoted 8 lines · Mark Brown
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.13.6 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
The arm64 defconfig build is broken (KernelCI reported this initially):
Quoted 8 lines
/build/stage/linux/arch/arm64/mm/hugetlbpage.c: In function ‘huge_ptep_get_and_clear’:
/build/stage/linux/arch/arm64/mm/hugetlbpage.c:397:35: error: ‘sz’ undeclared (first use in this function); did you mean ‘s8’?397 | ncontig = num_contig_ptes(sz, &pgsize); | ^~ | s8/build/stage/linux/arch/arm64/mm/hugetlbpage.c:397:35: note: each undeclared identifier is reported only once for each function it appears in
The same issue affects 6.12.
Thanks, I've now dropped the offending patch and will push out some -rc2 releases soon.
greg k-h
Hello,
Quoted 7 lines · On Wed, 5 Mar 2025 18:47:16 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.13.6 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 07 Mar 2025 17:44:26 +0000. Anything received after that time might be too late.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
[1] https://github.com/damonitor/damon-tests/tree/next/corr
[2] 30be4aa8b957 ("Linux 6.13.6-rc1")
Thanks,
SJ
[...]
---
ok 9 selftests: damon: damos_tried_regions.py
ok 10 selftests: damon: damon_nr_regions.py
ok 11 selftests: damon: reclaim.sh
ok 12 selftests: damon: lru_sort.sh
ok 13 selftests: damon: debugfs_empty_targets.sh
ok 14 selftests: damon: debugfs_huge_count_read_write.sh
ok 15 selftests: damon: debugfs_duplicate_context_creation.sh ok 16 selftests: damon: debugfs_rm_non_contexts.sh
ok 17 selftests: damon: debugfs_target_ids_read_before_terminate_race.sh ok 18 selftests: damon: debugfs_target_ids_pid_leak.sh
ok 19 selftests: damon: sysfs_update_removed_scheme_dir.sh
ok 20 selftests: damon: sysfs_update_schemes_tried_regions_hang.py ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh # SKIP
ok 12 selftests: damon-tests: build_m68k.sh # SKIP
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m
Am 05.03.2025 um 18:47 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.13.6 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.13.6 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 07 Mar 2025 17:44:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.13.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.13.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.13.6 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 07 Mar 2025 17:44:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.13.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.13.y
and the diffstat can be found below.thanks,
greg k-h
Regressions on arm64 the defconfig builds failed with clang-20 and gcc-13 the stable-rc d 6.13.6-rc1 and 6.12.18-rc1.
First seen on the 6.13.6-rc1
Good: v6.13.3
Bad: 6.13.6-rc1
* arm64, build
- clang-20-defconfig
- clang-nightly-defconfig
- gcc-13-defconfig
- gcc-8-defconfig
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
This commit is causing build regressions,
arm64: hugetlb: Fix huge_ptep_get_and_clear() for non-present ptes commit 49c87f7677746f3c5bd16c81b23700bb6b88bfd4 upstream.
Build regression: arm64 hugetlbpage.c undeclared identifier 'sz'
## Build logarch/arm64/mm/hugetlbpage.c:397:28: error: use of undeclared identifier 'sz'
397 | ncontig = num_contig_ptes(sz, &pgsize);
| ^
1 error generated.
## Source
* Kernel version: 6.13.6-rc1
* Git tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* Git sha: 30be4aa8b95762886fc27cf2a9931e14bce269d4
* Git describe: v6.13.3-555-g30be4aa8b957
* Project details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.13.y/build/v6.13.3-555-g30be4aa8b957
## Build
* Build log: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.13.y/build/v6.13.3-555-g30be4aa8b957/testrun/27516541/suite/build/test/clang-20-defconfig/log
* Build history:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.13.y/build/v6.13.3-555-g30be4aa8b957/testrun/27516541/suite/build/test/clang-20-defconfig/history/
* Build details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.13.y/build/v6.13.3-555-g30be4aa8b957/testrun/27516541/suite/build/test/clang-20-defconfig/details/
* Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2tuRCFN4wc8W1MqNki1qddcwCF3/
* Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2tuRCFN4wc8W1MqNki1qddcwCF3/config
## Steps to reproduce
- tuxmake --runtime podman --target-arch arm64 --toolchain clang-20
--kconfig defconfig LLVM=1 LLVM_IAS=1
--
Linaro LKFT
https://lkft.linaro.org
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.13.6 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 07 Mar 2025 17:44:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.13.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.13.y
and the diffstat can be found below.thanks,
greg k-h
6.13.6-rc1 tested.
Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.
Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)
[ 0.000000] Linux version 6.13.6-rc1rv-g30be4aa8b957
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 14.2.1 20250207, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Thu Mar 6 20:52:49 JST 2025
Thanks
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.13.6 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 07 Mar 2025 17:44:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.13.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.13.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
The kernel, bpf tool, perf tool, and kselftest builds fine for v6.13.6-rc1 on x86 Azure VM.
Kernel binary size for x86 build:
text data bss dec hex filename 29936840 17836986 6320128 54093954 3396882 vmlinux
arm64 build on Azure VM fails with the following error:
CC security/keys/request_key_auth.oarch/arm64/mm/hugetlbpage.c: In function 'huge_ptep_get_and_clear':arch/arm64/mm/hugetlbpage.c:397:35: error: 'sz' undeclared (first use in this function); did you mean 's8'?
397 | ncontig = num_contig_ptes(sz, &pgsize);
| ^~
| s8arch/arm64/mm/hugetlbpage.c:397:35: note: each undeclared identifier is reported only once for each function it appears in
Thanks,
Hardik