* Re: [PATCH v2] docs: sysctl: Add documentation for /proc/sys/xen/
From: Jonathan Corbet @ 2026-04-09 14:45 UTC (permalink / raw)
To: Shubham Chakraborty, jgross
Cc: sstabellini, boris.ostrovsky, linux-doc, xen-devel, linux-kernel,
Shubham Chakraborty
In-Reply-To: <20260304150419.16738-1-chakrabortyshubham66@gmail.com>
Shubham Chakraborty <chakrabortyshubham66@gmail.com> writes:
> Add documentation for the Xen hypervisor sysctl controls in
> /proc/sys/xen/balloon/.
>
> Documents the hotplug_unpopulated tunable (available when
> CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is enabled) which controls
> whether unpopulated memory regions are automatically hotplugged
> when the Xen balloon driver needs to reclaim memory.
>
> The documentation is based on source code analysis of
> drivers/xen/balloon.c.
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
> ---
> Documentation/admin-guide/sysctl/index.rst | 3 ++-
> Documentation/admin-guide/sysctl/xen.rst | 31 ++++++++++++++++++++++
> 2 files changed, 33 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/admin-guide/sysctl/xen.rst
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] Docs: hid: intel-ish-hid: make long URL usable
From: Jonathan Corbet @ 2026-04-09 14:42 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Randy Dunlap, Jiri Kosina, Benjamin Tissoires,
Srinivas Pandruvada, linux-input, Shuah Khan, linux-doc
In-Reply-To: <20260321230934.435020-1-rdunlap@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> The '\' line continuation character in this long URL
> doesn't help anything. There is no documentation tooling that
> handles the line continuation character to join the 2 lines
> to make a usable URL. Web browsers terminate the URL just
> before the '\' character so that the second line of the URL
> is lost. See:
> https://docs.kernel.org/hid/intel-ish-hid.html
>
> Join the 2 lines together so that the URL is usable.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <bentiss@kernel.org>
> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Cc: linux-input@vger.kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Shuah Khan <skhan@linuxfoundation.org>
> Cc: linux-doc@vger.kernel.org
>
> Documentation/hid/intel-ish-hid.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20260320.orig/Documentation/hid/intel-ish-hid.rst
> +++ linux-next-20260320/Documentation/hid/intel-ish-hid.rst
> @@ -163,8 +163,8 @@ The transport layer is a bi-directional
> - A flow control mechanism to avoid buffer overflows
>
> This protocol resembles bus messages described in the following document:
> -http://www.intel.com/content/dam/www/public/us/en/documents/technical-\
> -specifications/dcmi-hi-1-0-spec.pdf "Chapter 7: Bus Message Layer"
> +http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/dcmi-hi-1-0-spec.pdf
> +"Chapter 7: Bus Message Layer".
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2] Documentation/kernel-parameters: fix architecture alignment for pt, nopt, and nobypass
From: Jonathan Corbet @ 2026-04-09 14:37 UTC (permalink / raw)
To: lirongqing, Andrew Morton, Borislav Petkov, Randy Dunlap,
linux-doc, linux-kernel
Cc: Li RongQing, Shuah Khan, Peter Zijlstra, Feng Tang, Pawan Gupta,
Dapeng Mi, Kees Cook, Marco Elver, Paul E . McKenney, Askar Safin,
Bjorn Helgaas, Sohil Mehta
In-Reply-To: <20260330105957.2271-1-lirongqing@baidu.com>
lirongqing <lirongqing@baidu.com> writes:
> From: Li RongQing <lirongqing@baidu.com>
>
> Commit ab0e7f20768a ("Documentation: Merge x86-specific boot options doc
> into kernel-parameters.txt") introduced a formatting regression where
> architecture tags were placed on separate lines with broken indentation.
> This caused the 'nopt' [X86] parameter to appear as if it belonged to
> the [PPC/POWERNV] section.
>
> Furthermore, since the main 'iommu=' parameter heading already specifies
> it is for [X86, EARLY], the subsequent standalone [X86] tags for 'pt',
> 'nopt', and the AMD GART options are redundant and clutter the
> documentation.
>
> Clean up the formatting by removing these redundant tags and properly
> attributing the 'nobypass' option to [PPC/POWERNV].
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2] docs: pt_BR: translate process/2.Process.rst
From: Jonathan Corbet @ 2026-04-09 14:35 UTC (permalink / raw)
To: Daniel Castro, danielmaraboo; +Cc: linux-doc, Daniel Castro
In-Reply-To: <20260330180207.30224-1-arantescastro@gmail.com>
Daniel Castro <arantescastro@gmail.com> writes:
> Add Brazilian Portuguese translation of the development process
> document (Documentation/process/2.Process.rst), covering the
> development cycle overview, patch lifecycle, subsystem trees,
> staging trees, tools, mailing lists, and getting started with
> kernel development.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Daniel Castro <arantescastro@gmail.com>
> ---
> v2: Fix stray line breaks throughout the file.
>
> Documentation/translations/pt_BR/index.rst | 1 +
> .../translations/pt_BR/process/2.Process.rst | 502 ++++++++++++++++++
> 2 files changed, 503 insertions(+)
> create mode 100644 Documentation/translations/pt_BR/process/2.Process.rst
Unfortunately, this patch does not apply to docs-next. Please respin
and resend, and we'll get it in after the merge window.
Thanks,
jon
^ permalink raw reply
* Re: [RFC PATCH] Documentation: Add managed interrupts
From: Jonathan Corbet @ 2026-04-09 14:32 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, linux-doc, linux-kernel
Cc: Aaron Tomlin, Christoph Hellwig, Frederic Weisbecker, Jens Axboe,
Ming Lei, Thomas Gleixner, Valentin Schneider, Waiman Long,
Peter Zijlstra, John Ogness
In-Reply-To: <20260401110232.ET5RxZfl@linutronix.de>
Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes:
> I stumbled upon "isolcpus=managed_irq" which is the last piece which
> can only be handled by isolcpus= and has no runtime knob. I knew roughly
> what managed interrupts should do but I lacked some details how it is
> used and what the managed_irq sub parameter means in practise.
>
> This documents what we have as of today and how it works. I added some
> examples how the parameter affects the configuration. Did I miss
> something?
There's been a lot of silence on this one... should I pick this one up,
or are there other plans for it...?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] sched/doc: Update yield_task description in sched-design-CFS
From: Jonathan Corbet @ 2026-04-09 14:30 UTC (permalink / raw)
To: skhan, alexs, si.yanteng, dzm91, carlos.bilbao, avadhut.naik
Cc: fangqiurong, linux-doc, linux-kernel
In-Reply-To: <20260403055806.358921-1-user@fqr-pc>
fqr <user.email> writes:
> From: fangqiurong <fangqiurong@kylinos.cn>
>
> The yield_task description referenced the long-removed compat_yield
> sysctl and described the function as a dequeue/enqueue cycle. Update
> it to reflect current behavior: yielding the CPU by moving the
> current task's position back in the runqueue.
>
> Sync zh_CN and sp_SP translations.
>
> Signed-off-by: fangqiurong <fangqiurong@kylinos.cn>
> ---
> Documentation/scheduler/sched-design-CFS.rst | 5 ++---
> .../translations/sp_SP/scheduler/sched-design-CFS.rst | 6 +++---
> .../translations/zh_CN/scheduler/sched-design-CFS.rst | 4 ++--
> 3 files changed, 7 insertions(+), 8 deletions(-)
Applied, thanks.
Also dropped the strange user.email address in your email; you will want
to fix that before sending anything else.
jon
^ permalink raw reply
* Re: [PATCH v1] Documentation/rtla: Convert links to RST format
From: Jonathan Corbet @ 2026-04-09 14:24 UTC (permalink / raw)
To: Costa Shulyupin, Steven Rostedt, Tomas Glozar, Shuah Khan,
linux-trace-kernel, linux-kernel, linux-doc
Cc: Costa Shulyupin
In-Reply-To: <20260405163847.3337981-1-costa.shul@redhat.com>
Costa Shulyupin <costa.shul@redhat.com> writes:
> Web links in the documentation are not properly displayed.
>
> In the man pages web links look like:
> Osnoise tracer documentation: < <https://www.kernel.org/doc/html/lat‐
> est/trace/osnoise-tracer.html> >
>
> On web pages the URL caption is the URL itself.
>
> Convert tracer documentation links to RST anonymous hyperlink format
> for better rendering. Use newer docs.kernel.org instead of
> www.kernel.org/doc/html/latest for brevity.
>
> After the change, the links in the man pages look like:
> Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>
>
> On web pages the captions are the titles of the links.
>
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/tools/rtla/rtla-hwnoise.rst | 2 +-
> Documentation/tools/rtla/rtla-osnoise-hist.rst | 2 +-
> Documentation/tools/rtla/rtla-osnoise-top.rst | 2 +-
> Documentation/tools/rtla/rtla-osnoise.rst | 2 +-
> Documentation/tools/rtla/rtla-timerlat-hist.rst | 2 +-
> Documentation/tools/rtla/rtla-timerlat-top.rst | 2 +-
> Documentation/tools/rtla/rtla-timerlat.rst | 2 +-
> 7 files changed, 7 insertions(+), 7 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2] docs: fix typos and duplicated words across documentation
From: Jonathan Corbet @ 2026-04-09 14:22 UTC (permalink / raw)
To: Manuel Cortez, linux-doc; +Cc: rdunlap, Manuel Cortez
In-Reply-To: <20260406030323.1196-1-mdjesuscv@gmail.com>
Manuel Cortez <mdjesuscv@gmail.com> writes:
> Fix the following typos and duplicated words:
>
> - admin-guide/pm/intel-speed-select.rst: "weather" -> "whether"
> - core-api/real-time/differences.rst: "the the" -> "the"
> - admin-guide/bcache.rst: "to to" -> "to"
>
> Signed-off-by: Manuel Cortez <mdjesuscv@gmail.com>
> ---
> Changes in v2:
> - Dropped the networking/switchdev.rst change as "is in in" is correct
> per Randy Dunlap's review.
>
> Documentation/admin-guide/bcache.rst | 2 +-
> Documentation/admin-guide/pm/intel-speed-select.rst | 2 +-
> Documentation/core-api/real-time/differences.rst | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* [RFC PATCH v4 06/11] Docs/admin-guide/mm/damon/usage: document fail_charge_{num,denom} files
From: SeongJae Park @ 2026-04-09 14:21 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260409142148.60652-1-sj@kernel.org>
Update DAMON usage document for the DAMOS action failed regions quota
charge ratio control sysfs files.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index bfdb717441f05..d5548e460857c 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -84,7 +84,9 @@ comma (",").
│ │ │ │ │ │ │ │ sz/min,max
│ │ │ │ │ │ │ │ nr_accesses/min,max
│ │ │ │ │ │ │ │ age/min,max
- │ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,effective_bytes,goal_tuner
+ │ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,
+ │ │ │ │ │ │ │ effective_bytes,goal_tuner,
+ │ │ │ │ │ │ │ fail_charge_num,fail_charge_denom
│ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
│ │ │ │ │ │ │ │ :ref:`goals <sysfs_schemes_quota_goals>`/nr_goals
│ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid,path
@@ -381,9 +383,10 @@ schemes/<N>/quotas/
The directory for the :ref:`quotas <damon_design_damos_quotas>` of the given
DAMON-based operation scheme.
-Under ``quotas`` directory, five files (``ms``, ``bytes``,
-``reset_interval_ms``, ``effective_bytes`` and ``goal_tuner``) and two
-directories (``weights`` and ``goals``) exist.
+Under ``quotas`` directory, seven files (``ms``, ``bytes``,
+``reset_interval_ms``, ``effective_bytes``, ``goal_tuner``, ``fail_charge_num``
+and ``fail_charge_denom``) and two directories (``weights`` and ``goals``)
+exist.
You can set the ``time quota`` in milliseconds, ``size quota`` in bytes, and
``reset interval`` in milliseconds by writing the values to the three files,
@@ -402,6 +405,13 @@ the background design of the feature and the name of the selectable algorithms.
Refer to :ref:`goals directory <sysfs_schemes_quota_goals>` for the goals
setup.
+You can set the action-failed memory quota charging ratio by writing the
+numerator and the denominator for the ratio to ``fail_charge_num`` and
+``fail_charge_denom`` files, respectively. Reading those files will return the
+current set values. Refer to :ref:`design
+<damon_design_damos_quotas_failed_memory_charging_ratio>` for more details of
+the ratio feature.
+
The time quota is internally transformed to a size quota. Between the
transformed size quota and user-specified size quota, smaller one is applied.
Based on the user-specified :ref:`goal <sysfs_schemes_quota_goals>`, the
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v4 05/11] Docs/mm/damon/design: document fail_charge_{num,denom}
From: SeongJae Park @ 2026-04-09 14:21 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260409142148.60652-1-sj@kernel.org>
Update DAMON design document for the DAMOS action failed region quota
charge ratio.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/mm/damon/design.rst | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 510ec6375178d..94e898b671d15 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -572,6 +572,28 @@ interface <sysfs_interface>`, refer to :ref:`weights <sysfs_quotas>` part of
the documentation.
+.. _damon_design_damos_quotas_failed_memory_charging_ratio:
+
+Action-failed Memory Charging Ratio
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+DAMOS action to a given region can fail for some subsets of the memory of the
+region. For example, if the action is ``pageout`` and the region has some
+unreclaimable pages, applying the action to the pages will fail. The amount of
+system resource that is taken for such failed action applications is usually
+different from that for successful action applications. For such cases, users
+can set different charging ratio for such failed memory. The ratio can be
+specified using ``fail_charge_num`` and ``fail_charge_denom`` parameters. The
+two parameters represent the numerator and denominator of the ratio. The
+feature is enabled only if ``fail_charge_denom`` is not zero.
+
+For example, let's suppose a DAMOS action is applied to a region of 1,000 MiB
+size. The action is successfully applied to only 700 MiB of the region.
+``fail_charge_num`` and ``fail_charge_denom`` are set to ``1`` and ``1024``,
+respectively. Then only 700 MiB and 300 KiB of size (``700 MiB + 300 MiB * 1 /
+1024``) will be charged.
+
+
.. _damon_design_damos_quotas_auto_tuning:
Aim-oriented Feedback-driven Auto-tuning
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v4 00/11] mm/damon: introduce DAMOS failed region quota charge ratio
From: SeongJae Park @ 2026-04-09 14:21 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, Brendan Higgins,
David Gow, David Hildenbrand, Jonathan Corbet, Lorenzo Stoakes,
Michal Hocko, Mike Rapoport, Shuah Khan, Shuah Khan,
Suren Baghdasaryan, Vlastimil Babka, damon, kunit-dev, linux-doc,
linux-kernel, linux-kselftest, linux-mm
TL; DR: Let users set different DAMOS quota charge ratios for DAMOS
action failed regions, for deterministic and consistent DAMOS action
progress.
Common Reports: Unexpectedly Slow DAMOS
=======================================
One common issue report that we get from DAMON users is that DAMOS
action applying progress speed is sometimes much slower than expected.
And one common root cause is that the DAMOS quota is exceeded by the
action applying failed memory regions.
For example, a group of users tried to run DAMOS-based proactive memory
reclamation (DAMON_RECLAIM) with 100 MiB per second DAMOS quota. They
ran it on a system having no active workload which means all memory of
the system is cold. The expectation was that the system will show 100
MiB per second reclamation until (nearly) all memory is reclaimed. But
what they found is that the speed is quite inconsistent and sometimes it
becomes very slower than the expectation, sometimes even no reclamation
at all for about tens of seconds. The upper limit of the speed (100 MiB
per second) was being kept as expected, though.
By monitoring the qt_exceeds (number of DAMOS quota exceed events) DAMOS
stat, we found DAMOS quota is always exceeded when the speed is slow. By
monitoring sz_tried and sz_applied (the total amount of DAMOS action
tried memory and succeeded memory) DAMOS stats together, we found the
reclamation attempts nearly always failed when the speed is slow.
DAMOS quota charges DAMOS action tried regions regardless of the
successfulness of the try. Hence in the example reported case, there
was unreclaimable memory spread around the system memory. Sometimes
nearly 100 MiB of memory that DAMOS tried to reclaim in the given quota
interval was reclaimable, and therefore showed nearly 100 MiB per second
speed. Sometimes nearly 99 MiB of memory that DAMOS was trying to
reclaim in the given quota interval was unreclaimable, and therefore
showing only about 1 MiB per second reclaim speed.
We explained it is an expected behavior of the feature rather than a
bug, as DAMOS quota is there for only the upper-limit of the speed. The
users agreed and later reported a huge win from the adoption of
DAMON_RECLAIM on their products.
It is Not a Bug but a Feature; But...
=====================================
So nothing is broken. DAMOS quota is working as intended, as the upper
limit of the speed. It also provides its behavior observability via
DAMOS stat. In the real world production environment that runs long
term active workloads and matters stability, the speed sometimes being
slow is not a real problem.
But, the non-deterministic behavior is sometimes annoying, especially in
lab environments. Even in a realistic production environment, when
there is a huge amount of DAMOS action unapplicable memory, the speed
could be problematically slow. Let's suppose a virtual machines
provider that setup 99% of the host memory as hugetlb pages that cannot
be reclaimed, to give it to virtual machines. Also, when aim-oriented
DAMOS auto-tuning is applied, this could also make the internal feedback
loop confused.
The intention of the current behavior was that trying DAMOS action to
regions would anyway impose some overhead, and therefore somehow be
charged. But in the real world, the overhead for failed action is much
lighter than successful action. Charging those at the same ratio may be
unfair, or at least suboptimum in some environments.
DAMOS Action Failed Region Quota Charge Ratio
=============================================
Let users set the charge ratio for the action-failed memory, for more
optimal and deterministic use of DAMOS. It allows users to specify the
numerator and the denominator of the ratio for flexible setup. For
example, let's suppose the numerator and the denominator are set to 1
and 4,096, respectively. The ratio is 1 / 4,096. A DAMOS scheme action
is applied to 5 GiB memory. For 1 GiB of the memory, the action is
succeeded. For the rest (4 GiB), the action is failed. Then, only 1
GiB and 1 MiB quota is charged.
The optimal charge ratio will depend on the use case and
system/workload. I'd recommend starting from setting the nominator as 1
and the denominator as PAGE_SIZE and tune based on the results, because
many DAMOS actions are applied at page level.
Tests
=====
I tested this feature in the steps below.
1. Allocate 50% of system memory and mlock() it using a test program.
2. Fill up the page cache to exhaust nearly all free memory.
3. Start DAMON-based proactive reclamation with 100 MiB/second DAMOS
hard-quota. Auto-tune the DAMOS soft-quota under the hard-quota for
achieving 40% free memory of the system with 'temporal' tuner.
For step 1, I run a simple C program that is written by Gemini. It is
quite straightforward, so I'm not sharing the code here.
For step 2, I use dd command like below:
dd if=/dev/zero of=foo bs=1M count=$50_percent_of_system_memory
For step 3, I use the latest version of DAMON user-space tool (damo)
like below.
sudo damo start --damos_action pageout \
` # Do the pageout only up to 100 MiB per second ` \
--damos_quota_space 100M --damos_quota_interval 1s \
` # Auto-tune the quota below the hard quota aiming` \
` # 40% free memory of the node 0 ` \
` # (entire node of the test system)` \
--damos_quota_goal node_mem_free_bp 40% 0 \
` # use temporal tuner, which is easy to understnd ` \
--damos_quota_goal_tuner temporal
As expected, the progress of the reclamation is not consistent, because
the quota is exceeded for the failed reclamation of the unreclaimable
memory.
I do this again, but with the failed region charge ratio feature. For
this, the above 'damo' command is used, after appending command line
option for setup of the charge ratio like below. Note that the option
was added to 'damo' after v3.1.9.
sudo ./damo start --damos_action pageout \
[...]
` # quota-charge only 1/4096 for pageout-failed regions ` \
--damos_quota_fail_charge_ratio 1 4096
The progress of the reclamation was nearly 100 MiB per second until the
goal was achieved, meeting the expectation.
Patches Sequence
================
First two patches make preparational changes. Patch 1 updates fully
charged quota check to handle <min_region_sz remaining quota, which will
be able to exist after this series is applied. Patch 2 merges regions
that split out for quota as soon as possible, since the split can happen
much more frequently under a corner case that this series will make
available.
Patch 3 implements the feature and exposes it via DAMON core API. Patch
4 implements DAMON sysfs ABI for the feature. Three following patches
(5-7) document the feature and ABI on design, usage, and ABI documents,
respectively. Four patches for testing of the new feature follow.
Patch 8 implements a kunit test for the feature. Patches 9 and 10
extend DAMON selftest helpers for DAMON sysfs control and internal state
dumping for adding a new selftest for the feature. Patch 11 extends
existing DAMON sysfs interface selftest to test the new feature using
the extended helper scripts.
Changelog
=========
Changes from RFC v3
(https://lore.kernel.org/20260407010536.83603-1-sj@kernel.org)
- Make damos_quota_is_full() safe from overflow and easier to read.
- Avoid quota-based region split making too many new regions.
Changes from RFC v2
(https://lore.kernel.org/20260405151232.102690-1-sj@kernel.org)
- Handle <min_region_sz remaining quota.
- Document zero denum behavior.
- Fix typos: s/selftets/selftests/
Changes from RFC v1
(https://lore.kernel.org/20260404163943.89278-1-sj@kernel.org)
- Avoid overflows in charge amount calculation.
- Fix/wordsmith documentation for grammar, typo, and wrong examples.
- Improve unit test for more consistent comparison source use.
SeongJae Park (11):
mm/damon/core: handle <min_region_sz remaining quota as empty
mm/damon/core: merge quota-sliced regions back
mm/damon/core: introduce failed region quota charge ratio
mm/damon/sysfs-schemes: implement fail_charge_{num,denom} files
Docs/mm/damon/design: document fail_charge_{num,denom}
Docs/admin-guide/mm/damon/usage: document fail_charge_{num,denom}
files
Docs/ABI/damon: document fail_charge_{num,denom}
mm/damon/tests/core-kunit: test fail_charge_{num,denom} committing
selftests/damon/_damon_sysfs: support failed region quota charge ratio
selftests/damon/drgn_dump_damon_status: support failed region quota
charge ratio
selftests/damon/sysfs.py: test failed region quota charge ratio
.../ABI/testing/sysfs-kernel-mm-damon | 12 +++
Documentation/admin-guide/mm/damon/usage.rst | 18 ++++-
Documentation/mm/damon/design.rst | 22 ++++++
include/linux/damon.h | 9 +++
mm/damon/core.c | 76 ++++++++++++++++---
mm/damon/sysfs-schemes.c | 54 +++++++++++++
mm/damon/tests/core-kunit.h | 6 ++
tools/testing/selftests/damon/_damon_sysfs.py | 21 ++++-
.../selftests/damon/drgn_dump_damon_status.py | 2 +
tools/testing/selftests/damon/sysfs.py | 6 ++
10 files changed, 209 insertions(+), 17 deletions(-)
base-commit: dcd9caafdc7ec3f936d87d9698a6c126f77e9750
--
2.47.3
^ permalink raw reply
* Re: [PATCH] Documentation: sysctl: document net core sysctls
From: Jonathan Corbet @ 2026-04-09 14:19 UTC (permalink / raw)
To: Shubham Chakraborty, Shuah Khan, linux-doc, linux-kernel
Cc: Shubham Chakraborty
In-Reply-To: <20260407083213.27045-1-chakrabortyshubham66@gmail.com>
Shubham Chakraborty <chakrabortyshubham66@gmail.com> writes:
Thanks for working to make our documentation better. A few notes,
though...
This is a networking-related patch, so it really needs to go to the
networking maintainers.
> Document missing net.core and net.unix sysctl entries in admin-guide/sysctl/net.rst, and correct wording for defaults that are derived from PAGE_SIZE, HZ, or CONFIG_MAX_SKB_FRAGS.
>
> Also clarify that the RFS and flow-limit controls are only present when CONFIG_RPS or CONFIG_NET_FLOW_LIMIT is enabled, and describe rps_sock_flow_entries the way the handler implements it: non-zero values are rounded up to the nearest power of two.
Please word-wrap your changelog text.
> Validation: git diff --check -- Documentation/admin-guide/sysctl/net.rst
> Validation: make -j1 O=/tmp/linux-docs-check SPHINXDIRS=admin-guide/sysctl htmldocs
This isn't a recognized tag, so shouldn't be expressed this way. If you
want, you can describe your testing setup after the "---" line.
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
> ---
> Documentation/admin-guide/sysctl/net.rst | 66 +++++++++++++++++++++++-
> 1 file changed, 64 insertions(+), 2 deletions(-)
The actual changes are best reviewed by the networking developers.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] docs: fix typo in zoran driver documentation
From: Jonathan Corbet @ 2026-04-09 14:12 UTC (permalink / raw)
To: Gleb Golovko; +Cc: linux-doc, Gleb Golovko
In-Reply-To: <20260407212818.925-1-gaben123001@gmail.com>
Gleb Golovko <gaben123001@gmail.com> writes:
> Replace "an a few" with "and a few" in
> Documentation/driver-api/media/drivers/zoran.rst.
>
> Signed-off-by: Gleb Golovko <gaben123001@gmail.com>
> ---
> Documentation/driver-api/media/drivers/zoran.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/driver-api/media/drivers/zoran.rst b/Documentation/driver-api/media/drivers/zoran.rst
> index 3e05b7f0442a..2538473c3233 100644
> --- a/Documentation/driver-api/media/drivers/zoran.rst
> +++ b/Documentation/driver-api/media/drivers/zoran.rst
> @@ -222,7 +222,7 @@ The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
> Ireland, Nigeria, South Africa.
>
> The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate,
> -and is used in Argentina, Uruguay, an a few others
> +and is used in Argentina, Uruguay, and a few others
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH 3/4] docs/zh_CN: update rust/quick-start.rst translation
From: Alex Shi @ 2026-04-09 13:51 UTC (permalink / raw)
To: Gary Guo, Dongliang Mu, Ben Guo, Alex Shi, Yanteng Si,
Jonathan Corbet
Cc: linux-doc, linux-kernel, rust-for-linux
In-Reply-To: <DHOJEMI0WBYX.2Y6HFZ2PYD7HS@garyguo.net>
On 2026/4/9 18:03, Gary Guo wrote:
>> Hi Gary,
>>
>> Let’s wait for the rust-next changes to land upstream first, then I’ll
>> ask Ben Guo to sync that commit. Otherwise, the Chinese translation
>> would do not match the original English doc, which will confuse readers.
>>
>> We have checktransupdate.py in place for monitoring the updates in
>> English documents.
>>
>> Dongliang Mu
> Given that you have tools to catch this, I'm also okay with this patch landing
> as is, with a follow up translation when the new quick-start.rst lands upstream.
>
It's better to have the full translation after the formal English
documents merging into upstream instead of several parts to combine for
a whole document.
Thanks
Alex
^ permalink raw reply
* Re: [PATCH 7/8] arm64/cpufeature: Define hwcaps for 2025 dpISA features
From: Mark Brown @ 2026-04-09 12:12 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
linux-kernel, linux-doc, linux-kselftest
In-Reply-To: <adeOnmy60AUQzSvo@arm.com>
[-- Attachment #1: Type: text/plain, Size: 2963 bytes --]
On Thu, Apr 09, 2026 at 12:33:50PM +0100, Catalin Marinas wrote:
> On Mon, Mar 02, 2026 at 10:53:22PM +0000, Mark Brown wrote:
> > @@ -3290,11 +3295,13 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
> > HWCAP_CAP(ID_AA64ISAR1_EL1, I8MM, IMP, CAP_HWCAP, KERNEL_HWCAP_I8MM),
> > HWCAP_CAP(ID_AA64ISAR1_EL1, LS64, LS64, CAP_HWCAP, KERNEL_HWCAP_LS64),
> > HWCAP_CAP(ID_AA64ISAR2_EL1, LUT, IMP, CAP_HWCAP, KERNEL_HWCAP_LUT),
> > + HWCAP_CAP(ID_AA64ISAR2_EL1, LUT, LUT6, CAP_HWCAP, KERNEL_HWCAP_LUT6),
> IIUC that's a LUTI6 SVE instruction which would not be available if
> SVE2p3 is not available (or SVE in general), though we have the
> equivalent SME one with SME2p3 (and a separate HWCAP for it). We should
> rename it to HWCAP_SVE_LUT6 and make it conditional on
> has_sve_feature().
OK, and hope that the SME feature always keeps in sync with this.
> KVM will probably confuse guests here if SVE is disabled but the
> ISAR2.LUT field is not capped (I haven't checked). The conditional
> has_sve_feature() would solve this but it won't address the MRS
> emulation. Arguably it's a KVM problem for exposing inconsistent
> id regs: ISAR2.LUT==0b0010 is not permitted without SVE2p3 or SME2p3.
> But the spec isn't greatly written either - why does a field about
> AdvSIMD all of a sudden reports SVE instructions availability?
Yeah, it's just a generally interesting choice for the architecture.
It'll also be fun if we get a new LUT feature that isn't SVE/SME
specific.
> On SME, unless I'm misreading the spec, the bits seem to have been
> written by three different people in isolation:
> - ID_AA64ZFR0_EL1.SVEver + ID_AA64PFR1_EL1.SME (and if these weren't
> enough, we have ID_AA64SMFR0_EL1.SMEver) tells us that SME2p3 is
> implemented. LUTI6 is mandated by SME2p3
> - ID_AA64SMFR0_EL1.LUT6 means that the LUTI6 instruction is present but
> this field can only be 0b1 with SME2p3
> - ID_AA64ISAR2_EL1.LUT == 0b0010 means that LUTI6 instruction is present
> (if SVE2p3 or SME2p3) and, again, that's the only value permitted by
> SME2p3
> So a lot of redundancy and we did end up reporting the fine-grained
> details to the user already. The SMExpy versions seem to be cumulative
> unless Arm decides to make some of the instructions optional (it still
> doesn't explain why we have the same information in SMFR0 and ISAR2). I
> guess that's where the fine-grained HWCAPs come in handy.
There's a few things like this with the FP extension, I think mostly
with SME - it's future proofing in case we want to allow more
flexibility with when the individual features are available.
> I wonder if the user would ever be able to parse these ID fields
> correctly if using the MRS emulation. We'd need to sanity-check KVM as
> well, not sure it proactively caps id fields.
Yeah, there's some traps here. Generally you're probably best using the
most specific field for a given feature but there's still traps there.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 7/8] arm64/cpufeature: Define hwcaps for 2025 dpISA features
From: Catalin Marinas @ 2026-04-09 11:33 UTC (permalink / raw)
To: Mark Brown
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
linux-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260302-arm64-dpisa-2025-v1-7-0855e7f41689@kernel.org>
On Mon, Mar 02, 2026 at 10:53:22PM +0000, Mark Brown wrote:
> @@ -3290,11 +3295,13 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
> HWCAP_CAP(ID_AA64ISAR1_EL1, I8MM, IMP, CAP_HWCAP, KERNEL_HWCAP_I8MM),
> HWCAP_CAP(ID_AA64ISAR1_EL1, LS64, LS64, CAP_HWCAP, KERNEL_HWCAP_LS64),
> HWCAP_CAP(ID_AA64ISAR2_EL1, LUT, IMP, CAP_HWCAP, KERNEL_HWCAP_LUT),
> + HWCAP_CAP(ID_AA64ISAR2_EL1, LUT, LUT6, CAP_HWCAP, KERNEL_HWCAP_LUT6),
IIUC that's a LUTI6 SVE instruction which would not be available if
SVE2p3 is not available (or SVE in general), though we have the
equivalent SME one with SME2p3 (and a separate HWCAP for it). We should
rename it to HWCAP_SVE_LUT6 and make it conditional on
has_sve_feature().
KVM will probably confuse guests here if SVE is disabled but the
ISAR2.LUT field is not capped (I haven't checked). The conditional
has_sve_feature() would solve this but it won't address the MRS
emulation. Arguably it's a KVM problem for exposing inconsistent
id regs: ISAR2.LUT==0b0010 is not permitted without SVE2p3 or SME2p3.
But the spec isn't greatly written either - why does a field about
AdvSIMD all of a sudden reports SVE instructions availability?
On SME, unless I'm misreading the spec, the bits seem to have been
written by three different people in isolation:
- ID_AA64ZFR0_EL1.SVEver + ID_AA64PFR1_EL1.SME (and if these weren't
enough, we have ID_AA64SMFR0_EL1.SMEver) tells us that SME2p3 is
implemented. LUTI6 is mandated by SME2p3
- ID_AA64SMFR0_EL1.LUT6 means that the LUTI6 instruction is present but
this field can only be 0b1 with SME2p3
- ID_AA64ISAR2_EL1.LUT == 0b0010 means that LUTI6 instruction is present
(if SVE2p3 or SME2p3) and, again, that's the only value permitted by
SME2p3
So a lot of redundancy and we did end up reporting the fine-grained
details to the user already. The SMExpy versions seem to be cumulative
unless Arm decides to make some of the instructions optional (it still
doesn't explain why we have the same information in SMFR0 and ISAR2). I
guess that's where the fine-grained HWCAPs come in handy.
I wonder if the user would ever be able to parse these ID fields
correctly if using the MRS emulation. We'd need to sanity-check KVM as
well, not sure it proactively caps id fields.
--
Catalin
^ permalink raw reply
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: Gary Guo @ 2026-04-09 11:02 UTC (permalink / raw)
To: Joel Fernandes, Alexandre Courbot, Eliot Courtney,
Danilo Krummrich
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi, joel,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <2f004511-61d1-4197-84b6-cddcdd275e55@nvidia.com>
On Wed Apr 8, 2026 at 9:19 PM BST, Joel Fernandes wrote:
> Hi Alex, Eliot, Danilo,
>
> Thanks for taking a look. Let me respond to the specific points below.
>
> On Wed, 08 Apr 2026, Alexandre Courbot wrote:
>> After a quick look I'd say that having a trait here would actually be
>> *good* for correctness and maintainability.
>>
>> The current design implies that every operation on a page table (most
>> likely using the walker) goes through a branching point. Just looking at
>> `PtWalk::read_pte_at_level`, there are already at least 6
>> `if version == 2 { } else { }` branches that all resolve to the same
>> result. Include walking down the PDEs and you have at least a dozen of
>> these just to resolve a virtual address. I know CPUs are fast, but this
>> is still wasted cycles for no good reason.
>
> I did some measurements and there is no notieceable difference in both
> approaches. I ran perf and loaded nova with self-tests running. The extra
> potential branching is lost in the noise. In both cases, loading nova and
> running the self-tests has ~119.7M branch instructions on my Ampere. The total
> instruction count is also identical (~615M).
>
> I measured like this:
> perf stat -e
> branches,branch-misses,cache-references,cache-misses,instructions,cycles --
> modprobe nova_core
>
> So I think the branching argument is not a strong one. I also did more
> measurements and the dominant time taken is MMIO. During the map prep and
> execute, page table walks are done. A TLB flush alone costs ~1.4 microseconds.
> And PRAMIN BAR0 writes to write the PTE is also about 1 microsecond. Considering
> this, I don't think the extra branching argument holds (even without branch
> prediction and speculation).
>
> Also some branches cannot be eliminated even with parameterization:
>
> if level == self.mmu_version.dual_pde_level() {
> // 128-bit dual PDE read
> } else {
> // Regular 64-bit PDE read
> }
>
> This isn't really a version branch -- it's a structural branch that
> distinguishes between 64-bit PDE and 128-bit dual PDE entries. Any MMU
> version with a dual PDE level would need this same distinction.
>
> I also did code-generation size analysis (see diff of code used below):
>
> Code generation analysis:
>
> Module .ko size: Before: 511,792 bytes After: 524,464 bytes (+2.5%)
> .text section: Before: 112,620 bytes After: 116,628 bytes (+4,008 bytes)
>
> The +4K .text growth is the monomorphization cost: every generic function
> is compiled twice (once for MmuV2, once for MmuV3).
>
>> If you use a trait here, and make `PtWalk` generic against it, you can
>> optimize this away. We had a similar situation when we introduced Turing
>> support and the v2 ucode header, and tried both approaches: the
>> trait-based one was slightly shorter, and arguably more readable.
>
> Actually I was the one who suggested traits for Falcon ucode descriptor if you
> see this thread [1]. So basically you and Eliot are telling me to do what I
> suggested in [1]. :-) However, I disagree that it is the right choice for this code.
>
> [1] https://lore.kernel.org/all/20251117231028.GA1095236@joelbox2/
>
> I think the two cases are quite different in complexity:
>
> The falcon ucode descriptor is essentially a set of flat field accessors
> and a few params (imem_sec_load_params, dmem_load_params).
> The trait has ~10 simple getter methods. There's no multi-level hierarchy,
> no walker, and no generic propagation.
>
> The MMU page table case is structurally different. Making PtWalk generic
> over an Mmu trait would require:
>
> - PtWalk<M: Mmu> (the walker)
> - Plus all the associated types: M::Pte, M::Pde, M::DualPde each
> needing their own trait bounds
>
> And we would also need:
> - Vmm<M: Mmu> (which creates PtWalk)
> - BarUser<M: Mmu> (which creates Vmm)
>
> I am also against making Vmm an enum as Eliot suggested:
> enum Vmm {
> V2(VmmInner<MmuV2>),
> V3(VmmInner<MmuV3>),
> }
>
> That moves the version complexity up to the reader. Code complexity IMO should
> decrease as we go up abstractions, making it easier for users (Vmm/Bar).
>
> If you look at the the changes in vmm.rs to handle version dispatch there [2]:
> Added: +109
> Removed: -28
>
> [2]
> https://github.com/Edgeworth/linux/commit/3627af550b61256184d589e7ec666c1108971f0e
>
> The main benefit of my approach is version-specific dispatch complexity is
> completely isolated inside MmuVersion thus making the code outside of
> pagetable.rs much more readable, without having to parametrize anything, and
> without code size increase. I think that is worth considering.
>
>> But the main argument to use a trait here IMO is that it enables
>> associated types and constants. That's particularly critical since some
>> equivalent fields have different lengths between v2 and v3. An
>> associated `Bounded` type for these would force the caller to validate
>> the length of these fields before calling a non-fallible operation,
>> which is exactly the level of caution that we want when dealing with
>> page tables.
>
> I think Bounded validation is orthogonal to the dispatch model.
> We can add Bounded to the current design without restructuring
> into traits. For example:
>
> // In ver2::Pte
> pub fn new_vram(pfn: Bounded<Pfn, 25>, writable: bool) -> Self { ... }
>
> // In ver3::Pte
> pub fn new_vram(pfn: Bounded<Pfn, 40>, writable: bool) -> Self { ... }
>
> The unified Pte enum wrapper already dispatches to the correct
> version-specific constructor, which would enforce the correct Bounded
> constraint for that version.
>
>> In order to fully benefit from it, we will need the bitfield macro from
>> the `kernel` crate so the PDE/PTE fields can be `Bounded`, I will try to
>> make it available quickly in a patch that you can depend on.
>
> That would be great, and I'd be happy to integrate Bounded validation once
> the macro is available. I just don't think we need to restructure the
> dispatch model in order to benefit from it.
>
>> But long story short, and although I need to dive deeper into the code,
>> this looks like a good candidate for using a trait and associated types.
>
> The walker code (walk.rs) is already version-agnostic and reads cleanly.
> The version dispatch is encapsulated behind method calls, not exposed as
> inline if/else blocks.
>
> Generic propagation (or version-specific dispatch at higher levels) adds more
> complexity at higher layers.
>
> Enclosed below [3] is the diff I used for my testing with the data, I don't
> really see a net readability win there (IMO, it is a net-loss in readability).
>
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/commit/?h=trait-pt-dispatch&id=5eb0e98af11ba608ff4d0f7a06065ee863f5066a
IMO this diff is quite has got me quite in favour of trait approach.
I wanted about to purpose something similar (or maybe I had already?) trait
approach some versions ago but didn't due to the eventual need of `match` like
dispatch (like you had with `vmm_dispatch`), but your code made that looks not
as bad as I thought it would be.
Best,
Gary
^ permalink raw reply
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: Danilo Krummrich @ 2026-04-09 11:00 UTC (permalink / raw)
To: Joel Fernandes
Cc: John Hubbard, Eliot Courtney, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Dave Airlie,
Daniel Almeida, Koen Koning, dri-devel, rust-for-linux,
Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Vivi Rodrigo, Tvrtko Ursulin, Rui Huang, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, Alexey Ivanov,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <1775730646.3752.4760@nvidia.com>
On Thu Apr 9, 2026 at 12:33 PM CEST, Joel Fernandes wrote:
> Since it is 3 against 1 here, I rest my case :-).
That's not how I'd view it. :)
Anyways, in case I'm included in "3", that's not my position. My point was to
ensure we keep discussing advantages and disadvantages on their merits, as I
think you both have good points.
> I am still in disagreement since I do not see much benefit (that is why I said
> pointless above).
That is fair -- in this case please explain why the advantages pointed out by
others are not worth it, propose something that picks up the best of both
worlds, etc.
You can also turn it around and ask people whether they can tweak their counter
proposal to get rid of specific parts you dislike for a reason.
IOW, keep the ball rolling, so we can come up with the best possible solution.
^ permalink raw reply
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: Alexandre Courbot @ 2026-04-09 10:56 UTC (permalink / raw)
To: Joel Fernandes
Cc: Eliot Courtney, Danilo Krummrich, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Dave Airlie,
Daniel Almeida, Koen Koning, dri-devel, rust-for-linux,
Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi, joel,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <2f004511-61d1-4197-84b6-cddcdd275e55@nvidia.com>
On Thu Apr 9, 2026 at 5:19 AM JST, Joel Fernandes wrote:
> Hi Alex, Eliot, Danilo,
>
> Thanks for taking a look. Let me respond to the specific points below.
>
> On Wed, 08 Apr 2026, Alexandre Courbot wrote:
>> After a quick look I'd say that having a trait here would actually be
>> *good* for correctness and maintainability.
>>
>> The current design implies that every operation on a page table (most
>> likely using the walker) goes through a branching point. Just looking at
>> `PtWalk::read_pte_at_level`, there are already at least 6
>> `if version == 2 { } else { }` branches that all resolve to the same
>> result. Include walking down the PDEs and you have at least a dozen of
>> these just to resolve a virtual address. I know CPUs are fast, but this
>> is still wasted cycles for no good reason.
>
> I did some measurements and there is no notieceable difference in both
> approaches. I ran perf and loaded nova with self-tests running. The extra
> potential branching is lost in the noise. In both cases, loading nova and
> running the self-tests has ~119.7M branch instructions on my Ampere. The total
> instruction count is also identical (~615M).
That's expected - as I said, CPUs are fast - and that's also not my
point. My issue is that we are doing countless tests that all resolve to
the code path, a code path that is already known during probe time.
That's a huge code smell.
When we create the GPU, we know whether we will be using v2 or v3 page
tables. That we need to test that again 12 times per address resolution
is a design issue, irrespective of performance. There are 24 version
match sites in patch 12 alone.
And that's precisely a good justification for using monomorphization. v2
and v3 are technically two different page table implementations (they
even have their own distinct module in your series), we just use
generics to factorize the (source) code a bit.
>
> I measured like this:
> perf stat -e
> branches,branch-misses,cache-references,cache-misses,instructions,cycles --
> modprobe nova_core
>
> So I think the branching argument is not a strong one. I also did more
> measurements and the dominant time taken is MMIO. During the map prep and
> execute, page table walks are done. A TLB flush alone costs ~1.4 microseconds.
> And PRAMIN BAR0 writes to write the PTE is also about 1 microsecond. Considering
> this, I don't think the extra branching argument holds (even without branch
> prediction and speculation).
>
> Also some branches cannot be eliminated even with parameterization:
>
> if level == self.mmu_version.dual_pde_level() {
> // 128-bit dual PDE read
> } else {
> // Regular 64-bit PDE read
> }
>
> This isn't really a version branch -- it's a structural branch that
> distinguishes between 64-bit PDE and 128-bit dual PDE entries. Any MMU
> version with a dual PDE level would need this same distinction.
The dual PDE level should be an associated constant - you still need to
do the test, but note that you would also do it if there was only a
single page table version. It's orthogonal to whether we use a trait or
not here.
>
> I also did code-generation size analysis (see diff of code used below):
>
> Code generation analysis:
>
> Module .ko size: Before: 511,792 bytes After: 524,464 bytes (+2.5%)
> .text section: Before: 112,620 bytes After: 116,628 bytes (+4,008 bytes)
>
> The +4K .text growth is the monomorphization cost: every generic function
> is compiled twice (once for MmuV2, once for MmuV3).
I would say this is working as intended then.
>
>> If you use a trait here, and make `PtWalk` generic against it, you can
>> optimize this away. We had a similar situation when we introduced Turing
>> support and the v2 ucode header, and tried both approaches: the
>> trait-based one was slightly shorter, and arguably more readable.
>
> Actually I was the one who suggested traits for Falcon ucode descriptor if you
> see this thread [1]. So basically you and Eliot are telling me to do what I
> suggested in [1]. :-) However, I disagree that it is the right choice for this code.
>
> [1] https://lore.kernel.org/all/20251117231028.GA1095236@joelbox2/
>
> I think the two cases are quite different in complexity:
Exactly. The complexity is different (this one involves multiple traits
and associated types) but the pattern is the same - and that's a pattern
traits are designed to address. If we were supposed to stop applying it
when things go beyond a certain level of complexity, the conceptors of
Rust would not have bothered addings things like associated types.
These traits are nothing new, they simply formalize a reality that
already exists in your code, which is that each version of the page
table needs to implement a given set of methods. It's already there with
the version doing dispatches, only it is not articulated clearly to the
reader. So in that respect, having traits make the code *more* readable
imho.
>
> The falcon ucode descriptor is essentially a set of flat field accessors
> and a few params (imem_sec_load_params, dmem_load_params).
> The trait has ~10 simple getter methods. There's no multi-level hierarchy,
> no walker, and no generic propagation.
>
> The MMU page table case is structurally different. Making PtWalk generic
> over an Mmu trait would require:
>
> - PtWalk<M: Mmu> (the walker)
> - Plus all the associated types: M::Pte, M::Pde, M::DualPde each
> needing their own trait bounds
>
> And we would also need:
> - Vmm<M: Mmu> (which creates PtWalk)
> - BarUser<M: Mmu> (which creates Vmm)
>
> I am also against making Vmm an enum as Eliot suggested:
> enum Vmm {
> V2(VmmInner<MmuV2>),
> V3(VmmInner<MmuV3>),
> }
>
> That moves the version complexity up to the reader. Code complexity IMO should
> decrease as we go up abstractions, making it easier for users (Vmm/Bar).
>
> If you look at the the changes in vmm.rs to handle version dispatch there [2]:
> Added: +109
> Removed: -28
>
> [2]
> https://github.com/Edgeworth/linux/commit/3627af550b61256184d589e7ec666c1108971f0e
>
> The main benefit of my approach is version-specific dispatch complexity is
> completely isolated inside MmuVersion thus making the code outside of
> pagetable.rs much more readable, without having to parametrize anything, and
> without code size increase. I think that is worth considering.
>
>> But the main argument to use a trait here IMO is that it enables
>> associated types and constants. That's particularly critical since some
>> equivalent fields have different lengths between v2 and v3. An
>> associated `Bounded` type for these would force the caller to validate
>> the length of these fields before calling a non-fallible operation,
>> which is exactly the level of caution that we want when dealing with
>> page tables.
>
> I think Bounded validation is orthogonal to the dispatch model.
> We can add Bounded to the current design without restructuring
> into traits. For example:
>
> // In ver2::Pte
> pub fn new_vram(pfn: Bounded<Pfn, 25>, writable: bool) -> Self { ... }
>
> // In ver3::Pte
> pub fn new_vram(pfn: Bounded<Pfn, 40>, writable: bool) -> Self { ... }
>
> The unified Pte enum wrapper already dispatches to the correct
> version-specific constructor, which would enforce the correct Bounded
> constraint for that version.
But then what type does the `new_vram` dispatch method take? Generic
code lets us expose the expected `Bounded` type to the caller, which can
do the proper validation. This is a small example, but I expect this
pattern to come up in other parts of the code as well.
>
>> In order to fully benefit from it, we will need the bitfield macro from
>> the `kernel` crate so the PDE/PTE fields can be `Bounded`, I will try to
>> make it available quickly in a patch that you can depend on.
>
> That would be great, and I'd be happy to integrate Bounded validation once
> the macro is available. I just don't think we need to restructure the
> dispatch model in order to benefit from it.
I'll finish the series and hopefully send it a bit later today. That's
another significant rework for the series (sorry about that) but it
should be worth the effort for the added correctness.
^ permalink raw reply
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: Joel Fernandes @ 2026-04-09 10:33 UTC (permalink / raw)
To: John Hubbard
Cc: Joel Fernandes, Eliot Courtney, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Vivi Rodrigo, Tvrtko Ursulin, Rui Huang, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, Alexey Ivanov,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <42dd707f-e23a-4725-8b6f-08ca346b0143@nvidia.com>
> On Apr 8, 2026, at 7:13 PM, John Hubbard <jhubbard@nvidia.com> wrote:
>
> On 4/8/26 9:58 AM, Joel Fernandes wrote:
>>> On 4/8/2026 9:26 AM, Eliot Courtney wrote:
>>> On Tue Apr 7, 2026 at 10:59 PM JST, Joel Fernandes wrote:
>>>> On 4/7/2026 9:42 AM, Eliot Courtney wrote:
>>>>> On Tue Apr 7, 2026 at 6:55 AM JST, Joel Fernandes wrote:
> ...>> [1]: https://github.com/Edgeworth/linux/commits/review/nova-mm-v10/
>> First, thanks for the effort. I looked through this, its pretty much what I
>> had before when I used traits. I don't think it is better to be honest. In
>> fact your version is worse, it adds many new types and things like the
>> following which I did not need before.
>
> Hi Joel and all,
>
> I also looked through Eliot's above attempt carefully, and actually
> liked it a lot (sorry! haha):
>
> * It cleans up the code. The initial working version was readable, but
> also had lots of noise on the screen: match statements and pairs of
> v2/v3 statements.
>
> And interestingly, the mmu_version was, in effect, sporadically
> implementing a Trait-based approach. But because it is custom,
> readers don't benefit as much as they would with Traits, which
> tell you immediately how things are structured.
>
> Joel, I am passionately in agreement with your principles: code must
> be readable on the screen.
>
> In this case, though, Traits make considerably more readable,
> especially if one makes the very reasonable assumption that readers are
> thoroughly accustomed to dealing with Rust traits.
>
>>
>> To put it mildly, the following suggestion should not be anywhere near my code:
>>
>
> lol I understand, believe me. But this is short and not too bad, really.
>
>> /// Type-erased MMU-specific [`Vmm`] implementations.
>
> Type erasure remains a semi-exotic thing, IMHO. As such, another
> sentence to elaborate on this would be a nice touch.
>
>> enum VmmInner {
>> /// `Vmm` implementation for MMU v2.
>> V2(VmmImpl<MmuV2>),
>> /// `Vmm` implementation for MMU v3.
>> V3(VmmImpl<MmuV3>),
>> }
>>
>> /// MMU-specific [`Vmm`] implementation.
>> struct VmmImpl<M: Mmu> {
>>
>> Seriously, I have to pass on this. :-)
>>
>> And, you unfortunately seem to have ignored my point about requiring 4 NEW
>> traits (Mmu, PteOps, PdeOps, DualPdeOps etc), which I did not need before.
>> So you're making the code much much worse than before actually. We don't
>> new traits and types pointlessly.
>
> They are not pointless.
>
> However! What I think would be nice is: do a new v11 with approximately
> this approach, and then we can beat it into being as readable as
> possible.
Since it is 3 against 1 here, I rest my case :-). I am still in
disagreement since I do not see much benefit (that is why I said
pointless above). Actually it is not even about readability, that is
subjective (and I haven’t heard most people say parametrizing code for
the sake of it makes it more readable anyway). It is that the code gen
is worse, and the complexity is just moved to a higher level in the
code, not removed. So what are we getting out of this really, other than
more boiler plate in higher layers of the code that did not exist
before? Not performance, not better generated code. Really nothing. See
all the data points in my previous reply.
Note that if the mmu version threading bothers everyone so much, we can
also pass down chipset instead and let the walker deal with determining
versioning. Would that be better?
But otherwise and since you guys asked, here comes a parameterized v11... ;-).
(Coming next week since this week I’m working on IRQ handling).
thanks,
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH 3/4] docs/zh_CN: update rust/quick-start.rst translation
From: Gary Guo @ 2026-04-09 10:03 UTC (permalink / raw)
To: Dongliang Mu, Gary Guo, Ben Guo, Alex Shi, Yanteng Si,
Jonathan Corbet
Cc: linux-doc, linux-kernel, rust-for-linux
In-Reply-To: <d7e81015-f17e-4ab9-a9e5-d2ac6dd82e7b@hust.edu.cn>
On Thu Apr 9, 2026 at 6:37 AM BST, Dongliang Mu wrote:
>
> On 4/9/26 1:43 AM, Gary Guo wrote:
>> On Wed Apr 8, 2026 at 5:51 PM BST, Ben Guo wrote:
>>> On 4/8/26 7:33 PM, Gary Guo wrote:
>>>> Hi Ben,
>>>>
>>>> Thanks on updating the doc translation. There has been new changes to
>>>> quick-start.rst on rust-next, could you update the translation to base on that
>>>> please?
>>>>
>>>> Thanks,
>>>> Gary
>>> Hi Gary,
>>>
>>>
>>>
>>>
>>>
>>> Thanks for the review. This series is based on the Chinese documentation
>>> maintainer's tree (alexs/linux.git docs-next), which does not yet have
>>> the latest quick-start.rst changes from the Rust-for-Linux rust-next
>>> tree.
>>>
>>> Would it be better to wait until those changes land in our base tree
>>> and then resend with the updated translation? Or would you prefer a
>>> different approach?
>>>
>>> Thanks,
>>> Ben
>> I don't see the issue of sending translation of the latest quick-start.rst even
>> if it's not in your base yet. By the time the changes land upstream, the
>> original quick-start.rst would already be there.
>
> Hi Gary,
>
> Let’s wait for the rust-next changes to land upstream first, then I’ll
> ask Ben Guo to sync that commit. Otherwise, the Chinese translation
> would do not match the original English doc, which will confuse readers.
>
> We have checktransupdate.py in place for monitoring the updates in
> English documents.
>
> Dongliang Mu
Given that you have tools to catch this, I'm also okay with this patch landing
as is, with a follow up translation when the new quick-start.rst lands upstream.
Acked-by: Gary Guo <gary@garyguo.net> # Rust
Thanks,
Gary
^ permalink raw reply
* Re: [PATCH net-next v2 05/14] libie: add bookkeeping support for control queue messages
From: Paolo Abeni @ 2026-04-09 9:07 UTC (permalink / raw)
To: Tony Nguyen, davem, kuba, edumazet, andrew+netdev, netdev
Cc: Phani R Burra, larysa.zaremba, przemyslaw.kitszel,
aleksander.lobakin, sridhar.samudrala, anjali.singhai,
michal.swiatkowski, maciej.fijalkowski, emil.s.tantilov,
madhu.chittim, joshua.a.hay, jacob.e.keller,
jayaprakash.shanmugam, jiri, horms, corbet, richardcochran,
linux-doc, Bharath R, Samuel Salin, Aleksandr Loktionov
In-Reply-To: <20260403194938.3577011-6-anthony.l.nguyen@intel.com>
On 4/3/26 9:49 PM, Tony Nguyen wrote:
> +static bool
> +libie_ctlq_xn_process_recv(struct libie_ctlq_xn_recv_params *params,
> + struct libie_ctlq_msg *ctlq_msg)
> +{
> + struct libie_ctlq_xn_manager *xnm = params->xnm;
> + struct libie_ctlq_xn *xn;
> + u16 msg_cookie, xn_index;
> + struct kvec *response;
> + int status;
> + u16 data;
> +
> + data = ctlq_msg->sw_cookie;
> + xn_index = FIELD_GET(LIBIE_CTLQ_XN_INDEX_M, data);
> + msg_cookie = FIELD_GET(LIBIE_CTLQ_XN_COOKIE_M, data);
> + status = ctlq_msg->chnl_retval ? -EFAULT : 0;
> +
> + xn = &xnm->ring[xn_index];
> + if (ctlq_msg->chnl_opcode != xn->virtchnl_opcode ||
> + msg_cookie != xn->cookie)
> + return false;
> +
> + spin_lock(&xn->xn_lock);
Sashiko says:
---
Because the cookie and opcode are checked before acquiring the lock, is
it possible for the transaction to time out, be returned to the free
list, and get reallocated for a new message before the lock is acquired?
If that happens, could the old delayed response falsely complete the
newly allocated transaction since the identifiers are not re-verified
inside the lock?
---
> +/**
> + * libie_xn_check_async_timeout - Check for asynchronous message timeouts
> + * @xnm: Xn transaction manager
> + *
> + * Call the corresponding callback to notify the caller about the timeout.
> + */
> +static void libie_xn_check_async_timeout(struct libie_ctlq_xn_manager *xnm)
> +{
> + u32 idx;
> +
> + for_each_clear_bit(idx, xnm->free_xns_bm, LIBIE_CTLQ_MAX_XN_ENTRIES) {
Sashiko says:
---
This iterates over the bitmap without holding the lock. Concurrently,
other paths modify this bitmap using non-atomic bitwise operations like
__clear_bit() and __set_bit() under the lock. Will this cause torn reads
or data races that might lead the timeout handler to skip valid
transactions or examine invalid ones?
---
> + params->ctlq_msg->sw_cookie = cookie;
> + params->ctlq_msg->send_mem = *dma_mem;
> + params->ctlq_msg->data_len = buf_len;
> + params->ctlq_msg->chnl_opcode = params->chnl_opcode;
> + ret = libie_ctlq_send(params->ctlq, params->ctlq_msg, 1);
> + }
> +
> + if (ret && !libie_cp_can_send_onstack(buf_len))
> + libie_cp_unmap_dma_mem(dev, dma_mem);
Sashiko says:
---
When libie_ctlq_send() fails here, the DMA memory is unmapped and the
buffer is freed by the caller. However, the software tracking ring at
tx_msg[next_to_use] still contains the populated send_mem details and a
non-zero data_len.
During driver teardown, libie_ctlq_xn_send_clean() is invoked with
params->force = true, which processes the ring without checking the
hardware completion bit. Could this cause the cleanup routine to process
the failed slot again, resulting in a double-free and double-unmap?
---
There are more remarks on the following patch, please have a look.
Also, it would be very helpful if you could help triaging such
(overwhelming amount of) feedback on future submissions, explicitly
commenting on the ML. Sashiko tends to be quite noise on device driver code.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH v3 0/2] docs: advanced search with benchmark harness
From: Rito Rhymes @ 2026-04-09 9:04 UTC (permalink / raw)
To: Randy Dunlap, Rito Rhymes; +Cc: linux-doc, linux-kernel
In-Reply-To: <b3c87ef0-5faf-4bda-90e4-e6b24419e0c0@infradead.org>
> I like it. I think it's useful -- the old search could give a bit too
> much output. The search result tabs (groups) are helpful.
Thanks for taking the time to test it out again and give feedback.
I'm glad you see potential utility for it.
> I mostly use 'grep' for searching Documentation/ and I expect lots
> of other developers also do that (if they bother to look).
That's definitely what I expect kernel hackers to default to.
I'd like to get a clearer sense of your perspective, it may represent
others too, and I can weigh it against my own assumptions here.
So my question framed for you is:
You know a particular concept you want to look up, but you do not know
the exact file, and related words repeat a lot across the source.
Could you imagine yourself going through grep results, not quickly
finding what you need, burning mental bandwidth and then deciding:
"let me just go on docs.kernel.org real quick, hit the advanced search,
and see what I find"?
Is that something you could actually see ever happening?
Maybe even, in that type of situation, eventually defaulting to that
mode first to avoid spending time scanning through noisy grep results.
Or is grep and staying in the terminal a comfortable enough place to
remain even when the results are not very fruitful and the time spent
there is not especially efficient?
Or does that situation just not come up often enough to justify a
separate mental workflow for it outside the grep norm?
> I do notice under the Pages tab that all of the pages listed say
> "Summary unavailable." I don't know what should be there instead of
> that message.
It's supposed to be populated with an excerpt from the page related
to the search criterion; 2-3 lines of text or so.
I encountered that same issue after an incremental rebuild, doing a
full rebuild fixed it.
Could you please confirm if it works after a full rebuild?
Rito
^ permalink raw reply
* Re: [PATCH net-next v2 02/14] libie: add PCI device initialization helpers to libie
From: Paolo Abeni @ 2026-04-09 8:56 UTC (permalink / raw)
To: Tony Nguyen, davem, kuba, edumazet, andrew+netdev, netdev
Cc: Phani R Burra, larysa.zaremba, przemyslaw.kitszel,
aleksander.lobakin, sridhar.samudrala, anjali.singhai,
michal.swiatkowski, maciej.fijalkowski, emil.s.tantilov,
madhu.chittim, joshua.a.hay, jacob.e.keller,
jayaprakash.shanmugam, jiri, horms, corbet, richardcochran,
linux-doc, bhelgaas, linux-pci, Bharath R, Samuel Salin,
Aleksandr Loktionov
In-Reply-To: <20260403194938.3577011-3-anthony.l.nguyen@intel.com>
On 4/3/26 9:49 PM, Tony Nguyen wrote:
> + mr = libie_find_mmio_region(&mmio_info->mmio_list, offset, size,
> + bar_idx);
> + if (mr) {
> + pci_warn(pdev,
> + "Mapping of BAR%u (offset=%llu, size=%llu) intersecting region (offset=%llu, size=%llu) already exists\n",
> + bar_idx, (unsigned long long)mr->offset,
> + (unsigned long long)mr->size,
> + (unsigned long long)offset, (unsigned long long)size);
> + return mr->offset <= offset &&
> + mr->offset + mr->size >= offset + size;
Sashiko says:
---
Does returning true here without creating a new tracking object leave
the new mapping tied to the original mapping's lifetime?
If the driver unmaps the original region, iounmap() is called and the
tracking object is freed. Any cached virtual address pointers to the
sub-region would then become a use-after-free, and subsequent queries
for the sub-region would fail.
---
/P
^ permalink raw reply
* Re: [PATCH] hwmon: (asus-ec-sensors) add ROG STRIX B650E-E GAMING WIFI
From: Eugene Shalygin @ 2026-04-09 8:18 UTC (permalink / raw)
To: Veronika Kossmann
Cc: Guenter Roeck, Veronika Kossmann, Veronika Kossmann,
Jonathan Corbet, Shuah Khan, linux-hwmon, linux-doc, linux-kernel
In-Reply-To: <25bbdd98-656e-407a-ada7-da2bdacb1aea@rxtx.cx>
Hey Veronika,
On Wed, 8 Apr 2026 at 22:29, Veronika Kossmann <nanodesu@rxtx.cx> wrote:
>
> Of course:
>
> $sensors asusec-isa-000a
> asusec-isa-000a
> Adapter: ISA adapter
> CPU: +37.0°C
> Motherboard: +38.0°C
> VRM: +51.0°C
>
> These are relevant to actual temperatures.
>
Thanks! So, there is no output for CPU current and chipset
temperature. Could you, please, test that CPU current displays
reasonable values with the following additional change:
diff --git a/asus-ec-sensors.c b/asus-ec-sensors.c
index 47e6c2db8b97..4a0b80012a6d 100644
--- a/asus-ec-sensors.c
+++ b/asus-ec-sensors.c
@@ -284,6 +284,7 @@ static const struct ec_sensor_info
sensors_family_amd_600[] = {
EC_SENSOR("VRM", hwmon_temp, 1, 0x00, 0x33),
[ec_sensor_temp_t_sensor] =
EC_SENSOR("T_Sensor", hwmon_temp, 1, 0x00, 0x36),
+ [ec_sensor_curr_cpu] = EC_SENSOR("CPU", hwmon_curr, 1, 0x00, 0xf4),
[ec_sensor_fan_cpu_opt] =
EC_SENSOR("CPU_Opt", hwmon_fan, 2, 0x00, 0xb0),
[ec_sensor_temp_water_in] =
At least it should correlate with CPU load.
And we need to replace SENSOR_SET_TEMP_CHIPSET_CPU_MB with
SENSOR_TEMP_CPU | SENSOR_TEMP_MB.
Cheers,
Eugene
^ permalink raw reply related
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