6.12.18-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 127/150 rcuref: Plug slowpath race in rcuref_put()
In reply to Greg Kroah-Hartman6.12-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 128/150 sched/core: Prevent rescheduling when interrupts are disabled
In reply to Greg Kroah-Hartman6.12-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
@@ -7229,7 +7229,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 129/150 sched_ext: Fix pick_task_scx() picking non-queued tasks when its called without balance()
In reply to Greg Kroah-Hartman6.12-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
@@ -3047,7 +3047,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;
@@ -3067,14 +3066,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 130/150 selftests/landlock: Test TCP accesses with protocol=IPPROTO_TCP
In reply to Greg Kroah-Hartman6.12-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 131/150 dm-integrity: Avoid divide by zero in table status in Inline mode
In reply to Greg Kroah-Hartman6.12-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 dm_target *ti, status_type_t type,break ;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 dm_target *ti, status_type_t type,DMEMIT (" 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); }
Signature · 1 line
2.48.1
Greg Kroah-Hartman
maintainerPATCH 132/150 dm vdo: add missing spin_lock_init
In reply to Greg Kroah-Hartman6.12-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 133/150 ima: Reset IMA_NONACTION_RULE_FLAGS after post_setattr
In reply to Greg Kroah-Hartman6.12-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 134/150 scsi: ufs: core: bsg: Fix crash when arpmb command fails
In reply to Greg Kroah-Hartman6.12-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 135/150 rseq/selftests: Fix riscv rseq_offset_deref_addv inline asm
In reply to Greg Kroah-Hartman6.12-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 136/150 riscv/futex: sign extend compare value in atomic cmpxchg
In reply to Greg Kroah-Hartman6.12-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 137/150 riscv: signal: fix signal frame size
In reply to Greg Kroah-Hartman6.12-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 138/150 riscv: cacheinfo: Use of_property_present() for non-boolean properties
In reply to Greg Kroah-Hartman6.12-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 139/150 riscv: signal: fix signal_minsigstksz
In reply to Greg Kroah-Hartman6.12-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
@@ -288,8 +288,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 140/150 riscv: cpufeature: use bitmap_equal() instead of memcmp()
In reply to Greg Kroah-Hartman6.12-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
@@ -454,7 +454,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 141/150 efi: Dont map the entire mokvar table to determine its size
In reply to Greg Kroah-Hartman6.12-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 142/150 amdgpu/pm/legacy: fix suspend/resume issues
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: chr[] <[email protected]>
commit 91dcc66b34beb72dde8412421bdc1b4cd40e4fb8 upstream.
resume and irq handler happily races in set_power_state()
* amdgpu_legacy_dpm_compute_clocks() needs lock
* protect irq work handler
* fix dpm_enabled usage
v2: fix clang build, integrate Lijo's comments (Alex)
--- drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c | 25 ++++++++++++++++++------ drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c | 8 +++++-- drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 26 +++++++++++++++++++------ 3 files changed, 45 insertions(+), 14 deletions(-)
drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c +19 -6
@@ -3043,6 +3043,7 @@ static int kv_dpm_hw_init(void *handle)if (!amdgpu_dpm)return 0 ; +mutex_lock (&adev->pm.mutex);kv_dpm_setup_asic (adev); ret =kv_dpm_enable (adev);if (ret)
@@ -3050,6 +3051,8 @@ static int kv_dpm_hw_init(void *handle)else adev->pm.dpm_enabled = true;amdgpu_legacy_dpm_compute_clocks (adev); +mutex_unlock (&adev->pm.mutex); +return ret; }
@@ -3067,32 +3070,42 @@ static int kv_dpm_suspend(void *handle) {struct amdgpu_device *adev = (struct amdgpu_device *)handle; +cancel_work_sync (&adev->pm.dpm.thermal.work); +if (adev->pm.dpm_enabled) { +mutex_lock (&adev->pm.mutex); + adev->pm.dpm_enabled = false;/* disable dpm */ kv_dpm_disable (adev);/* reset the power state */ adev->pm.dpm.current_ps = adev->pm.dpm.requested_ps = adev->pm.dpm.boot_ps; +mutex_unlock (&adev->pm.mutex); }return 0 ; }static int kv_dpm_resume (void *handle) { -int ret; +int ret =0 ;struct amdgpu_device *adev = (struct amdgpu_device *)handle; -if (adev->pm.dpm_enabled) { +if (!amdgpu_dpm) +return 0 ; + +if (!adev->pm.dpm_enabled) { +mutex_lock (&adev->pm.mutex);/* asic init will reset to the boot state */ kv_dpm_setup_asic (adev); ret =kv_dpm_enable (adev); -if (ret) +if (ret) { adev->pm.dpm_enabled = false; -else + }else { adev->pm.dpm_enabled = true; -if (adev->pm.dpm_enabled)amdgpu_legacy_dpm_compute_clocks (adev); + } +mutex_unlock (&adev->pm.mutex); } -return 0 ; +return ret; }static bool kv_dpm_is_idle (void *handle)
drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c +6 -2
@@ -1009,9 +1009,12 @@ void amdgpu_dpm_thermal_work_handler(strenum amd_pm_state_type dpm_state =POWER_STATE_TYPE_INTERNAL_THERMAL ;int temp, size =sizeof (temp); -if (!adev->pm.dpm_enabled) -return ; +mutex_lock (&adev->pm.mutex); +if (!adev->pm.dpm_enabled) { +mutex_unlock (&adev->pm.mutex); +return ; + } if (!pp_funcs->read_sensor(adev->powerplay.pp_handle, AMDGPU_PP_SENSOR_GPU_TEMP, (void *)&temp,
@@ -1033,4 +1036,5 @@ void amdgpu_dpm_thermal_work_handler(str adev->pm.dpm.state = dpm_state;amdgpu_legacy_dpm_compute_clocks (adev->powerplay.pp_handle); +mutex_unlock (&adev->pm.mutex); }
drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c +20 -6
@@ -7783,6 +7783,7 @@ static int si_dpm_hw_init(void *handle)if (!amdgpu_dpm)return 0 ; +mutex_lock (&adev->pm.mutex);si_dpm_setup_asic (adev); ret =si_dpm_enable (adev);if (ret)
@@ -7790,6 +7791,7 @@ static int si_dpm_hw_init(void *handle)else adev->pm.dpm_enabled = true;amdgpu_legacy_dpm_compute_clocks (adev); +mutex_unlock (&adev->pm.mutex);return ret; }
@@ -7807,32 +7809,44 @@ static int si_dpm_suspend(void *handle) {struct amdgpu_device *adev = (struct amdgpu_device *)handle; +cancel_work_sync (&adev->pm.dpm.thermal.work); +if (adev->pm.dpm_enabled) { +mutex_lock (&adev->pm.mutex); + adev->pm.dpm_enabled = false;/* disable dpm */ si_dpm_disable (adev);/* reset the power state */ adev->pm.dpm.current_ps = adev->pm.dpm.requested_ps = adev->pm.dpm.boot_ps; +mutex_unlock (&adev->pm.mutex); } +return 0 ; }static int si_dpm_resume (void *handle) { -int ret; +int ret =0 ;struct amdgpu_device *adev = (struct amdgpu_device *)handle; -if (adev->pm.dpm_enabled) { +if (!amdgpu_dpm) +return 0 ; + +if (!adev->pm.dpm_enabled) {/* asic init will reset to the boot state */ +mutex_lock (&adev->pm.mutex);si_dpm_setup_asic (adev); ret =si_dpm_enable (adev); -if (ret) +if (ret) { adev->pm.dpm_enabled = false; -else + }else { adev->pm.dpm_enabled = true; -if (adev->pm.dpm_enabled)amdgpu_legacy_dpm_compute_clocks (adev); + } +mutex_unlock (&adev->pm.mutex); } -return 0 ; + +return ret; }static bool si_dpm_is_idle (void *handle)
Greg Kroah-Hartman
maintainerPATCH 143/150 x86/microcode/AMD: Return bool from find_blobs_in_containers()
In reply to Greg Kroah-Hartman6.12-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 144/150 x86/microcode/AMD: Have __apply_microcode_amd() return bool
In reply to Greg Kroah-Hartman6.12-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 145/150 x86/microcode/AMD: Remove ugly linebreak in __verify_patch_section() signature
In reply to Greg Kroah-Hartman6.12-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 146/150 x86/microcode/AMD: Remove unused save_microcode_in_initrd_amd() declarations
In reply to Greg Kroah-Hartman6.12-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 147/150 x86/microcode/AMD: Merge early_apply_microcode() into its single callsite
In reply to Greg Kroah-Hartman6.12-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 148/150 x86/microcode/AMD: Get rid of the _load_microcode_amd() forward declaration
In reply to Greg Kroah-Hartman6.12-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 149/150 x86/microcode/AMD: Add get_patch_level()
In reply to Greg Kroah-Hartman6.12-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 150/150 x86/microcode/AMD: Load only SHA256-checksummed patches
In reply to Greg Kroah-Hartman6.12-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
@@ -1333,6 +1333,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
Hello,
Quoted 7 lines · On Wed, 5 Mar 2025 18:47:09 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.12.18 release. There are 150 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] 43639cc57b22 ("Linux 6.12.18-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.12.18 release. There are 150 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.12.18 release. There are 150 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.12.18-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.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.12.18 release. There are 150 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.12.18-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.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 6.12.18-rc1 and 6.13.6-rc1.
First seen on the 6.12.18-rc1
Good: v6.12.14
Bad: 6.12.18-rc1
* arm64, build
- clang-20-defconfig
- clang-nightly-defconfig
- gcc-13-defconfig
- gcc-8-defconfig
Regression Analysis:
- New regression? yes
- Reproducibility? Yes
This commmit 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:386:28: error: use of undeclared identifier 'sz'
386 | ncontig = num_contig_ptes(sz, &pgsize);
| ^
1 error generated.
## Source
* Kernel version: 6.12.18-rc1
* Git tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* Git sha: 43639cc57b2273fce42874dd7f6e0b872f4984c5
* Git describe: v6.12.15-531-g43639cc57b22
* Project details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.15-531-g43639cc57b22
## Build
* Build log: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.15-531-g43639cc57b22/testrun/27516239/suite/build/test/clang-20-defconfig/log
* Build history:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.15-531-g43639cc57b22/testrun/27514393/suite/build/test/clang-20-defconfig/history/
* Build details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.15-531-g43639cc57b22/testrun/27516239/suite/build/test/clang-20-defconfig/
* Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2tuR9WQOit4WjRC1XVxLJKTcQia/
* Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2tuR9WQOit4WjRC1XVxLJKTcQia/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
Quoted 42 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.18 release. There are 150 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.12.18-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.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 6.12.18-rc1 and 6.13.6-rc1.
First seen on the 6.12.18-rc1
Good: v6.12.14
Bad: 6.12.18-rc1* arm64, build
- clang-20-defconfig
- clang-nightly-defconfig
- gcc-13-defconfig
- gcc-8-defconfigRegression Analysis:
- New regression? yes
- Reproducibility? YesThis commmit is causing build regressions,
arm64: hugetlb: Fixhuge_ptep_get_and_clear()for non-present ptes commit49c87f7677746f3c5bd16c81b23700bb6b88bfd4upstream.
Quoted 8 lines
Build regression: arm64
hugetlbpage.cundeclared identifier 'sz'## Build log
arch/arm64/mm/hugetlbpage.c:386:28: error: use of undeclared identifier 'sz'
386 | ncontig =num_contig_ptes(sz, &pgsize);
| ^
1 error generated.
This is the same problem we were discussing againt the 6.13 backport. This patch depends on a patch that conflicted so wasn't auto-backported. I'll send out the manual backports in due course.
Quoted 28 lines
## Source
* Kernel version: 6.12.18-rc1
* Git tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* Git sha:43639cc57b2273fce42874dd7f6e0b872f4984c5
* Git describe: v6.12.15-531-g43639cc57b22
* Project details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.15-531-g43639cc57b22## Build
* Build log: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.15-531-g43639cc57b22/testrun/27516239/suite/build/test/clang-20-defconfig/log
* Build history:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.15-531-g43639cc57b22/testrun/27514393/suite/build/test/clang-20-defconfig/history/
* Build details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.15-531-g43639cc57b22/testrun/27516239/suite/build/test/clang-20-defconfig/
* Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2tuR9WQOit4WjRC1XVxLJKTcQia/
* Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2tuR9WQOit4WjRC1XVxLJKTcQia/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
Jon Hunter
maintainerHi Greg,
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.18 release. There are 150 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:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.18-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.
Quoted 6 lines
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
...
The ARM64 build is failing with ...
kernel/arch/arm64/mm/hugetlbpage.c: In function ‘huge_ptep_get_and_clear’:kernel/arch/arm64/mm/hugetlbpage.c:386:35: error: ‘sz’ undeclared (first use in this function); did you mean ‘s8’?
386 | ncontig = num_contig_ptes(sz, &pgsize);
| ^~
| s8Quoted 2 lines
Ryan Roberts <[email protected]>
arm64: hugetlb: Fixhuge_ptep_get_and_clear()for non-present ptes
Bisect is point to the above commit. I am seeing the same build failure on both linux-6.12.y and linux-6.13.y.
Cheers
Jon
Signature · 1 line
nvpublic
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.18 release. There are 150 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.12.18-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.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.12.18-rc1 on x86 Azure VM.
Kernel binary size for x86 build:
text data bss dec hex filename 27755354 17713522 6397952 51866828 3176ccc vmlinux
arm64 build on Azure VM fails with the following error:
CC arch/arm64/kernel/vdso.oarch/arm64/mm/hugetlbpage.c: In function 'huge_ptep_get_and_clear':arch/arm64/mm/hugetlbpage.c:386:35: error: 'sz' undeclared (first use in this function); did you mean 's8'?
386 | ncontig = num_contig_ptes(sz, &pgsize);
| ^~
| s8arch/arm64/mm/hugetlbpage.c:386:35: note: each undeclared identifier is reported only once for each function it appears in
Same issue with v6.13.6-rc1
Thanks,
Hardik