Hi everyone,
Looking at
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
there are a number of criteria for patches to -stable releases.
However, there is no mention of preserving the stability of internal
kernel ABIs and/or APIs.
Do successive patch releases of -stable kernels provide any guarantees
that they will not change ABIs and/or APIs, remove functionality, change
behaviour, etc.? For example, would a -stable commit be allowed to
make a change that would break an out-of-tree (but open-source) device
driver if that's the only way to fix a bug?
I know that during the development of new major/minor versions
developers are free to break ABIs and APIs at will as long as they fix
up all the in-tree code. Does that still hold true for -stable commits
or do things get more restrictive?
Thanks,
Chris
The patch titled
Subject: mm: fix the inaccurate memory statistics issue for users
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-fix-the-inaccurate-memory-statistics-issue-for-users.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Baolin Wang <baolin.wang(a)linux.alibaba.com>
Subject: mm: fix the inaccurate memory statistics issue for users
Date: Sat, 24 May 2025 09:59:53 +0800
On some large machines with a high number of CPUs running a 64K pagesize
kernel, we found that the 'RES' field is always 0 displayed by the top
command for some processes, which will cause a lot of confusion for users.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
875525 root 20 0 12480 0 0 R 0.3 0.0 0:00.08 top
1 root 20 0 172800 0 0 S 0.0 0.0 0:04.52 systemd
The main reason is that the batch size of the percpu counter is quite
large on these machines, caching a significant percpu value, since
converting mm's rss stats into percpu_counter by commit f1a7941243c1 ("mm:
convert mm's rss stats into percpu_counter"). Intuitively, the batch
number should be optimized, but on some paths, performance may take
precedence over statistical accuracy. Therefore, introducing a new
interface to add the percpu statistical count and display it to users,
which can remove the confusion. In addition, this change is not expected
to be on a performance-critical path, so the modification should be
acceptable.
Link: https://lkml.kernel.org/r/4f0fd51eb4f48c1a34226456b7a8b4ebff11bf72.17480518…
Fixes: f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter")
Signed-off-by: Baolin Wang <baolin.wang(a)linux.alibaba.com>
Tested-by Donet Tom <donettom(a)linux.ibm.com>
Reviewed-by: Aboorva Devarajan <aboorvad(a)linux.ibm.com>
Tested-by: Aboorva Devarajan <aboorvad(a)linux.ibm.com>
Acked-by: Shakeel Butt <shakeel.butt(a)linux.dev>
Acked-by: SeongJae Park <sj(a)kernel.org>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Liam Howlett <liam.howlett(a)oracle.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Mike Rapoport <rppt(a)kernel.org>
Cc: Suren Baghdasaryan <surenb(a)google.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/proc/task_mmu.c | 14 +++++++-------
include/linux/mm.h | 5 +++++
2 files changed, 12 insertions(+), 7 deletions(-)
--- a/fs/proc/task_mmu.c~mm-fix-the-inaccurate-memory-statistics-issue-for-users
+++ a/fs/proc/task_mmu.c
@@ -36,9 +36,9 @@ void task_mem(struct seq_file *m, struct
unsigned long text, lib, swap, anon, file, shmem;
unsigned long hiwater_vm, total_vm, hiwater_rss, total_rss;
- anon = get_mm_counter(mm, MM_ANONPAGES);
- file = get_mm_counter(mm, MM_FILEPAGES);
- shmem = get_mm_counter(mm, MM_SHMEMPAGES);
+ anon = get_mm_counter_sum(mm, MM_ANONPAGES);
+ file = get_mm_counter_sum(mm, MM_FILEPAGES);
+ shmem = get_mm_counter_sum(mm, MM_SHMEMPAGES);
/*
* Note: to minimize their overhead, mm maintains hiwater_vm and
@@ -59,7 +59,7 @@ void task_mem(struct seq_file *m, struct
text = min(text, mm->exec_vm << PAGE_SHIFT);
lib = (mm->exec_vm << PAGE_SHIFT) - text;
- swap = get_mm_counter(mm, MM_SWAPENTS);
+ swap = get_mm_counter_sum(mm, MM_SWAPENTS);
SEQ_PUT_DEC("VmPeak:\t", hiwater_vm);
SEQ_PUT_DEC(" kB\nVmSize:\t", total_vm);
SEQ_PUT_DEC(" kB\nVmLck:\t", mm->locked_vm);
@@ -92,12 +92,12 @@ unsigned long task_statm(struct mm_struc
unsigned long *shared, unsigned long *text,
unsigned long *data, unsigned long *resident)
{
- *shared = get_mm_counter(mm, MM_FILEPAGES) +
- get_mm_counter(mm, MM_SHMEMPAGES);
+ *shared = get_mm_counter_sum(mm, MM_FILEPAGES) +
+ get_mm_counter_sum(mm, MM_SHMEMPAGES);
*text = (PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK))
>> PAGE_SHIFT;
*data = mm->data_vm + mm->stack_vm;
- *resident = *shared + get_mm_counter(mm, MM_ANONPAGES);
+ *resident = *shared + get_mm_counter_sum(mm, MM_ANONPAGES);
return mm->total_vm;
}
--- a/include/linux/mm.h~mm-fix-the-inaccurate-memory-statistics-issue-for-users
+++ a/include/linux/mm.h
@@ -2708,6 +2708,11 @@ static inline unsigned long get_mm_count
return percpu_counter_read_positive(&mm->rss_stat[member]);
}
+static inline unsigned long get_mm_counter_sum(struct mm_struct *mm, int member)
+{
+ return percpu_counter_sum_positive(&mm->rss_stat[member]);
+}
+
void mm_trace_rss_stat(struct mm_struct *mm, int member);
static inline void add_mm_counter(struct mm_struct *mm, int member, long value)
_
Patches currently in -mm which might be from baolin.wang(a)linux.alibaba.com are
mm-fix-the-inaccurate-memory-statistics-issue-for-users.patch
Cc: stable
On 2025/5/28 19:42, Lance Yang wrote:
>
> Thanks for taking the time to review!
>
> On 2025/5/28 19:05, Florian Westphal wrote:
>> Lance Yang <ioworker0(a)gmail.com> wrote:
>>> From: Lance Yang <lance.yang(a)linux.dev>
>>>
>>> When no logger is registered, nf_conntrack_log_invalid fails to log
>>> invalid
>>> packets, leaving users unaware of actual invalid traffic. Improve
>>> this by
>>> loading nf_log_syslog, similar to how 'iptables -I FORWARD 1 -m
>>> conntrack
>>> --ctstate INVALID -j LOG' triggers it.
>>
>> Acked-by: Florian Westphal <fw(a)strlen.de>
>
> Hmm... should this patch be backported to stable kernels? Without it,
> nf_conntrack_log_invalid won't log invalid packets when no logger is
> registered, causing unnecessary debugging effort ;)
>
> Back then, I actually thought my machine wasn't seeing any invalid
> packets... turns out they just weren't logged in dmesg :(
>
> Thanks,
> Lance
[Sinldo Technology]
Company Profile
Hong Kong Sinldo Technology Co., Ltd. was established in 2009 and focuses on the supply chain of Qualcomm chips. As a leading supplier in the industry,
We have established solid cooperative relationships with many internationally renowned manufacturers and are committed to providing customers with high-quality and reliable chip products.
Business Scope:
Import and distribution of Qualcomm chips
Management and bidding for excess electronic components
Provide high-quality customer service and technical support
Mission
Stable supply
Vision
Mutual benefit and Triumph
Value
Reduce Fees and increase efficiency
Environment
The company is located in the core business district, with convenient transportation, elegant environment and complete surrounding supporting facilities, which facilitates the travel and business exchanges of employees and customers.
Milestones
2025
2020
2015
2009
It is expected to complete the upgrade strategic planning, further increase market share, and strive for sustainable development
The company implemented a digital management system and began to actively develop online Deals channels
The company has added multiple 4G Qualcomm chips and established partnerships with more OEM customers。
The company was formally established in Shenzhen and initially established cooperative relationships with global suppliers
Company Environment
Coastal Huanqing
Building
Office Area
storehouse
[Qualcomm]Company Spot
[ WIFI6 - IPQ5018 Kits ]
IPQ5018-0-MRQFN232-MT-01-0
QCN6102-0-DRQFN116-TR-01-0
QCA8337-AL3C
Snapdragon SDM-450-B Kits
SDM-450-B-792NSP-TR-01-0-AA
WTR-2965-0-59F0WNSP-TR-07-1
PMI-8952-0-144WLNSP-TR-02-0-00
WCN-3680B-0-79BWLNSP-TR-05-1
PM-8953-0-187F0WNSP-TR-01-1
MDM9x07 Kits
MDM-9607-0-328PSP-TR-00-0
MDM-9207-0-328PSP-TR-00-0
WTR-2965-0-59F0WNSP-TR-07-1
PMD-9607-0-94WLNSP-TR-04-2
[Sinldo Technology Co., Ltd.]
Email:yesunjian888(a)gmail.com
Skype:625285556(a)qq.com
Address:Room 2305, Hai'an Huanqing Building,
Futian Road, Futian District, Shenzhen
Wechat
Hit subscribe now to receive regular updates and our product’s latest features! Subscribe
If you don't want to receive our emails, you can easily unsubscribe here.
Alan Ye
Purchasing Manager
:+86 136 0651 6680
QUALCOMM
Supply chain : yesunjian888(a)gmail.com
With kernel 6.12.30 waking up from hibernate fails in a Ryzen 3 5600G
system with the latest BIOS. At the end of the wake-up procedure the
screen goes black instead of showing the log-in screen and the system
becomes unresponsive. A hard reset is necessary.
Seeing messages like the following in the system log, I suspected an
amdgpu problem:
May 23 19:09:30 LUX kernel: [16885.524496] amdgpu 0000:30:00.0: [drm]
*ERROR* flip_done timed out
May 23 19:09:30 LUX kernel: [16885.524501] amdgpu 0000:30:00.0: [drm]
*ERROR* [CRTC:73:crtc-0] commit wait timed out
I don't know whether those messages and the problem are really related
but I bisected in 'drivers/gpu/drm/amd' anyway and the result was:
> git bisect bad
25e07c8403f4daad35cffc18d96e32a80a2a3222 is the first bad commit
commit 25e07c8403f4daad35cffc18d96e32a80a2a3222 (HEAD)
Author: Alex Deucher <alexander.deucher(a)amd.com>
Date: Thu May 1 13:46:46 2025 -0400
drm/amdgpu: fix pm notifier handling
commit 4aaffc85751da5722e858e4333e8cf0aa4b6c78f upstream.
Set the s3/s0ix and s4 flags in the pm notifier so that we can skip
the resource evictions properly in pm prepare based on whether
we are suspending or hibernating. Drop the eviction as processes
are not frozen at this time, we we can end up getting stuck trying
to evict VRAM while applications continue to submit work which
causes the buffers to get pulled back into VRAM.
HTH. Thanks.
Rainer
--
The truth always turns out to be simpler than you thought.
Richard Feynman