* Re: [PATCH printk 3/3] printk: Support setting console sync mode via console=
From: Petr Mladek @ 2026-07-15 12:23 UTC (permalink / raw)
To: John Ogness
Cc: Sergey Senozhatsky, Steven Rostedt, Andrew Murray, Chris Down,
linux-kernel, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260710144609.194487-4-john.ogness@linutronix.de>
On Fri 2026-07-10 16:51:53, John Ogness wrote:
> Extend the console= kernel command line argument to support specifying
> sync mode at boot time. This is achieved by introducing a new "sync"
> option that can be passed within a console= cmdline argument.
>
> For example, assuming the first serial device should be a console using
> sync mode:
>
> console=ttyS0,115200,sync
>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> Co-authored-by: Chris Down <chris@chrisdown.name>
Just for record, I guess that Chris Down is mentioned as a Co-author
because of the function find_and_remove_console_option() which seems
to be taken from
https://lore.kernel.org/all/d1cae00c839a3681759061e646f21a35b9b66613.1764272407.git.chris@chrisdown.name/
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2567,6 +2567,81 @@ static void set_user_specified(struct console_cmdline *c, bool user_specified)
> console_set_on_cmdline = 1;
> }
>
> +/**
> + * find_and_remove_console_option - Find and remove a named option from console options string
> + * @options: The console options string (will be modified in-place)
> + * @key: The option name to find (e.g., "loglevel")
> + * @val_buf: Buffer to store the option value (if present)
> + * @val_buf_size: Size of @val_buf
> + *
> + * This function searches for a named option in a comma-separated options string
> + * (e.g., "9600n8,loglevel:3,sync"). If found, it extracts the value
> + * (the part after ':') and removes the entire option from the string.
> + *
> + * If an option does not support values, @val_buf should be NULL, in which
> + * case no value part is extracted and any user provided ':' is considered part
> + * of the option key.
> + *
> + * The function modifies @options in-place by:
> + * 1. Temporarily null-terminating option names and values during parsing
> + * 2. Restoring separators if the option isn't found
> + * 3. Removing the found option by shifting the remaining string
> + *
> + * Return: true if the option was found and removed, false otherwise
> + */
> +static bool find_and_remove_console_option(char *options, const char *key,
> + char *val_buf, size_t val_buf_size)
> +{
> + bool found = false, first = true;
> + char *option, *next = options;
> +
> + while ((option = strsep(&next, ","))) {
Sashiko AI pointed out that add_preferred_console() is called also
by of_console_check() where the @options parameter is casted from
"const char *", see
https://sashiko.dev/#/patchset/20260710144609.194487-1-john.ogness%40linutronix.de
I believe that we should be on the safe side. Honestly, I did not
analyze it to the bottom. But the string "of_stdout_options":
+ must be '\0' terminated. So that it can't be part of a full memory dump
of the original device tree file. It must be a dedicated memory
entity which is accessed separately in some node tree, see
of_find_node_opts_by_path().
+ is used only by of_console_check(). So there should not be problem
with parallel access [*]
[*] of_console_check() is actually called from two locations:
serial_core_add_one_port() and sprd_uart_is_console(). So there
is some risk of parallelism.
On the other hand, it makes sense to add the console from
the device tree only once. And we would have bigger problems
when add_preferred_console() is called by mode CPUs in
parallel.
Sigh, I think that we could keep it because it should be good enough.
But I do not have 100% good feeling about it.
Second sigh, proper fix would need to either allocate a copy
or create some static buffer for options in struct console_cmdline
or so.
Or handle this a different way.
> + char *value = NULL;
> +
> + if (val_buf) {
> + value = strchr(option, ':');
> + if (value)
> + *(value++) = '\0';
> + }
> +
> + if (strcmp(option, key) == 0) {
> + found = true;
> + if (value) {
> + if (strlen(value) >= val_buf_size) {
> + pr_warn("Cannot copy console option value for %s:%s: not enough space (%zu)\n",
> + option, value, val_buf_size);
> + found = false;
> + } else {
> + strscpy(val_buf, value, val_buf_size);
> + }
> + } else if (val_buf) {
> + *val_buf = '\0';
> + }
> + }
> +
> + if (found)
> + break;
> +
> + if (next)
> + *(next - 1) = ',';
> + if (value)
> + *(value - 1) = ':';
> +
> + first = false;
> + }
> +
> + if (found) {
> + if (next)
> + memmove(option, next, strlen(next) + 1);
> + else if (first)
> + *option = '\0';
Sashiko AI also pointed out that this would create an empty string.
For example, serial8250_console_setup() checks only whether it is NULL
and tries to read the baudate, ...
Sigh, the handling of the console parameters is yet another historic
mess which would deserve a clean up. I'll add this to my TODO
in the console registration clean up. But I think that it is beyond
the scope of this patch set.
Well, we should stay conservative and set options to NULL in this case.
> + else
> + *--option = '\0';
> + }
> +
> + return found;
> +}
> +
> static int __add_preferred_console(const char *name, const short idx,
> const char *devname, char *options,
> char *brl_options, bool user_specified)
Otherwise, it looks good to me.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH] arm64: errata: Mitigate AmpereOne erratum AC03_CPU_57 and AC04_CPU_29
From: Marc Zyngier @ 2026-07-15 12:29 UTC (permalink / raw)
To: D Scott Phillips
Cc: Oliver Upton, Catalin Marinas, Will Deacon, Jonathan Corbet,
Shuah Khan, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Mark Rutland, Zeng Heng, Wei Xu, Vladimir Murzin,
Lucas Wei, Kuninori Morimoto, Sascha Bischoff, Yicong Yang,
Yeoreum Yun, linux-arm-kernel, linux-doc, linux-kernel, kvmarm
In-Reply-To: <86jyqx189z.fsf@scott-ph-mail.amperecomputing.com>
On Wed, 15 Jul 2026 00:06:00 +0100,
D Scott Phillips <scott@os.amperecomputing.com> wrote:
>
> > OK, that's pretty good news. Can I safely assume that your HW doesn't
> > support VLPIs/VSGIs in any form (no GICv4+)?
>
> AmpereOne AC04 does have gicv4.1 with vlpis/vsgis. Those take a
> different enough path in the core that a deactivation of a pending
> vlpi/vsgi won't cause the issue. The wording about "physical interrupt"
> is meant to exclude vlpis/vsgis, sorry that it didn't come out clearly.
Given that the write-up didn't mention direct injection at all, it
wasn't totally obvious whether this was taken into account or not.
Might be worth adding to the errata document for clarity.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 1/2] mm/zswap: Fix global shrinker when memory cgroup is disabled
From: Hao Jia @ 2026-07-15 12:30 UTC (permalink / raw)
To: Andrew Morton, Yosry Ahmed, nphamcs
Cc: tj, hannes, shakeel.butt, mhocko, mkoutny, chengming.zhou,
muchun.song, roman.gushchin, linux-mm, linux-kernel, linux-doc,
Hao Jia, stable
In-Reply-To: <20260714193129.f81711f516504b659d544741@linux-foundation.org>
On 2026/7/15 10:31, Andrew Morton wrote:
> On Tue, 14 Jul 2026 09:52:59 -0700 Yosry Ahmed <yosry@kernel.org> wrote:
>
>>> When memory cgroup is disabled, mem_cgroup_iter() always returns NULL.
>>> Therefore, the global shrinker shrink_worker() always takes the !memcg
>>> branch. After MAX_RECLAIM_RETRIES empty walks, the worker simply gives up,
>>> so it fails to write back anything.
>>>
>>> Therefore, when memory cgroup is disabled, fall through with the !memcg
>>> branch and shrink the root memcg directly.
>>>
>>> With memcg disabled, shrink_memcg() only returns -ENOENT when the root
>>> LRU is empty, which means the total pages are already below thr. The
>>> loop then safely bails out via the zswap_total_pages() <= thr check.
>>> For any other return value from shrink_memcg(), the loop is guaranteed
>>> to terminate, either after MAX_RECLAIM_RETRIES failures or once the
>>> threshold is met.
>>>
>>> Fixes: a65b0e7607cc ("zswap: make shrinking memcg-aware")
>>> Cc: stable@vger.kernel.org
>>> Suggested-by: Nhat Pham <nphamcs@gmail.com>
>>> Acked-by: Nhat Pham <nphamcs@gmail.com>
>>> Acked-by: Yosry Ahmed <yosry@kernel.org>
>>> Reported-by: Yosry Ahmed <yosry@kernel.org>
>>> Closes: https://lore.kernel.org/all/CAO9r8zPVzMKFbCixxD-qgtRrkFxWVrHiZZeLc=eyTPKPVQgX4g@mail.gmail.com
>>> Signed-off-by: Hao Jia <jiahao1@lixiang.com>
>>
>> Patch 2 doesn't really depend on this one, right?
>>
>> If that's the case I think this can (and should be) picked up
>> separately as a hotfix. Andrew, WDYT?
>
> Please update the changelog to clearly describe the userspace-visible
> effects of the bug, thanks.
I am not entirely sure if my understanding is correct here, but maybe I
should add something like this to the commit message?
When cgroup_disable=memory is used (or with CONFIG_MEMCG=n), the global
shrinker fails to write back any pages. Consequently, the zswap pool
fills up to its limit and rejects further storage, preventing memory
pressure from being offloaded to the backing swap device.
> Also, AI review has flagged several possible issues, all appear to be
> serious:
> https://sashiko.dev/#/patchset/20260714081510.16895-1-jiahao.kernel@gmail.com
For AI review comments on this patch:
I suspect this scenario might only exist in theory. For zswap LRU to be
empty while zswap_total_pages() > thr holds true, it would require a
prolonged state where there are always more than thr zswap entries on
the zswap LRU whenever zswap_total_pages() > thr is evaluated, yet the
zswap LRU happens to be empty during shrink_memcg(root_memcg).
If we want to fix this, perhaps we could do something like this?
Yosry, Nhat, what are your thoughts on this?
diff --git a/mm/zswap.c b/mm/zswap.c
index b5a17ea20237..ca71b517a58d 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -1356,11 +1356,12 @@ static void shrink_worker(struct work_struct *w)
} while (memcg && !mem_cgroup_tryget_online(memcg));
spin_unlock(&zswap_shrink_lock);
- if (!memcg) {
- /*
- * Continue shrinking without incrementing
failures if
- * we found candidate memcgs in the last tree walk.
- */
+ /*
+ * A NULL memcg ends a full hierarchy pass (except when
memcg is
+ * disabled, where it is always NULL: fall through to
the root LRU).
+ * Count a failure only if the last pass found no
candidates.
+ */
+ if (!memcg && !mem_cgroup_disabled()) {
if (!attempts && ++failures == MAX_RECLAIM_RETRIES)
break;
@@ -1378,8 +1379,15 @@ static void shrink_worker(struct work_struct *w)
* with pages in zswap. Skip this without incrementing
attempts
* and failures.
*/
- if (ret == -ENOENT)
+ if (ret == -ENOENT) {
+ /*
+ * With memcg disabled the root LRU is the only
target, so
+ * we should abort if it has no
writeback-candidate pages.
+ */
+ if (mem_cgroup_disabled())
+ break;
continue;
+ }
++attempts;
if (ret && ++failures == MAX_RECLAIM_RETRIES)
Thanks,
Hao
^ permalink raw reply related
* Re: [PATCH v2 0/4] mm/hmm: Clarify notifier retry state and scope HMM timeouts
From: David Hildenbrand (Arm) @ 2026-07-15 12:41 UTC (permalink / raw)
To: Stanislav Kinsburskii, airlied, akhilesh, akpm, corbet, dakr, jgg,
kees, leon, liam, lizhi.hou, ljs, lyude, maarten.lankhorst,
mamin506, mhocko, mripard, nouveau, ogabbay, oleg, rppt, shuah,
simona, skhan, surenb, tzimmermann, vbabka
Cc: dri-devel, linux-mm, linux-doc, linux-kernel, linux-kselftest,
linux-rdma
In-Reply-To: <178406760622.1106335.2379450382728057793.stgit@skinsburskii>
On 7/15/26 00:21, Stanislav Kinsburskii wrote:
> This small fixup series applies on top of:
>
> [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
>
> The first patch updates the HMM documentation example to make the
> mmu_interval_read_retry() state explicit: callers should use the notifier and
> notifier_seq stored in the same hmm_range that was passed to
> hmm_range_fault_unlocked_timeout().
>
> The remaining patches adjust nouveau, amdxdna, and drm_gpusvm users so the
> timeout passed to hmm_range_fault_unlocked_timeout() is treated as a relative
> HMM retry budget. These callers no longer keep an absolute deadline around
> their outer driver retry loops or pass a computed remaining time into HMM.
>
> This keeps the timeout scoped to HMM's internal mmu-notifier retry handling. If
> HMM succeeds and the driver later observes an invalidation through
> mmu_interval_read_retry(), the driver retries the operation with a fresh HMM
> retry budget.
>
> Changes in v2:
> - Kept the nouveau outer absolute timeout around the
> mmu_interval_read_retry() loop. hmm_range_fault_unlocked_timeout() only
> bounds HMM’s internal retries, while nouveau faults are handled from a GPU
> fault worker, so userspace fatal signals cannot break an endless stream of
> invalidations there.
> - Updated nouveau to use time_after_eq() before calling HMM, so the remaining
> timeout passed to hmm_range_fault_unlocked_timeout() is always positive and
> never 0, which would mean retry indefinitely.
> - Updated the nouveau fixup commit message to explain the worker-thread
> timeout issue and the time_after_eq() boundary behavior.
> - Fixed the amdxdna fixup commit message. It now describes
> aie2_populate_range() correctly instead of carrying stale nouveau prose,
> and notes that command submission still keeps its broader timeout while HMM
> gets a fresh relative retry budget.
>
>
> ---
>
> Stanislav Kinsburskii (4):
> fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support
> fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults
> fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population
> fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults
Why a fixup series instead of properly resending the full thing?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2] scripts/kernel-doc: Suggest possible names for excess descriptions
From: Mauro Carvalho Chehab @ 2026-07-15 12:42 UTC (permalink / raw)
To: Ryszard Knop
Cc: Randy Dunlap, linux-doc, Shuicheng Lin, Jani Nikula, linux-kernel,
intel-xe
In-Reply-To: <20260715111726.394565-1-ryszard.knop@intel.com>
On Wed, 15 Jul 2026 13:17:26 +0200
Ryszard Knop <ryszard.knop@intel.com> wrote:
> Since check_sections() now warns if a documentation tag member name is
> the same as defined in the struct, we can suggest names the checker
> knows, so that it's more obvious how to deal with the warning.
>
> v2 (rdunlap):
> - Strip whitespace from warnings, nicer when the hint is empty
>
> Signed-off-by: Ryszard Knop <ryszard.knop@intel.com>
> ---
> tools/lib/python/kdoc/kdoc_parser.py | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/tools/lib/python/kdoc/kdoc_parser.py b/tools/lib/python/kdoc/kdoc_parser.py
> index 2dedda215c22..a22c3e3182f0 100644
> --- a/tools/lib/python/kdoc/kdoc_parser.py
> +++ b/tools/lib/python/kdoc/kdoc_parser.py
> @@ -558,6 +558,13 @@ class KernelDoc:
> self.push_parameter(ln, decl_type, param, dtype,
> arg, declaration_name)
>
> + def get_suggestions_hint(self, decl_name, possible_names):
> + suggestions = set(name for name in possible_names if decl_name in name)
> + if not suggestions:
> + return ""
> +
> + return f"(did you mean one of: '{"', '".join(suggestions)}')"
> +
There is a better way to propose suggestions. See:
Documentation/sphinx/kernel_include.py
E.g. use something like:
from difflib import get_close_matches
matches = get_close_matches(decl_name, possible_names)
See: https://docs.python.org/3/library/difflib.html#difflib.get_close_matches
If the problem is due to a typo, this will likely return the
right name.
Regards,
Mauro
^ permalink raw reply
* Re: [PATCH v2] docs: translations: pt_BR: process: email-clients: traduz para pt_BR
From: Daniel Pereira @ 2026-07-15 13:08 UTC (permalink / raw)
To: Ygor Otavio; +Cc: linux-doc, corbet
In-Reply-To: <20260714210124.5364-1-ygorotavio.sjc@gmail.com>
Em ter., 14 de jul. de 2026 às 18:01, Ygor Otavio
<ygorotavio.sjc@gmail.com> escreveu:
>
> Translates the documentation regarding email clients info for Linux
> into Brazilian Portuguese, maintaining consistency with original
> formatting rules.
> For V2, the errors "bullet list ends without a blank line" and
> "inline interpreted text start-string without end-string" were fixed.
> The others errors that appeared after the submission of v2 were also
> fixed.
>
> Signed-off-by: Ygor Otavio <ygorotavio.sjc@gmail.com>
> ---
> .../pt_BR/process/email-clients.rst | 368 ++++++++++++++++++
> 1 file changed, 368 insertions(+)
> create mode 100644 Documentation/translations/pt_BR/process/email-clients.rst
Also, the new document was not added to index.rst.
> +depois salvá-lo como rascunho. Depois de abri-lonovamente dos rascunhos, ele
> +estará com quebras de linha rígidas e você poderá desmarcar “quebra de linha
> +automática” sem perder a quebra existente.
Hi, this word 'abri-lonovamente' should be 'Abri-lo novamente', correct?
> +Ao salvar patches enviados como texto inserido, selecione o email que contém o
> +patch no painel da lista de mensagens, clique com o botão direito e selecione
> +:menuselection:`salvar como`. Você pode usar o email inteiro sem alterações como
> +patch se ele tiver sido composto corretamente. Emails são salvos como leitura e
> +gravação apenas para o usuário, então você terá que chmodá-los para torná-los
I believe 'leitura e escrita' sounds more natural than 'leitura e
gravação'. Also, the word
'chmodá-los' sounds very weird in Portuguese; a better and more
standard technical translation
would be 'alterar as permissões' (to change the permissions)
> +Ao mesmo tempo, ele quebra linhas a cada 78 caracteres com quebras de linha no
> +estilo CRLF, embora o problema de tab para espaço possaser resolvido com um
> +editor externo.
We have the same issue here: 'possaser' should be 'possa ser'
^ permalink raw reply
* Re: [PATCH v6 1/5] spi: dt-bindings: Add spi-device-addr peripheral property
From: Mark Brown @ 2026-07-15 13:09 UTC (permalink / raw)
To: Janani Sunil
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, Marius Cristea, Marcus Folkesson, Kent Gustavsson,
linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson
In-Reply-To: <20260715-ad5529r-driver-v6-1-cfdf8b9f5ee3@analog.com>
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
On Wed, Jul 15, 2026 at 01:41:04PM +0200, Janani Sunil wrote:
> Some SPI devices support sharing a single chip select across multiple
> physical chips by encoding a device address in the SPI frame itself.
> Add the generic spi-device-addr property for describing these hardware
> addresses. The property is placed on the SPI peripheral node and may
> contain multiple addresses.
This really isn't a generic SPI thing, if nothing else you need *far*
more information in there about how exactly this would be put onto the
bus. If it belongs anywhere outside of the specific device's binding it
feels like it might be regmap.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v2] mm/mseal: fix mseal documentation for 32-bit kernels
From: Leon Hwang @ 2026-07-15 13:12 UTC (permalink / raw)
To: linux-mm
Cc: Jonathan Corbet, Shuah Khan, Andrew Morton, Liam R . Howlett,
Lorenzo Stoakes, Vlastimil Babka, Jann Horn, Pedro Falcato,
Lance Yang, Leon Hwang, Nathan Chancellor, Miguel Ojeda,
Nicolas Schier, Peter Zijlstra, Thomas Gleixner,
Thomas Weißschuh, Alice Ryhl, Douglas Anderson, Gary Guo,
Anand Moon, Randy Dunlap, linux-doc, linux-kernel
mseal.o is built only for 64-bit kernels, so 32-bit kernels fall back
to sys_ni_syscall() and return -ENOSYS rather than -EPERM.
Drop architecture description in mseal.rst, since the arch feature
doc has the latest state of mseal for each architecture.
Fix the CONFIG_MSEAL_SYSTEM_MAPPINGS typo in init/Kconfig.
Drop the whole comment of do_mseal() to avoid stale info in the
comment, as we have the doc in mseal.rst.
Acked-by: Lance Yang <lance.yang@linux.dev>
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
---
v1 -> v2:
* Drop -EINTR description in mseal.rst. (per Mathew)
* Drop VM_SEALED_SYSMAP change in mseal.rst. (per Pedro)
* Drop architecture description in mseal.rst. (per Pedro)
* Drop the whole comment of do_mseal(). (per Pedro)
* v1: https://lore.kernel.org/linux-mm/20260703022507.187457-1-leon.hwang@linux.dev/
---
Documentation/userspace-api/mseal.rst | 14 ++++----
init/Kconfig | 2 +-
mm/mseal.c | 52 ---------------------------
3 files changed, 7 insertions(+), 61 deletions(-)
diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
index ea9b11a0bd89..c039d782f9f5 100644
--- a/Documentation/userspace-api/mseal.rst
+++ b/Documentation/userspace-api/mseal.rst
@@ -50,8 +50,8 @@ mseal syscall signature
* The start address (``addr``) is not allocated.
* The end address (``addr`` + ``len``) is not allocated.
* A gap (unallocated memory) between start and end address.
- - **-EPERM**:
- * sealing is supported only on 64-bit CPUs, 32-bit is not supported.
+ - **-ENOSYS**:
+ * The kernel does not implement ``mseal()``.
**Note about error return**:
- For above error cases, users can expect the given memory range is
@@ -62,7 +62,8 @@ mseal syscall signature
memory range could happen. However, those cases should be rare.
**Architecture support**:
- mseal only works on 64-bit CPUs, not 32-bit CPUs.
+ mseal is built only for 64-bit kernels. 32-bit kernels return
+ ``-ENOSYS``.
**Idempotent**:
users can call mseal multiple times. mseal on an already sealed memory
@@ -131,11 +132,11 @@ Use cases
- Chrome browser: protect some security sensitive data structures.
- System mappings:
- The system mappings are created by the kernel and includes vdso, vvar,
+ The system mappings are created by the kernel and include vdso, vvar,
vvar_vclock, vectors (arm compat-mode), sigpage (arm compat-mode), uprobes.
Those system mappings are readonly only or execute only, memory sealing can
- protect them from ever changing to writable or unmmap/remapped as different
+ protect them from ever changing to writable or unmapped/remapped as different
attributes. This is useful to mitigate memory corruption issues where a
corrupted pointer is passed to a memory management system.
@@ -143,9 +144,6 @@ Use cases
the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this
architecture.
- The following architectures currently support this feature: x86-64, arm64,
- loongarch and s390.
-
WARNING: This feature breaks programs which rely on relocating
or unmapping system mappings. Known broken software at the time
of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
diff --git a/init/Kconfig b/init/Kconfig
index 9d91074c5d0a..a1402bd82026 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2120,7 +2120,7 @@ config ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
from a kernel perspective.
After the architecture enables this, a distribution can set
- CONFIG_MSEAL_SYSTEM_MAPPING to manage access to the feature.
+ CONFIG_MSEAL_SYSTEM_MAPPINGS to manage access to the feature.
For complete descriptions of memory sealing, please see
Documentation/userspace-api/mseal.rst
diff --git a/mm/mseal.c b/mm/mseal.c
index 9781647483d1..69a53207ab57 100644
--- a/mm/mseal.c
+++ b/mm/mseal.c
@@ -88,58 +88,6 @@ static int mseal_apply(struct mm_struct *mm,
return 0;
}
-/*
- * mseal(2) seals the VM's meta data from
- * selected syscalls.
- *
- * addr/len: VM address range.
- *
- * The address range by addr/len must meet:
- * start (addr) must be in a valid VMA.
- * end (addr + len) must be in a valid VMA.
- * no gap (unallocated memory) between start and end.
- * start (addr) must be page aligned.
- *
- * len: len will be page aligned implicitly.
- *
- * Below VMA operations are blocked after sealing.
- * 1> Unmapping, moving to another location, and shrinking
- * the size, via munmap() and mremap(), can leave an empty
- * space, therefore can be replaced with a VMA with a new
- * set of attributes.
- * 2> Moving or expanding a different vma into the current location,
- * via mremap().
- * 3> Modifying a VMA via mmap(MAP_FIXED).
- * 4> Size expansion, via mremap(), does not appear to pose any
- * specific risks to sealed VMAs. It is included anyway because
- * the use case is unclear. In any case, users can rely on
- * merging to expand a sealed VMA.
- * 5> mprotect and pkey_mprotect.
- * 6> Some destructive madvice() behavior (e.g. MADV_DONTNEED)
- * for anonymous memory, when users don't have write permission to the
- * memory. Those behaviors can alter region contents by discarding pages,
- * effectively a memset(0) for anonymous memory.
- *
- * flags: reserved.
- *
- * return values:
- * zero: success.
- * -EINVAL:
- * invalid input flags.
- * start address is not page aligned.
- * Address range (start + len) overflow.
- * -ENOMEM:
- * addr is not a valid address (not allocated).
- * end (start + len) is not a valid address.
- * a gap (unallocated memory) between start and end.
- * -EPERM:
- * - In 32 bit architecture, sealing is not supported.
- * Note:
- * user can call mseal(2) multiple times, adding a seal on an
- * already sealed memory is a no-action (no error).
- *
- * unseal() is not supported.
- */
int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
{
size_t len;
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v2] scripts/kernel-doc: Suggest possible names for excess descriptions
From: Knop, Ryszard @ 2026-07-15 13:21 UTC (permalink / raw)
To: mchehab+huawei@kernel.org
Cc: intel-xe@lists.freedesktop.org, Lin, Shuicheng,
linux-doc@vger.kernel.org, rdunlap@infradead.org,
jani.nikula@linux.intel.com, linux-kernel@vger.kernel.org
In-Reply-To: <20260715144243.60686000@localhost>
On Wed, 2026-07-15 at 14:42 +0200, Mauro Carvalho Chehab wrote:
> On Wed, 15 Jul 2026 13:17:26 +0200
> Ryszard Knop <ryszard.knop@intel.com> wrote:
>
> > Since check_sections() now warns if a documentation tag member name is
> > the same as defined in the struct, we can suggest names the checker
> > knows, so that it's more obvious how to deal with the warning.
> >
> > v2 (rdunlap):
> > - Strip whitespace from warnings, nicer when the hint is empty
> >
> > Signed-off-by: Ryszard Knop <ryszard.knop@intel.com>
> > ---
> > tools/lib/python/kdoc/kdoc_parser.py | 13 +++++++++++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/lib/python/kdoc/kdoc_parser.py b/tools/lib/python/kdoc/kdoc_parser.py
> > index 2dedda215c22..a22c3e3182f0 100644
> > --- a/tools/lib/python/kdoc/kdoc_parser.py
> > +++ b/tools/lib/python/kdoc/kdoc_parser.py
> > @@ -558,6 +558,13 @@ class KernelDoc:
> > self.push_parameter(ln, decl_type, param, dtype,
> > arg, declaration_name)
> >
> > + def get_suggestions_hint(self, decl_name, possible_names):
> > + suggestions = set(name for name in possible_names if decl_name in name)
> > + if not suggestions:
> > + return ""
> > +
> > + return f"(did you mean one of: '{"', '".join(suggestions)}')"
> > +
>
> There is a better way to propose suggestions. See:
> Documentation/sphinx/kernel_include.py
>
> E.g. use something like:
>
> from difflib import get_close_matches
>
> matches = get_close_matches(decl_name, possible_names)
>
> See: https://docs.python.org/3/library/difflib.html#difflib.get_close_matches
>
> If the problem is due to a typo, this will likely return the
> right name.
The checks here specifically were added to deal with situations like
[1] which boils down to:
struct {
/** @flags: good description */
int flags;
/** @substruct: also good */
struct {
/** @mode: bad, wrong, no good */
int mode;
} substruct;
} big_block_o_data;
The docs should say "@substruct.mode" instead of just "@mode", so this
is distant enough from the actual input that difflib would not suggest
it. I could merge suggestions from both difflib and the plain substring
comparison if you'd like me to?
[1] https://patchwork.freedesktop.org/patch/734307/?series=168905&rev=1
>
> Regards,
> Mauro
Thanks, Ryszard
^ permalink raw reply
* Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>
From: Yureka Lilian @ 2026-07-15 13:24 UTC (permalink / raw)
To: Sudeep Holla, Yureka Lilian
Cc: Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
Anshuman Khandual, linux-doc, linux-kernel, linux-arm-kernel
In-Reply-To: <20260713-bulky-thistle-leopard-c66a18@sudeepholla>
On 7/13/26 11:57, Sudeep Holla wrote:
> On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
>> Overriding the idle mechanism might be useful for debugging and performance
>> testing. Add a cmdline parameter for it, similar to the existing idle=
>> parameter already present for the x86 and ppc architectures.
>>
>> It is also useful on platforms where the WFI instruction misbehaves,
>> such as Apple Silicon SoCs. Generally, a misbehaving instruction should
>> be treated as an erratum and patched using the alternatives framework.
>> However, in the Apple Silicon case we need more flexibility because it is
>> difficult to detect whether the erratum applies. For example, Linux VMs
>> inside macOS have the same MIDR and may even seem like they're running
>> in EL2 in the case of NV, but should continue using WFI (it's trapped and
>> handled correctly by the hypervisor there). Thus, we prefer to
>> let the m1n1 bootloader add the idle=nop parameter[1].
>>
>> Link[1]: https://lore.kernel.org/all/99b69262-e54b-424e-baa2-96ef7013b87a@kernel.org/
>> Suggested-by: Will Deacon <will@kernel.org>
>> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
>> ---
>> Changes in v2:
>> - Applied suggestions by Anshuman Khandual (Thanks!)
>> - Link to v1: https://patch.msgid.link/20260705-arm64-idle-param-v1-1-7454249f473f@cyberchaos.dev
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++
>> arch/arm64/kernel/idle.c | 30 +++++++++++++++++++++++--
>> arch/arm64/kernel/idle.h | 13 +++++++++++
>> arch/arm64/lib/delay.c | 5 ++++-
>> 4 files changed, 68 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index b2d7d3540ded..d7f5471edf8f 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2239,6 +2239,29 @@ Kernel parameters
>>
>> idle=nomwait: Disable mwait for CPU C-states
>>
>> + [ARM64,EARLY]
>> + Format: idle=wfi, idle=yield, idle=nop
>> +
>> + idle=wfi: Use the WFI (Wait For Interrupt) hint
>> + instruction in the idle loop. This is the default and
>> + allows the CPU to enter a low-power state until an
>> + interrupt arrives.
> Just curious as when and why one would need to use idle=wfi if that is the
> default behaviour. I am missing the need to have it.
>
>> +
>> + idle=yield: Use the YIELD hint instruction instead of
>> + WFI. CPUs supporting simultaneous multi-threading (SMT),
>> + can continue executing another thread when the current
>> + thread reaches the idle loop. This will make the CPUs
>> + eat more power, but may be useful to get slightly better
>> + performance in some applications, since the CPUs will
>> + not enter a low-power state.
>> +
>> + idle=nop: Do not execute any idle instruction in the
>> + idle loop. This is useful on platforms where WFI
>> + misbehaves, leading to system instability or loss of CPU
>> + state. This will make the CPUs eat more power, but may
>> + give slightly better performance in some applications,
>> + since the CPUs will not enter a low-power state.
>> +
>> idxd.sva= [HW]
>> Format: <bool>
>> Allow force disabling of Shared Virtual Memory (SVA)
>> diff --git a/arch/arm64/kernel/idle.c b/arch/arm64/kernel/idle.c
>> index 05cfb347ec26..f161711a9954 100644
>> --- a/arch/arm64/kernel/idle.c
>> +++ b/arch/arm64/kernel/idle.c
>> @@ -11,6 +11,27 @@
>> #include <asm/cpufeature.h>
>> #include <asm/sysreg.h>
>>
>> +#include "idle.h"
>> +
>> +enum arm64_idle_mode idle = ARM64_IDLE_WFI;
>> +
>> +static int __init setup_idle(char *arg)
>> +{
>> + if (!arg)
>> + return -1;
>> + else if (!strcmp(arg, "wfi"))
>> + idle = ARM64_IDLE_WFI;
>> + else if (!strcmp(arg, "yield"))
>> + idle = ARM64_IDLE_YIELD;
>> + else if (!strcmp(arg, "nop"))
>> + idle = ARM64_IDLE_NOP;
>> + else
>> + return -1;
>> +
>> + return 0;
>> +}
>> +early_param("idle", setup_idle);
>> +
>> /*
>> * cpu_do_idle()
>> *
>> @@ -26,8 +47,13 @@ void __cpuidle cpu_do_idle(void)
>>
>> arm_cpuidle_save_irq_context(&context);
>>
>> - dsb(sy);
>> - wfi();
>> + if (likely(idle == ARM64_IDLE_WFI)) {
>> + dsb(sy);
>> + wfi();
>> + } else if (idle == ARM64_IDLE_YIELD) {
>> + dsb(sy);
>> + asm volatile("yield" ::: "memory");
>> + }
>>
>> arm_cpuidle_restore_irq_context(&context);
>
> If WFI is replaced by NOP or YIELD, do we really need to save/restore
> IRQ context used for pseudo-NMIs which may add some overhead ?
There are optimizations, even in the ARM64_IDLE_WFI case, which could be
done here, such as checking that an interrupt actually occurred before
continuing (and repeating the wfi/yield/nop until this is the case). I
would prefer not to do these optimizations in this patch series, and
leave it as future work, because I don't understand all the implications
at this point. Is this acceptable for you?
Thanks,
— Yureka
^ permalink raw reply
* Re: [PATCH v6 1/5] spi: dt-bindings: Add spi-device-addr peripheral property
From: Nuno Sá @ 2026-07-15 13:29 UTC (permalink / raw)
To: Mark Brown
Cc: Janani Sunil, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Jonathan Corbet, Shuah Khan, Marius Cristea, Marcus Folkesson,
Kent Gustavsson, linux-iio, devicetree, linux-kernel, linux-doc,
Janani Sunil, linux-spi, Kent Gustavsson
In-Reply-To: <1c4af9b1-9937-4cbb-b57f-52ac575b8b89@sirena.org.uk>
On Wed, Jul 15, 2026 at 02:09:19PM +0100, Mark Brown wrote:
> On Wed, Jul 15, 2026 at 01:41:04PM +0200, Janani Sunil wrote:
> > Some SPI devices support sharing a single chip select across multiple
> > physical chips by encoding a device address in the SPI frame itself.
> > Add the generic spi-device-addr property for describing these hardware
> > addresses. The property is placed on the SPI peripheral node and may
> > contain multiple addresses.
>
> This really isn't a generic SPI thing, if nothing else you need *far*
> more information in there about how exactly this would be put onto the
> bus. If it belongs anywhere outside of the specific device's binding it
> feels like it might be regmap.
Just for some context,
For the analog chip, it can share the same CS line with another 3
identical chips. It has two pins that depending on how they are set act
as the device address (so only one replies to a given transfer -
naturally the peripheral driver needs to setup the correct transfer
and that depends on these pins setup and hence dt property).
This property reflects that. Apparently some microchip chips are doing something
very similar so Conor proposed a generic property given that we would have at
least 3 users of it.
- Nuno Sá
^ permalink raw reply
* Re: [PATCH v6 1/5] spi: dt-bindings: Add spi-device-addr peripheral property
From: Mark Brown @ 2026-07-15 13:37 UTC (permalink / raw)
To: Nuno Sá
Cc: Janani Sunil, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Jonathan Corbet, Shuah Khan, Marius Cristea, Marcus Folkesson,
Kent Gustavsson, linux-iio, devicetree, linux-kernel, linux-doc,
Janani Sunil, linux-spi, Kent Gustavsson
In-Reply-To: <lpbqk3wv6emhdtxhnczrgufzzxprcfpfgenfepnmzhzfj3b3ci@rdphuko7ikti>
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
On Wed, Jul 15, 2026 at 03:29:32PM +0200, Nuno Sá wrote:
> On Wed, Jul 15, 2026 at 02:09:19PM +0100, Mark Brown wrote:
> > This really isn't a generic SPI thing, if nothing else you need *far*
> > more information in there about how exactly this would be put onto the
> > bus. If it belongs anywhere outside of the specific device's binding it
> > feels like it might be regmap.
> Just for some context,
> For the analog chip, it can share the same CS line with another 3
> identical chips. It has two pins that depending on how they are set act
> as the device address (so only one replies to a given transfer -
> naturally the peripheral driver needs to setup the correct transfer
> and that depends on these pins setup and hence dt property).
> This property reflects that. Apparently some microchip chips are doing something
> very similar so Conor proposed a generic property given that we would have at
> least 3 users of it.
You still need to work out how the ID appears in the byte stream that
gets sent to/from the device, that's way more information than just a
number and not something the byte stream SPI offers is going to cope
well with.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 00/23] Introduce SCMI Telemetry support
From: Subrahmanya Lingappa @ 2026-07-15 13:45 UTC (permalink / raw)
To: Cristian Marussi
Cc: arm-scmi, linux-arm-kernel, linux-kernel, linux-doc, sudeep.holla,
james.quinlan, f.fainelli, vincent.guittot, etienne.carriere,
peng.fan, michal.simek, d-gole, jic23, elif.topuz, lukasz.luba,
philip.radford, brauner, david, souvik.chakravarty, leitao, kas,
puranjay, usama.arif, kernel-team
In-Reply-To: <alCuJsOgh1ioFHAL@pluto>
Hi David, Cristian,
Thanks, both. Fair points.
On Fri, Jul 10, 2026 at 2:02 PM Cristian Marussi
<cristian.marussi@arm.com> wrote:
>
> On Tue, Jul 07, 2026 at 12:01:37PM +0530, Subrahmanya Lingappa wrote:
> > Hi Cristian,
>
> Hi,
>
> I will add a few considerations here aside the main points highlighed
> already by David in this thread.
>
> >
> > Thanks for posting this. I think the direction of not forcing these
> > Telemetry Data Events into hwmon/IIO/perf prematurely is the right one.
> > The cover letter explains the core problem well: most DE IDs are
> > platform-defined, and without external metadata the kernel cannot reliably
> > know whether a DE is a thermal sensor, a performance counter, a power value,
> > or something entirely platform-specific.
> >
> > That said, I think the current layering is still too SCMI-shaped for the
> > ABI it is trying to introduce.
> >
>
> well... "Introduce SCMI Telemetry" seems a pretty much telling $SUBJECT :P
>
> > The thing being exposed here is not only "SCMI Telemetry"; it is a more
> > general kernel concept of telemetry:
> >
> > - enumerate provider-specific data/event descriptors
> > - expose capabilities, units, data format and topology/grouping metadata
> > - configure collection rate and collection mode where supported
> > - collect samples with timestamp/freshness/validity information
> > - track generation/state changes
> > - optionally expose provider-private raw backing storage for debugging
> >
> > SCMI is one provider of that model. It happens to transport the data through
> > SCMI v4.0 concepts such as DEs, groups, SHMTIs and TDCF. But another firmware
> > or control-plane specification could show up later with the same broad
> > telemetry model and a different wire format. Call it XXMI or YYMI: the
> > protocol mechanics would differ, but the kernel consumers should not have to
> > learn a new in-kernel and userspace ABI for each one.
> >
>
> So, in the early episodes of this Telemetry 'saga' when it still was an
> RFC [1] in which I was exploring/experimenting/evaluating different approaches
> I DID mention that one possible evolutions of whatever interface would have been
> used (SysFS vs chardev vs FileSystem) could have been:
>
> "D. generalize enough one of the above choices to make it abstract enough
> that other non-SCMI based telemetry can plug into some sort of geenric
> Telemetry subsystem"
>
> ...BUT the reality check that immediately stopped this possibility onto
> his tracks for me was the fact that at that time, like now, there was/is
> ONLY the SCMI protocol acting as a possible Telemetry provider so that would
> have meant:
>
> 1. limited real use case examples to use to build a common Telemetry abstraction
> resulting most probably in a 'generic' common framework heavily
> biased toward SCMI mechanisms...for the simple fact that only SCMI really
> existed that provided such broad range of generic telemetry data....
>
> 2. sure rejection from upstream, having created a supposedly generic common
> framework, sadly used by....just ONLY one user
>
> These concerns came on top of the basic main fact that, as David pointed out,
> a fully generic and common abstraction of Telemetry concepts is hard...
>
> ...it definitely seems easy at first by looking at some basic simple
> common ideas, but it quickly becomes very challenging to represent in a
> common way very speficic bits like, as an example, topology, grouping
> etc etc ...and again especially when you have ONLY one user of this new
> abstraction to look at for inspiration ...
>
> > The common ABI should therefore avoid treating the DE numeric namespace or
> > the wire/storage format as the abstraction. The useful common contract is
> > closer to:
> >
> > - what is being measured: component/type/instance/name;
> > - how to interpret it: unit, exponent/rate unit, data width and signedness;
> > - how it behaves: instantaneous, accumulating, average, state/counter, etc.;
> > - how it is controlled: individual event vs group-wide collection;
> > - how fresh it is: timestamp, sequence/generation and validity/error flags.
> >
> > So I would strongly consider inserting a generic telemetry layer above SCMI,
> > with SCMI registering as a telemetry provider rather than owning the stable
> > userspace ABI directly.
> >
> > Roughly:
> >
> > drivers/telemetry/
> > provider registration
> > descriptor/sample/config abstractions
> > generation tracking and poll support
> > common userspace ABI
> >
> > drivers/firmware/arm_scmi/telemetry.c
> > SCMI protocol implementation
> > TDCF/SHMTI/notification parsing
> > translation into generic telemetry descriptors/samples
> >
> > optional provider-private raw/debug path
> > SCMI SHMTI mmap or dumps, if kept, behind explicit privilege/debug
> > policy rather than as the baseline telemetry ABI
> >
> > With that shape, future in-kernel consumers could bind to generic telemetry
> > objects and capabilities instead of SCMI internals. Architected/well-known
> > DEs could later grow adapters into hwmon/IIO/perf where the semantics are
> > clear, while platform-specific DEs remain available through the generic
> > telemetry interface plus userspace metadata.
> >
> > This would also help avoid making the SCMI protocol's internal resource
> > storage part of the ABI. Right now the public protocol header exposes
> > structures such as scmi_telemetry_res_info, scmi_telemetry_group and
>
> Well here you are mentioning the SCMI internal API as exposed by the SCMI
> core in include/linux/scmi_protocol.h and used by SCMI drivers to build
> on top of the common protocol layer...of course it is SCMI specific,
> always will be, even when/if a common Telemetry framework would exist.
>
> > scmi_telemetry_de, and the chardev indexes those objects directly. That feels
> > too tightly coupled for something that may need more consumers later. I would
> > prefer copy-out or iterator-style provider ops instead, for example:
> >
> > info_get()
> > de_count_get()
> > de_info_get()
> > group_info_get()
> > intervals_get()
> > collection_set()
> > collection_get()
> > sample_read()
> > reset()
> >
> > where the backing arrays, xarrays, lazy enumeration, SHMTI mappings and TDCF
> > parsing remain private to the SCMI provider.
>
> I could agree on this...IF any of this would have a chance to exist now
> with the current existing Telemetry providers...thing that seems not
> plausible for the reasons above....
>
> >
> > The sample side probably needs an explicit common result contract too. A
> > sample is not only an integer value: it may have optional timestamping,
> > provider data width, stale/not-yet-valid state, partial collection failures,
> > hardware-fault indications, and a sequence/generation value that lets
> > userspace detect races against reconfiguration or shared-memory updates. Those
> > details can still be backed by SCMI-specific status codes and TDCF parsing
> > internally, but I think the stable ABI should expose them in provider-neutral
> > terms.
>
> Yes some of these are theoretically possible, but NOT really in the only
> example we have so far that is SCMI....
>
> >
> > I would also be careful about freezing the raw SHMTI mmap part as a baseline
> > ABI. It is useful for bring-up and high-performance tooling, but it exposes
> > firmware-owned shared memory layout and TDCF parsing rules directly to
> > userspace. If this stays, I think it should be clearly separated as a
> > privileged/debug/raw provider facility, with a precise mmap contract:
> >
> > - required mmap length
> > - vm_pgoff semantics
> > - page alignment
> > - VMA flags
> > - cache/coherency expectations
> > - lifetime across reset/remove/reprobe
> > - required capability, if any
>
> I would also prefer to expose only kernel mediated Telemetry data to
> avoid fragmentation (even within the same protocol when implemented by
> different vendors...), BUT RAW access I am afraid is inevitable to be
> able to write high-perf tools, and those will have necessarily to be
> protocol/backend specific...
>
> ...which leads straight to the other point raised by David...
>
> ...Is really a common Telemetry UAPI needed ?
>
> ...if anyway multiple protocols would dictate multiple custom tools
> probably not...
>
> > Even outside the raw mmap case, telemetry can be a sensitive high-rate view
> > of system behavior. The ABI should make access policy explicit: who can
> > enumerate, who can read, who can change collection state, and whether
> > production systems can restrict sampling granularity or intervals
> > independently of what firmware advertises.
> >
>
> Yes this has defintely to be documented better...but..
>
> ..this is something again very much protocol specific, that evidentiates
> once more that a common ABI to rule them all is not probably the way...
>
> ...in SCMI the platform firmware is the ultimate arbiter, it is in charge
> of any kind of policying...it can cope even with the most unreasonable
> asks coming from the agents, even come from root privileged users...
>
> ...simply because those requests will get denied OR silently ignored...
>
> ...in the case of SCMI Telemetry, as an example, it is up to the server expose
> to the Linux Agent ONLY what it deems to be safe enough to be shared with normal
> world entities without the risk of enabling side channel attacks...
>
> IOW, in the SCMI world, in any protocol, the agents see and live in an
> illusion that is created and enforced by the SCMI server, if you are
> switching your point of view and start considering how to enforce policies
> around SCMI resources at the agent level ("...only root will be able to do
> that"), you are already doing it wrong...
>
> Can this view of the platform be absracted, Telemetry-wise, in a common
> interface across any other protocol and any other arch ?
>
> It seems to me, again, very unlikely...
>
> > For the stable telemetry ABI, I would start smaller: descriptor enumeration,
> > sample reads with validity metadata, optional group-aware configuration, and a
> > generation counter/poll mechanism so userspace can detect reconfiguration or
> > partial re-enumeration races.
> >
> > One other point related to this layering: configuration appears to be global
> > to the SCMI instance. Any process opening /dev/scmi/tlm_N can change
> > collection mode, sampling interval, DE enablement and timestamp state for
> > other users. That may be OK, but it should be an explicit policy decision.
>
> Based on the SCMI architecture and the SCMI implementation in Linux, the
> only boundary that you can use to identify a 'user' is am SCMI instance
> (i.e. one /dev/scmi/tlm_<N>) because that is what the server(s) on the other
> side can identify as a distinct agent and that it can fed with a well defined
> set of resources at enumeration time...especially in the case of Telemetry
> it seems dificult to be able to partition resources at the agent side...
>
> As it was with the defunct Filesyste approach, I would NOT in general
> enfore any policy on configuration...last config request will win PLUS
> a generation counter to spot unexpected reconfig happening in background...
>
> If you are using 2 tools or daemons to configure telemetry on the same
> system in a conflicting way, it is NONE of kernel businness, you have a
> misconfigured platform..
>
> Last but NOT least, I think that maybe a Telemetry framework subsystem
> could be instead useful for future possible in-kernel users of Telemetry
> (you may have mentioned that too..) ... should someone decide to use this
> type of data in-kernel, it would certainly be useful to a have common
> in-kernel API to consume these data no matter which is the provider from
> which that data is collected...
>
> ...BUT, again, in this case we do NOT even have a single user as of now
> to model this intefrcae against, since we are currently NOT using SCMI
> Telemetry for that...so it is seems even more a remote/impossible thing
> to get something like this upstream for now...
>
> Thanks,
> Cristian
>
> [1]: https://lore.kernel.org/arm-scmi/20250620192813.2463367-1-cristian.marussi@arm.com/
>
I agree that asking this series to grow a generic telemetry subsystem now is
too much. With only SCMI in-tree, it would be easy to create a "generic"
interface that is really just SCMI with different names. I also agree that raw
SHMTI is not just a debug path if the expected users are high-rate tooling.
So let me narrow the ask.
I am not asking for `drivers/telemetry/` in v6. I am asking that the SCMI
chardev/UAPI not be tied too closely to the current SCMI core storage layout.
In particular, I think v6 should try to:
- copy descriptor/config/sample data through fixed and extensible UAPI
structs, not structs mirroring SCMI internal objects;
- treat DE IDs, group IDs and SHMTI IDs as protocol identifiers, not as
implicit indexes into kernel arrays;
- keep the TDCF/SHMTI parsing and SCMI command handling behind small
internal ops used by the chardev side;
- document the config model explicitly: per SCMI instance, last writer wins,
generation changes tell userspace that state changed;
- document the mmap contract: length, offsets, cache attributes, lifetime,
and reset/reconfiguration behaviour.
That keeps the ABI explicitly SCMI-specific and does not make SHMTI second
class. It just avoids baking too much of today's SCMI implementation shape into
the userspace contract.
Cristian's point about policy being enforced by the SCMI server also makes
sense to me. I am not suggesting Linux should second-guess that partitioning.
Documenting the Linux-visible semantics is enough: what is shared per SCMI
instance, what userspace may race with, and how generation/poll reports that.
So I would reduce my earlier suggestion to: no generic framework required now,
but please keep a clean provider/backend boundary inside the driver and leave
some UAPI growth room. That should make a later common layer possible, if a
second provider or an in-kernel user ever justifies it, without forcing this
series to solve that problem today.
Thanks,
Subrahmanya
^ permalink raw reply
* [PATCH] overlayfs.rst: remove mention of workdir needing to be empty
From: Jesse Van Gavere via B4 Relay @ 2026-07-15 13:52 UTC (permalink / raw)
To: Miklos Szeredi, Amir Goldstein, Jonathan Corbet, Shuah Khan
Cc: linux-unionfs, linux-doc, linux-kernel, Jesse Van Gavere
From: Jesse Van Gavere <jesse.vangavere@teledyne.com>
This requirement has not been true since v4.8 when automatic cleanup was
added in commit eea2fb4851e9 ("ovl: proper cleanup of workdir")
Signed-off-by: Jesse Van Gavere <jesse.vangavere@teledyne.com>
---
Documentation/filesystems/overlayfs.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
index eb846518e6ac..7e28bfb4a99e 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -123,8 +123,8 @@ At mount time, the two directories given as mount options "lowerdir" and
mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
workdir=/work /merged
-The "workdir" needs to be an empty directory on the same filesystem
-as upperdir.
+The "workdir" will be cleaned up at mount time and needs to be on the same
+filesystem as upperdir.
Then whenever a lookup is requested in such a merged directory, the
lookup is performed in each actual directory and the combined result
---
base-commit: 58717b2a1365d06c8c64b72aa948541b53fe31eb
change-id: 20260715-overlayfs-rst-update-750d58792f79
Best regards,
--
Jesse Van Gavere <jesse.vangavere@teledyne.com>
^ permalink raw reply related
* Re: [PATCH v2] scripts/kernel-doc: Suggest possible names for excess descriptions
From: Mauro Carvalho Chehab @ 2026-07-15 13:52 UTC (permalink / raw)
To: Knop, Ryszard
Cc: intel-xe@lists.freedesktop.org, Lin, Shuicheng,
linux-doc@vger.kernel.org, rdunlap@infradead.org,
jani.nikula@linux.intel.com, linux-kernel@vger.kernel.org
In-Reply-To: <80ccd6405e31b1200a391b2755780b7676597c74.camel@intel.com>
On Wed, 15 Jul 2026 13:21:27 +0000
"Knop, Ryszard" <ryszard.knop@intel.com> wrote:
> On Wed, 2026-07-15 at 14:42 +0200, Mauro Carvalho Chehab wrote:
> > On Wed, 15 Jul 2026 13:17:26 +0200
> > Ryszard Knop <ryszard.knop@intel.com> wrote:
> >
> > > Since check_sections() now warns if a documentation tag member name is
> > > the same as defined in the struct, we can suggest names the checker
> > > knows, so that it's more obvious how to deal with the warning.
> > >
> > > v2 (rdunlap):
> > > - Strip whitespace from warnings, nicer when the hint is empty
> > >
> > > Signed-off-by: Ryszard Knop <ryszard.knop@intel.com>
> > > ---
> > > tools/lib/python/kdoc/kdoc_parser.py | 13 +++++++++++--
> > > 1 file changed, 11 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/tools/lib/python/kdoc/kdoc_parser.py b/tools/lib/python/kdoc/kdoc_parser.py
> > > index 2dedda215c22..a22c3e3182f0 100644
> > > --- a/tools/lib/python/kdoc/kdoc_parser.py
> > > +++ b/tools/lib/python/kdoc/kdoc_parser.py
> > > @@ -558,6 +558,13 @@ class KernelDoc:
> > > self.push_parameter(ln, decl_type, param, dtype,
> > > arg, declaration_name)
> > >
> > > + def get_suggestions_hint(self, decl_name, possible_names):
> > > + suggestions = set(name for name in possible_names if decl_name in name)
> > > + if not suggestions:
> > > + return ""
> > > +
> > > + return f"(did you mean one of: '{"', '".join(suggestions)}')"
> > > +
> >
> > There is a better way to propose suggestions. See:
> > Documentation/sphinx/kernel_include.py
> >
> > E.g. use something like:
> >
> > from difflib import get_close_matches
> >
> > matches = get_close_matches(decl_name, possible_names)
> >
> > See: https://docs.python.org/3/library/difflib.html#difflib.get_close_matches
> >
> > If the problem is due to a typo, this will likely return the
> > right name.
>
> The checks here specifically were added to deal with situations like
> [1] which boils down to:
>
> struct {
> /** @flags: good description */
> int flags;
>
> /** @substruct: also good */
> struct {
> /** @mode: bad, wrong, no good */
> int mode;
> } substruct;
> } big_block_o_data;
>
> The docs should say "@substruct.mode" instead of just "@mode", so this
> is distant enough from the actual input that difflib would not suggest
> it.
Ok, but there should be cases like, instead of "mode", someone writes
for instance "modes".
> I could merge suggestions from both difflib and the plain substring
> comparison if you'd like me to?
Makes sense to me. Just ensure that they aren't duplicated.
>
> [1] https://patchwork.freedesktop.org/patch/734307/?series=168905&rev=1
>
> >
> > Regards,
> > Mauro
>
> Thanks, Ryszard
--
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH] arm64: errata: Mitigate AmpereOne erratum AC03_CPU_57 and AC04_CPU_29
From: D Scott Phillips @ 2026-07-15 13:55 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, Catalin Marinas, Will Deacon, Jonathan Corbet,
Shuah Khan, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Mark Rutland, Zeng Heng, Wei Xu, Vladimir Murzin,
Lucas Wei, Kuninori Morimoto, Sascha Bischoff, Yicong Yang,
Yeoreum Yun, linux-arm-kernel, linux-doc, linux-kernel, kvmarm
In-Reply-To: <86a4rso2qs.wl-maz@kernel.org>
Marc Zyngier <maz@kernel.org> writes:
> On Wed, 15 Jul 2026 00:06:00 +0100,
> D Scott Phillips <scott@os.amperecomputing.com> wrote:
>>
>> > OK, that's pretty good news. Can I safely assume that your HW doesn't
>> > support VLPIs/VSGIs in any form (no GICv4+)?
>>
>> AmpereOne AC04 does have gicv4.1 with vlpis/vsgis. Those take a
>> different enough path in the core that a deactivation of a pending
>> vlpi/vsgi won't cause the issue. The wording about "physical interrupt"
>> is meant to exclude vlpis/vsgis, sorry that it didn't come out clearly.
>
> Given that the write-up didn't mention direct injection at all, it
> wasn't totally obvious whether this was taken into account or not.
> Might be worth adding to the errata document for clarity.
Yep, makes sense. I'll work on getting that clarification added.
^ permalink raw reply
* Re: [RFC v2 0/3] mm/mglru: proactive aging via memory.aging
From: Johannes Weiner @ 2026-07-15 14:00 UTC (permalink / raw)
To: Zicheng Wang
Cc: akpm, yuanchu, tj, mkoutny, corbet, kasong, qi.zheng,
shakeel.butt, baohua, axelrasmussen, weixugc, david, ljs, liam,
vbabka, rppt, surenb, mhocko, roman.gushchin, muchun.song,
cgroups, linux-mm, linux-kernel, linux-doc, willy, denghaojie,
baoquan.he, kaleshsingh, tjmercier, tao.wangtao, zhangji1,
wangzhen5
In-Reply-To: <20260714121529.2237261-1-wangzicheng@honor.com>
On Tue, Jul 14, 2026 at 08:15:26PM +0800, Zicheng Wang wrote:
> MGLRU inverts the reclaim order when anonymous memory is faulted in
> bulk: anonymous pages sit in the young generations while file pages
> sit in the oldest two, so reclaim evicts hot file pages before cold
> anonymous pages.
An aging inversion in the reclaim algorithm seems like an exceedingly
poor justification for a userspace interface to work around them.
^ permalink raw reply
* Re: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
From: kernel test robot @ 2026-07-15 14:01 UTC (permalink / raw)
To: Simon Schippers
Cc: oe-lkp, lkp, Brett Sheffield, netdev, linux-kernel, ltp,
Willem de Bruijn, Jason Wang, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Michael S . Tsirkin, Simon Horman,
Jonathan Corbet, Shuah Khan, Andrew Lunn, Tim Gebauer, linux-doc,
Simon Schippers, oliver.sang
In-Reply-To: <20260709095511.168235-1-simon.schippers@tu-dortmund.de>
Hello,
kernel test robot noticed "ltp.ioctl03.fail" on:
commit: 09154ff2072e36b86ba2d92d436b7f27df153ed1 ("[PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE")
url: https://github.com/intel-lab-lkp/linux/commits/Simon-Schippers/tun-tap-vhost-net-make-qdisc-backpressure-opt-in-via-IFF_BACKPRESSURE/20260709-181234
base: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git fabb881df322da25442f98d23f5fa371e3c78ec4
patch link: https://lore.kernel.org/all/20260709095511.168235-1-simon.schippers@tu-dortmund.de/
patch subject: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
in testcase: ltp
version:
with following parameters:
disk: 1HDD
fs: ext4
test: syscalls-03
config: x86_64-rhel-9.4-ltp
compiler: gcc-14
test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (Ivy Bridge) with 8G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202607151550.5d829a99-lkp@intel.com
....
^[[1;37mgetuid03: ^[[0m^[[1;32mpass^[[0m (0.028s)
^[[1;37mioctl03: ^[[0m^[[1;31mfail^[[0m (0.047s) <-----
^[[1;37mioctl05: ^[[0m^[[1;32mpass^[[0m (0.471s)
....
Execution time: 3m 35s
Disconnecting from SUT: default
Target information
──────────────────
Kernel: Linux 7.2.0-rc1+ #1 SMP PREEMPT_DYNAMIC Sun Jul 12 07:25:38 CST 2026
Cmdline: ip=::::lkp-ivb-d04::dhcp
root=/dev/ram0
RESULT_ROOT=/result/ltp/1HDD-ext4-syscalls-03/lkp-ivb-d04/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-ltp/gcc-14/09154ff2072e36b86ba2d92d436b7f27df153ed1/0
BOOT_IMAGE=/pkg/linux/x86_64-rhel-9.4-ltp/gcc-14/09154ff2072e36b86ba2d92d436b7f27df153ed1/vmlinuz-7.2.0-rc1+
branch=linux-devel/devel-hourly-20260709-190759
job=/lkp/jobs/scheduled/lkp-ivb-d04/ltp-1HDD-ext4-syscalls-03-debian-13-x86_64-20250902.cgz-09154ff2072e-20260712-19649-tc8bu6-0.yaml
user=lkp
ARCH=x86_64
kconfig=x86_64-rhel-9.4-ltp
commit=09154ff2072e36b86ba2d92d436b7f27df153ed1
intremap=posted_msi
max_uptime=7200
LKP_SERVER=internal-lkp-server
nokaslr
selinux=0
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
console=tty0
earlyprintk=ttyS0,115200
console=ttyS0,115200
vga=normal
rw
keep_initrds=/osimage/pkg/debian-13-x86_64-20250902.cgz/ltp-x86_64-ed2758122-1_20260711.cgz
acpi_rsdp=0x000f0490
Machine: unknown
Arch: x86_64
RAM: 6895596 kB
Swap: 0 kB
Distro: debian 13
────────────────────────
TEST SUMMARY
────────────────────────
Suite: syscalls-03
Runtime: 3m 24s
Runs: 183
Results:
Passed: 2144
Failed: 1
Broken: 0
Skipped: 222
Warnings: 0
^[[1;31mFailures:^[[0m
• ioctl03
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260715/202607151550.5d829a99-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2] PCI: rcar-gen4: Isolate driver to ARM64
From: Manivannan Sadhasivam @ 2026-07-15 14:03 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Marek Vasut, linux-pci, kernel test robot,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Marc Zyngier, Rob Herring, Yoshihiro Shimoda,
devicetree, linux-arm-kernel, linux-doc, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260714211030.GA1412991@bhelgaas>
On Tue, Jul 14, 2026 at 04:10:30PM -0500, Bjorn Helgaas wrote:
> On Tue, Jul 14, 2026 at 03:19:27PM +0200, Marek Vasut wrote:
> > The driver includes linux/irqchip/arm-gic-v3.h which pulls in headers
> > which are available only on ARM and ARM64, on other architectures the
> > headers are not present and the driver fails to build. This driver is
> > used only on ARM64 hardware, isolate its build only to ARM64 to avoid
> > build failures on other architectures.
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> Mani, I assume you'll squash this into 89bded511a66 ("PCI: rcar-gen4:
> Configure AXIINTC if iMSI-RX is not used") so it's connected to the
> addition of the linux/irqchip/arm-gic-v3.h include and there's no
> bisection hole?
>
Yes, squashed now!
- Mani
> > ---
> > Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Conor Dooley <conor+dt@kernel.org>
> > Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> > Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > Cc: Manivannan Sadhasivam <mani@kernel.org>
> > Cc: Marc Zyngier <maz@kernel.org>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linux-doc@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: linux-pci@vger.kernel.org
> > Cc: linux-renesas-soc@vger.kernel.org
> > ---
> > V2: This is a rework of PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro
> > which isolates the driver build to ARM64 via Kconfig instead:
> > https://lore.kernel.org/linux-pci/CAMuHMdVvWE7YZgKvreSn_vJLOVD4eMmn3TCGOyqSXksqjBCwvg@mail.gmail.com/
> > https://lore.kernel.org/linux-pci/20260714110041.GA1349622@bhelgaas/
> > ---
> > drivers/pci/controller/dwc/Kconfig | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
> > index 49a7a2c50ca15..3260d916110b2 100644
> > --- a/drivers/pci/controller/dwc/Kconfig
> > +++ b/drivers/pci/controller/dwc/Kconfig
> > @@ -346,7 +346,7 @@ config PCIE_RCAR_GEN4
> >
> > config PCIE_RCAR_GEN4_HOST
> > tristate "Renesas R-Car Gen4 PCIe controller (host mode)"
> > - depends on ARCH_RENESAS || COMPILE_TEST
> > + depends on ARM64 && (ARCH_RENESAS || COMPILE_TEST)
> > depends on PCI_MSI
> > select PCIE_DW_HOST
> > select PCIE_RCAR_GEN4
> > @@ -357,7 +357,7 @@ config PCIE_RCAR_GEN4_HOST
> >
> > config PCIE_RCAR_GEN4_EP
> > tristate "Renesas R-Car Gen4 PCIe controller (endpoint mode)"
> > - depends on ARCH_RENESAS || COMPILE_TEST
> > + depends on ARM64 && (ARCH_RENESAS || COMPILE_TEST)
> > depends on PCI_ENDPOINT
> > select PCIE_DW_EP
> > select PCIE_RCAR_GEN4
> > --
> > 2.53.0
> >
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2] PCI: rcar-gen4: Isolate driver to ARM64
From: Marek Vasut @ 2026-07-15 14:10 UTC (permalink / raw)
To: Manivannan Sadhasivam, Bjorn Helgaas
Cc: Marek Vasut, linux-pci, kernel test robot,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Marc Zyngier, Rob Herring, Yoshihiro Shimoda,
devicetree, linux-arm-kernel, linux-doc, linux-kernel,
linux-renesas-soc
In-Reply-To: <jipy4hvsmksv6fy352y23sjdnutpkqoi2577qp5vymqqggiscz@cnx2vijnhvh4>
On 7/15/26 4:03 PM, Manivannan Sadhasivam wrote:
> On Tue, Jul 14, 2026 at 04:10:30PM -0500, Bjorn Helgaas wrote:
>> On Tue, Jul 14, 2026 at 03:19:27PM +0200, Marek Vasut wrote:
>>> The driver includes linux/irqchip/arm-gic-v3.h which pulls in headers
>>> which are available only on ARM and ARM64, on other architectures the
>>> headers are not present and the driver fails to build. This driver is
>>> used only on ARM64 hardware, isolate its build only to ARM64 to avoid
>>> build failures on other architectures.
>>>
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/
>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>>
>> Mani, I assume you'll squash this into 89bded511a66 ("PCI: rcar-gen4:
>> Configure AXIINTC if iMSI-RX is not used") so it's connected to the
>> addition of the linux/irqchip/arm-gic-v3.h include and there's no
>> bisection hole?
>>
>
> Yes, squashed now!
Thank you both.
^ permalink raw reply
* Re: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
From: Simon Schippers @ 2026-07-15 14:32 UTC (permalink / raw)
To: kernel test robot
Cc: oe-lkp, lkp, Brett Sheffield, netdev, linux-kernel, ltp,
Willem de Bruijn, Jason Wang, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Michael S . Tsirkin, Simon Horman,
Jonathan Corbet, Shuah Khan, Andrew Lunn, Tim Gebauer, linux-doc
In-Reply-To: <202607151550.5d829a99-lkp@intel.com>
On 7/15/26 16:01, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed "ltp.ioctl03.fail" on:
ioctl03.c does not know about IFF_BACKPRESSURE which is introduced here,
consequently it fails.
See [1] where it compares TUN features with known_flags.
Thanks.
[1] Link: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioctl/ioctl03.c#L82
>
> commit: 09154ff2072e36b86ba2d92d436b7f27df153ed1 ("[PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE")
> url: https://github.com/intel-lab-lkp/linux/commits/Simon-Schippers/tun-tap-vhost-net-make-qdisc-backpressure-opt-in-via-IFF_BACKPRESSURE/20260709-181234
> base: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git fabb881df322da25442f98d23f5fa371e3c78ec4
> patch link: https://lore.kernel.org/all/20260709095511.168235-1-simon.schippers@tu-dortmund.de/
> patch subject: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
>
> in testcase: ltp
> version:
> with following parameters:
>
> disk: 1HDD
> fs: ext4
> test: syscalls-03
>
>
>
> config: x86_64-rhel-9.4-ltp
> compiler: gcc-14
> test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (Ivy Bridge) with 8G memory
>
> (please refer to attached dmesg/kmsg for entire log/backtrace)
>
>
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202607151550.5d829a99-lkp@intel.com
>
>
> ....
>
> ^[[1;37mgetuid03: ^[[0m^[[1;32mpass^[[0m (0.028s)
> ^[[1;37mioctl03: ^[[0m^[[1;31mfail^[[0m (0.047s) <-----
> ^[[1;37mioctl05: ^[[0m^[[1;32mpass^[[0m (0.471s)
>
> ....
>
> Execution time: 3m 35s
>
> Disconnecting from SUT: default
>
> Target information
> ──────────────────
> Kernel: Linux 7.2.0-rc1+ #1 SMP PREEMPT_DYNAMIC Sun Jul 12 07:25:38 CST 2026
> Cmdline: ip=::::lkp-ivb-d04::dhcp
> root=/dev/ram0
> RESULT_ROOT=/result/ltp/1HDD-ext4-syscalls-03/lkp-ivb-d04/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-ltp/gcc-14/09154ff2072e36b86ba2d92d436b7f27df153ed1/0
> BOOT_IMAGE=/pkg/linux/x86_64-rhel-9.4-ltp/gcc-14/09154ff2072e36b86ba2d92d436b7f27df153ed1/vmlinuz-7.2.0-rc1+
> branch=linux-devel/devel-hourly-20260709-190759
> job=/lkp/jobs/scheduled/lkp-ivb-d04/ltp-1HDD-ext4-syscalls-03-debian-13-x86_64-20250902.cgz-09154ff2072e-20260712-19649-tc8bu6-0.yaml
> user=lkp
> ARCH=x86_64
> kconfig=x86_64-rhel-9.4-ltp
> commit=09154ff2072e36b86ba2d92d436b7f27df153ed1
> intremap=posted_msi
> max_uptime=7200
> LKP_SERVER=internal-lkp-server
> nokaslr
> selinux=0
> debug
> apic=debug
> sysrq_always_enabled
> rcupdate.rcu_cpu_stall_timeout=100
> net.ifnames=0
> printk.devkmsg=on
> panic=-1
> softlockup_panic=1
> nmi_watchdog=panic
> oops=panic
> load_ramdisk=2
> prompt_ramdisk=0
> drbd.minor_count=8
> systemd.log_level=err
> ignore_loglevel
> console=tty0
> earlyprintk=ttyS0,115200
> console=ttyS0,115200
> vga=normal
> rw
> keep_initrds=/osimage/pkg/debian-13-x86_64-20250902.cgz/ltp-x86_64-ed2758122-1_20260711.cgz
> acpi_rsdp=0x000f0490
> Machine: unknown
> Arch: x86_64
> RAM: 6895596 kB
> Swap: 0 kB
> Distro: debian 13
>
> ────────────────────────
> TEST SUMMARY
> ────────────────────────
> Suite: syscalls-03
> Runtime: 3m 24s
> Runs: 183
>
> Results:
> Passed: 2144
> Failed: 1
> Broken: 0
> Skipped: 222
> Warnings: 0
>
> ^[[1;31mFailures:^[[0m
> • ioctl03
>
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20260715/202607151550.5d829a99-lkp@intel.com
>
>
>
^ permalink raw reply
* Re: [PATCH v2 0/4] mm/hmm: Clarify notifier retry state and scope HMM timeouts
From: Stanislav Kinsburskii @ 2026-07-15 14:42 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: airlied, akhilesh, akpm, corbet, dakr, jgg, kees, leon, liam,
lizhi.hou, ljs, lyude, maarten.lankhorst, mamin506, mhocko,
mripard, nouveau, ogabbay, oleg, rppt, shuah, simona, skhan,
surenb, tzimmermann, vbabka, dri-devel, linux-mm, linux-doc,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <4300f09b-8f93-4605-b072-7c09a82cb16e@kernel.org>
On Wed, Jul 15, 2026 at 02:41:43PM +0200, David Hildenbrand (Arm) wrote:
> On 7/15/26 00:21, Stanislav Kinsburskii wrote:
> > This small fixup series applies on top of:
> >
> > [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
> >
> > The first patch updates the HMM documentation example to make the
> > mmu_interval_read_retry() state explicit: callers should use the notifier and
> > notifier_seq stored in the same hmm_range that was passed to
> > hmm_range_fault_unlocked_timeout().
> >
> > The remaining patches adjust nouveau, amdxdna, and drm_gpusvm users so the
> > timeout passed to hmm_range_fault_unlocked_timeout() is treated as a relative
> > HMM retry budget. These callers no longer keep an absolute deadline around
> > their outer driver retry loops or pass a computed remaining time into HMM.
> >
> > This keeps the timeout scoped to HMM's internal mmu-notifier retry handling. If
> > HMM succeeds and the driver later observes an invalidation through
> > mmu_interval_read_retry(), the driver retries the operation with a fresh HMM
> > retry budget.
> >
> > Changes in v2:
> > - Kept the nouveau outer absolute timeout around the
> > mmu_interval_read_retry() loop. hmm_range_fault_unlocked_timeout() only
> > bounds HMM’s internal retries, while nouveau faults are handled from a GPU
> > fault worker, so userspace fatal signals cannot break an endless stream of
> > invalidations there.
> > - Updated nouveau to use time_after_eq() before calling HMM, so the remaining
> > timeout passed to hmm_range_fault_unlocked_timeout() is always positive and
> > never 0, which would mean retry indefinitely.
> > - Updated the nouveau fixup commit message to explain the worker-thread
> > timeout issue and the time_after_eq() boundary behavior.
> > - Fixed the amdxdna fixup commit message. It now describes
> > aie2_populate_range() correctly instead of carrying stale nouveau prose,
> > and notes that command submission still keeps its broader timeout while HMM
> > gets a fresh relative retry budget.
> >
> >
> > ---
> >
> > Stanislav Kinsburskii (4):
> > fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support
> > fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults
> > fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population
> > fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults
>
> Why a fixup series instead of properly resending the full thing?
>
The goal was to get a Sashiko review, and v8 has already been applied to
both `mm-new` and `linux-next`.
You can find more details here:
https://sashiko.dev/#/message/alaWmUEeIBeSkmO0%40skinsburskii
Thanks, Stanislav
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [PATCH v21 06/14] dmaengine: qcom: bam_dma: add support for BAM locking
From: Bartosz Golaszewski @ 2026-07-15 14:43 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Bjorn Andersson, Peter Ujfalusi,
Michal Simek, Frank Li, Andy Gross, Neil Armstrong, dmaengine,
linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <alYGGu7_3G6mJAzQ@linaro.org>
On Tue, 14 Jul 2026 11:49:14 +0200, Stephan Gerhold
<stephan.gerhold@linaro.org> said:
> On Mon, Jul 13, 2026 at 03:01:07PM +0200, Bartosz Golaszewski wrote:
>> Add support for BAM pipe locking. To that end: when starting DMA on an RX
>> channel - prepend the existing queue of issued descriptors with an
>> additional "dummy" command descriptor with the LOCK bit set. Once the
>> transaction is done (no more issued descriptors), issue one more dummy
>> descriptor with the UNLOCK bit.
>>
>> We *must* wait until the transaction is signalled as done because we
>> must not perform any writes into config registers while the engine is
>> busy.
>>
>> The dummy writes must be issued into a scratchpad register of the client
>> so provide a mechanism to communicate the right address via descriptor
>> metadata.
>>
>> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
> Thanks for the fixes. The lock/unlock sequence looks good to me now,
> I commented on a couple of minor things below that would be good to fix
> (some of them are also reported by Sashiko).
>
Thanks.
>> ---
>> drivers/dma/qcom/bam_dma.c | 191 +++++++++++++++++++++++++++++++++++++--
>> include/linux/dma/qcom_bam_dma.h | 14 +++
>> 2 files changed, 198 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
>> index f3e713a5259c2c7c24cfdcec094814eb1202971a..f08549ee3872eece85884606d6ee9e540ee688ca 100644
>> --- a/drivers/dma/qcom/bam_dma.c
>> +++ b/drivers/dma/qcom/bam_dma.c
>> [...]
>> @@ -686,6 +702,35 @@ static int bam_slave_config(struct dma_chan *chan,
>> return 0;
>> }
>>
>> +static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
>> +{
>> + struct bam_chan *bchan = to_bam_chan(desc->chan);
>> + const struct bam_device_data *bdata = bchan->bdev->dev_data;
>> + struct bam_desc_metadata *metadata = data;
>> +
>> + if (!data)
>
> Doesn't really matter much, but since the parameter exists you might as
> well add
>
> && len == sizeof(*metadata)
>
> here to be sure.
>
Ok.
>> + return -EINVAL;
>> +
>> + if (!bdata->pipe_lock_supported)
>> + /*
>> + * The client wants to use locking but this BAM version doesn't
>> + * support it. Don't return an error here as this will stop the
>> + * client from using DMA at all for no reason.
>> + */
>> + return 0;
>> +
>> + guard(spinlock_irqsave)(&bchan->vc.lock);
>> +
>> + bchan->scratchpad_addr = metadata->scratchpad_addr;
>> + bchan->direction = metadata->direction;
>> +
>> + return 0;
>> +}
>> +
>> +static const struct dma_descriptor_metadata_ops bam_metadata_ops = {
>> + .attach = bam_metadata_attach,
>> +};
>
> I'm not sure if we have discussed this before, but could we avoid
> re-programming the scratchpad_addr all the time by placing it into
> struct dma_slave_config -> peripheral_config? It still feels awkward to
> me to place a global constant configuration value into per-descriptor
> metadata.
>
Yes, this was discussed several versions ago. I went with using
dmaengine_slave_config() until v11. I think Vinod or Dmitry requested we change
it to the metadata.
>> +
>> /**
>> * bam_prep_slave_sg - Prep slave sg transaction
>> *
>> [...]
>> @@ -802,6 +851,7 @@ static int bam_dma_terminate_all(struct dma_chan *chan)
>> }
>>
>> vchan_get_all_descriptors(&bchan->vc, &head);
>> + bchan->bam_locked = false;
>
> I wonder about the implications of this. If the LOCK descriptor was
> already processed, will we cause a deadlock if we never submit the
> UNLOCK descriptor? Or I guess bam_reset_channel() might reset the lock
> as well?
>
I'll look into it.
>> }
>>
>> vchan_dma_desc_free_list(&bchan->vc, &head);
>> [...]
>> @@ -870,6 +929,7 @@ static u32 process_channel_irqs(struct bam_device *bdev)
>> {
>> u32 i, srcs, pipe_stts, offset, avail;
>> struct bam_async_desc *async_desc, *tmp;
>> + struct bam_desc_hw *hdesc;
>>
>> srcs = readl_relaxed(bam_addr(bdev, 0, BAM_IRQ_SRCS_EE));
>>
>> @@ -919,13 +979,20 @@ static u32 process_channel_irqs(struct bam_device *bdev)
>> * push back to front of desc_issued so that
>> * it gets restarted by the work queue.
>> */
>> +
>> + list_del(&async_desc->desc_node);
>> if (!async_desc->num_desc) {
>> - vchan_cookie_complete(&async_desc->vd);
>> + hdesc = async_desc->desc;
>> + u16 flags = le16_to_cpu(hdesc->flags);
>
> Is this unused? Also a bit odd to have hdesc declared outside of the
> loop and flags declared inside.
>
>> +
>> + if (async_desc->is_lock_desc)
>> + bam_dma_free_lock_desc(&async_desc->vd);
>> + else
>> + vchan_cookie_complete(&async_desc->vd);
>> } else {
>> list_add(&async_desc->vd.node,
>> &bchan->vc.desc_issued);
>> }
>> - list_del(&async_desc->desc_node);
>> }
>> }
>>
>> @@ -1046,13 +1113,102 @@ static void bam_apply_new_config(struct bam_chan *bchan,
>> bchan->reconfigure = 0;
>> }
>>
>> +static struct bam_async_desc *
>> +bam_make_lock_desc(struct bam_chan *bchan, unsigned long flag)
>> +{
>> + struct dma_chan *chan = &bchan->vc.chan;
>> + struct bam_async_desc *async_desc;
>> + struct bam_desc_hw *desc;
>> + struct virt_dma_desc *vd;
>> + struct virt_dma_chan *vc;
>> + unsigned int mapped;
>> +
>> + async_desc = kzalloc_flex(*async_desc, desc, 1, GFP_NOWAIT);
>> + if (!async_desc) {
>> + dev_err(bchan->bdev->dev, "failed to allocate the BAM lock descriptor\n");
>> + return ERR_PTR(-ENOMEM);
>> + }
>> +
>> + sg_init_table(&async_desc->lock_sg, 1);
>> +
>> + async_desc->num_desc = 1;
>> + async_desc->curr_desc = async_desc->desc;
>> + async_desc->dir = DMA_MEM_TO_DEV;
>> + async_desc->is_lock_desc = true;
>> +
>> + desc = async_desc->desc;
>> +
>> + bam_prep_ce_le32(&async_desc->lock_ce, bchan->scratchpad_addr, BAM_WRITE_COMMAND, 0);
>> + sg_set_buf(&async_desc->lock_sg, &async_desc->lock_ce, sizeof(async_desc->lock_ce));
>> +
>> + mapped = dma_map_sg(chan->slave, &async_desc->lock_sg, 1, DMA_TO_DEVICE);
>
> I agree with Sashiko that mapping using the BAM device
> (bchan->bdev->dev) would be more precise, since the BAM will be reading
> the descriptor. (It doesn't matter in practice since both BAM and
> consumer usually have the same IOMMUs defined.)
>
Ok
>> + if (!mapped) {
>> + kfree(async_desc);
>> + return ERR_PTR(-ENOMEM);
>> + }
>> +
>> + desc->flags |= cpu_to_le16(DESC_FLAG_CMD | flag);
>> + desc->addr = sg_dma_address(&async_desc->lock_sg);
>
> cpu_to_le32()
>
Right.
>> + desc->size = cpu_to_le16(sizeof(struct bam_cmd_element));
>> +
>> + vc = &bchan->vc;
>> + vd = &async_desc->vd;
>> +
>> + dma_async_tx_descriptor_init(&vd->tx, &vc->chan);
>> + vd->tx.flags = DMA_PREP_CMD;
>> + vd->tx_result.result = DMA_TRANS_NOERROR;
>> + vd->tx_result.residue = 0;
>> +
>> + return async_desc;
>> +}
>> +
>> [...]
>> @@ -1072,6 +1229,18 @@ static void bam_start_dma(struct bam_chan *bchan)
>> return;
>>
>> while (vd && !IS_BUSY(bchan)) {
>> + /*
>> + * Open a LOCK/UNLOCK bracket around each fresh sequence.
>> + * Sentinels inserted by bam_setup_pipe_lock() are skipped: they
>> + * already have bam_locked set and must not trigger a second pair.
>> + */
>> + if (!bchan->bam_locked &&
>> + !container_of(vd, struct bam_async_desc, vd)->is_lock_desc) {
>
> Do we need the ->is_lock_desc check here? Looks redundant to me.
>
I don't remember anymore but I think I did it on purpose for some reason. I'll
double check.
>> + ret = bam_setup_pipe_lock(bchan);
>> + if (ret == 0 && bchan->bam_locked)
>> + vd = vchan_next_desc(&bchan->vc);
>
> Do we want some error handling here? If there is an error, this will
> silently continue queuing everything without any locking.
>
Ok, makes sense.
Bart
^ permalink raw reply
* [RFC PATCH net-next v2 1/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Leon Hwang @ 2026-07-15 14:53 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen, Leon Hwang,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <20260715145328.54597-1-leon.hwang@linux.dev>
Introduce a new sysctl knob, net.ipv4.tcp_purge_receive_queue, to
address an unreleased SKBs issue related to TCP sockets.
Issue:
When a TCP socket in the CLOSE_WAIT state receives a RST packet, the
current implementation does not clear the socket's receive queue. This
causes SKBs in the queue to remain allocated until the socket is
explicitly closed by the application. As a consequence:
1. The page pool pages held by these SKBs are not released.
2. The associated page pool cannot be freed.
RFC 9293 Section 3.10.7.4 specifies that when a RST is received in
CLOSE_WAIT state, "all segment queues should be flushed." However, the
current implementation does not flush the receive queue.
Solution:
Add a per-namespace sysctl (net.ipv4.tcp_purge_receive_queue) that,
when enabled, causes the kernel to purge the receive queue when a RST
packet is received in CLOSE_WAIT state. This allows immediate release
of SKBs and their associated memory resources.
The feature is disabled by default to maintain backward compatibility
with existing behavior.
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
---
Documentation/networking/ip-sysctl.rst | 18 +++++++++++++++
.../net_cachelines/netns_ipv4_sysctl.rst | 1 +
include/net/netns/ipv4.h | 1 +
net/ipv4/sysctl_net_ipv4.c | 9 ++++++++
net/ipv4/tcp_input.c | 22 +++++++++++++++++++
5 files changed, 51 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
index 208f46967ee5..abbee0326f15 100644
--- a/Documentation/networking/ip-sysctl.rst
+++ b/Documentation/networking/ip-sysctl.rst
@@ -1448,6 +1448,24 @@ tcp_rto_max_ms - INTEGER
Default: 120,000
+tcp_purge_receive_queue - BOOLEAN
+ When a socket in the TCP_CLOSE_WAIT state receives a RST packet, the
+ default behavior is to not clear its receive queue. As a result,
+ any SKBs in the queue are not freed until the socket is closed.
+ Consequently, the pages held by these SKBs are not released, which
+ can also prevent the associated page pool from being freed.
+
+ If enabled, the receive queue is purged upon receiving the RST,
+ allowing the SKBs and their associated memory to be released
+ promptly.
+
+ Possible values:
+
+ - 0 (disabled)
+ - 1 (enabled)
+
+ Default: 0 (disabled)
+
UDP variables
=============
diff --git a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
index 3dc03bff739e..2945de40ad78 100644
--- a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
+++ b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
@@ -126,6 +126,7 @@ unsigned_long sysctl_tcp_comp_sack_delay_ns
unsigned_long sysctl_tcp_comp_sack_slack_ns __tcp_ack_snd_check
int sysctl_max_syn_backlog
int sysctl_tcp_fastopen
+u8 sysctl_tcp_purge_receive_queue
struct_tcp_congestion_ops tcp_congestion_control init_cc
struct_tcp_fastopen_context tcp_fastopen_ctx
unsigned_int sysctl_tcp_fastopen_blackhole_timeout
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index cb7f8bf15671..ab9b92807d9f 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -222,6 +222,7 @@ struct netns_ipv4 {
u8 sysctl_tcp_nometrics_save;
u8 sysctl_tcp_no_ssthresh_metrics_save;
u8 sysctl_tcp_workaround_signed_windows;
+ u8 sysctl_tcp_purge_receive_queue;
int sysctl_tcp_challenge_ack_limit;
u8 sysctl_tcp_min_tso_segs;
u8 sysctl_tcp_reflect_tos;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index ca1180dba1de..82412fd98e0e 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -1652,6 +1652,15 @@ static struct ctl_table ipv4_net_table[] = {
.extra1 = SYSCTL_ONE_THOUSAND,
.extra2 = &tcp_rto_max_max,
},
+ {
+ .procname = "tcp_purge_receive_queue",
+ .data = &init_net.ipv4.sysctl_tcp_purge_receive_queue,
+ .maxlen = sizeof(u8),
+ .mode = 0644,
+ .proc_handler = proc_dou8vec_minmax,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE,
+ },
};
static __net_init int ipv4_sysctl_init_net(struct net *net)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 61045a8886e4..4f1027173e95 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4853,6 +4853,7 @@ void tcp_done_with_error(struct sock *sk, int err)
/* When we get a reset we do this. */
void tcp_reset(struct sock *sk, struct sk_buff *skb)
{
+ const struct net *net = sock_net(sk);
int err;
trace_tcp_receive_reset(sk);
@@ -4869,6 +4870,27 @@ void tcp_reset(struct sock *sk, struct sk_buff *skb)
err = ECONNREFUSED;
break;
case TCP_CLOSE_WAIT:
+ /* RFC9293 3.10.7.4. Other States
+ * Second, check the RST bit:
+ * CLOSE-WAIT STATE
+ *
+ * If the RST bit is set, then any outstanding RECEIVEs and
+ * SEND should receive "reset" responses. All segment queues
+ * should be flushed. Users should also receive an unsolicited
+ * general "connection reset" signal. Enter the CLOSED state,
+ * delete the TCB, and return.
+ *
+ * If net.ipv4.tcp_purge_receive_queue is enabled,
+ * sk_receive_queue will be flushed too.
+ */
+ if (unlikely(READ_ONCE(net->ipv4.sysctl_tcp_purge_receive_queue))) {
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ skb_queue_purge(&sk->sk_receive_queue);
+ WRITE_ONCE(tp->copied_seq, tp->rcv_nxt);
+ WRITE_ONCE(tp->urg_data, 0);
+ sk_set_peek_off(sk, -1);
+ }
err = EPIPE;
break;
case TCP_CLOSE:
--
2.55.0
^ permalink raw reply related
* [RFC PATCH net-next v2 0/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Leon Hwang @ 2026-07-15 14:53 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen, Leon Hwang,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
Introduce a new sysctl knob, net.ipv4.tcp_purge_receive_queue, to
address an unreleased SKBs issue related to TCP sockets.
Issue:
When a TCP socket in the CLOSE_WAIT state receives a RST packet, the
current implementation does not clear the socket's receive queue. This
causes SKBs in the queue to remain allocated until the socket is
explicitly closed by the application. As a consequence:
1. The page pool pages held by these SKBs are not released.
2. The associated page pool cannot be freed.
RFC 9293 Section 3.10.7.4 specifies that when a RST is received in
CLOSE_WAIT state, "all segment queues should be flushed." However, the
current implementation does not flush the receive queue.
Solution:
Add a per-namespace sysctl (net.ipv4.tcp_purge_receive_queue) that,
when enabled, causes the kernel to purge the receive queue when a RST
packet is received in CLOSE_WAIT state. This allows immediate release
of SKBs and their associated memory resources.
The feature is disabled by default to maintain backward compatibility
with existing behavior.
Note: the user-space issue, the root cause of the unreleased SKBs, has
been fixed by https://github.com/IBM/sarama/pull/3384.
Changes:
v1 -> v2:
* Update 'tp->copied_seq', 'tp->urg_data', and 'sk->sk_peek_off' like
'tcp_disconnect()'.
* Drop "memory leak" words in commit msg. (per Eric)
* Add two packetdrill tests. (per Eric)
* v1: https://lore.kernel.org/netdev/20260225074633.149590-1-leon.huangfu@shopee.com/
Leon Hwang (2):
tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
selftests/net: packetdrill: Add two tcp_purge_receive_queue tests
Documentation/networking/ip-sysctl.rst | 18 ++++++++
.../net_cachelines/netns_ipv4_sysctl.rst | 1 +
include/net/netns/ipv4.h | 1 +
net/ipv4/sysctl_net_ipv4.c | 9 ++++
net/ipv4/tcp_input.c | 22 ++++++++++
.../tcp_purge_receive_queue_disabled.pkt | 40 ++++++++++++++++++
.../tcp_purge_receive_queue_enabled.pkt | 42 +++++++++++++++++++
7 files changed, 133 insertions(+)
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt
--
2.55.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox