* Re:
From: Jonathan Corbet @ 2026-07-16 22:50 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260716021013.48025-1-danielmaraboo@gmail.com>
Daniel Pereira <danielmaraboo@gmail.com> writes:
> Subject: [PATCH 0/4] doc: pt_BR: Add translations for process and guidelines
>
> Hello,
>
> This patch series adds the Brazilian Portuguese (pt_BR) translations for
> several essential files regarding community standards, submit checklists, and
> best development practices.
>
> Specifically, this series translates:
> 1. The submit-checklist guide.
> 2. The Code of Conduct interpretation document.
> 3. The core Contributor Covenant Code of Conduct.
> 4. The deprecated interfaces, attributes, and language features guide.
>
> All files have been formatted to respect the 80-character line limit and
> the main index.rst has been updated accordingly. The Sphinx documentation build
> (make htmldocs) compiles successfully with no warnings or errors related to
> these new files.
I've applied the series, thanks.
For future reference, a lot of the Portuguese translation patches are
giving me conflicts on Documentation/translations/pt_BR/index.rst. That
happens when you have a big file that everybody just appends to. Might
I request that you start managing the index.rst structure in the same
way as the English docs so that these additions are spread out and don't
conflict? That would also yield a more readable result for the
translation.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3] docs/ja_JP: submitting-patches: Refine wording etc for "splitting changes" and later
From: Jonathan Corbet @ 2026-07-16 22:42 UTC (permalink / raw)
To: Akira Yokosawa
Cc: Shuah Khan, Weijie Yuan, linux-doc, linux-kernel, Akira Yokosawa,
Akiyoshi Kurita
In-Reply-To: <20260715120545.99917-1-akiyks@gmail.com>
Akira Yokosawa <akiyks@gmail.com> writes:
> Resolve rough edges in translation text added since commit 61e4155c81d1
> ("docs/ja_JP: translate more of submitting-patches.rst").
>
> As with commit 999084ee0b11 ("docs/ja_JP: submitting-patches: Amend
> "Describe your changes""), do the following tweaks:
>
> - Rewording and rephrasing.
> - Suppress extra white spaces rendered before and after strong emphasis
> in HTML and PDF by using espcaped spaces.
> - Provide translation words for "embargo", "word-wrap", "top-posting",
> etc.
> - Rather than keep "interleaved replies", use only 「インライン返信」
> ("inline reply"), which is a popular term in Japanese.
>
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> Cc: Akiyoshi Kurita <weibu@redadmin.org>
> ---
> v3: Remove duplicated Signed-off-by: ...
> v2: Use 「件名」 for "subject line".
> (Inspired by Kurita-san's submission at:
> https://lore.kernel.org/20260712210535.161387-1-weibu@redadmin.org/
> , "[PATCH v3] docs/ja_JP: translate submitting-patches.rst (sign-off)")
> ---
> .../ja_JP/process/submitting-patches.rst | 150 +++++++++---------
> 1 file changed, 75 insertions(+), 75 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] scripts/kernel-doc: Suggest possible names for excess descriptions
From: Jonathan Corbet @ 2026-07-16 22:40 UTC (permalink / raw)
To: Ryszard Knop, linux-doc
Cc: Shuicheng Lin, Randy Dunlap, Jani Nikula, linux-kernel, intel-xe
In-Reply-To: <20260714111208.323108-1-ryszard.knop@intel.com>
Ryszard Knop <ryszard.knop@intel.com> writes:
> 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.
>
> Signed-off-by: Ryszard Knop <ryszard.knop@intel.com>
> ---
> tools/lib/python/kdoc/kdoc_parser.py | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
So I almost applied this version of this patch. For future reference,
please:
- Post new versions standalone, not as a reply
- Do not include version information in the changelog (put it below the
"---" line)
- Provide a more coherent changelog; the one above does not say what is
actually going on here.
- CC the maintainer (me).
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] Documentation: usb: remove dead link to external USB programming guide
From: Jonathan Corbet @ 2026-07-16 22:23 UTC (permalink / raw)
To: Utsav Shankar; +Cc: Shuah Khan, linux-doc, linux-usb, Utsav Shankar
In-Reply-To: <20260713150544.20962-1-utsaveshan0206@gmail.com>
Utsav Shankar <utsaveshan0206@gmail.com> writes:
> The "Programming Guide for Linux USB Device Drivers" was last hosted
> at lmu.web.psi.ch and is no longer reachable. The original source
> (TUM, cs.tum.edu) is also defunct. Remove the dead reference rather
> than link to a third-party archive of a 20+ year old, outdated guide.
>
> Signed-off-by: Utsav Shankar <utsaveshan0206@gmail.com>
> ---
> Documentation/driver-api/usb/writing_usb_driver.rst | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/Documentation/driver-api/usb/writing_usb_driver.rst b/Documentation/driver-api/usb/writing_usb_driver.rst
> index 95c4f5d14..6f024e164 100644
> --- a/Documentation/driver-api/usb/writing_usb_driver.rst
> +++ b/Documentation/driver-api/usb/writing_usb_driver.rst
> @@ -322,7 +322,4 @@ http://linux-hotplug.sourceforge.net/
> linux-usb Mailing List Archives:
> https://lore.kernel.org/linux-usb/
>
> -Programming Guide for Linux USB Device Drivers:
> -https://lmu.web.psi.ch/docu/manuals/software_manuals/linux_sl/usb_linux_programming_guide.pdf
> -
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: pt_BR: process: Translate the kernel driver statement
From: Jonathan Corbet @ 2026-07-16 22:21 UTC (permalink / raw)
To: Igor Giamoniano, danielmaraboo; +Cc: linux-doc, Igor Giamoniano
In-Reply-To: <20260708130558.12604-1-igorgphotoarte@gmail.com>
Igor Giamoniano <igorgphotoarte@gmail.com> writes:
> Translate Documentation/process/kernel-driver-statement.rst into Brazilian
> Portuguese, keeping the reStructuredText formatting and the list of
> signatories unchanged.
>
> Signed-off-by: Igor Giamoniano <igorgphotoarte@gmail.com>
> ---
> .../pt_BR/process/kernel-driver-statement.rst | 205 ++++++++++++++++++
> 1 file changed, 205 insertions(+)
> create mode 100644 Documentation/translations/pt_BR/process/kernel-driver-statement.rst
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: custom.css: don't limit randering to old 800px monitors
From: Jonathan Corbet @ 2026-07-16 21:55 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, linux-kernel, Clinton Phillips,
Daniel Lundberg Pedersen, Hans Verkuil, Mauro Carvalho Chehab,
Petr Vorel, Randy Dunlap, Rito Rhymes, Shuah Khan, linux-media
In-Reply-To: <20260711094821.5e262356@foz.lan>
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> +div.body { max-width: 120em; }
For me that's still painfully wide, but I guess I'm weird; I went ahead
and applied it.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2 1/1] docs: maintainers_include: fix entry names
From: Jonathan Corbet @ 2026-07-16 21:49 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab, linux-kernel, Shuah Khan, Manuel Ebner
In-Reply-To: <bb00e9ba66f2d95306e7ca88fdf0f39fcc570cff.1783884625.git.mchehab+huawei@kernel.org>
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> Right now, it is printing duplicated values as profile entries, as
> it is not properly handling subsystem name.
>
> Fix it.
>
> Reported-by: Manuel Ebner <manuelebner@mailbox.org>
> Closes: https://lore.kernel.org/linux-doc/98a558a87a07ab641f47c66c372ee7ed0735f4f5.camel@mailbox.org/
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
> Documentation/sphinx/maintainers_include.py | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH 2/2] mm/zswap: Support batch writeback in shrink_memcg()
From: Yosry Ahmed @ 2026-07-16 20:35 UTC (permalink / raw)
To: Hao Jia
Cc: akpm, tj, hannes, shakeel.butt, mhocko, mkoutny, nphamcs,
chengming.zhou, muchun.song, roman.gushchin, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <b910e870-9583-a2f5-b681-e69edb9af290@gmail.com>
On Wed, Jul 15, 2026 at 7:54 PM Hao Jia <jiahao.kernel@gmail.com> wrote:
>
>
>
> On 2026/7/16 00:14, Yosry Ahmed wrote:
> >>>> Test Setup:
> >>>> Total memory: 32 GB.
> >>>> zswap settings: max_pool_percent=1, accept_threshold_percent=50,
> >>>> shrinker_enabled=N.
> >>>> Allocate 512MB of anonymous pages and fill them with random data (to avoid
> >>>> compression), then use cgroup memory.reclaim to force a large amount of
> >>>> anonymous pages into zswap. At an interval of 2ms, allocate a 4K anonymous
> >>>> page where the first 4 bytes are random numbers and the rest are zeros, and
> >>>> then trigger a reclamation of this 4K anonymous page through cgroup
> >>>> memory.reclaim. When the pool threshold is reached, shrink_memcg() will
> >>>> be triggered.
> >>>>
> >>>> The test data after running for 120s is as follows:
> >>>> Baseline Patched
> >>>> shrink_worker wakeups 5363 85
> >>>> shrink_memcg calls 11,345,012 188,264
> >>>> written_back 40214 40275
> >>>>
> >>>> Conclusion:
> >>>> Under the same workload and run duration, the patched kernel shows a
> >>>> significant reduction in both shrink_worker wakeups and shrink_memcg calls.
> >>>
> >>> Please also include data from the case where zswap store failures are
> >>> observed and pages go to disk, and compare before and after this
> >>> patch. I think that part is also really important.
> >>
> >> I retested and added some collected information. Perhaps
> >> `pool_limit_hit` and `pswpout` can explain that batch shrinking of zswap
> >> can reduce the number of pages that fail to be stored due to the pool
> >> limit, allowing zswap to skip zswap and go directly to disk.
> >
> > Oh I meant the other test case with high memory pressure where we saw
> > a lot more writeback with this patch. Do you have similar data from
> > that test case?
> >
>
> Below are the results from stress-ng (high memory pressure case), which
> lead to a similar conclusion:
>
> Baseline Patched
> shrink_worker wakeups 5,640 987
> shrink_memcg calls 8,481,500 2,504,818
> written_back pages 260 768,576
> zswap_store calls 2,742,756 2,301,414
> store succeeded (ret=1) 934,640 1,308,686
> store rejected (ret=0) 1,808,116 992,728 <-
> store reject rate ~65% ~43%
> pool_limit_hit delta 1,181,310 101,593 <-
> pswpout 1,808,376 1,761,304
> pswpin 4,288,497 3,902,658
>
>
> pswpout = store rejected + written_back pages
> Note that pswpout comprises two parts: the store rejected count (where
> we skip zswap and go directly to disk) and the number of pages written
> back by shrink_memcg().
>
> Therefore, we can directly leverage store rejected to evaluate the
> scenario where zswap is skipped and pages bypass it to disk. This
> provides a much clearer picture than looking at pswpout alone.
>
> Do we need to include both sets of test results along with the
> comparison data in the final commit message?
Yeah, I think you can include a summarized version of both sets of
results. I think the important part to highlight here is that batching
results in a great reduction in store rejection rate, which translates
to significantly more writeback, as the LRU ordering is maintained
more correctly. We are also doing a bit less swapping from disk
overall if I am reading this correctly, which means we are placing
less hot data on disk as expected.
It is a bit alarming that the store rejection rate is still 43% with
batching, but we can worry about this later :)
^ permalink raw reply
* [PATCH v4 1/1] Documentation: real-time: Add kernel configuration guide
From: Ahmed S. Darwish @ 2026-07-16 19:57 UTC (permalink / raw)
To: Jonathan Corbet, Clark Williams, Steven Rostedt, linux-rt-devel
Cc: Matthew Wilcox, Sebastian Andrzej Siewior, John Ogness,
Derek Barbosa, linux-doc, linux-kernel, Ahmed S. Darwish
In-Reply-To: <20260716195716.256025-1-darwi@linutronix.de>
Add a configuration guide for real-time kernels.
List all Kconfig options that are recommended to be either enabled or
disabled. Explicitly add a table of contents at the top of the document,
so that all the options can be seen in a glance.
Whenever appropriate, link to other kernel guides; e.g. cpuidle, cpufreq,
power management, workqueues, and no_hz.
Add a summary at the end of the document warning users that there is a no
"one size fits all solution" for configuring a real-time system.
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
---
Documentation/core-api/real-time/index.rst | 1 +
.../real-time/kernel-configuration.rst | 310 ++++++++++++++++++
2 files changed, 311 insertions(+)
create mode 100644 Documentation/core-api/real-time/kernel-configuration.rst
diff --git a/Documentation/core-api/real-time/index.rst b/Documentation/core-api/real-time/index.rst
index f08d2395a22c..a17a3dec535c 100644
--- a/Documentation/core-api/real-time/index.rst
+++ b/Documentation/core-api/real-time/index.rst
@@ -15,3 +15,4 @@ the required changes compared to a non-PREEMPT_RT configuration.
differences
hardware
architecture-porting
+ kernel-configuration
diff --git a/Documentation/core-api/real-time/kernel-configuration.rst b/Documentation/core-api/real-time/kernel-configuration.rst
new file mode 100644
index 000000000000..99dfc73aa4d3
--- /dev/null
+++ b/Documentation/core-api/real-time/kernel-configuration.rst
@@ -0,0 +1,310 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+Real-Time Kernel configuration
+==============================
+
+.. contents:: Table of Contents
+ :depth: 3
+ :local:
+
+Introduction
+============
+
+This document lists the kernel configuration options that might affect a
+real-time kernel's worst-case latency. It is intended for system integrators.
+
+Configuration options
+=====================
+
+``CONFIG_CPU_FREQ``
+-------------------
+
+:Expectation: enabled
+:Severity: *high*
+
+The CPU frequency scaling subsystem ensures that the processor can operate
+at its maximum supported frequency. While, in general, bootloaders are
+tasked with setting the CPU clock to the highest speed on boot, some do
+not. It is thus desirable to keep this option enabled.
+
+.. caution::
+
+ A real-time kernel is not about being "as fast as possible", however
+ real-time requirements may demand that the CPU is clocked at a
+ particular speed.
+
+``CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE``
+-------------------------------------------
+
+:Expectation: enabled
+:Severity: *high*
+
+Real-Time workloads expect a fixed CPU frequency during execution. Using
+the performance governor is an easy way to achieve that purely from kernel
+configuration.
+
+This is not a blanket rule. Some setups might prefer to clock the CPU to
+lower speeds due to thermal packaging or other requirements. The key is
+that the CPU frequency remains constant once set.
+
+``CONFIG_CPU_IDLE``
+-------------------
+
+:Expectation: enabled
+:Severity: *info*
+
+CPU idle states (C-states) allow the processor to enter low-power modes
+during periods of inactivity. Very-low CPU idle states may require
+flushing the CPU caches and lowering or disabling the clocking. This can
+lower power consumption, but it also increases the entry and exit latency
+from such states.
+
+While disabling this option eliminates cpuidle-related latencies, doing so
+can significantly impact hardware longevity, warranty, and thermal
+behavior. Users should cap the maximum C-state to C1 instead. For ACPI
+platforms, this can be achieved by using the boot parameter [1]_::
+
+ processor.max_cstate=1
+
+Higher C-states can be acceptable depending on the user workload's latency
+requirements. For ACPI-based platforms, use the ``cpupower idle-info``
+command to inspect the available idle states.
+
+For more information, please see:
+
+- ``linux/tools/power/cpupower``
+- :doc:`/admin-guide/pm/cpuidle`
+- :doc:`/admin-guide/pm/index`
+
+``CONFIG_DRM``
+--------------
+
+:Expectation: disabled
+:Severity: *info*
+
+GPU-accelerated workloads can share system resources with the CPU,
+including last-level cache (LLC) and memory bandwidth. Modern integrated
+GPUs optimize graphics performance at the expense of CPU determinism.
+
+Examples of affected platforms:
+
+- Intel processors with integrated graphics (Gen9 and later)
+- AMD APUs with Radeon Graphics
+- Xilinx Zynq UltraScale+ MPSoC EG/EV series
+
+If graphics workloads must run alongside real-time tasks, users must
+conduct thorough stress testing using tools like ``glmark2`` while
+measuring the overall system latency.
+
+For more information, please check:
+
+- :doc:`Regarding hardware (System memory and cache) </core-api/real-time/hardware>`
+- :doc:`/filesystems/resctrl`
+- `Real-Time and Graphics: A Contradiction?`_
+
+``CONFIG_EFI_DISABLE_RUNTIME``
+------------------------------
+
+:Expectation: enabled
+:Severity: *medium*
+
+EFI is the standard boot and firmware interface for multiple
+architectures. EFI runtime services provide callback functions to be
+called from the kernel; e.g., as utilized by (``CONFIG_EFI_VARS*``) or
+(``CONFIG_RTC_DRV_EFI``). For the former, the kernel calls into EFI to
+update the EFI variables.
+
+Calling into EFI means invoking firmware callbacks. During such
+invocations, the system might not be able to react to interrupts and will
+thus not be able to perform a context switch. This can cause significant
+latency spikes for the real-time system.
+
+``CONFIG_PREEMPT_RT`` enables this option by default. If this option is
+manually disabled at build time, the following boot parameter [1]_ may be
+used to disable EFI runtime at boot up::
+
+ efi=noruntime
+
+Alternatively, confine EFI runtime service calls to a housekeeping CPU by
+restricting the ``efi_runtime`` workqueue CPU affinity. For example, set
+that workqueue's affinity to CPU #0 and pin your RT tasks to a different
+CPU range. See :doc:`/core-api/workqueue`.
+
+``CONFIG_NO_HZ`` / ``CONFIG_NO_HZ_FULL``
+----------------------------------------
+
+:Expectation: disabled
+:Severity: *medium*
+
+Tickless operation can increase kernel-to-userspace transition latency due
+to the extra accounting and state book-keeping.
+
+*Guidance by real-time workload type:*
+
+- For periodic workloads; e.g., control loops executing every 100 µs, avoid
+ ``NO_HZ`` modes. Consistent kernel ticks are preferable.
+
+- For computation-intensive workloads; e.g. extended userspace execution,
+ ``NO_HZ_FULL`` may be beneficial. In such cases, users should offload
+ the kernel housekeeping to dedicated CPUs and isolate compute cores.
+
+See also :doc:`/timers/no_hz`.
+
+``CONFIG_PREEMPT_RT``
+---------------------
+
+:Expectation: enabled
+:Severity: **fatal**
+
+This option must be enabled, or the resulting kernel will not be fully
+preemptible and real-time capable.
+
+``CONFIG_TRACING`` (and tracing options)
+----------------------------------------
+
+:Expectation: enabled
+:Severity: *info*
+
+Shipping kernels with tracing support enabled (but not actively running) is
+highly recommended. This will allow the users to extract more information
+if latency problems arise. Nonetheless, some tracers do incur latency
+overhead by just being enabled; see :ref:`tracers`.
+
+.. caution::
+
+ Users should *not* make use of tracers or trace events during production
+ real-time kernel operation as they can add considerable overhead and
+ degrade the system's latency.
+
+Non-performance CPU frequency governors
+---------------------------------------
+
+:Expectation: disabled
+:Severity: *medium*
+
+To ensure reproducible system latency measurements, disable the
+non-``PERFORMANCE`` CPU frequency governors when possible. This avoids the
+risk of unknown userspace tasks implicitly or explicitly setting a
+different CPU frequency governor, and thus achieving different latency
+results across the system's runtime.
+
+If disabling other frequency governors is not an option, then
+``CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE`` should be enabled. In that case,
+users should set a *stable* CPU frequency setting during the system
+runtime, as changing the CPU frequency will increase the system latency and
+affect latency measurements reproducibility. If a lower CPU frequency is
+desired, then ``CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE`` should be set.
+
+The ``ONDEMAND`` CPU frequency governor should *not* be enabled in a
+real-time system since it dramatically affects determinism depending on the
+workload.
+
+For more information, please check :doc:`/admin-guide/pm/cpufreq`.
+
+Kernel Debug Options
+====================
+
+Most kernel debug options add runtime overhead that increases the
+worst-case latency.
+
+.. caution::
+
+ During development and early testing, users are encouraged to run their
+ real-time workloads and peripherals with lockdep (:ref:`lockdep`) and
+ other kernel debug options enabled, for a considerable amount of time.
+ Such workloads might trigger kernel code paths that were not triggered
+ during the internal Linux real-time kernel development, thus helping to
+ uncover locking and other types of kernel bugs.
+
+Problematic debug options
+-------------------------
+
+.. _tracers:
+
+``CONFIG_IRQSOFF_TRACER`` and ``CONFIG_PREEMPT_TRACER``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Severity: *high*
+
+These tracers do incur measurable latency overhead even when tracing is not
+currently active.
+
+``CONFIG_LOCKUP_DETECTOR``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Severity: *high*
+
+The lockup detector creates kernel timer callbacks that execute every few
+seconds, in hard-IRQ context, even on real-time kernels. These periodic
+interrupts can cause latency spikes.
+
+Users should use hardware watchdogs instead, which will provide a similar
+functionality without the software-induced latency.
+
+.. _lockdep:
+
+``CONFIG_PROVE_LOCKING``
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Severity: *high*
+
+Proving the correctness of all kernel locking adds substantial overhead
+and significantly increases worst-case latency.
+
+Allowed kernel debug options
+----------------------------
+
+Kernel debug options which are not included in this list should be enabled
+with caution, after extensive auditing of their impact on system latency.
+
+``CONFIG_DEBUG_ATOMIC_SLEEP``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This sanity check catches common kernel programming errors with
+a tolerable latency cost.
+
+``CONFIG_DEBUG_BUGVERBOSE``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This improves the debugging capabilities without affecting normal
+operation latency.
+
+``CONFIG_DEBUG_FS``
+^^^^^^^^^^^^^^^^^^^
+
+This is safe to include in real-time kernels, *provided that debugfs is
+not accessed during production runtime*.
+
+``CONFIG_DEBUG_INFO``
+^^^^^^^^^^^^^^^^^^^^^
+
+This increases the kernel image size but has no latency impact. It is
+also essential for meaningful crash dumps and profiling.
+
+``CONFIG_DEBUG_KERNEL``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Meta-option which allows debug features to be enabled. This configuration
+option has no runtime impact, but be aware of any debug features that it
+may have allowed to be enabled.
+
+Summary
+=======
+
+There is no "one size fits all" solution for configuring a real-time Linux
+system. Beginning with the system real-time requirements, integrators
+must consider the features and functions of the system's hardware, kernel,
+and userspace. All such components must be properly configured in order
+to establish and constrain the system's maximum latency.
+
+With that in mind, any incorrect real-time kernel configuration could cause
+a new maximum latency that shows up at the wrong time and is catastrophic
+for the real-time system's latency.
+
+References
+==========
+
+.. [1] See :doc:`/admin-guide/kernel-parameters`
+
+.. _Real-Time and Graphics\: A Contradiction?: https://web.archive.org/web/20221025085614/https://linutronix.de/PDF/Realtime_and_graphics-acontradiction2021.pdf
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/1] Documentation: Add real-time kernel configuration guide
From: Ahmed S. Darwish @ 2026-07-16 19:57 UTC (permalink / raw)
To: Jonathan Corbet, Clark Williams, Steven Rostedt, linux-rt-devel
Cc: Matthew Wilcox, Sebastian Andrzej Siewior, John Ogness,
Derek Barbosa, linux-doc, linux-kernel, Ahmed S. Darwish
Hi,
There is a no "one size fits all" solution for configuring a PREEMPT_RT
kernel.
Intorduce a PREEMPT_RT kernel configuration guide to better help system
developers and integrators.
Changelog v4
------------
Handle Sashiko review: Remove a no-longer-referenced link. Remove
CONFIG_WQ_SYS reference, which I thought it exists due to a quick
misunderstanding of core-api/workqueue.
Changelog v3
------------
CONFIG_EFI_DISABLE_RUNTIME: Mention that system integrators can now assign
the efi_runtime workqueue CPU affinity, then safely pin RT tasks on a
different CPU range.
Changelog v2
------------
https://msgid.link/20260414174159.1271171-1-darwi@linutronix.de
Handle Rostedt remarks:
- Better reword certain paragraphs and statements
- Warn about enabling CONFIG_IRQSOFF_TRACER and CONFIG_PREEMPT_TRACER
Handle Wilcox remarks:
- Remove ToC comment + minor rewording
Changelog v1
------------
https://msgid.link/20260305205023.361530-1-darwi@linutronix.de
Thanks,
8<-----
Ahmed S. Darwish (1):
Documentation: real-time: Add kernel configuration guide
Documentation/core-api/real-time/index.rst | 1 +
.../real-time/kernel-configuration.rst | 310 ++++++++++++++++++
2 files changed, 311 insertions(+)
create mode 100644 Documentation/core-api/real-time/kernel-configuration.rst
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
--
2.54.0
^ permalink raw reply
* Re: [PATCH 1/2] mm/zswap: Fix global shrinker when memory cgroup is disabled
From: Nhat Pham @ 2026-07-16 18:18 UTC (permalink / raw)
To: Hao Jia
Cc: Yosry Ahmed, Andrew Morton, tj, hannes, shakeel.butt, mhocko,
mkoutny, chengming.zhou, muchun.song, roman.gushchin, linux-mm,
linux-kernel, linux-doc, Hao Jia, stable
In-Reply-To: <7b35fd4e-7662-10ae-159b-303350e4e59c@gmail.com>
On Wed, Jul 15, 2026 at 7:21 PM Hao Jia <jiahao.kernel@gmail.com> wrote:
>
>
>
> On 2026/7/16 00:13, Yosry Ahmed wrote:
> > On Wed, Jul 15, 2026 at 5:31 AM Hao Jia <jiahao.kernel@gmail.com> wrote:
> >>
> >>
> >>
> >> 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.
> >
> > I think you can simply write that zswap writeback when the limit is
> > hit is broken when memcg is disabled.
> Will do. Thanks!
>
> >
> >>
> >>> 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?
> >
> > Do we need to do this? The last paragraph in your changelog explains
> > why this can't happen because zswap_total_pages() should be 0 in this
> > case. Did I miss something?
>
> The loop would require the following sequence to repeat indefinitely:
>
> 1、zswap_total_pages() > thr evaluates to true.
> 2、During shrink_memcg(root_memcg), the zswap LRU is concurrently drained
> to empty.
> 3、Before zswap_total_pages() > thr is evaluated again, the zswap LRU is
> heavily refilled such that zswap_total_pages() > thr holds true once more.
>
> For our case to manifest, it would require zswap_total_pages() and the
> zswap LRU state to repeatedly hit this exact window with perfect
> alignment over a **prolonged period**. Therefore, I suspect this
> scenario might only exist in theory.
Yeah seems very artificial indeed.
If we want to be extra careful here, maybe we can put a cond_resched()
there or replace the continue with goto resched or sth?
^ permalink raw reply
* Re: [PATCH v4 net-next 1/7] ptp: Add ioctls for PHC timestamps with quality attributes
From: Jacob Keller @ 2026-07-16 18:14 UTC (permalink / raw)
To: Arthur Kiyanovski
Cc: David Miller, Jakub Kicinski, netdev, Richard Cochran,
Eric Dumazet, Paolo Abeni, David Woodhouse, Thomas Gleixner,
Miroslav Lichvar, Andrew Lunn, Wen Gu, Xuan Zhuo, David Woodhouse,
Yonatan Sarna, Zorik Machulsky, Alexander Matushevsky,
Saeed Bshara, Matt Wilson, Anthony Liguori, Nafea Bshara,
Evgeny Schmeilin, Netanel Belgazal, Ali Saidi,
Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, linux-kselftest,
linux-doc, shuah, Jonathan Corbet, Shuah Khan, Simon Horman,
vadim.fedorenko
In-Reply-To: <178418934680.25423.291292029139415698.b4-reply@b4>
On 7/16/2026 1:09 AM, Arthur Kiyanovski wrote:
> On 2026-07-14 17:45:34-07:00, Jacob Keller wrote:
>> On 7/13/2026 7:03 PM, Arthur Kiyanovski wrote:
>> I'm also wondering if this can expose device-known error bounds on
>> timestamps even for devices which are operated as synchronized by ptp4l..
>>
>
> The intent is for these attributes to represent device-
> known clock quality information. The mechanism is
> deliberately synchronization-agnostic: drivers may report
> any attributes they can meaningfully vouch for, regardless
> of how the clock is being disciplined. Thus a device that
> genuinely knows a hardware error bound could report it even
> if the PHC is being adjusted by ptp4l.
>
> In practice, however, when a PHC is disciplined entirely
> from userspace the driver often has little or no visibility
> into synchronization quality. The valid bitmask is designed
> for exactly this case: a driver advertises only the
> attributes it can populate, so anything it cannot determine
> is simply reported as unavailable.
>
Right.
>>> Timescale definitions use a Continuity/Discipline framework to describe
>>> timeline properties and steering behavior consistently across all
>>> entries.
>>>
>>> This implementation is based on the original RFC and the UAPI design
>>> discussion linked below.
>>
>> Not a dig against this patch set, nor a request that you work to
>> implement anything else, but I am beginning to wonder if/when it would
>> make sense to transition from ioctl-based implementation to genetlink or
>> something. We did something similar for ethtool ioctls a few years ago.
>> I know the maintainer for PTP has some distaste for netlink and prefers
>> the simplicity of the ioctls.. but I think we're moving past where the
>> ioctls are "simple". Now that we have ynl tools, it has gotten easier to
>> implement properly. It makes extending the API much easier for the
>> future vs the array of ioctls we now carry for legacy implementations.
>>
>
> That's an interesting direction for future PTP UAPI
> evolution, and ynl does make that path easier than it used
> to be. For this series I've kept to the existing PTP
> userspace API model and extended the current timestamping
> interfaces in a backwards-compatible way; a move to a
> netlink family would be a broader subsystem effort and feels
> separate from this work.
Absolutely. I don't think that should change this patch series. Its just
a thought that we might want to tackle this at some point as the ioctl
interface is clearly reaching its limits.
>>
>> Do you have any thought on how ptp4l synchronizing the clock should
>> impact the clock status here? Is this intended purely for device/drivers
>> which have their own synchronization and not for ones which expose a
>> clock that is synchronized by userspace? Would it make sense to have a
>> mode that is something like "this clock has been modified by userspace"
>> after any call to the .adjtime or .adjfreq is made?
>>
>
> Regarding a "modified by userspace" mode, I wasn't
> planning to add one. Whether adjtime() or adjfreq() was
> invoked does not by itself describe the current
> synchronization state or quality of the clock. A clock
> disciplined from userspace may still be highly accurate. I'd
> prefer to keep clock_status focused on clock quality
> information that the driver can directly determine rather
> than on how the clock is being controlled.
Makes sense. Leave it up to userspace to coordinate and combine relevant
data from the device/driver and the daemons together. Ok.
>>> @@ -106,7 +350,11 @@ struct ptp_clock_caps {
>>> /* Whether the clock supports adjust phase */
>>> int adjust_phase;
>>> int max_phase_adj; /* Maximum phase adjustment in nanoseconds. */
>>> - int rsv[11]; /* Reserved for future use. */
>>> + /* Whether the clock supports extended timestamps with attributes */
>>> + int extended_attrs;
>>> + /* Whether the clock supports precise cross-timestamps with attributes */
>>> + int precise_attrs;
>>> + int rsv[9]; /* Reserved for future use. */
>>
>> I do kind of wish we had opted for bit flags here given the number of
>> ints being used as booleans.. :( A lot of wasted reserved space.
>
> Agreed — a flags field would likely have scaled better. I
> followed the existing ptp_clock_caps convention (one int per
> capability) to stay consistent with the current UAPI
> structure rather than mix two styles within the same struct.
>
>
Yep, I agree that it is best to stick to the same pattern.
^ permalink raw reply
* Re: [PATCH v4 net-next 7/7] net: ena: Implement gettimexattrs64 callback for PTP attributes
From: Jacob Keller @ 2026-07-16 18:07 UTC (permalink / raw)
To: Arthur Kiyanovski
Cc: David Miller, Jakub Kicinski, netdev, Richard Cochran,
Eric Dumazet, Paolo Abeni, David Woodhouse, Thomas Gleixner,
Miroslav Lichvar, Andrew Lunn, Wen Gu, Xuan Zhuo, David Woodhouse,
Yonatan Sarna, Zorik Machulsky, Alexander Matushevsky,
Saeed Bshara, Matt Wilson, Anthony Liguori, Nafea Bshara,
Evgeny Schmeilin, Netanel Belgazal, Ali Saidi,
Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, linux-kselftest,
linux-doc, shuah, Jonathan Corbet, Shuah Khan, Simon Horman,
vadim.fedorenko
In-Reply-To: <178418947570.25423.8298339939975321346.b4-reply@b4>
On 7/16/2026 1:11 AM, Arthur Kiyanovski wrote:
> On 2026-07-14 17:47:35-07:00, Jacob Keller wrote:
>> On 7/13/2026 7:03 PM, Arthur Kiyanovski wrote:
>>
>>> Implement the gettimexattrs64 callback in the ENA driver to support
>>> the PTP_SYS_OFFSET_EXTENDED_ATTRS ioctl.
>>>
>>> This enables applications to retrieve PHC timestamps with quality
>>> attributes through the standard PTP ioctl interface.
>>>
>>> The ENA device currently reports only error_bound (valid bit set).
>>> Other attributes are not reported (valid bits unset).
>>
>> Typically it would be a policy not to introduce new attributes which are
>> not yet used, and add the other attributes once a user appears. However,
>> I think it makes sense to have the full set of desired attributes
>> especially given the ioctl interface limitations which would otherwise
>> require a lot of reserved space or new ioctl numbers. Especially given
>> the uAPI here has been discussed and changed heavily from previous patch
>> iterations.
>
> Thanks — that matches the reasoning. We defined the full
> attribute set up front because of the ioctl interface
> constraints you describe. The valid bitmask ensures that
> userspace only consumes attributes that a driver explicitly
> reports, while still allowing additional attributes to
> become available in future drivers without further UAPI
> changes.
>
Yea, I think that makes a lot of sense.
^ permalink raw reply
* Re: [PATCH 2/2] mm/zswap: Support batch writeback in shrink_memcg()
From: Nhat Pham @ 2026-07-16 18:04 UTC (permalink / raw)
To: Hao Jia
Cc: Yosry Ahmed, akpm, tj, hannes, shakeel.butt, mhocko, mkoutny,
chengming.zhou, muchun.song, roman.gushchin, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <b910e870-9583-a2f5-b681-e69edb9af290@gmail.com>
On Wed, Jul 15, 2026 at 7:54 PM Hao Jia <jiahao.kernel@gmail.com> wrote:
>
>
>
> On 2026/7/16 00:14, Yosry Ahmed wrote:
> >>>> Test Setup:
> >>>> Total memory: 32 GB.
> >>>> zswap settings: max_pool_percent=1, accept_threshold_percent=50,
> >>>> shrinker_enabled=N.
> >>>> Allocate 512MB of anonymous pages and fill them with random data (to avoid
> >>>> compression), then use cgroup memory.reclaim to force a large amount of
> >>>> anonymous pages into zswap. At an interval of 2ms, allocate a 4K anonymous
> >>>> page where the first 4 bytes are random numbers and the rest are zeros, and
> >>>> then trigger a reclamation of this 4K anonymous page through cgroup
> >>>> memory.reclaim. When the pool threshold is reached, shrink_memcg() will
> >>>> be triggered.
> >>>>
> >>>> The test data after running for 120s is as follows:
> >>>> Baseline Patched
> >>>> shrink_worker wakeups 5363 85
> >>>> shrink_memcg calls 11,345,012 188,264
> >>>> written_back 40214 40275
> >>>>
> >>>> Conclusion:
> >>>> Under the same workload and run duration, the patched kernel shows a
> >>>> significant reduction in both shrink_worker wakeups and shrink_memcg calls.
> >>>
> >>> Please also include data from the case where zswap store failures are
> >>> observed and pages go to disk, and compare before and after this
> >>> patch. I think that part is also really important.
> >>
> >> I retested and added some collected information. Perhaps
> >> `pool_limit_hit` and `pswpout` can explain that batch shrinking of zswap
> >> can reduce the number of pages that fail to be stored due to the pool
> >> limit, allowing zswap to skip zswap and go directly to disk.
> >
> > Oh I meant the other test case with high memory pressure where we saw
> > a lot more writeback with this patch. Do you have similar data from
> > that test case?
> >
>
> Below are the results from stress-ng (high memory pressure case), which
> lead to a similar conclusion:
>
> Baseline Patched
> shrink_worker wakeups 5,640 987
> shrink_memcg calls 8,481,500 2,504,818
> written_back pages 260 768,576
> zswap_store calls 2,742,756 2,301,414
> store succeeded (ret=1) 934,640 1,308,686
> store rejected (ret=0) 1,808,116 992,728 <-
> store reject rate ~65% ~43%
> pool_limit_hit delta 1,181,310 101,593 <-
> pswpout 1,808,376 1,761,304
> pswpin 4,288,497 3,902,658
>
>
> pswpout = store rejected + written_back pages
> Note that pswpout comprises two parts: the store rejected count (where
> we skip zswap and go directly to disk) and the number of pages written
> back by shrink_memcg().
>
> Therefore, we can directly leverage store rejected to evaluate the
> scenario where zswap is skipped and pages bypass it to disk. This
> provides a much clearer picture than looking at pswpout alone.
>
> Do we need to include both sets of test results along with the
> comparison data in the final commit message?
I mean, it helps your case no? :)
But nicely done. My understanding is, this batching of the global
shrinker reduces overall disk swap fallback, correct?
Other than Yosry's comment, the rest LGTM FWIW :) Thanks for fixing this, Hao!
^ permalink raw reply
* Re: [PATCH v5 3/5] rpmsg: virtio_rpmsg_bus: get buffer size from config space
From: Arnaud POULIQUEN @ 2026-07-16 17:37 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Tanmay Shah, andersson, corbet, skhan, linux-remoteproc,
linux-doc, linux-kernel
In-Reply-To: <CANLsYkze9Txw2u+bF_yC-HnHprsEWJscmTAsVeokhakxRTUYoQ@mail.gmail.com>
On 7/16/26 17:29, Mathieu Poirier wrote:
> On Thu, 16 Jul 2026 at 02:19, Arnaud POULIQUEN
> <arnaud.pouliquen@foss.st.com> wrote:
>>
>> Hello Mathieu,
>>
>> On 7/15/26 18:24, Mathieu Poirier wrote:
>>> On Fri, Jul 10, 2026 at 12:28:29PM -0700, Tanmay Shah wrote:
>>>> 512 bytes isn't always suitable for all case, let firmware
>>>> maker decide the best value from resource table.
>>>> enable by VIRTIO_RPMSG_F_BUFSZ feature bit.
>>>>
>>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>>> ---
>>>> Changes in v5:
>>>>
>>>> - fix documentation about alignment of the buffer size
>>>> - change version field from u16 to u8
>>>> - remove buffer alignment check
>>>> - Separate buffer alignment vs MTU of a single buffer
>>>> - Use buffer alignment only to get next buffer address at alignment
>>>> boundary
>>>>
>>>> Changes in v4:
>>>>
>>>> - Introduce new patch to modify rpmsg.rst documentation
>>>> - check version is always 1.
>>>> - check size field is same as size of struct virtio_rpmsg_config
>>>> - introduce alignment field
>>>> - check alignment field is power of 2
>>>> - check tx and rx buf size is aligned with alignment passed in the
>>>> structure
>>>>
>>>> Changes in v3:
>>>>
>>>> - change version field from u16 to u8
>>>> - introduce size field in the rpmsg_virtio_config structure
>>>> - check version field is set to any non-zero value.
>>>> - check size field is not 0.
>>>> - Remove field for private config, as not needed for now.
>>>> - add documentation of rpmsg_virtio_config structure
>>>>
>>>> drivers/rpmsg/virtio_rpmsg_bus.c | 130 ++++++++++++++++++++++++-----
>>>> include/linux/rpmsg/virtio_rpmsg.h | 48 +++++++++++
>>>> 2 files changed, 159 insertions(+), 19 deletions(-)
>>>> create mode 100644 include/linux/rpmsg/virtio_rpmsg.h
>>>>
>>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>> index c84b6cec9caf..5e5473f4adeb 100644
>>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>> @@ -15,11 +15,13 @@
>>>> #include <linux/idr.h>
>>>> #include <linux/jiffies.h>
>>>> #include <linux/kernel.h>
>>>> +#include <linux/log2.h>
>>>> #include <linux/module.h>
>>>> #include <linux/mutex.h>
>>>> #include <linux/rpmsg.h>
>>>> #include <linux/rpmsg/byteorder.h>
>>>> #include <linux/rpmsg/ns.h>
>>>> +#include <linux/rpmsg/virtio_rpmsg.h>
>>>> #include <linux/scatterlist.h>
>>>> #include <linux/slab.h>
>>>> #include <linux/sched.h>
>>>> @@ -39,7 +41,10 @@
>>>> * @tx_bufs: kernel address of tx buffers
>>>> * @num_rx_buf: total number of rx buffers
>>>> * @num_tx_buf: total number of tx buffers
>>>> - * @buf_size: size of one rx or tx buffer
>>>> + * @rx_buf_size: size of one rx buffer
>>>> + * @tx_buf_size: size of one tx buffer
>>>> + * @rx_buf_size_aligned: aligned size of one rx buffer
>>>> + * @tx_buf_size_aligned: aligned size of one tx buffer
>>>> * @last_tx_buf: index of last tx buffer used
>>>> * @bufs_dma: dma base addr of the buffers
>>>> * @tx_lock: protects svq and tx_bufs, to allow concurrent senders.
>>>> @@ -59,7 +64,10 @@ struct virtproc_info {
>>>> void *rx_bufs, *tx_bufs;
>>>> unsigned int num_rx_buf;
>>>> unsigned int num_tx_buf;
>>>> - unsigned int buf_size;
>>>> + unsigned int rx_buf_size;
>>>> + unsigned int tx_buf_size;
>>>> + unsigned int rx_buf_size_aligned;
>>>> + unsigned int tx_buf_size_aligned;
>>>> int last_tx_buf;
>>>> dma_addr_t bufs_dma;
>>>> struct mutex tx_lock;
>>>> @@ -68,9 +76,6 @@ struct virtproc_info {
>>>> wait_queue_head_t sendq;
>>>> };
>>>>
>>>> -/* The feature bitmap for virtio rpmsg */
>>>> -#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
>>>> -
>>>> /**
>>>> * struct rpmsg_hdr - common header for all rpmsg messages
>>>> * @src: source address
>>>> @@ -128,7 +133,7 @@ struct virtio_rpmsg_channel {
>>>> * processor.
>>>> */
>>>> #define MAX_RPMSG_NUM_BUFS (256)
>>>> -#define MAX_RPMSG_BUF_SIZE (512)
>>>> +#define DEFAULT_RPMSG_BUF_SIZE (512)
>>>>
>>>> /*
>>>> * Local addresses are dynamically allocated on-demand.
>>>> @@ -443,7 +448,7 @@ static void *get_a_tx_buf(struct virtproc_info *vrp)
>>>>
>>>> /* either pick the next unused tx buffer */
>>>> if (vrp->last_tx_buf < vrp->num_tx_buf)
>>>> - ret = vrp->tx_bufs + vrp->buf_size * vrp->last_tx_buf++;
>>>> + ret = vrp->tx_bufs + vrp->tx_buf_size_aligned * vrp->last_tx_buf++;
>>>> /* or recycle a used one */
>>>> else
>>>> ret = virtqueue_get_buf(vrp->svq, &len);
>>>> @@ -513,7 +518,7 @@ static int rpmsg_send_offchannel_raw(struct rpmsg_device *rpdev,
>>>> * messaging), or to improve the buffer allocator, to support
>>>> * variable-length buffer sizes.
>>>> */
>>>> - if (len > vrp->buf_size - sizeof(struct rpmsg_hdr)) {
>>>> + if (len > vrp->tx_buf_size - sizeof(struct rpmsg_hdr)) {
>>>> dev_err(dev, "message is too big (%d)\n", len);
>>>> return -EMSGSIZE;
>>>> }
>>>> @@ -646,7 +651,7 @@ static ssize_t virtio_rpmsg_get_mtu(struct rpmsg_endpoint *ept)
>>>> struct rpmsg_device *rpdev = ept->rpdev;
>>>> struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
>>>>
>>>> - return vch->vrp->buf_size - sizeof(struct rpmsg_hdr);
>>>> + return vch->vrp->tx_buf_size - sizeof(struct rpmsg_hdr);
>>>> }
>>>>
>>>> static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
>>>> @@ -672,7 +677,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
>>>> * We currently use fixed-sized buffers, so trivially sanitize
>>>> * the reported payload length.
>>>> */
>>>> - if (len > vrp->buf_size ||
>>>> + if (len > vrp->rx_buf_size ||
>>>> msg_len > (len - sizeof(struct rpmsg_hdr))) {
>>>> dev_warn(dev, "inbound msg too big: (%d, %d)\n", len, msg_len);
>>>> return -EINVAL;
>>>> @@ -705,7 +710,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
>>>> dev_warn_ratelimited(dev, "msg received with no recipient\n");
>>>>
>>>> /* publish the real size of the buffer */
>>>> - rpmsg_sg_init(&sg, msg, vrp->buf_size);
>>>> + rpmsg_sg_init(&sg, msg, vrp->rx_buf_size);
>>>>
>>>> /* add the buffer back to the remote processor's virtqueue */
>>>> err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, msg, GFP_KERNEL);
>>>> @@ -819,10 +824,13 @@ static int rpmsg_probe(struct virtio_device *vdev)
>>>> struct virtproc_info *vrp;
>>>> struct virtio_rpmsg_channel *vch = NULL;
>>>> struct rpmsg_device *rpdev_ns, *rpdev_ctrl;
>>>> + u16 rpmsg_buf_align = 0;
>>>> void *bufs_va;
>>>> int err = 0, i;
>>>> size_t total_buf_space;
>>>> bool notify;
>>>> + u8 version;
>>>> + u16 size;
>>>>
>>>> vrp = kzalloc_obj(*vrp);
>>>> if (!vrp)
>>>> @@ -854,9 +862,87 @@ static int rpmsg_probe(struct virtio_device *vdev)
>>>> else
>>>> vrp->num_tx_buf = MAX_RPMSG_NUM_BUFS;
>>>>
>>>> - vrp->buf_size = MAX_RPMSG_BUF_SIZE;
>>>> + /*
>>>> + * If VIRTIO_RPMSG_F_BUFSZ feature is supported, then configure buf
>>>> + * size from virtio device config space from the resource table.
>>>> + * If the feature is not supported, then assign default buf size.
>>>> + */
>>>> + if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_BUFSZ)) {
>>>> + virtio_cread(vdev, struct virtio_rpmsg_config,
>>>> + version, &version);
>>>> +
>>>> + /* for now we support only v1 */
>>>> + if (version != RPMSG_VDEV_CONFIG_V1) {
>>>> + dev_err(&vdev->dev,
>>>> + "unsupported vdev config version %u\n", version);
>>>> + err = -EINVAL;
>>>> + goto vqs_del;
>>>> + }
>>>> +
>>>> + /* size of the config space must match */
>>>> + virtio_cread(vdev, struct virtio_rpmsg_config,
>>>> + size, &size);
>>>> + if (size != sizeof(struct virtio_rpmsg_config)) {
>>>> + dev_err(&vdev->dev, "invalid size of vdev config %u\n",
>>>> + size);
>>>> + err = -EINVAL;
>>>> + goto vqs_del;
>>>> + }
>>>>
>>>> - total_buf_space = (vrp->num_rx_buf + vrp->num_tx_buf) * vrp->buf_size;
>>>> + /*
>>>> + * Optional alignment applied to each buffer size and to the TX
>>>> + * buffer base address (e.g. to align buffers on a cache line).
>>>> + * It must be a power of two; zero means no extra alignment.
>>>> + */
>>>> + virtio_cread(vdev, struct virtio_rpmsg_config,
>>>> + rpmsg_buf_align, &rpmsg_buf_align);
>>>> + if (rpmsg_buf_align && !is_power_of_2(rpmsg_buf_align)) {
>>>> + dev_err(&vdev->dev,
>>>> + "bad vdev config: rpmsg_buf_align %u is not a power of 2\n",
>>>> + rpmsg_buf_align);
>>>> + err = -EINVAL;
>>>> + goto vqs_del;
>>>> + }
>>>> +
>>>> + /* note: tx and rx are defined from remote view */
>>>> + virtio_cread(vdev, struct virtio_rpmsg_config,
>>>> + txbuf_size, &vrp->rx_buf_size);
>>>> + virtio_cread(vdev, struct virtio_rpmsg_config,
>>>> + rxbuf_size, &vrp->tx_buf_size);
>>>> +
>>>> + /* The buffers must hold at least the rpmsg header */
>>>> + if (vrp->rx_buf_size < sizeof(struct rpmsg_hdr) ||
>>>> + vrp->tx_buf_size < sizeof(struct rpmsg_hdr)) {
>>>> + dev_err(&vdev->dev,
>>>> + "bad vdev config: rx buf sz = %u, tx buf sz = %u\n",
>>>> + vrp->rx_buf_size, vrp->tx_buf_size);
>>>> + err = -EINVAL;
>>>> + goto vqs_del;
>>>> + }
>>>> +
>>>> + if (rpmsg_buf_align) {
>>>> + vrp->rx_buf_size_aligned = ALIGN(vrp->rx_buf_size,
>>>> + rpmsg_buf_align);
>>>> + vrp->tx_buf_size_aligned = ALIGN(vrp->tx_buf_size,
>>>> + rpmsg_buf_align);
>>>> + } else {
>>>> + vrp->rx_buf_size_aligned = vrp->rx_buf_size;
>>>> + vrp->tx_buf_size_aligned = vrp->tx_buf_size;
>>>> + }
>>>> +
>>>> + dev_dbg(&vdev->dev,
>>>> + "vdev config: ver=%u, align=0x%x, rx sz = 0x%x, tx sz = 0x%x\n",
>>>> + version, rpmsg_buf_align, vrp->rx_buf_size,
>>>> + vrp->tx_buf_size);
>>>> + } else {
>>>> + vrp->rx_buf_size = DEFAULT_RPMSG_BUF_SIZE;
>>>> + vrp->tx_buf_size = DEFAULT_RPMSG_BUF_SIZE;
>>>> + vrp->rx_buf_size_aligned = vrp->rx_buf_size;
>>>> + vrp->tx_buf_size_aligned = vrp->tx_buf_size;
>>>> + }
>>>> +
>>>> + total_buf_space = (vrp->num_rx_buf * vrp->rx_buf_size_aligned) +
>>>> + (vrp->num_tx_buf * vrp->tx_buf_size_aligned);
>>>>
>>>> /* allocate coherent memory for the buffers */
>>>> bufs_va = dma_alloc_coherent(vdev->dev.parent,
>>>> @@ -873,15 +959,20 @@ static int rpmsg_probe(struct virtio_device *vdev)
>>>> /* first part of the buffers is dedicated for RX */
>>>> vrp->rx_bufs = bufs_va;
>>>>
>>>> - /* and second part is dedicated for TX */
>>>> - vrp->tx_bufs = bufs_va + vrp->num_rx_buf * vrp->buf_size;
>>>> + /*
>>>> + * Here buf_va is aligned to a page. Also rx buf size is aligned with
>>>> + * cache line alignment provided by the firmware, so tx buf's start
>>>> + * address is guranteed to be aligned with the alignment provided by
>>>> + * the firmware.
>>>> + */
>>>> + vrp->tx_bufs = bufs_va + (vrp->num_rx_buf * vrp->rx_buf_size_aligned);
>>>>
>>>> /* set up the receive buffers */
>>>> for (i = 0; i < vrp->num_rx_buf; i++) {
>>>> struct scatterlist sg;
>>>> - void *cpu_addr = vrp->rx_bufs + i * vrp->buf_size;
>>>> + void *cpu_addr = vrp->rx_bufs + i * vrp->rx_buf_size_aligned;
>>>>
>>>> - rpmsg_sg_init(&sg, cpu_addr, vrp->buf_size);
>>>> + rpmsg_sg_init(&sg, cpu_addr, vrp->rx_buf_size);
>>>>
>>>> err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, cpu_addr,
>>>> GFP_KERNEL);
>>>> @@ -964,8 +1055,8 @@ static int rpmsg_remove_device(struct device *dev, void *data)
>>>> static void rpmsg_remove(struct virtio_device *vdev)
>>>> {
>>>> struct virtproc_info *vrp = vdev->priv;
>>>> - unsigned int num_bufs = vrp->num_rx_buf + vrp->num_tx_buf;
>>>> - size_t total_buf_space = num_bufs * vrp->buf_size;
>>>> + size_t total_buf_space = (vrp->num_rx_buf * vrp->rx_buf_size_aligned) +
>>>> + (vrp->num_tx_buf * vrp->tx_buf_size_aligned);
>>>> int ret;
>>>>
>>>> virtio_reset_device(vdev);
>>>> @@ -991,6 +1082,7 @@ static struct virtio_device_id id_table[] = {
>>>>
>>>> static unsigned int features[] = {
>>>> VIRTIO_RPMSG_F_NS,
>>>> + VIRTIO_RPMSG_F_BUFSZ,
>>>> };
>>>>
>>>> static struct virtio_driver virtio_ipc_driver = {
>>>> diff --git a/include/linux/rpmsg/virtio_rpmsg.h b/include/linux/rpmsg/virtio_rpmsg.h
>>>> new file mode 100644
>>>> index 000000000000..735a947d5582
>>>> --- /dev/null
>>>> +++ b/include/linux/rpmsg/virtio_rpmsg.h
>>>> @@ -0,0 +1,48 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>> +/*
>>>> + * Copyright (C) Pinecone Inc. 2019
>>>> + * Copyright (C) Xiang Xiao <xiaoxiang@pinecone.net>
>>>> + * Copyright (C) Advanced Micro Devices, Inc. 2026
>>>> + */
>>>> +
>>>> +#ifndef _LINUX_VIRTIO_RPMSG_H
>>>> +#define _LINUX_VIRTIO_RPMSG_H
>>>> +
>>>> +#include <linux/types.h>
>>>> +#include <linux/virtio_types.h>
>>>> +
>>>> +/* The feature bitmap for virtio rpmsg */
>>>> +#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
>>>> +#define VIRTIO_RPMSG_F_BUFSZ 1 /* RP get buffer size from config space */
>>>> +
>>>> +/* Version of struct virtio_rpmsg_config understood by this driver */
>>>> +#define RPMSG_VDEV_CONFIG_V1 1
>>>> +
>>>> +/**
>>>> + * struct virtio_rpmsg_config - config space for rpmsg virtio device
>>>> + *
>>>> + * @version: version of this structure, currently %RPMSG_VDEV_CONFIG_V1.
>>>> + * @size: size of this structure in bytes.
>>>> + * @rpmsg_buf_align: alignment in bytes for each buffer. Must be a power of
>>>> + * two. If 0 then no alignment will be done. This alignment
>>>> + * will not decide actual size of the buffer but will be
>>>> + * used to decided the start address of the buffer. The
>>>> + * actual size of the buffer can be different than the
>>>> + * aligned size of the buffer.
>>>
>>> Is there really a need to have a buffer size different from its alignment? It's
>>> not like the (small) delta between the buffer size and its alignment will be
>>> used for something else. I'm fine with a buffer alignment requirement but in
>>> those cases, the firmware should set the size of the buffer in accordance with
>>> its alignment requirement. Otherwise, the complexity needed to manage the
>>> discrpancy between the two yields a driver that is hard to maintain and prone to
>>> bugs.
>>
>> I would be in favor to keep it.
>>
>> The remote processor could expose some alignment constraints. The Linux
>> kernel
>> or another main processor OS can have its own constraints. As it
>> allocates the
>> buffers, it can decide the final alignment independently of the buffer
>> sizes.
>>
>> An example is a remote processor without a cache and a main processor with a
>> cache. rpmsg_buf_align could be set to 0, but the main processor could
>> decide to
>> align buffer addresses on a cache line.
>
> But is there an immediate need for that? I'm all for it if there is a
> legitimate use case where we know exactly what the constraints are.
> If not we are adding complexity that may, or may not, be able to
> address hypothetical constraints.
>
It is difficult to determine all customer usage...
what I can say is that cache support is native in the OpenAMP library,
and Zephyr already allows it for virtio/RPMsg buffers. For performance
reasons, using cache alignment with the no-copy option can make sense.
Concerning your proposal, “Set the buffer size in accordance with its
alignment requirement,” could be an option, but it introduces an
implicit rule, whereas an alignment field is more explicit.
Moreover, this does not seem reliable. After rereading the Virtio spec
1.3 [1] I found the following sentence:
“The driver performs device-specific setup, including discovery of
virtqueues for the device, optional per-bus setup, reading and possibly
writing the device’s virtio configuration space.”
We cannot prevent the main processor from adjusting the buffer sizes
according to its own constraints, which would break the implicit
alignment. Negotiating an alignment field seems more robust to me.
In this patch, the Linux kernel simply aligns with the remote
processor’s constraints, so the implementation is not very complex.
However, it still allows alternative implementations in other OSes or
libraries.
[1]https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-1230001
>> Thanks,
>> Arnaud
>>
>>>
>>>> + * @txbuf_size: Tx buf size from remote's view. For Linux this is rx buf size.
>>>> + * @rxbuf_size: Rx buf size from remote's view. For Linux this is tx buf size.
>>>> + *
>>>> + * This is the configuration structure shared by the device and the driver,
>>>> + * read when %VIRTIO_RPMSG_F_BUFSZ is negotiated. The fields are laid out so
>>>> + * the structure is naturally 32-bit aligned.
>>>> + */
>>>> +struct virtio_rpmsg_config {
>>>> + u8 version;
>>>> + __virtio16 size;
>>>> + __virtio16 rpmsg_buf_align;
>>>> + /* The tx/rx individual buffer size (if VIRTIO_RPMSG_F_BUFSZ) */
>>>> + __virtio32 txbuf_size;
>>>> + __virtio32 rxbuf_size;
>>>> +} __packed;
>>>> +
>>>> +#endif /* _LINUX_VIRTIO_RPMSG_H */
>>>> --
>>>> 2.34.1
>>>>
>>>
>>
^ permalink raw reply
* Re: [PATCH v8 09/46] KVM: guest_memfd: Introduce function to check GFN private/shared status
From: Ackerley Tng @ 2026-07-16 17:20 UTC (permalink / raw)
To: Binbin Wu
Cc: aik, andrew.jones, brauner, chao.p.peng, david, jmattson,
jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, tabba, willy,
wyihan, yan.y.zhao, forkloop, pratyush, suzuki.poulose,
aneesh.kumar, liam, Paolo Bonzini, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt, Kiryl Shutsemau,
Baoquan He, Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <1b59fec2-a464-4429-8532-880394912af5@linux.intel.com>
Binbin Wu <binbin.wu@linux.intel.com> writes:
> On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote:
>> From: Ackerley Tng <ackerleytng@google.com>
>>
>> Introduce function for KVM to check the private/shared status of guest
> ^
> Nit: a
> > memory at a given GFN.
>>
For v9, I added the "a" in the commit messsage body but retained
"Introduce function" in the header (save characters, and make it sound
like a headline).
>>
>> [...snip...]
>>
^ permalink raw reply
* Re: [PATCH v6 1/5] spi: dt-bindings: Add spi-device-addr peripheral property
From: Conor Dooley @ 2026-07-16 17:06 UTC (permalink / raw)
To: Mark Brown
Cc: Nuno Sá, 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: <0e3e45fe-4c34-45d0-b985-0938f60b5914@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1961 bytes --]
On Thu, Jul 16, 2026 at 01:28:15PM +0100, Mark Brown wrote:
> On Thu, Jul 16, 2026 at 11:22:19AM +0200, Nuno Sá wrote:
> > On Wed, Jul 15, 2026 at 02:37:12PM +0100, Mark Brown wrote:
>
> > > 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.
>
> > Not sure if I'm following you. Those ID pins just become something you
> > need to set on the spi_xfer. Or in Janani case, she's using regmap
> > reg_base in order to set the right thing depending on the address. I
> > would image this is always something that peripherals need to address in
> > terms of how the message/stream needs to be set. So my understanding is
> > that this should be pretty much transparent for the spi core.
>
> Oh, isn't that just multi-pin chip selects then:
>
> https://patch.msgid.link/cover.1783729282.git.Jonathan.Santos@analog.com
No, I think that's something different.
In this case, there is one chip select that all instances of the device
share. Both the ADI and Microchip devices then use the upper bits of the
first/address byte during reads and write to access individual devices.
In the microchip case that I'm familiar with, what upper bits the device
responds to are set by fuses in the factory. They also share the same MOSI
and MISO.
https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/MCP3911-3.3V-Two-Channel-Analog-Front-End-DS20002286D.pdf
(See Figure 6-1 and section 6.2 on page 43)
The SPI core already supports two of these devices from Microchip, since
it just modifies the contents of tx_buf in a spi_transfer.
What Jonathan is working on seems to be a setup where they have multiple
instances of a device with their own chip selects and their own MISO, but
a shared SCLK and MOSI.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/4] mm/hmm: Clarify notifier retry state and scope HMM timeouts
From: Stanislav Kinsburskii @ 2026-07-16 16:37 UTC (permalink / raw)
To: Lorenzo Stoakes (ARM)
Cc: David Hildenbrand (Arm), Andrew Morton, airlied, akhilesh, corbet,
dakr, jgg, kees, leon, liam, lizhi.hou, 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: <aligdOKNwoOtD4io@lucifer>
On Thu, Jul 16, 2026 at 10:12:56AM +0100, Lorenzo Stoakes (ARM) wrote:
> On Thu, Jul 16, 2026 at 10:59:56AM +0200, David Hildenbrand (Arm) wrote:
> > On 7/15/26 19:14, Andrew Morton wrote:
> > > On Wed, 15 Jul 2026 09:39:37 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > >
> > >>>
> > >>> Please don't do this, this is completely impossible to track for review :)
> > >>>
> > >>> mm review is currently very difficult based on volumes, it'll become impossible
> > >>> to manage if people sound fragments of series.
> > >>>
> > >>> Please just resend the whole thing at this point.
> > >>>
> > >>
> > >> Well, I followed the guidance provided by Andrew, and I believe he
> > >> applied all of the changes, including these, to the `mm` tree.
> > >>
> > >> Do you still want me to send v9 under these circumstances?
> > >
> > > Sure, if that's what reviewers prefer.
> > >
> > > This is a bit unfriendly to people who have already reviewed the code.
> > > Which is one of the reasons why I respond to a new version with a
> > > single diff showing reviewers (and the author, and myself) what changed
> > > since the previous version.
> >
> > As much as I dislike fixup patches, I tolerate them in reply to the existing series.
> >
> > But having some random fixup series is just crazy, really.
> >
> > --
> > Cheers,
> >
> > David
>
> Yes.
>
> Stanislav - also see Jason's suggestion - if you give a base commit then sashiko
> seems to work better. Maybe look at using b4 which does all of this for you
> automatically?
>
Sure. Thank you all for the suggestions. I'll use b4 next time.
Thanks,
Stanislav
> Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH] Documentation: Extend the real-time hardware bits with some firmware bits
From: Sebastian Andrzej Siewior @ 2026-07-16 16:13 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: jenswi@kernel.org, linux-rt-devel, linux-doc, linux-efi, op-tee,
Ard Biesheuvel, Clark Williams, Jan Kiszka, Jonathan Corbet,
Shuah Khan, Steven Rostedt, John Ogness
In-Reply-To: <CAC_iWjLO3CAAFXE3s15Xcy3pWFK3ge5sWYmHHRBtcccKM2e1hw@mail.gmail.com>
On 2026-07-10 10:53:16 [+0300], Ilias Apalodimas wrote:
> > > > +Execution flows from the normal world (Linux) into the secure world (OP‑TEE)
> > > > +through the secure monitor at EL3. Linux and OP‑TEE cannot disable or mask each
> > > > +other’s interrupts because both run at EL1 in different security states.
> > >
> > > That's not always true. It depends on a combination of OP-TEE and TF-A
> > > configs iirc.
> > > The most common though is that IRQs and FIQs are directly delivered to
> > > S-EL1, in which case OP-TEE can mask IRQs.
> > > There's also a difference between GICv2 and GICv3 in the way
> > > interrupts are delivered.
> >
> > You are saying that OP-TEE can mask Linux' interrupts or if OP-TEE
> > instructs TF-A to do so (via config)?
>
> OP-TEE can mask Linux IRQs
So what I got so far:
- linux has access to the normal world (not secure group 1)
- OP-TEE has access to the secure world (secure group 1)
This is for routing. And only secure world can manage secure and
non-secure its non-secure.
https://developer.arm.com/documentation/198123/0302/Configuring-the-Arm-GIC
But then we have ICC_PMR_EL1 to enable/ disable interrupts based on the
priority and non-secure has limited priority range while secure has a
wider range. It can disable non-secure interrupts. And it took me a
while to get the right document and find this section:
| The GIC security model provides Secure and Non-secure accesses to the
| interrupt priority settings.The Non-secure accesses can configure
| interrupts only in the lower priority half of the supported priority
| values. Therefore, if the GIC implements 32 priority values, Non-secure
| accesses see only 16 priority values.
Good. Let me update so it matches the reality more closely…
Sebastian
^ permalink raw reply
* Re: [PATCH v5 3/5] rpmsg: virtio_rpmsg_bus: get buffer size from config space
From: Shah, Tanmay @ 2026-07-16 16:12 UTC (permalink / raw)
To: Mathieu Poirier, tanmay.shah
Cc: andersson, corbet, skhan, linux-remoteproc, linux-doc,
linux-kernel
In-Reply-To: <CANLsYkyL8_YSb39QqbC0Z+udahMtCV1e+OeoKGvmGSxQ6h3_qA@mail.gmail.com>
On 7/16/2026 10:48 AM, Mathieu Poirier wrote:
> On Wed, 15 Jul 2026 at 11:28, Shah, Tanmay <tanmays@amd.com> wrote:
>>
>> Hi,
>>
>> Please find my response below:
>>
>> On 7/15/2026 11:24 AM, Mathieu Poirier wrote:
>>> On Fri, Jul 10, 2026 at 12:28:29PM -0700, Tanmay Shah wrote:
>>>> 512 bytes isn't always suitable for all case, let firmware
>>>> maker decide the best value from resource table.
>>>> enable by VIRTIO_RPMSG_F_BUFSZ feature bit.
>>>>
>>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>>> ---
>>>> Changes in v5:
>>>>
>>>> - fix documentation about alignment of the buffer size
>>>> - change version field from u16 to u8
>>>> - remove buffer alignment check
>>>> - Separate buffer alignment vs MTU of a single buffer
>>>> - Use buffer alignment only to get next buffer address at alignment
>>>> boundary
>>>>
>>
>> [...]
>>
>>>> +#ifndef _LINUX_VIRTIO_RPMSG_H
>>>> +#define _LINUX_VIRTIO_RPMSG_H
>>>> +
>>>> +#include <linux/types.h>
>>>> +#include <linux/virtio_types.h>
>>>> +
>>>> +/* The feature bitmap for virtio rpmsg */
>>>> +#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
>>>> +#define VIRTIO_RPMSG_F_BUFSZ 1 /* RP get buffer size from config space */
>>>> +
>>>> +/* Version of struct virtio_rpmsg_config understood by this driver */
>>>> +#define RPMSG_VDEV_CONFIG_V1 1
>>>> +
>>>> +/**
>>>> + * struct virtio_rpmsg_config - config space for rpmsg virtio device
>>>> + *
>>>> + * @version: version of this structure, currently %RPMSG_VDEV_CONFIG_V1.
>>>> + * @size: size of this structure in bytes.
>>>> + * @rpmsg_buf_align: alignment in bytes for each buffer. Must be a power of
>>>> + * two. If 0 then no alignment will be done. This alignment
>>>> + * will not decide actual size of the buffer but will be
>>>> + * used to decided the start address of the buffer. The
>>>> + * actual size of the buffer can be different than the
>>>> + * aligned size of the buffer.
>>>
>>> Is there really a need to have a buffer size different from its alignment? It's
>>> not like the (small) delta between the buffer size and its alignment will be
>>> used for something else. I'm fine with a buffer alignment requirement but in
>>> those cases, the firmware should set the size of the buffer in accordance with
>>> its alignment requirement. Otherwise, the complexity needed to manage the
>>> discrpancy between the two yields a driver that is hard to maintain and prone to
>>> bugs.
>>>
>>
>> I had the same concern before. However, following example changed my mind:
>>
>> So, a single buffer size is the MTU size of a packet for the protocol
>> supported by the firmware. Now that can be different than the aligned
>> size of the buffer.
>>
>> For example, the higher level protocol (not rpmsg) has 430 bytes as the
>> max size of a payload. However, cache line alignment is 64-bytes. Then
>> in that case, the aligned buffer size is 448 bytes. But, that doesn't
>> mean we can say protocol's MTU size is 448 bytes. If user end up
>> treating MTU size 448 bytes and use space beyond 430 bytes, then the
>> higher level apps might discard that data and communication may fail.
>>
>
> How is that scenario different from today's 512 byte buffer size?
> Most users don't use all 512 bytes and we don't run in the problem
> described above?
>
512 buffer size is hardcoded, so it is enforced on the protocol by the
framework. But by allowing the configuration of the buffer size we are
allowing the protocol to decide what the buffer size should be. So, when
user request the buffer via rpmsg_get_mtu() API, then that should be the
original buffer size which is expected by the protocol, which may not be
same as the aligned buffer size.
If for internal management we want to treat buffer size = aligned buffer
size, I am okay. But rpmsg_get_mtu() must give unaligned buffer size
which is expected by the protocol.
Thanks,
Tanmay
>> The alignment field is used only to decide where the next buffer start
>> address is to ease cache operations.
>>
>> Sure, we need to maintain this complexity, but I think it's worth it.
>>
>
> The same as in my previous email to Arnaud applies here - is this an
> immediate requirement of something we think may be happening in the
> future?
>
IMHO, vendors will use it if the feature is available, otherwise the
need to optimize alignment is not easily encountered.
>
>> Thanks,
>> Tanmay
>>
>>>> + * @txbuf_size: Tx buf size from remote's view. For Linux this is rx buf size.
>>>> + * @rxbuf_size: Rx buf size from remote's view. For Linux this is tx buf size.
>>>> + *
>>>> + * This is the configuration structure shared by the device and the driver,
>>>> + * read when %VIRTIO_RPMSG_F_BUFSZ is negotiated. The fields are laid out so
>>>> + * the structure is naturally 32-bit aligned.
>>>> + */
>>>> +struct virtio_rpmsg_config {
>>>> + u8 version;
>>>> + __virtio16 size;
>>>> + __virtio16 rpmsg_buf_align;
>>>> + /* The tx/rx individual buffer size (if VIRTIO_RPMSG_F_BUFSZ) */
>>>> + __virtio32 txbuf_size;
>>>> + __virtio32 rxbuf_size;
>>>> +} __packed;
>>>> +
>>>> +#endif /* _LINUX_VIRTIO_RPMSG_H */
>>>> --
>>>> 2.34.1
>>>>
>>
^ permalink raw reply
* Re: [PATCH bpf-next v5 8/8] selftests: net: add test for XDP_PASS skb checksum invalidation
From: Lorenzo Bianconi @ 2026-07-16 16:06 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Andrew Lunn, Tony Nguyen, Przemek Kitszel, Alexander Lobakin,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Shuah Khan,
Maciej Fijalkowski, Jonathan Corbet, Shuah Khan,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Vladimir Vdovin,
Jakub Sitnicki, netdev, bpf, intel-wired-lan, linux-kselftest,
linux-doc
In-Reply-To: <aljNR2sf8qJVKFgb@devvm7509.cco0.facebook.com>
[-- Attachment #1: Type: text/plain, Size: 3751 bytes --]
On Jul 16, Stanislav Fomichev wrote:
> On 07/15, Lorenzo Bianconi wrote:
> > Add a test that verifies skb->ip_summed is set to CHECKSUM_NONE
> > when a device running in XDP mode creates an skb from a xdp_buff
> > if the attached ebpf program returns an XDP_PASS.
> > The test attaches an XDP program returning XDP_PASS, and a TC
> > ingress program that runs the bpf_skb_rx_checksum() kfunc to
> > inspect the resulting skb. After XDP_PASS the driver must invalidate
> > any previously computed hardware RX checksum since XDP may have
> > modified the packet data.
> > The BPF program counts packets per checksum type in a map, and the
> > test runner verifies that after sending traffic the CHECKSUM_NONE
> > counter is non-zero while CHECKSUM_UNNECESSARY and CHECKSUM_COMPLETE
> > counters are zero.
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > Documentation/networking/xdp-rx-metadata.rst | 5 ++
> > .../selftests/drivers/net/hw/xdp_metadata.py | 55 +++++++++++++++-
> > .../selftests/net/lib/skb_metadata_csum.bpf.c | 73 ++++++++++++++++++++++
> > 3 files changed, 132 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/networking/xdp-rx-metadata.rst b/Documentation/networking/xdp-rx-metadata.rst
> > index 93918b3769a3..7434ac98242a 100644
> > --- a/Documentation/networking/xdp-rx-metadata.rst
> > +++ b/Documentation/networking/xdp-rx-metadata.rst
> > @@ -90,6 +90,11 @@ conversion, and the XDP metadata is not used by the kernel when building
> > ``skbs``. However, TC-BPF programs can access the XDP metadata area using
> > the ``data_meta`` pointer.
>
> [..]
>
> > +If a driver is running in XDP mode, any existing hardware RX checksum
> > +(``CHECKSUM_UNNECESSARY`` or ``CHECKSUM_COMPLETE``) must be invalidated
> > +by setting ``skb->ip_summed`` to ``CHECKSUM_NONE`` before passing the
> > +skb to the kernel, since XDP may have modified the packet data.
> > +
> > In the future, we'd like to support a case where an XDP program
> > can override some of the metadata used for building ``skbs``.
>
> Sorry for keeping nitpicking on this, but I'm still not convinced that
> it is what we currently do. From my previous reply:
no worries :)
My current take-away from the previous discussion is we just need to document
what would be the driver expected behaviour adding a kselftest for it (without
modifying any driver).
>
> > > Looking at a few drivers:
> > > - bnxt (bnxt_rx_pkt) does UNNECESSARY - ok
> > > - mlx5 (mlx5e_handle_csum) does UNNECESSARY and skips COMPLETE if there is
> > > bpf prog attached
> > > - fbnic (fbnic_rx_csum) - can do COMPLETE even with xdp attached?
> > > - gve (gve_rx) - can do COMPLETE even with xdp attached?
>
> (although for gve I might be wrong, there is also gve_rx_skb_csum that only
> does UNNECESSARY).
>
> I'd wait for Jakub to chime in, but it feels like we should just document
> what we currently do as a recommended approach: for the drivers
> that support COMPLETE, do not report it when the bpf program is attached.
> Both NONE and UNNECESSARY are ok.
I am not completely sure the UNNECESSARY case is different from the COMPLETE
one. What are we supposed to do if the driver reports UNNECESSARY and the ebpf
program modifies some fields covered by the rx-checksum?
>
> Also, did you run this test on real HW? NIPA now has HW tests, maybe it
> makes sense to route this series via net-next to get the real coverage?
What about splitting this series and have two different series:
- bpf-next: add xdp rx kfunc and related selftest
- net-next: add kselftest for the driver expected behaviour.
What do you think?
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 12/24] fork: let kernel callers create embryonic tasks
From: Andy Lutomirski @ 2026-07-16 15:57 UTC (permalink / raw)
To: Li Chen
Cc: Christian Brauner, Kees Cook, Gabriel Krisman Bertazi,
Josh Triplett, Mateusz Guzik, Andy Lutomirski, John Ericson,
Jonathan Corbet, Shuah Khan, Arnd Bergmann, Oleg Nesterov,
Andrew Morton, Paul Moore, Eric Paris, Mickaël Salaün,
Günther Noack, Alexander Viro, Jan Kara, linux-api,
linux-fsdevel, linux-kernel, linux-kselftest, linux-doc, audit,
linux-security-module, linux-arch, linux-mm
In-Reply-To: <538e494dd8fcc677da24ec985c6e90dde554e7f3.1784204592.git.me@linux.beauty>
On Thu, Jul 16, 2026 at 8:52 AM Li Chen <me@linux.beauty> wrote:
>
> A kernel-created task can become visible before it has installed a new
> executable image or a valid userspace register frame. Exposing such a task
> through ptrace can disclose kernel setup state.
>
> Add a task-local embryonic flag and an internal clone argument for callers
> that need this lifecycle. Reject ptrace access until the creator clears the
> flag. Clear it with release ordering and observe it with acquire ordering.
> This orders visibility of the completed exec state with the transition.
>
> Existing fork, vfork, clone, and kernel-thread callers leave the argument
> unset and retain their current behavior.
>
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -56,6 +56,8 @@ bool ptracer_access_allowed(struct task_struct *tsk)
> guard(rcu)();
> if (ptrace_parent(tsk) != current)
> return false;
> + if (task_is_embryonic_exec(tsk))
> + return false;
> es = task_exec_state_rcu(tsk);
> return READ_ONCE(es->dumpable) == TASK_DUMPABLE_OWNER ||
> ptracer_capable(tsk, es->user_ns);
> @@ -312,6 +314,8 @@ static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> WARN(1, "denying ptrace access check without PTRACE_MODE_*CREDS\n");
> return -EPERM;
> }
> + if (task_is_embryonic_exec(task))
> + return -EPERM;
Would it be better to use a different error code? -ECONNREFUSED?
After all, this isn't a permission failure per se.
There's a not-locally-obvious gotcha here: reading other process
attributes prior to calling task_is_embryonic_exec may result in
(security-relevant!) data races. This should at least be documented
-- it's critical to check task_is_embryonic_exec *before* trying to
read credentials. Also, I think /proc and many pidfd APIs have the
same issue.
--Andy
^ permalink raw reply
* Re: [PATCH v3 5/6] printk: nbcon: move printk_delay to console emiting code
From: Petr Mladek @ 2026-07-16 15:52 UTC (permalink / raw)
To: Andrew Murray
Cc: Steven Rostedt, John Ogness, Sergey Senozhatsky, Jonathan Corbet,
Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Andrew Morton, Greg Kroah-Hartman, Sebastian Andrzej Siewior,
Clark Williams, linux-kernel, linux-doc, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <20260712-printkcleanup-v3-5-574547b8f71b@thegoodpenguin.co.uk>
On Sun 2026-07-12 11:20:36, Andrew Murray wrote:
> The printk_delay and boot_delay features are helpful for debugging
> as kernel output can be slowed down during boot allowing messages to
> be seen before scrolling off the screen, or to correlate timing between
> some physical event and console output.
>
> However, since the introduction of nbcon and the legacy printer thread
> for PREEMPT_RT kernels, printk records are now emited to the console
> asynchronously to the caller of printk. Thus, any printk delay added by
> boot_delay/printk_delay continues to slow down the calling process but
> may not have any impact to the rate in which records are emited to the
> console.
>
> Let's address this by moving the printk delay from the calling code
> to the console emiting code instead. Whilst this ensures that delays
> are still observed (especially for slower consoles), it doesn't improve
> the use-case of using boot_delay/printk_delay to correlate timings
> between physical events and console output.
>
> Behavior change:
>
> Please note that printk delays now occur after messages are emitted
> rather than before.
>
> Please also note that the printk delays occur within the printk_safe
> (irqs off) context.
>
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -266,6 +266,8 @@ struct printk_buffers;
> * might cause a system freeze when the console
> * is used later.
> * @backlog: Ringbuffer has pending records
> + * @emitted: The context attempted to emit the message. Might
> + * be incomplete.
> * @pbufs: Pointer to the text buffer for this context
> * @seq: The sequence number to print for this context
> */
> @@ -278,6 +280,7 @@ struct nbcon_context {
>
> /* members set by emit */
> unsigned int backlog : 1;
> + unsigned char emitted : 1;
We should be consistent. Note that there is one more
"allow_unsafe_takeover" bit defined above.
Maybe, the "unsigned int" was a waste of space. I do not see any
technical reason to keep it. But we should switch the existing
members in a separate patch. It might help bisecting eventual
problems, ...
> /* members set by acquire */
> struct printk_buffers *pbufs;
> @@ -298,7 +301,7 @@ struct nbcon_write_context {
> struct nbcon_context __private ctxt;
> char *outbuf;
> unsigned int len;
> - bool unsafe_takeover;
> + unsigned char unsafe_takeover : 1;
Makes perfect sense. But it should be done in a separate patch. We
should not hide this in complex patches. It will most likely
just work. But there is always a tiny risk that such changes
might cause regression or unveil an existing problem which was
hidded before.
> #ifdef CONFIG_PRINTK_EXECUTION_CTX
> int cpu;
> pid_t pid;
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1267,11 +1269,16 @@ static int nbcon_kthread_func(void *__console)
>
> con_flags = console_srcu_read_flags(con);
>
> + ctxt->emitted = 0;
> +
> if (console_is_usable(con, con_flags, false))
> backlog = nbcon_emit_one(&wctxt, false);
>
> console_srcu_read_unlock(cookie);
>
> + if (backlog && ctxt->emitted)
> + printk_delay(false);
This should be:
/*
* This is a compromise between reliability and effectiveness.
* A less intrusive sleeping wait might be used here. But
* the released nbcon context allows to print one more message
* in an emergency or panic context immediately. But
* next messages in these contexts will have its own delay.
*/
if (ctxt->emitted)
printk_delay(false);
We need to check only ctxt->emitted. Otherwise, the delay would be
skipped for the last message. It would be bad when messages are added
slow-enough so that the kthread can emit them immediately and
the delay is always skipped. But it still might be too fast for a
human reader.
> +
> cond_resched();
>
> } while (backlog);
> @@ -1525,6 +1532,8 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
> }
>
> progress = nbcon_emit_one(&wctxt, use_atomic);
> + if (progress && ctxt->emitted)
> + printk_delay(use_atomic);
Same here:
if (ctxt->emitted)
printk_delay(use_atomic);
>
> if (use_atomic) {
> start_critical_timings();
> @@ -1584,6 +1593,8 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> if (!nbcon_context_try_acquire(ctxt, false))
> return -EPERM;
>
> + ctxt->emitted = 0;
> +
> /*
> * nbcon_emit_next_record() returns false when
> * the console was handed over or taken over.
> @@ -1600,6 +1611,8 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> if (nbcon_seq_read(con) < stop_seq)
> err = -ENOENT;
> break;
> + } else if (ctxt->emitted) {
> + printk_delay(true);
Similar here. We need something like:
if (ctxt->emitted) {
printk_delay(true);
if (!ctxt->backlog) {
/* Are there reserved but not yet finalized records? */
if (nbcon_seq_read(con) < stop_seq)
err = -ENOENT;
break;
}
> }
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 4517266e9ca112e0dcb0163a99dd0e8d50931848..5df09e56cf8abc2d0555b6950eed4e483ba56d4b 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3206,6 +3205,7 @@ static bool console_emit_next_record(struct console *con, bool *handover, int co
> printk_legacy_allow_spinlock_enter();
> con->write(con, outbuf, pmsg.outbuf_len);
> printk_legacy_allow_spinlock_exit();
> + printk_delay(true);
>
> start_critical_timings();
>
The rest looks good to me.
Well, the bool parameters are always hard to follow. I would prefer to
create two wrappers. They might be defined in kernel/printk/internal.h
static inline void printk_delay_atomic(void)
{
printk_delay(true);
}
static inline void printk_delay_thread(void)
{
printk_delay(false);
}
Or maybe rename the original printk_delay() to __printk_delay().
And use:
static inline void printk_delay_atomic(void)
{
printk_delay(true);
}
static inline void printk_delay(void)
{
printk_delay(false);
}
Finally, Sashiko AI pointed out that the delay is newly done while
holding console_sem and might trigger lockup detector warning, see
https://sashiko.dev/#/patchset/20260712-printkcleanup-v3-0-574547b8f71b%40thegoodpenguin.co.uk
I would ignore it until we see real-life problems.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v5 3/5] rpmsg: virtio_rpmsg_bus: get buffer size from config space
From: Mathieu Poirier @ 2026-07-16 15:48 UTC (permalink / raw)
To: tanmay.shah
Cc: andersson, corbet, skhan, linux-remoteproc, linux-doc,
linux-kernel
In-Reply-To: <66e4a85c-be14-4bd8-8328-bf17d2437994@amd.com>
On Wed, 15 Jul 2026 at 11:28, Shah, Tanmay <tanmays@amd.com> wrote:
>
> Hi,
>
> Please find my response below:
>
> On 7/15/2026 11:24 AM, Mathieu Poirier wrote:
> > On Fri, Jul 10, 2026 at 12:28:29PM -0700, Tanmay Shah wrote:
> >> 512 bytes isn't always suitable for all case, let firmware
> >> maker decide the best value from resource table.
> >> enable by VIRTIO_RPMSG_F_BUFSZ feature bit.
> >>
> >> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> >> ---
> >> Changes in v5:
> >>
> >> - fix documentation about alignment of the buffer size
> >> - change version field from u16 to u8
> >> - remove buffer alignment check
> >> - Separate buffer alignment vs MTU of a single buffer
> >> - Use buffer alignment only to get next buffer address at alignment
> >> boundary
> >>
>
> [...]
>
> >> +#ifndef _LINUX_VIRTIO_RPMSG_H
> >> +#define _LINUX_VIRTIO_RPMSG_H
> >> +
> >> +#include <linux/types.h>
> >> +#include <linux/virtio_types.h>
> >> +
> >> +/* The feature bitmap for virtio rpmsg */
> >> +#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
> >> +#define VIRTIO_RPMSG_F_BUFSZ 1 /* RP get buffer size from config space */
> >> +
> >> +/* Version of struct virtio_rpmsg_config understood by this driver */
> >> +#define RPMSG_VDEV_CONFIG_V1 1
> >> +
> >> +/**
> >> + * struct virtio_rpmsg_config - config space for rpmsg virtio device
> >> + *
> >> + * @version: version of this structure, currently %RPMSG_VDEV_CONFIG_V1.
> >> + * @size: size of this structure in bytes.
> >> + * @rpmsg_buf_align: alignment in bytes for each buffer. Must be a power of
> >> + * two. If 0 then no alignment will be done. This alignment
> >> + * will not decide actual size of the buffer but will be
> >> + * used to decided the start address of the buffer. The
> >> + * actual size of the buffer can be different than the
> >> + * aligned size of the buffer.
> >
> > Is there really a need to have a buffer size different from its alignment? It's
> > not like the (small) delta between the buffer size and its alignment will be
> > used for something else. I'm fine with a buffer alignment requirement but in
> > those cases, the firmware should set the size of the buffer in accordance with
> > its alignment requirement. Otherwise, the complexity needed to manage the
> > discrpancy between the two yields a driver that is hard to maintain and prone to
> > bugs.
> >
>
> I had the same concern before. However, following example changed my mind:
>
> So, a single buffer size is the MTU size of a packet for the protocol
> supported by the firmware. Now that can be different than the aligned
> size of the buffer.
>
> For example, the higher level protocol (not rpmsg) has 430 bytes as the
> max size of a payload. However, cache line alignment is 64-bytes. Then
> in that case, the aligned buffer size is 448 bytes. But, that doesn't
> mean we can say protocol's MTU size is 448 bytes. If user end up
> treating MTU size 448 bytes and use space beyond 430 bytes, then the
> higher level apps might discard that data and communication may fail.
>
How is that scenario different from today's 512 byte buffer size?
Most users don't use all 512 bytes and we don't run in the problem
described above?
> The alignment field is used only to decide where the next buffer start
> address is to ease cache operations.
>
> Sure, we need to maintain this complexity, but I think it's worth it.
>
The same as in my previous email to Arnaud applies here - is this an
immediate requirement of something we think may be happening in the
future?
> Thanks,
> Tanmay
>
> >> + * @txbuf_size: Tx buf size from remote's view. For Linux this is rx buf size.
> >> + * @rxbuf_size: Rx buf size from remote's view. For Linux this is tx buf size.
> >> + *
> >> + * This is the configuration structure shared by the device and the driver,
> >> + * read when %VIRTIO_RPMSG_F_BUFSZ is negotiated. The fields are laid out so
> >> + * the structure is naturally 32-bit aligned.
> >> + */
> >> +struct virtio_rpmsg_config {
> >> + u8 version;
> >> + __virtio16 size;
> >> + __virtio16 rpmsg_buf_align;
> >> + /* The tx/rx individual buffer size (if VIRTIO_RPMSG_F_BUFSZ) */
> >> + __virtio32 txbuf_size;
> >> + __virtio32 rxbuf_size;
> >> +} __packed;
> >> +
> >> +#endif /* _LINUX_VIRTIO_RPMSG_H */
> >> --
> >> 2.34.1
> >>
>
^ permalink raw reply
* Re: [PATCH v5 3/5] rpmsg: virtio_rpmsg_bus: get buffer size from config space
From: Mathieu Poirier @ 2026-07-16 15:29 UTC (permalink / raw)
To: Arnaud POULIQUEN
Cc: Tanmay Shah, andersson, corbet, skhan, linux-remoteproc,
linux-doc, linux-kernel
In-Reply-To: <697f5a2d-8682-4027-babf-4b1337fc94c6@foss.st.com>
On Thu, 16 Jul 2026 at 02:19, Arnaud POULIQUEN
<arnaud.pouliquen@foss.st.com> wrote:
>
> Hello Mathieu,
>
> On 7/15/26 18:24, Mathieu Poirier wrote:
> > On Fri, Jul 10, 2026 at 12:28:29PM -0700, Tanmay Shah wrote:
> >> 512 bytes isn't always suitable for all case, let firmware
> >> maker decide the best value from resource table.
> >> enable by VIRTIO_RPMSG_F_BUFSZ feature bit.
> >>
> >> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> >> ---
> >> Changes in v5:
> >>
> >> - fix documentation about alignment of the buffer size
> >> - change version field from u16 to u8
> >> - remove buffer alignment check
> >> - Separate buffer alignment vs MTU of a single buffer
> >> - Use buffer alignment only to get next buffer address at alignment
> >> boundary
> >>
> >> Changes in v4:
> >>
> >> - Introduce new patch to modify rpmsg.rst documentation
> >> - check version is always 1.
> >> - check size field is same as size of struct virtio_rpmsg_config
> >> - introduce alignment field
> >> - check alignment field is power of 2
> >> - check tx and rx buf size is aligned with alignment passed in the
> >> structure
> >>
> >> Changes in v3:
> >>
> >> - change version field from u16 to u8
> >> - introduce size field in the rpmsg_virtio_config structure
> >> - check version field is set to any non-zero value.
> >> - check size field is not 0.
> >> - Remove field for private config, as not needed for now.
> >> - add documentation of rpmsg_virtio_config structure
> >>
> >> drivers/rpmsg/virtio_rpmsg_bus.c | 130 ++++++++++++++++++++++++-----
> >> include/linux/rpmsg/virtio_rpmsg.h | 48 +++++++++++
> >> 2 files changed, 159 insertions(+), 19 deletions(-)
> >> create mode 100644 include/linux/rpmsg/virtio_rpmsg.h
> >>
> >> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> >> index c84b6cec9caf..5e5473f4adeb 100644
> >> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> >> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> >> @@ -15,11 +15,13 @@
> >> #include <linux/idr.h>
> >> #include <linux/jiffies.h>
> >> #include <linux/kernel.h>
> >> +#include <linux/log2.h>
> >> #include <linux/module.h>
> >> #include <linux/mutex.h>
> >> #include <linux/rpmsg.h>
> >> #include <linux/rpmsg/byteorder.h>
> >> #include <linux/rpmsg/ns.h>
> >> +#include <linux/rpmsg/virtio_rpmsg.h>
> >> #include <linux/scatterlist.h>
> >> #include <linux/slab.h>
> >> #include <linux/sched.h>
> >> @@ -39,7 +41,10 @@
> >> * @tx_bufs: kernel address of tx buffers
> >> * @num_rx_buf: total number of rx buffers
> >> * @num_tx_buf: total number of tx buffers
> >> - * @buf_size: size of one rx or tx buffer
> >> + * @rx_buf_size: size of one rx buffer
> >> + * @tx_buf_size: size of one tx buffer
> >> + * @rx_buf_size_aligned: aligned size of one rx buffer
> >> + * @tx_buf_size_aligned: aligned size of one tx buffer
> >> * @last_tx_buf: index of last tx buffer used
> >> * @bufs_dma: dma base addr of the buffers
> >> * @tx_lock: protects svq and tx_bufs, to allow concurrent senders.
> >> @@ -59,7 +64,10 @@ struct virtproc_info {
> >> void *rx_bufs, *tx_bufs;
> >> unsigned int num_rx_buf;
> >> unsigned int num_tx_buf;
> >> - unsigned int buf_size;
> >> + unsigned int rx_buf_size;
> >> + unsigned int tx_buf_size;
> >> + unsigned int rx_buf_size_aligned;
> >> + unsigned int tx_buf_size_aligned;
> >> int last_tx_buf;
> >> dma_addr_t bufs_dma;
> >> struct mutex tx_lock;
> >> @@ -68,9 +76,6 @@ struct virtproc_info {
> >> wait_queue_head_t sendq;
> >> };
> >>
> >> -/* The feature bitmap for virtio rpmsg */
> >> -#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
> >> -
> >> /**
> >> * struct rpmsg_hdr - common header for all rpmsg messages
> >> * @src: source address
> >> @@ -128,7 +133,7 @@ struct virtio_rpmsg_channel {
> >> * processor.
> >> */
> >> #define MAX_RPMSG_NUM_BUFS (256)
> >> -#define MAX_RPMSG_BUF_SIZE (512)
> >> +#define DEFAULT_RPMSG_BUF_SIZE (512)
> >>
> >> /*
> >> * Local addresses are dynamically allocated on-demand.
> >> @@ -443,7 +448,7 @@ static void *get_a_tx_buf(struct virtproc_info *vrp)
> >>
> >> /* either pick the next unused tx buffer */
> >> if (vrp->last_tx_buf < vrp->num_tx_buf)
> >> - ret = vrp->tx_bufs + vrp->buf_size * vrp->last_tx_buf++;
> >> + ret = vrp->tx_bufs + vrp->tx_buf_size_aligned * vrp->last_tx_buf++;
> >> /* or recycle a used one */
> >> else
> >> ret = virtqueue_get_buf(vrp->svq, &len);
> >> @@ -513,7 +518,7 @@ static int rpmsg_send_offchannel_raw(struct rpmsg_device *rpdev,
> >> * messaging), or to improve the buffer allocator, to support
> >> * variable-length buffer sizes.
> >> */
> >> - if (len > vrp->buf_size - sizeof(struct rpmsg_hdr)) {
> >> + if (len > vrp->tx_buf_size - sizeof(struct rpmsg_hdr)) {
> >> dev_err(dev, "message is too big (%d)\n", len);
> >> return -EMSGSIZE;
> >> }
> >> @@ -646,7 +651,7 @@ static ssize_t virtio_rpmsg_get_mtu(struct rpmsg_endpoint *ept)
> >> struct rpmsg_device *rpdev = ept->rpdev;
> >> struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
> >>
> >> - return vch->vrp->buf_size - sizeof(struct rpmsg_hdr);
> >> + return vch->vrp->tx_buf_size - sizeof(struct rpmsg_hdr);
> >> }
> >>
> >> static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
> >> @@ -672,7 +677,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
> >> * We currently use fixed-sized buffers, so trivially sanitize
> >> * the reported payload length.
> >> */
> >> - if (len > vrp->buf_size ||
> >> + if (len > vrp->rx_buf_size ||
> >> msg_len > (len - sizeof(struct rpmsg_hdr))) {
> >> dev_warn(dev, "inbound msg too big: (%d, %d)\n", len, msg_len);
> >> return -EINVAL;
> >> @@ -705,7 +710,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
> >> dev_warn_ratelimited(dev, "msg received with no recipient\n");
> >>
> >> /* publish the real size of the buffer */
> >> - rpmsg_sg_init(&sg, msg, vrp->buf_size);
> >> + rpmsg_sg_init(&sg, msg, vrp->rx_buf_size);
> >>
> >> /* add the buffer back to the remote processor's virtqueue */
> >> err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, msg, GFP_KERNEL);
> >> @@ -819,10 +824,13 @@ static int rpmsg_probe(struct virtio_device *vdev)
> >> struct virtproc_info *vrp;
> >> struct virtio_rpmsg_channel *vch = NULL;
> >> struct rpmsg_device *rpdev_ns, *rpdev_ctrl;
> >> + u16 rpmsg_buf_align = 0;
> >> void *bufs_va;
> >> int err = 0, i;
> >> size_t total_buf_space;
> >> bool notify;
> >> + u8 version;
> >> + u16 size;
> >>
> >> vrp = kzalloc_obj(*vrp);
> >> if (!vrp)
> >> @@ -854,9 +862,87 @@ static int rpmsg_probe(struct virtio_device *vdev)
> >> else
> >> vrp->num_tx_buf = MAX_RPMSG_NUM_BUFS;
> >>
> >> - vrp->buf_size = MAX_RPMSG_BUF_SIZE;
> >> + /*
> >> + * If VIRTIO_RPMSG_F_BUFSZ feature is supported, then configure buf
> >> + * size from virtio device config space from the resource table.
> >> + * If the feature is not supported, then assign default buf size.
> >> + */
> >> + if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_BUFSZ)) {
> >> + virtio_cread(vdev, struct virtio_rpmsg_config,
> >> + version, &version);
> >> +
> >> + /* for now we support only v1 */
> >> + if (version != RPMSG_VDEV_CONFIG_V1) {
> >> + dev_err(&vdev->dev,
> >> + "unsupported vdev config version %u\n", version);
> >> + err = -EINVAL;
> >> + goto vqs_del;
> >> + }
> >> +
> >> + /* size of the config space must match */
> >> + virtio_cread(vdev, struct virtio_rpmsg_config,
> >> + size, &size);
> >> + if (size != sizeof(struct virtio_rpmsg_config)) {
> >> + dev_err(&vdev->dev, "invalid size of vdev config %u\n",
> >> + size);
> >> + err = -EINVAL;
> >> + goto vqs_del;
> >> + }
> >>
> >> - total_buf_space = (vrp->num_rx_buf + vrp->num_tx_buf) * vrp->buf_size;
> >> + /*
> >> + * Optional alignment applied to each buffer size and to the TX
> >> + * buffer base address (e.g. to align buffers on a cache line).
> >> + * It must be a power of two; zero means no extra alignment.
> >> + */
> >> + virtio_cread(vdev, struct virtio_rpmsg_config,
> >> + rpmsg_buf_align, &rpmsg_buf_align);
> >> + if (rpmsg_buf_align && !is_power_of_2(rpmsg_buf_align)) {
> >> + dev_err(&vdev->dev,
> >> + "bad vdev config: rpmsg_buf_align %u is not a power of 2\n",
> >> + rpmsg_buf_align);
> >> + err = -EINVAL;
> >> + goto vqs_del;
> >> + }
> >> +
> >> + /* note: tx and rx are defined from remote view */
> >> + virtio_cread(vdev, struct virtio_rpmsg_config,
> >> + txbuf_size, &vrp->rx_buf_size);
> >> + virtio_cread(vdev, struct virtio_rpmsg_config,
> >> + rxbuf_size, &vrp->tx_buf_size);
> >> +
> >> + /* The buffers must hold at least the rpmsg header */
> >> + if (vrp->rx_buf_size < sizeof(struct rpmsg_hdr) ||
> >> + vrp->tx_buf_size < sizeof(struct rpmsg_hdr)) {
> >> + dev_err(&vdev->dev,
> >> + "bad vdev config: rx buf sz = %u, tx buf sz = %u\n",
> >> + vrp->rx_buf_size, vrp->tx_buf_size);
> >> + err = -EINVAL;
> >> + goto vqs_del;
> >> + }
> >> +
> >> + if (rpmsg_buf_align) {
> >> + vrp->rx_buf_size_aligned = ALIGN(vrp->rx_buf_size,
> >> + rpmsg_buf_align);
> >> + vrp->tx_buf_size_aligned = ALIGN(vrp->tx_buf_size,
> >> + rpmsg_buf_align);
> >> + } else {
> >> + vrp->rx_buf_size_aligned = vrp->rx_buf_size;
> >> + vrp->tx_buf_size_aligned = vrp->tx_buf_size;
> >> + }
> >> +
> >> + dev_dbg(&vdev->dev,
> >> + "vdev config: ver=%u, align=0x%x, rx sz = 0x%x, tx sz = 0x%x\n",
> >> + version, rpmsg_buf_align, vrp->rx_buf_size,
> >> + vrp->tx_buf_size);
> >> + } else {
> >> + vrp->rx_buf_size = DEFAULT_RPMSG_BUF_SIZE;
> >> + vrp->tx_buf_size = DEFAULT_RPMSG_BUF_SIZE;
> >> + vrp->rx_buf_size_aligned = vrp->rx_buf_size;
> >> + vrp->tx_buf_size_aligned = vrp->tx_buf_size;
> >> + }
> >> +
> >> + total_buf_space = (vrp->num_rx_buf * vrp->rx_buf_size_aligned) +
> >> + (vrp->num_tx_buf * vrp->tx_buf_size_aligned);
> >>
> >> /* allocate coherent memory for the buffers */
> >> bufs_va = dma_alloc_coherent(vdev->dev.parent,
> >> @@ -873,15 +959,20 @@ static int rpmsg_probe(struct virtio_device *vdev)
> >> /* first part of the buffers is dedicated for RX */
> >> vrp->rx_bufs = bufs_va;
> >>
> >> - /* and second part is dedicated for TX */
> >> - vrp->tx_bufs = bufs_va + vrp->num_rx_buf * vrp->buf_size;
> >> + /*
> >> + * Here buf_va is aligned to a page. Also rx buf size is aligned with
> >> + * cache line alignment provided by the firmware, so tx buf's start
> >> + * address is guranteed to be aligned with the alignment provided by
> >> + * the firmware.
> >> + */
> >> + vrp->tx_bufs = bufs_va + (vrp->num_rx_buf * vrp->rx_buf_size_aligned);
> >>
> >> /* set up the receive buffers */
> >> for (i = 0; i < vrp->num_rx_buf; i++) {
> >> struct scatterlist sg;
> >> - void *cpu_addr = vrp->rx_bufs + i * vrp->buf_size;
> >> + void *cpu_addr = vrp->rx_bufs + i * vrp->rx_buf_size_aligned;
> >>
> >> - rpmsg_sg_init(&sg, cpu_addr, vrp->buf_size);
> >> + rpmsg_sg_init(&sg, cpu_addr, vrp->rx_buf_size);
> >>
> >> err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, cpu_addr,
> >> GFP_KERNEL);
> >> @@ -964,8 +1055,8 @@ static int rpmsg_remove_device(struct device *dev, void *data)
> >> static void rpmsg_remove(struct virtio_device *vdev)
> >> {
> >> struct virtproc_info *vrp = vdev->priv;
> >> - unsigned int num_bufs = vrp->num_rx_buf + vrp->num_tx_buf;
> >> - size_t total_buf_space = num_bufs * vrp->buf_size;
> >> + size_t total_buf_space = (vrp->num_rx_buf * vrp->rx_buf_size_aligned) +
> >> + (vrp->num_tx_buf * vrp->tx_buf_size_aligned);
> >> int ret;
> >>
> >> virtio_reset_device(vdev);
> >> @@ -991,6 +1082,7 @@ static struct virtio_device_id id_table[] = {
> >>
> >> static unsigned int features[] = {
> >> VIRTIO_RPMSG_F_NS,
> >> + VIRTIO_RPMSG_F_BUFSZ,
> >> };
> >>
> >> static struct virtio_driver virtio_ipc_driver = {
> >> diff --git a/include/linux/rpmsg/virtio_rpmsg.h b/include/linux/rpmsg/virtio_rpmsg.h
> >> new file mode 100644
> >> index 000000000000..735a947d5582
> >> --- /dev/null
> >> +++ b/include/linux/rpmsg/virtio_rpmsg.h
> >> @@ -0,0 +1,48 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +/*
> >> + * Copyright (C) Pinecone Inc. 2019
> >> + * Copyright (C) Xiang Xiao <xiaoxiang@pinecone.net>
> >> + * Copyright (C) Advanced Micro Devices, Inc. 2026
> >> + */
> >> +
> >> +#ifndef _LINUX_VIRTIO_RPMSG_H
> >> +#define _LINUX_VIRTIO_RPMSG_H
> >> +
> >> +#include <linux/types.h>
> >> +#include <linux/virtio_types.h>
> >> +
> >> +/* The feature bitmap for virtio rpmsg */
> >> +#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
> >> +#define VIRTIO_RPMSG_F_BUFSZ 1 /* RP get buffer size from config space */
> >> +
> >> +/* Version of struct virtio_rpmsg_config understood by this driver */
> >> +#define RPMSG_VDEV_CONFIG_V1 1
> >> +
> >> +/**
> >> + * struct virtio_rpmsg_config - config space for rpmsg virtio device
> >> + *
> >> + * @version: version of this structure, currently %RPMSG_VDEV_CONFIG_V1.
> >> + * @size: size of this structure in bytes.
> >> + * @rpmsg_buf_align: alignment in bytes for each buffer. Must be a power of
> >> + * two. If 0 then no alignment will be done. This alignment
> >> + * will not decide actual size of the buffer but will be
> >> + * used to decided the start address of the buffer. The
> >> + * actual size of the buffer can be different than the
> >> + * aligned size of the buffer.
> >
> > Is there really a need to have a buffer size different from its alignment? It's
> > not like the (small) delta between the buffer size and its alignment will be
> > used for something else. I'm fine with a buffer alignment requirement but in
> > those cases, the firmware should set the size of the buffer in accordance with
> > its alignment requirement. Otherwise, the complexity needed to manage the
> > discrpancy between the two yields a driver that is hard to maintain and prone to
> > bugs.
>
> I would be in favor to keep it.
>
> The remote processor could expose some alignment constraints. The Linux
> kernel
> or another main processor OS can have its own constraints. As it
> allocates the
> buffers, it can decide the final alignment independently of the buffer
> sizes.
>
> An example is a remote processor without a cache and a main processor with a
> cache. rpmsg_buf_align could be set to 0, but the main processor could
> decide to
> align buffer addresses on a cache line.
But is there an immediate need for that? I'm all for it if there is a
legitimate use case where we know exactly what the constraints are.
If not we are adding complexity that may, or may not, be able to
address hypothetical constraints.
> Thanks,
> Arnaud
>
> >
> >> + * @txbuf_size: Tx buf size from remote's view. For Linux this is rx buf size.
> >> + * @rxbuf_size: Rx buf size from remote's view. For Linux this is tx buf size.
> >> + *
> >> + * This is the configuration structure shared by the device and the driver,
> >> + * read when %VIRTIO_RPMSG_F_BUFSZ is negotiated. The fields are laid out so
> >> + * the structure is naturally 32-bit aligned.
> >> + */
> >> +struct virtio_rpmsg_config {
> >> + u8 version;
> >> + __virtio16 size;
> >> + __virtio16 rpmsg_buf_align;
> >> + /* The tx/rx individual buffer size (if VIRTIO_RPMSG_F_BUFSZ) */
> >> + __virtio32 txbuf_size;
> >> + __virtio32 rxbuf_size;
> >> +} __packed;
> >> +
> >> +#endif /* _LINUX_VIRTIO_RPMSG_H */
> >> --
> >> 2.34.1
> >>
> >
>
^ 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