* [PATCH 5.15 061/123] arm64, mm: avoid always making PTE dirty in pte_mkwrite()
2025-10-27 18:34 [PATCH 5.15 000/123] 5.15.196-rc1 review Greg Kroah-Hartman
@ 2025-10-27 18:35 ` Greg Kroah-Hartman
2025-10-27 18:36 ` [PATCH 5.15 114/123] devcoredump: Fix circular locking dependency with devcd->mutex Greg Kroah-Hartman
` (7 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Greg Kroah-Hartman @ 2025-10-27 18:35 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Huang Ying, Will Deacon,
Anshuman Khandual, Ryan Roberts, Gavin Shan, Ard Biesheuvel,
Matthew Wilcox (Oracle), Yicong Yang, linux-arm-kernel,
linux-kernel, Catalin Marinas, Sasha Levin
5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <ying.huang@linux.alibaba.com>
[ Upstream commit 143937ca51cc6ae2fccc61a1cb916abb24cd34f5 ]
Current pte_mkwrite_novma() makes PTE dirty unconditionally. This may
mark some pages that are never written dirty wrongly. For example,
do_swap_page() may map the exclusive pages with writable and clean PTEs
if the VMA is writable and the page fault is for read access.
However, current pte_mkwrite_novma() implementation always dirties the
PTE. This may cause unnecessary disk writing if the pages are
never written before being reclaimed.
So, change pte_mkwrite_novma() to clear the PTE_RDONLY bit only if the
PTE_DIRTY bit is set to make it possible to make the PTE writable and
clean.
The current behavior was introduced in commit 73e86cb03cf2 ("arm64:
Move PTE_RDONLY bit handling out of set_pte_at()"). Before that,
pte_mkwrite() only sets the PTE_WRITE bit, while set_pte_at() only
clears the PTE_RDONLY bit if both the PTE_WRITE and the PTE_DIRTY bits
are set.
To test the performance impact of the patch, on an arm64 server
machine, run 16 redis-server processes on socket 1 and 16
memtier_benchmark processes on socket 0 with mostly get
transactions (that is, redis-server will mostly read memory only).
The memory footprint of redis-server is larger than the available
memory, so swap out/in will be triggered. Test results show that the
patch can avoid most swapping out because the pages are mostly clean.
And the benchmark throughput improves ~23.9% in the test.
Fixes: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()")
Signed-off-by: Huang Ying <ying.huang@linux.alibaba.com>
Cc: Will Deacon <will@kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Gavin Shan <gshan@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Yicong Yang <yangyicong@hisilicon.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/include/asm/pgtable.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index a0bfa9cd76dab..a1902dcf7a7e3 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -175,7 +175,8 @@ static inline pmd_t set_pmd_bit(pmd_t pmd, pgprot_t prot)
static inline pte_t pte_mkwrite(pte_t pte)
{
pte = set_pte_bit(pte, __pgprot(PTE_WRITE));
- pte = clear_pte_bit(pte, __pgprot(PTE_RDONLY));
+ if (pte_sw_dirty(pte))
+ pte = clear_pte_bit(pte, __pgprot(PTE_RDONLY));
return pte;
}
--
2.51.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 5.15 114/123] devcoredump: Fix circular locking dependency with devcd->mutex.
2025-10-27 18:34 [PATCH 5.15 000/123] 5.15.196-rc1 review Greg Kroah-Hartman
2025-10-27 18:35 ` [PATCH 5.15 061/123] arm64, mm: avoid always making PTE dirty in pte_mkwrite() Greg Kroah-Hartman
@ 2025-10-27 18:36 ` Greg Kroah-Hartman
2025-10-27 21:01 ` [PATCH 5.15 000/123] 5.15.196-rc1 review Florian Fainelli
` (6 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Greg Kroah-Hartman @ 2025-10-27 18:36 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Mukesh Ojha, Johannes Berg,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel,
Maarten Lankhorst, Matthew Brost, Mukesh Ojha, Sasha Levin
5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maarten Lankhorst <dev@lankhorst.se>
[ Upstream commit a91c8096590bd7801a26454789f2992094fe36da ]
The original code causes a circular locking dependency found by lockdep.
======================================================
WARNING: possible circular locking dependency detected
6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U
------------------------------------------------------
xe_fault_inject/5091 is trying to acquire lock:
ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660
but task is already holding lock:
ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&devcd->mutex){+.+.}-{3:3}:
mutex_lock_nested+0x4e/0xc0
devcd_data_write+0x27/0x90
sysfs_kf_bin_write+0x80/0xf0
kernfs_fop_write_iter+0x169/0x220
vfs_write+0x293/0x560
ksys_write+0x72/0xf0
__x64_sys_write+0x19/0x30
x64_sys_call+0x2bf/0x2660
do_syscall_64+0x93/0xb60
entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (kn->active#236){++++}-{0:0}:
kernfs_drain+0x1e2/0x200
__kernfs_remove+0xae/0x400
kernfs_remove_by_name_ns+0x5d/0xc0
remove_files+0x54/0x70
sysfs_remove_group+0x3d/0xa0
sysfs_remove_groups+0x2e/0x60
device_remove_attrs+0xc7/0x100
device_del+0x15d/0x3b0
devcd_del+0x19/0x30
process_one_work+0x22b/0x6f0
worker_thread+0x1e8/0x3d0
kthread+0x11c/0x250
ret_from_fork+0x26c/0x2e0
ret_from_fork_asm+0x1a/0x30
-> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}:
__lock_acquire+0x1661/0x2860
lock_acquire+0xc4/0x2f0
__flush_work+0x27a/0x660
flush_delayed_work+0x5d/0xa0
dev_coredump_put+0x63/0xa0
xe_driver_devcoredump_fini+0x12/0x20 [xe]
devm_action_release+0x12/0x30
release_nodes+0x3a/0x120
devres_release_all+0x8a/0xd0
device_unbind_cleanup+0x12/0x80
device_release_driver_internal+0x23a/0x280
device_driver_detach+0x14/0x20
unbind_store+0xaf/0xc0
drv_attr_store+0x21/0x50
sysfs_kf_write+0x4a/0x80
kernfs_fop_write_iter+0x169/0x220
vfs_write+0x293/0x560
ksys_write+0x72/0xf0
__x64_sys_write+0x19/0x30
x64_sys_call+0x2bf/0x2660
do_syscall_64+0x93/0xb60
entry_SYSCALL_64_after_hwframe+0x76/0x7e
other info that might help us debug this:
Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&devcd->mutex);
lock(kn->active#236);
lock(&devcd->mutex);
lock((work_completion)(&(&devcd->del_wk)->work));
*** DEADLOCK ***
5 locks held by xe_fault_inject/5091:
#0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0
#1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220
#2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280
#3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0
#4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660
stack backtrace:
CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)}
Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER
Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021
Call Trace:
<TASK>
dump_stack_lvl+0x91/0xf0
dump_stack+0x10/0x20
print_circular_bug+0x285/0x360
check_noncircular+0x135/0x150
? register_lock_class+0x48/0x4a0
__lock_acquire+0x1661/0x2860
lock_acquire+0xc4/0x2f0
? __flush_work+0x25d/0x660
? mark_held_locks+0x46/0x90
? __flush_work+0x25d/0x660
__flush_work+0x27a/0x660
? __flush_work+0x25d/0x660
? trace_hardirqs_on+0x1e/0xd0
? __pfx_wq_barrier_func+0x10/0x10
flush_delayed_work+0x5d/0xa0
dev_coredump_put+0x63/0xa0
xe_driver_devcoredump_fini+0x12/0x20 [xe]
devm_action_release+0x12/0x30
release_nodes+0x3a/0x120
devres_release_all+0x8a/0xd0
device_unbind_cleanup+0x12/0x80
device_release_driver_internal+0x23a/0x280
? bus_find_device+0xa8/0xe0
device_driver_detach+0x14/0x20
unbind_store+0xaf/0xc0
drv_attr_store+0x21/0x50
sysfs_kf_write+0x4a/0x80
kernfs_fop_write_iter+0x169/0x220
vfs_write+0x293/0x560
ksys_write+0x72/0xf0
__x64_sys_write+0x19/0x30
x64_sys_call+0x2bf/0x2660
do_syscall_64+0x93/0xb60
? __f_unlock_pos+0x15/0x20
? __x64_sys_getdents64+0x9b/0x130
? __pfx_filldir64+0x10/0x10
? do_syscall_64+0x1a2/0xb60
? clear_bhb_loop+0x30/0x80
? clear_bhb_loop+0x30/0x80
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x76e292edd574
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574
RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b
RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063
R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000
</TASK>
xe 0000:03:00.0: [drm] Xe device coredump has been deleted.
Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work")
Cc: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v6.1+
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Cc: Matthew Brost <matthew.brost@intel.com>
Acked-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ replaced disable_delayed_work_sync() with cancel_delayed_work_sync() ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/base/devcoredump.c | 138 +++++++++++++++++++++++++++------------------
1 file changed, 84 insertions(+), 54 deletions(-)
--- a/drivers/base/devcoredump.c
+++ b/drivers/base/devcoredump.c
@@ -26,50 +26,46 @@ struct devcd_entry {
void *data;
size_t datalen;
/*
- * Here, mutex is required to serialize the calls to del_wk work between
- * user/kernel space which happens when devcd is added with device_add()
- * and that sends uevent to user space. User space reads the uevents,
- * and calls to devcd_data_write() which try to modify the work which is
- * not even initialized/queued from devcoredump.
+ * There are 2 races for which mutex is required.
*
+ * The first race is between device creation and userspace writing to
+ * schedule immediately destruction.
*
+ * This race is handled by arming the timer before device creation, but
+ * when device creation fails the timer still exists.
*
- * cpu0(X) cpu1(Y)
+ * To solve this, hold the mutex during device_add(), and set
+ * init_completed on success before releasing the mutex.
*
- * dev_coredump() uevent sent to user space
- * device_add() ======================> user space process Y reads the
- * uevents writes to devcd fd
- * which results into writes to
+ * That way the timer will never fire until device_add() is called,
+ * it will do nothing if init_completed is not set. The timer is also
+ * cancelled in that case.
*
- * devcd_data_write()
- * mod_delayed_work()
- * try_to_grab_pending()
- * del_timer()
- * debug_assert_init()
- * INIT_DELAYED_WORK()
- * schedule_delayed_work()
- *
- *
- * Also, mutex alone would not be enough to avoid scheduling of
- * del_wk work after it get flush from a call to devcd_free()
- * mentioned as below.
- *
- * disabled_store()
- * devcd_free()
- * mutex_lock() devcd_data_write()
- * flush_delayed_work()
- * mutex_unlock()
- * mutex_lock()
- * mod_delayed_work()
- * mutex_unlock()
- * So, delete_work flag is required.
+ * The second race involves multiple parallel invocations of devcd_free(),
+ * add a deleted flag so only 1 can call the destructor.
*/
struct mutex mutex;
- bool delete_work;
+ bool init_completed, deleted;
struct module *owner;
ssize_t (*read)(char *buffer, loff_t offset, size_t count,
void *data, size_t datalen);
void (*free)(void *data);
+ /*
+ * If nothing interferes and device_add() was returns success,
+ * del_wk will destroy the device after the timer fires.
+ *
+ * Multiple userspace processes can interfere in the working of the timer:
+ * - Writing to the coredump will reschedule the timer to run immediately,
+ * if still armed.
+ *
+ * This is handled by using "if (cancel_delayed_work()) {
+ * schedule_delayed_work() }", to prevent re-arming after having
+ * been previously fired.
+ * - Writing to /sys/class/devcoredump/disabled will destroy the
+ * coredump synchronously.
+ * This is handled by using disable_delayed_work_sync(), and then
+ * checking if deleted flag is set with &devcd->mutex held.
+ */
struct delayed_work del_wk;
struct device *failing_dev;
};
@@ -98,14 +94,27 @@ static void devcd_dev_release(struct dev
kfree(devcd);
}
+static void __devcd_del(struct devcd_entry *devcd)
+{
+ devcd->deleted = true;
+ device_del(&devcd->devcd_dev);
+ put_device(&devcd->devcd_dev);
+}
+
static void devcd_del(struct work_struct *wk)
{
struct devcd_entry *devcd;
+ bool init_completed;
devcd = container_of(wk, struct devcd_entry, del_wk.work);
- device_del(&devcd->devcd_dev);
- put_device(&devcd->devcd_dev);
+ /* devcd->mutex serializes against dev_coredumpm_timeout */
+ mutex_lock(&devcd->mutex);
+ init_completed = devcd->init_completed;
+ mutex_unlock(&devcd->mutex);
+
+ if (init_completed)
+ __devcd_del(devcd);
}
static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj,
@@ -125,12 +134,12 @@ static ssize_t devcd_data_write(struct f
struct device *dev = kobj_to_dev(kobj);
struct devcd_entry *devcd = dev_to_devcd(dev);
- mutex_lock(&devcd->mutex);
- if (!devcd->delete_work) {
- devcd->delete_work = true;
- mod_delayed_work(system_wq, &devcd->del_wk, 0);
- }
- mutex_unlock(&devcd->mutex);
+ /*
+ * Although it's tempting to use mod_delayed work here,
+ * that will cause a reschedule if the timer already fired.
+ */
+ if (cancel_delayed_work(&devcd->del_wk))
+ schedule_delayed_work(&devcd->del_wk, 0);
return count;
}
@@ -158,11 +167,21 @@ static int devcd_free(struct device *dev
{
struct devcd_entry *devcd = dev_to_devcd(dev);
+ /*
+ * To prevent a race with devcd_data_write(), cancel work and
+ * complete manually instead.
+ *
+ * We cannot rely on the return value of
+ * cancel_delayed_work_sync() here, because it might be in the
+ * middle of a cancel_delayed_work + schedule_delayed_work pair.
+ *
+ * devcd->mutex here guards against multiple parallel invocations
+ * of devcd_free().
+ */
+ cancel_delayed_work_sync(&devcd->del_wk);
mutex_lock(&devcd->mutex);
- if (!devcd->delete_work)
- devcd->delete_work = true;
-
- flush_delayed_work(&devcd->del_wk);
+ if (!devcd->deleted)
+ __devcd_del(devcd);
mutex_unlock(&devcd->mutex);
return 0;
}
@@ -186,12 +205,10 @@ static ssize_t disabled_show(struct clas
* put_device() <- last reference
* error = fn(dev, data) devcd_dev_release()
* devcd_free(dev, data) kfree(devcd)
- * mutex_lock(&devcd->mutex);
*
*
- * In the above diagram, It looks like disabled_store() would be racing with parallely
- * running devcd_del() and result in memory abort while acquiring devcd->mutex which
- * is called after kfree of devcd memory after dropping its last reference with
+ * In the above diagram, it looks like disabled_store() would be racing with parallelly
+ * running devcd_del() and result in memory abort after dropping its last reference with
* put_device(). However, this will not happens as fn(dev, data) runs
* with its own reference to device via klist_node so it is not its last reference.
* so, above situation would not occur.
@@ -353,7 +370,7 @@ void dev_coredumpm(struct device *dev, s
devcd->read = read;
devcd->free = free;
devcd->failing_dev = get_device(dev);
- devcd->delete_work = false;
+ devcd->deleted = false;
mutex_init(&devcd->mutex);
device_initialize(&devcd->devcd_dev);
@@ -362,8 +379,14 @@ void dev_coredumpm(struct device *dev, s
atomic_inc_return(&devcd_count));
devcd->devcd_dev.class = &devcd_class;
- mutex_lock(&devcd->mutex);
dev_set_uevent_suppress(&devcd->devcd_dev, true);
+
+ /* devcd->mutex prevents devcd_del() completing until init finishes */
+ mutex_lock(&devcd->mutex);
+ devcd->init_completed = false;
+ INIT_DELAYED_WORK(&devcd->del_wk, devcd_del);
+ schedule_delayed_work(&devcd->del_wk, DEVCD_TIMEOUT);
+
if (device_add(&devcd->devcd_dev))
goto put_device;
@@ -380,13 +403,20 @@ void dev_coredumpm(struct device *dev, s
dev_set_uevent_suppress(&devcd->devcd_dev, false);
kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD);
- INIT_DELAYED_WORK(&devcd->del_wk, devcd_del);
- schedule_delayed_work(&devcd->del_wk, DEVCD_TIMEOUT);
+
+ /*
+ * Safe to run devcd_del() now that we are done with devcd_dev.
+ * Alternatively we could have taken a ref on devcd_dev before
+ * dropping the lock.
+ */
+ devcd->init_completed = true;
mutex_unlock(&devcd->mutex);
return;
put_device:
- put_device(&devcd->devcd_dev);
mutex_unlock(&devcd->mutex);
+ cancel_delayed_work_sync(&devcd->del_wk);
+ put_device(&devcd->devcd_dev);
+
put_module:
module_put(owner);
free:
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 5.15 000/123] 5.15.196-rc1 review
2025-10-27 18:34 [PATCH 5.15 000/123] 5.15.196-rc1 review Greg Kroah-Hartman
2025-10-27 18:35 ` [PATCH 5.15 061/123] arm64, mm: avoid always making PTE dirty in pte_mkwrite() Greg Kroah-Hartman
2025-10-27 18:36 ` [PATCH 5.15 114/123] devcoredump: Fix circular locking dependency with devcd->mutex Greg Kroah-Hartman
@ 2025-10-27 21:01 ` Florian Fainelli
2025-10-27 23:26 ` Slade Watkins
` (5 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Florian Fainelli @ 2025-10-27 21:01 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, sudipm.mukherjee, rwarsow, conor,
hargar, broonie, achill, sr
On 10/27/25 11:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 5.15 000/123] 5.15.196-rc1 review
2025-10-27 18:34 [PATCH 5.15 000/123] 5.15.196-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2025-10-27 21:01 ` [PATCH 5.15 000/123] 5.15.196-rc1 review Florian Fainelli
@ 2025-10-27 23:26 ` Slade Watkins
2025-10-28 4:49 ` Ron Economos
` (4 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Slade Watkins @ 2025-10-27 23:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill
On 10/27/2025 2:34 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +0000.
> Anything received after that time might be too late.
5.15.196-rc1 built and run on x86_64 test system with no errors or
regressions:
Tested-by: Slade Watkins <sr@sladewatkins.com>
Slade
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 5.15 000/123] 5.15.196-rc1 review
2025-10-27 18:34 [PATCH 5.15 000/123] 5.15.196-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2025-10-27 23:26 ` Slade Watkins
@ 2025-10-28 4:49 ` Ron Economos
2025-10-28 8:33 ` Greg Kroah-Hartman
2025-10-28 8:09 ` Pavel Machek
` (3 subsequent siblings)
8 siblings, 1 reply; 13+ messages in thread
From: Ron Economos @ 2025-10-28 4:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee,
rwarsow, conor, hargar, broonie, achill, sr
On 10/27/25 11:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
The RISC-V build fails with:
arch/riscv/kernel/cpu.c: In function 'riscv_of_processor_hartid':
arch/riscv/kernel/cpu.c:24:33: error: implicit declaration of function
'of_get_cpu_hwid'; did you mean 'of_get_cpu_node'?
[-Werror=implicit-function-declaration]
24 | *hart = (unsigned long) of_get_cpu_hwid(node, 0);
| ^~~~~~~~~~~~~~~
| of_get_cpu_node
cc1: some warnings being treated as errors
The function of_get_cpu_hwid() doesn't exist in Linux 5.15.x. It was
introduced in 5.16-rc1. The following patches should be reverted:
87b94f8227b3b654ea6e7670cefb32dab0e570ed RISC-V: Don't fail in
riscv_of_parent_hartid() for disabled HARTs
568d34c6aafa066bbdb5e7b6aed9c492d81964e8 RISC-V: Don't print details of
CPUs disabled in DT
And the stable-dep-of patches for the above should also be reverted
since they cause warnings:
989694ece94da2bbae6c6f3f044994302f923cc8 riscv: cpu: Add 64bit hartid
support on RV64
8c2544fd913bb7b29ee3af79e0b302036689fe7a RISC-V: Minimal parser for
"riscv, isa" strings
e0cc917db8fb7b4881ad3e8feb76cefa06f04fe6 RISC-V: Correctly print
supported extensions
c616540d6b67830bb4345130e8fa3d8e217249a0 iscv: Use of_get_cpu_hwid()
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 5.15 000/123] 5.15.196-rc1 review
2025-10-28 4:49 ` Ron Economos
@ 2025-10-28 8:33 ` Greg Kroah-Hartman
0 siblings, 0 replies; 13+ messages in thread
From: Greg Kroah-Hartman @ 2025-10-28 8:33 UTC (permalink / raw)
To: Ron Economos
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill, sr
On Mon, Oct 27, 2025 at 09:49:59PM -0700, Ron Economos wrote:
> On 10/27/25 11:34, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.15.196 release.
> > There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> The RISC-V build fails with:
>
> arch/riscv/kernel/cpu.c: In function 'riscv_of_processor_hartid':
> arch/riscv/kernel/cpu.c:24:33: error: implicit declaration of function
> 'of_get_cpu_hwid'; did you mean 'of_get_cpu_node'?
> [-Werror=implicit-function-declaration]
> 24 | *hart = (unsigned long) of_get_cpu_hwid(node, 0);
> | ^~~~~~~~~~~~~~~
> | of_get_cpu_node
> cc1: some warnings being treated as errors
>
> The function of_get_cpu_hwid() doesn't exist in Linux 5.15.x. It was
> introduced in 5.16-rc1. The following patches should be reverted:
>
> 87b94f8227b3b654ea6e7670cefb32dab0e570ed RISC-V: Don't fail in
> riscv_of_parent_hartid() for disabled HARTs
>
> 568d34c6aafa066bbdb5e7b6aed9c492d81964e8 RISC-V: Don't print details of CPUs
> disabled in DT
>
> And the stable-dep-of patches for the above should also be reverted since
> they cause warnings:
>
> 989694ece94da2bbae6c6f3f044994302f923cc8 riscv: cpu: Add 64bit hartid
> support on RV64
>
> 8c2544fd913bb7b29ee3af79e0b302036689fe7a RISC-V: Minimal parser for "riscv,
> isa" strings
>
> e0cc917db8fb7b4881ad3e8feb76cefa06f04fe6 RISC-V: Correctly print supported
> extensions
>
> c616540d6b67830bb4345130e8fa3d8e217249a0 iscv: Use of_get_cpu_hwid()
Thanks, I'll go drop all of these and push out a -rc2
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.15 000/123] 5.15.196-rc1 review
2025-10-27 18:34 [PATCH 5.15 000/123] 5.15.196-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2025-10-28 4:49 ` Ron Economos
@ 2025-10-28 8:09 ` Pavel Machek
2025-10-28 11:28 ` Jon Hunter
` (2 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Pavel Machek @ 2025-10-28 8:09 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, jonathanh, f.fainelli, sudipm.mukherjee,
rwarsow, conor, hargar, broonie, achill, sr
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
Hi!
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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.
Same problem as 5.10:
arch/riscv/kernel/cpufeature.c: In function 'riscv_fill_hwcap':
2328
arch/riscv/kernel/cpufeature.c:107:16: warning: unused variable 'ext_end' [-Wunused-variable]
2329
107 | const char *ext_end = isa;
2330
| ^~~~~~~
2331
arch/riscv/kernel/cpu.c: In function 'riscv_of_processor_hartid':
2332
arch/riscv/kernel/cpu.c:24:26: error: implicit declaration of function 'of_get_cpu_hwid'; did you mean 'of_get_cpu_node'? [-Werror=implicit-function-declaration]
2333
24 | *hart = (unsigned long) of_get_cpu_hwid(node, 0);
2334
| ^~~~~~~~~~~~~~~
2335
| of_get_cpu_node
2336
CC arch/riscv/kernel/ptrace.o
2337
AR usr/built-in.a
2338
cc1: some warnings being treated as errors
2339
make[2]: *** [scripts/Makefile.build:289: arch/riscv/kernel/cpu.o] Error 1
2340
make[2]: *** Waiting for unfinished jobs
BR,
Pavel
--
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich,
Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 5.15 000/123] 5.15.196-rc1 review
2025-10-27 18:34 [PATCH 5.15 000/123] 5.15.196-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2025-10-28 8:09 ` Pavel Machek
@ 2025-10-28 11:28 ` Jon Hunter
2025-10-28 15:41 ` Vijayendra Suman
2025-10-28 19:27 ` Shuah Khan
8 siblings, 0 replies; 13+ messages in thread
From: Jon Hunter @ 2025-10-28 11:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill, sr,
linux-tegra, stable
On Mon, 27 Oct 2025 19:34:40 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
105 tests: 105 pass, 0 fail
Linux version: 5.15.196-rc1-g01e66f319490
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 5.15 000/123] 5.15.196-rc1 review
2025-10-27 18:34 [PATCH 5.15 000/123] 5.15.196-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2025-10-28 11:28 ` Jon Hunter
@ 2025-10-28 15:41 ` Vijayendra Suman
2025-10-29 10:20 ` Greg Kroah-Hartman
2025-10-28 19:27 ` Shuah Khan
8 siblings, 1 reply; 13+ messages in thread
From: Vijayendra Suman @ 2025-10-28 15:41 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee,
rwarsow, conor, hargar, broonie, achill, sr
On 28/10/25 12:04 am, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/
> patch-5.15.196-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
perf failed to compile with following errors at compilation.
BUILDSTDERR: tests/perf-record.c: In function 'test__PERF_RECORD':
BUILDSTDERR: tests/perf-record.c:118:17: error: implicit declaration of
function 'evlist__cancel_workload'; did you mean
'evlist__start_workload'? [-Werror=implicit-function-declaration]
BUILDSTDERR: 118 | evlist__cancel_workload(evlist);
BUILDSTDERR: | ^~~~~~~~~~~~~~~~~~~~~~~
BUILDSTDERR: | evlist__start_workload
There is no definition for evlist__cancel_workload
Following are references of 'evlist__cancel_workload'
tools/perf/tests/perf-record.c:118: evlist__cancel_workload(evlist);
tools/perf/tests/perf-record.c:130: evlist__cancel_workload(evlist);
tools/perf/tests/perf-record.c:142: evlist__cancel_workload(evlist);
tools/perf/tests/perf-record.c:155: evlist__cancel_workload(evlist);
Commit which need to be reverted.
b7e5c59f3b09 perf test: Don't leak workload gopipe in PERF_RECORD_*
thanks
Vijay
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 5.15 000/123] 5.15.196-rc1 review
2025-10-28 15:41 ` Vijayendra Suman
@ 2025-10-29 10:20 ` Greg Kroah-Hartman
2025-10-30 18:30 ` Vijayendra Suman
0 siblings, 1 reply; 13+ messages in thread
From: Greg Kroah-Hartman @ 2025-10-29 10:20 UTC (permalink / raw)
To: Vijayendra Suman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill, sr
On Tue, Oct 28, 2025 at 09:11:58PM +0530, Vijayendra Suman wrote:
>
>
> On 28/10/25 12:04 am, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.15.196 release.
> > There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/
> > patch-5.15.196-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> perf failed to compile with following errors at compilation.
>
> BUILDSTDERR: tests/perf-record.c: In function 'test__PERF_RECORD':
> BUILDSTDERR: tests/perf-record.c:118:17: error: implicit declaration of
> function 'evlist__cancel_workload'; did you mean 'evlist__start_workload'?
> [-Werror=implicit-function-declaration]
> BUILDSTDERR: 118 | evlist__cancel_workload(evlist);
> BUILDSTDERR: | ^~~~~~~~~~~~~~~~~~~~~~~
> BUILDSTDERR: | evlist__start_workload
>
>
> There is no definition for evlist__cancel_workload
>
> Following are references of 'evlist__cancel_workload'
> tools/perf/tests/perf-record.c:118: evlist__cancel_workload(evlist);
> tools/perf/tests/perf-record.c:130: evlist__cancel_workload(evlist);
> tools/perf/tests/perf-record.c:142: evlist__cancel_workload(evlist);
> tools/perf/tests/perf-record.c:155: evlist__cancel_workload(evlist);
>
>
> Commit which need to be reverted.
> b7e5c59f3b09 perf test: Don't leak workload gopipe in PERF_RECORD_*
This is already being reverted in the latest -rc release, does that not
work here for you?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.15 000/123] 5.15.196-rc1 review
2025-10-29 10:20 ` Greg Kroah-Hartman
@ 2025-10-30 18:30 ` Vijayendra Suman
0 siblings, 0 replies; 13+ messages in thread
From: Vijayendra Suman @ 2025-10-30 18:30 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill, sr
Hi Greg,
On 29/10/25 3:50 pm, Greg Kroah-Hartman wrote:
> On Tue, Oct 28, 2025 at 09:11:58PM +0530, Vijayendra Suman wrote:
>>
>>
>> On 28/10/25 12:04 am, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.15.196 release.
>>> There are 123 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 Wed, 29 Oct 2025 18:34:15 +0000.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> https://urldefense.com/v3/__https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/__;!!ACWV5N9M2RV99hQ!IVHnCNGPANSvr6y0A-odHf0UE4PdtiY7sjGz2BlRApDAo-XoZrirsziXr5syGOL9x2-s6GjtEsk_yVSVuFc7OkW3YM4C$
>>> patch-5.15.196-rc1.gz
>>> or in the git tree and branch at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> perf failed to compile with following errors at compilation.
>>
>> BUILDSTDERR: tests/perf-record.c: In function 'test__PERF_RECORD':
>> BUILDSTDERR: tests/perf-record.c:118:17: error: implicit declaration of
>> function 'evlist__cancel_workload'; did you mean 'evlist__start_workload'?
>> [-Werror=implicit-function-declaration]
>> BUILDSTDERR: 118 | evlist__cancel_workload(evlist);
>> BUILDSTDERR: | ^~~~~~~~~~~~~~~~~~~~~~~
>> BUILDSTDERR: | evlist__start_workload
>>
>>
>> There is no definition for evlist__cancel_workload
>>
>> Following are references of 'evlist__cancel_workload'
>> tools/perf/tests/perf-record.c:118: evlist__cancel_workload(evlist);
>> tools/perf/tests/perf-record.c:130: evlist__cancel_workload(evlist);
>> tools/perf/tests/perf-record.c:142: evlist__cancel_workload(evlist);
>> tools/perf/tests/perf-record.c:155: evlist__cancel_workload(evlist);
>>
>>
>> Commit which need to be reverted.
>> b7e5c59f3b09 perf test: Don't leak workload gopipe in PERF_RECORD_*
>
> This is already being reverted in the latest -rc release, does that not
> work here for you?
I think saw, this error on v5.15.196-rc1, When I rechecked on
v5.15.196-rc2, It was fixed as "perf test: Don't leak workload gopipe in
PERF_RECORD_*" was reverted, had confirmed same on revert of rc2 release.
>
> thanks,
>
> greg k-h
thanks,
Vijay
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.15 000/123] 5.15.196-rc1 review
2025-10-27 18:34 [PATCH 5.15 000/123] 5.15.196-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2025-10-28 15:41 ` Vijayendra Suman
@ 2025-10-28 19:27 ` Shuah Khan
8 siblings, 0 replies; 13+ messages in thread
From: Shuah Khan @ 2025-10-28 19:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee,
rwarsow, conor, hargar, broonie, achill, sr, Shuah Khan
On 10/27/25 12:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 13+ messages in thread