* [PATCH v1 0/7] gpu: nova-core: add INTR_CTRL interrupt controller and CPU doorbell self-test
From: Joel Fernandes @ 2026-05-01 20:58 UTC (permalink / raw)
To: linux-kernel
Cc: Danilo Krummrich, Alexandre Courbot, John Hubbard, Alice Ryhl,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Jonathan Corbet, Shuah Khan, nova-gpu, dri-devel,
rust-for-linux, linux-doc, Joel Fernandes
This series adds interrupt controller support to nova-core, and validates the
full interrupt path with a CPU-doorbell self-test. It is based on today's
drm-rust-next tree.
The GPU interrupt controller block (INTR_CTRL)
----------------------------------------------
INTR_CTRL is the GPU's two-level (top/leaf) interrupt controller. It
multiplexes all GSP and engine interrupts onto a single PCI MSI line. We need
it to receive asynchronous messages from GSP. GSP will the host with a SWGEN0
interrupt (routed via INTR_CTRL) to deliver async RPC messages like error
reports (XIDs) and other event. INTR_CTRL also routes notifications from GPU
engines to PCIe MSI such as submitted work completion, MMU faults, etc.
Detailed documentation of the architecture with diagrams are provided in a
separate patch (patch 7/7).
What this series proves
-----------------------
The CPU doorbell self-test (patch 6/7) exercises the full interrupt path
end-to-end. It uses the LEAF_TRIGGER hardware register in INTR_CTRL to trigger
a interrupt, then waits for the IRQ handler to fire. The path under test is:
LEAF_TRIGGER write
v
INTR_CTRL TOP/LEAF goes pending
v
GPU fires PCI MSI write
v
Host VFIO -> guest IOMMU/IRQ
v
Guest Linux IRQ -> nova-core handler
v
Handler
The full stack has been end-to-end tested on Ampere GA102 with GPU passthrough.
What comes next
---------------
This is the first stage. Once this lands, the next step is to read (via RPC)
the interrupt vector table that GSP programs at boot. That table tells us which
INTR_CTRL leaf and bit each engine is wired to, so the driver can route
incoming interrupts to per-engine handlers. Future patches will also add GSP interrupt
support, and a per-engine ISR dispatch loops.
The git tree with all patches can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git (tag: nova-intr-ctrl-v1-20260501b)
Joel Fernandes (7):
rust: sync: completion: add wait_for_completion_timeout()
gpu: nova-core: allocate PCI MSI vector during probe
gpu: nova-core: add interrupt controller register definitions
gpu: nova-core: add Architecture::is_pre_hopper() helper
gpu: nova-core: add INTR_CTRL interrupt controller API
gpu: nova-core: add CPU doorbell IRQ self-test
gpu: nova-core: document INTR_CTRL interrupt tree
Documentation/gpu/nova/core/intr-ctrl.rst | 305 +++++++++++++++++++++
Documentation/gpu/nova/index.rst | 1 +
drivers/gpu/nova-core/Kconfig | 13 +
drivers/gpu/nova-core/gpu.rs | 22 ++
drivers/gpu/nova-core/irq.rs | 29 ++
drivers/gpu/nova-core/irq/doorbell_test.rs | 203 ++++++++++++++
drivers/gpu/nova-core/irq/intr_ctrl.rs | 281 +++++++++++++++++++
drivers/gpu/nova-core/nova_core.rs | 2 +
drivers/gpu/nova-core/regs.rs | 13 +
rust/kernel/sync/completion.rs | 18 +-
10 files changed, 886 insertions(+), 1 deletion(-)
create mode 100644 Documentation/gpu/nova/core/intr-ctrl.rst
create mode 100644 drivers/gpu/nova-core/irq.rs
create mode 100644 drivers/gpu/nova-core/irq/doorbell_test.rs
create mode 100644 drivers/gpu/nova-core/irq/intr_ctrl.rs
base-commit: 610e892bdb57043c7769982c2bff0260b6007b75
--
2.34.1
^ permalink raw reply
* [PATCH v1 1/7] rust: sync: completion: add wait_for_completion_timeout()
From: Joel Fernandes @ 2026-05-01 20:58 UTC (permalink / raw)
To: linux-kernel
Cc: Danilo Krummrich, Alexandre Courbot, John Hubbard, Alice Ryhl,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Jonathan Corbet, Shuah Khan, nova-gpu, dri-devel,
rust-for-linux, linux-doc, Joel Fernandes
In-Reply-To: <20260501205825.73614-1-joelagnelf@nvidia.com>
Add a timeout variant of wait_for_completion() that wraps the C
function wait_for_completion_timeout(). Returns true if the task
completed before the timeout, else false.
The timeout is specified in jiffies. This is needed by drivers
that perform interrupt self-tests during probe, where an indefinite
wait would hang the system if the interrupt path is broken.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
---
rust/kernel/sync/completion.rs | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/rust/kernel/sync/completion.rs b/rust/kernel/sync/completion.rs
index c50012a940a3..a2f46862365e 100644
--- a/rust/kernel/sync/completion.rs
+++ b/rust/kernel/sync/completion.rs
@@ -6,7 +6,12 @@
//!
//! C header: [`include/linux/completion.h`](srctree/include/linux/completion.h)
-use crate::{bindings, prelude::*, types::Opaque};
+use crate::{
+ bindings,
+ prelude::*,
+ time::Jiffies,
+ types::Opaque, //
+};
/// Synchronization primitive to signal when a certain task has been completed.
///
@@ -109,4 +114,15 @@ pub fn wait_for_completion(&self) {
// SAFETY: `self.as_raw()` is a pointer to a valid `struct completion`.
unsafe { bindings::wait_for_completion(self.as_raw()) };
}
+
+ /// Wait for completion of a task with a timeout.
+ ///
+ /// This method waits for the completion of a task; it is not interruptible but has a timeout.
+ /// Returns `true` if the task completed before the timeout, `false` if the timeout elapsed.
+ ///
+ /// The timeout is specified in jiffies. See also [`Completion::complete_all`].
+ pub fn wait_for_completion_timeout(&self, timeout: Jiffies) -> bool {
+ // SAFETY: `self.as_raw()` is a pointer to a valid `struct completion`.
+ unsafe { bindings::wait_for_completion_timeout(self.as_raw(), timeout) != 0 }
+ }
}
base-commit: 610e892bdb57043c7769982c2bff0260b6007b75
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v1] docs: Remove icn= ISDN parameter
From: Randy Dunlap @ 2026-05-01 20:34 UTC (permalink / raw)
To: Costa Shulyupin, Jonathan Corbet, Shuah Khan, Andrew Morton,
Borislav Petkov (AMD), Dave Hansen, Dapeng Mi, Kees Cook,
Marco Elver, Jakub Kicinski, Li RongQing, Eric Biggers,
Paul E. McKenney, linux-doc, linux-kernel
In-Reply-To: <20260501182634.1110715-1-costa.shul@redhat.com>
On 5/1/26 11:26 AM, Costa Shulyupin wrote:
> The ICN ISDN driver was removed in commit 02bbd9802da7
> ("staging: i4l: delete the whole thing"), but the icn= kernel
> parameter documentation was left behind.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 41c657cd362c..6e21d8638d77 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2245,9 +2245,6 @@ Kernel parameters
> syscalls, essentially overriding IA32_EMULATION_DEFAULT_DISABLED at
> boot time. When false, unconditionally disables IA32 emulation.
>
> - icn= [HW,ISDN]
> - Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
> -
>
> idle= [X86,EARLY]
> Format: idle=poll, idle=halt, idle=nomwait
The pcbit (ISDN) driver has also been removed.
Would you also delete this line:
pcbit= [HW,ISDN]
--
~Randy
^ permalink raw reply
* [bvanassche:copy-offloading 6/15] Warning: block/blk-copy.c:10 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
From: kernel test robot @ 2026-05-01 20:29 UTC (permalink / raw)
To: Nitesh Shetty
Cc: oe-kbuild-all, Bart Van Assche, Vincent Fu, Anuj Gupta, linux-doc
tree: https://github.com/bvanassche/linux copy-offloading
head: 145ce5577cb6e492710d78c469338bac08d916d4
commit: fbd1337059d2e2acd851258f7aecd627917c4f7b [6/15] block: Add an onloaded copy implementation
config: arc-allnoconfig (https://download.01.org/0day-ci/archive/20260502/202605020409.k5N4LYv0-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260502/202605020409.k5N4LYv0-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605020409.k5N4LYv0-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: block/blk-copy.c:10 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
* Tracks the state of a single onloaded copy operation.
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3] docs/ja_JP: translate more of submitting-patches.rst
From: Akiyoshi Kurita @ 2026-05-01 19:11 UTC (permalink / raw)
To: linux-doc; +Cc: linux-kernel, corbet, akiyks, Akiyoshi Kurita
Translate the "Separate your changes", "Style-check your changes",
and "Select the recipients for your patch" sections in
Documentation/translations/ja_JP/process/submitting-patches.rst.
Keep the wording close to the English text and wrap lines to match
the style used in the surrounding Japanese translation.
Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org>
---
v3:
- Use a file-local cross-reference to the translated "変更を分割する" section
- Keep the TODO for the untranslated "The canonical patch format" section
- Drop the obsolete TODO for "Separate your changes"
- Rewrap the latter part more consistently
.../ja_JP/process/submitting-patches.rst | 123 +++++++++++++++++-
1 file changed, 118 insertions(+), 5 deletions(-)
diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst
index 91bd79a0e9dc..8f85d2cfde71 100644
--- a/Documentation/translations/ja_JP/process/submitting-patches.rst
+++ b/Documentation/translations/ja_JP/process/submitting-patches.rst
@@ -85,17 +85,16 @@ Linux の多くの環境は、上流から特定のパッチだけを取り込
パッチ説明を Linux のソースコード管理システム ``git`` の
「コミットログ」としてそのまま取り込める形で書けば、メンテナは
-助かります。詳細は原文の該当節を参照してください。
+助かります。詳細は原文の該当節 ("The canonical patch format") を
+参照してください。
.. TODO: Convert to file-local cross-reference when the destination is
translated.
1 つのパッチでは 1 つの問題だけを解決してください。記述が長くなり
-始めたら、パッチを分割すべきサインです。詳細は原文の該当節を参照
-してください。
+始めたら、パッチを分割すべきサインです。詳細は `変更を分割する`_ を
+参照してください。
-.. TODO: Convert to file-local cross-reference when the destination is
- translated.
パッチまたはパッチシリーズを投稿／再投稿する際は、その完全な
説明と、それを正当化する理由を含めてください。単に、これが
@@ -180,3 +179,117 @@ lore.kernel.org のメッセージアーカイブサービスを使ってくだ
$ git log -1 --pretty=fixes 54a4f0239f2e
Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
+
+変更を分割する
+--------------
+
+各 **論理的な変更** は、個別のパッチに分けてください。
+
+たとえば、単一のドライバに対する変更にバグ修正と性能改善の
+両方が含まれるなら、それらは 2 つ以上のパッチに分けてください。
+変更に API の更新と、その新しい API を使う新しいドライバが
+含まれるなら、それらは 2 つのパッチに分けてください。
+
+一方、多数のファイルに対して単一の変更を行う場合は、それらを
+1 つのパッチにまとめてください。つまり、1 つの論理的な変更は
+1 つのパッチに含めるべきです。
+
+覚えておくべき点は、各パッチがレビューアに理解しやすく、
+検証できる変更であるべきだということです。各パッチは、
+それ自体の妥当性で正当化できなければなりません。
+
+変更を完成させるために、あるパッチが別のパッチに依存するなら、
+それでも構いません。単に、パッチの説明に
+**"this patch depends on patch X"** と記してください。
+
+変更を一連のパッチに分ける際は、シリーズ中の各パッチを
+適用した後でも、カーネルが正しくビルドされ、正常に動作することを
+特に注意して確認してください。問題の追跡に ``git bisect`` を
+使う開発者は、あなたのパッチシリーズを任意の地点で分割する
+ことがあります。途中でバグを持ち込めば、彼らに感謝されることは
+ないでしょう。
+
+パッチセットをこれ以上小さくできないなら、一度に投稿するのは
+15 個程度までにして、レビューと統合を待ってください。
+
+
+変更のスタイルを確認する
+------------------------
+
+パッチに基本的なスタイル違反がないか確認してください。詳細は
+Documentation/process/coding-style.rst を参照してください。
+これを怠ると、単にレビューアの時間を無駄にするだけでなく、
+パッチはおそらく読まれもせずに却下されます。
+
+大きな例外が 1 つあります。コードをあるファイルから別の
+ファイルへ移動する場合です。このときは、コードを移動する
+その同じパッチの中で、移動したコードを一切変更してはいけません。
+そうすることで、コードの移動という行為と、あなたの変更とを
+明確に区別できます。これは実際の差分のレビューを大いに助け、
+ツールがコード自体の履歴をより適切に追跡できるようにします。
+
+提出前に、パッチスタイルチェッカー
+(``scripts/checkpatch.pl``) でパッチを確認してください。
+ただし、スタイルチェッカーは指針として見るべきであり、
+人間の判断に取って代わるものではないことに注意してください。
+違反があっても、その方がコードの見栄えがよいなら、
+そのままにしておくのが最善でしょう。
+
+チェッカーは 3 つのレベルで報告します:
+
+ - ERROR: 間違っている可能性が非常に高いもの
+ - WARNING: 慎重なレビューを要するもの
+ - CHECK: 検討を要するもの
+
+パッチに残した違反については、すべて理由を説明できなければ
+なりません。
+
+
+パッチの宛先を選択する
+----------------------
+
+各パッチでは、そのコードを保守する適切なサブシステムメンテナと
+メーリングリストを、必ず Cc に入れてください。誰がその
+メンテナかは、MAINTAINERS ファイルとソースコードの改訂履歴を
+調べて確認してください。この段階では ``scripts/get_maintainer.pl``
+が非常に役立ちます（パッチへのパスを引数として
+``scripts/get_maintainer.pl`` に渡してください）。作業中の
+サブシステムのメンテナが見つからない場合は、Andrew Morton
+(akpm@linux-foundation.org) が最後の手段となるメンテナです。
+
+すべてのパッチでは、デフォルトで linux-kernel@vger.kernel.org を
+使うべきですが、このリストの流量が多いため、目を通さなくなった
+開発者も少なくありません。とはいえ、無関係なメーリングリストや
+無関係な人々にスパムを送らないでください。
+
+カーネル関連のメーリングリストの多くは kernel.org で運営されており、
+その一覧は https://subspace.kernel.org で確認できます。ただし、
+他所で運営されているカーネル関連のメーリングリストもあります。
+
+Linux カーネルに採用されるすべての変更の最終的な裁定者は
+Linus Torvalds です。彼のメールアドレスは
+<torvalds@linux-foundation.org> です。Linus は大量のメールを
+受け取っており、現時点では彼に直接届くパッチはごくわずかなので、
+通常は彼にメールを送ることを極力避けてください。
+
+悪用可能なセキュリティバグを修正するパッチがあるなら、
+そのパッチを security@kernel.org に送ってください。深刻なバグに
+ついては、ディストリビュータがユーザーにパッチを配布できるよう、
+短期間の embargo が検討される場合があります。そのような場合、
+そのパッチを公開メーリングリストに送るべきではありません。
+Documentation/process/security-bugs.rst も参照してください。
+
+リリース済みカーネルの深刻なバグを修正するパッチは、次のような行を
+パッチの sign-off 欄に入れることで、stable メンテナへ向けてください::
+
+ Cc: stable@vger.kernel.org
+
+これはメールの受信者ではないことに注意してください。また、
+この文書に加えて Documentation/process/stable-kernel-rules.rst も
+読んでください。
+
+変更がユーザーランドとカーネルのインターフェースに影響する場合は、
+MAINTAINERS ファイルに記載されている MAN-PAGES メンテナに
+man-pages パッチ、少なくとも変更の通知を送って、情報が
+マニュアルページに反映されるようにしてください。ユーザー空間 API の
+変更は、linux-api@vger.kernel.org にも Cc してください。
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 5/5] Documentation: networking: add OPEN Alliance 10BASE-T1x MAC-PHY serial interface
From: Selvamani Rajagopal @ 2026-05-01 19:15 UTC (permalink / raw)
To: Piergiorgio Beruto, parthiban.veerasooran@microchip.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, corbet@lwn.net,
skhan@linuxfoundation.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Added the changes to API to support onsemi devices and
new APIs introduced to support hardware timestamp.
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
---
Documentation/networking/oa-tc6-framework.rst | 32 ++++++++++++++++---
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/oa-tc6-framework.rst b/Documentation/networking/oa-tc6-framework.rst
index fe2aabde9..cae16e4bf 100644
--- a/Documentation/networking/oa-tc6-framework.rst
+++ b/Documentation/networking/oa-tc6-framework.rst
@@ -453,8 +453,9 @@ Device drivers API
The include/linux/oa_tc6.h defines the following functions:
-.. c:function:: struct oa_tc6 *oa_tc6_init(struct spi_device *spi, \
- struct net_device *netdev)
+.. c:function:: struct oa_tc6 *oa_tc6_init(void *priv, struct spi_device *spi, \
+ struct net_device *netdev, \
+ struct mii_bus *bus)
Initialize OA TC6 lib.
@@ -485,13 +486,36 @@ Reading multiple consecutive registers starting from @address in the MAC-PHY.
Maximum of 128 consecutive registers can be read starting at @address.
.. c:function:: netdev_tx_t oa_tc6_start_xmit(struct oa_tc6 *tc6, \
- struct sk_buff *skb);
+ struct sk_buff *skb)
The transmit Ethernet frame in the skb is or going to be transmitted through
the MAC-PHY.
-.. c:function:: int oa_tc6_zero_align_receive_frame_enable(struct oa_tc6 *tc6);
+.. c:function:: int oa_tc6_zero_align_receive_frame_enable(struct oa_tc6 *tc6)
Zero align receive frame feature can be enabled to align all receive ethernet
frames data to start at the beginning of any receive data chunk payload with a
start word offset (SWO) of zero.
+
+.. c:function:: int oa_tc6_hwtstamp_ioctl(struct oa_tc6 *tc6, \
+ struct ifreq *rq, int cmd)
+Legacy ioctl interface for supporting hardware timestmp.
+
+frames data to start at the beginning of any receive data chunk payload with a
+
+.. c:function:: int oa_tc6_hwtstamp_set(struct oa_tc6 *tc6, \
+ struct kernel_hwtstamp_config *cfg)
+Interface to set hardware timestmp configuration through ndo_hwtstamp_set.
+This API is used by legacy ioctl interface as well.
+
+.. c:function:: void oa_tc6_hwtstamp_get(struct oa_tc6 *tc6, \
+ struct kernel_hwtstamp_config *cfg)
+
+Interface to get the hardware timestmp configuration through ndo_hwtstamp_get.
+This API is used by legacy ioctl interface as well.
+
+.. c:function:: void *oa_tc6_priv(struct oa_tc6 *tc6)
+Interface to get vendor's private data structure from oa_tc6 structure. This
+is needed for vendor implemented mii_bus APIs, as mii_bus APIs priv
+pointer carries oa_tc6 structure.
+
--
2.43.0
Public Information
^ permalink raw reply related
* Re: [PATCH v1] docs: Remove icn= ISDN parameter
From: Dave Hansen @ 2026-05-01 18:35 UTC (permalink / raw)
To: Costa Shulyupin, Jonathan Corbet, Shuah Khan, Andrew Morton,
Borislav Petkov (AMD), Randy Dunlap, Dave Hansen, Dapeng Mi,
Kees Cook, Marco Elver, Jakub Kicinski, Li RongQing, Eric Biggers,
Paul E. McKenney, linux-doc, linux-kernel
In-Reply-To: <20260501182634.1110715-1-costa.shul@redhat.com>
On 5/1/26 11:26, Costa Shulyupin wrote:
> The ICN ISDN driver was removed in commit 02bbd9802da7
> ("staging: i4l: delete the whole thing"), but the icn= kernel
> parameter documentation was left behind.
>
> Assisted-by: Claude:claude-opus-4-6
You might also want to ask Claude to help you with your cc list. ;)
https://claude.ai/share/ba8d193d-d20c-409f-9f77-5e582e6a06a7
get_maintainer.pl is useful, but not to be blindly trusted, please.
^ permalink raw reply
* Re: [PATCH 0/5] mm: Support selecting doing direct COW for anonymous pmd entry
From: David Hildenbrand (Arm) @ 2026-05-01 18:30 UTC (permalink / raw)
To: Luka Bai
Cc: linux-mm, Jonathan Corbet, Shuah Khan, Andrew Morton,
Lorenzo Stoakes, Zi Yan, Baolin Wang, Liam R. Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Jann Horn,
Arnd Bergmann, Kairui Song, linux-kernel, linux-arch, linux-doc,
Luka Bai
In-Reply-To: <afTR48WxGnIpxK8a@LUKABAI-MC1>
>>
>> Note that there was a recent related discussion for executable, which was rejected:
>>
>> https://lore.kernel.org/r/20251226100337.4171191-1-zhangqilong3@huawei.com
>>
>
> Yes, I know this history, and I know that it will cost some memory or latency,
> That’s why I was wondering maybe I can add a switch to it to make it
> configurable :).
Switches for something like that is just not a good fit.
For example, for a short-lived child (e.g., fork+exec) it usually makes no sense
to cow a larger chunk of address space, when you know that it will exit
immediately either way and free up the memory.
>>>
>>> In addition to the problem above, this logic can also generate some
>>> deficiency for THP itself. Currently THP is just a "best-effort" choice
>>> with no "certainty". THP is easily splitted into multiple small pages
>>> on common calling path like reclaiming, COW. A transparent splitting
>>> can cause throughput fluctuation for some workloads. For these workloads,
>>> we may want to give THP some "certainty" just like hugetlbfs,
>>
>> There are no such guarantees, though. And We wouldn't want to commit to any such
>> guarantees today. For example, simple page migration can split the folio.
>> Allocation failures will fallback to small pages etc.
>>
>> If you need guarantees, use hugetlb for now.
>>
>
> The reason why I want to use THP over hugetlb is that I need reclamation for my
> workload :). There are many processes in my workload that need 2M
> aligned folios for better performance, and we want to reclaim them back automatically
> when the process doesn’t need the folios.
Can you share some details how exactly that is supposed to work?
> But hugetlbfs cannot do passive reclamation
> from what I know (except doing active madvise by the processes themselves). And using
Right, you can only return hugetlb folios by doing MADV_DONTNEED or munmap().
> THP can easily split the hugepages. So that’s why I would like to add certainty for THP,
Repeat after me: there are no guarantees. There is no certainty :)
> and use THP for these processes as backend, because THP is very well integrated with
> the swap system and other filesystems. And from what I checked,
> it seems the most common case for splitting a THP is COW and swapping so I am trying
> to handle these two scenarios (But coincidentally, PMD swapping is committed in
> https://lore.kernel.org/all/D3F08F85-76E0-4C5A-ABA1-537C68E038B8@nvidia.com/
> a few days before, which is a great implementation :) ).
Right, but that really only changes how we map large folios, not how we allocate
them. There are no guarantees.
>
>>> The effect
>>> we want is: after some customized setup, if only the system has usable
>>> folio, and the virtual memory alignment permits (or we setup to), we can
>>> make sure we always use THP for it, the system will never split it except
>>> the user wants to do so.
>>>
>>> This patchset is about both two things above, firstly we add pmd level
>>> THP COW support by revising the code in do_huge_pmd_wp_page, we added
>>> switch for it because different workloads may need different resources,
>>
>> The switch is bad, and we won't accept any toggle like that. A system-wide
>> setting does not make sense for such behavior.
>>
>
> Oh, the reason why I added a switch globally is also because the scenario I mentioned
> above, I want those processes to always use PMD sized folios as backend to make sure
> performance.
"Always" is wishful thinking in many scenarios I'm afraid.
> COW is truly not that common like swap out/swap in, it just can happen
> sometimes, which I guess the reason may be about image duplication. Setting the system
> globally is more convenient for my situation :). I can go without this global switch
> if it's more reasonable.
>
>> A per-VMA flag? Maybe, but I expect pushback as well, as it is way too specific.
>> So we'd have to find some concept that abstracts these semantics. But I expect
>> pushback as well.
>>
>> We messed up enough with toggles in THP space, unfortunately.
>>
>> Also, anything that only works for PMD-sized THPs is a warning sign in 2026 :)
>>
>
> And for PMD-sized THPs, actually, I’m also considering adding more support for
> COW to mTHP if the upstream consider it useful. And also for pud sized THPs
> also. But I guess I have to firstly handle stage 1: PMD level COW now :).
> And also, since PMD sized folio is commonly used in my workload, I'm also wondering
> digging into pmd sized KSM in the future, in which I think pmd sized COW may
> be more useful then :).
I'm afraid I have to stop you right there: there has to be a pretty convincing
story to add any of that. In particular KSM with large folios (/me shivering).
But I already don't buy the COW story. Just configure khugepaged in a better way
or use MADV_COLLAPSE and you don't really need to modify the kernel at all in
99.99% of the case. (khugepaged needs a lot of tuning work, it's currently not
the smartest implementation)
Maybe, we might give khugepaged better direction of what to try scanning next
(e.g., where we just COW'ed a THP). Not sure, there are plenty of things to explore.
>
>> You don't really raise any concrete use cases or performance numbers for these
>> use cases. Some details about applications that use fork() and rely on such
>> behavior would be helpful.
>>
>
> Sorry for that, the concrete workload itself hasn't been finished yet.
Okay, what I thought after seeing no workloads an no performance numbers :)
If you don't know the workload, how can you claim that the additional latency
and/or memory consumption is not a problem?
Also: there is no guarantee that you will actually succeed in allocating a PMD
THP during a COW fault.
> Now it just
> can happen sometimes in my multi-2M-sized-processes workload test. But the user
> of our 2M sized folio schema is actually not necessarily myself but also can be the
> userspace developers. I cannot guarantee that fork will not be used in the
> performance test of their workload since that is a normal posix call. Maybe a little
> overthinking? :)
If your application cares about performance, you either shouldn't be using
fork(), or you should be using it very, very wisely (e.g., interaction with
multi-threading, MADV_DONTFORK, avoid touching memory in parent until child
completed).
> I just think swap and COW are two main scenarios that may transparently split pmd sized
> folios, so maybe we can solve it and make THP both reclaimable and stable.
There is page migration, MADV_DONTNEED, munmap/mremap/madvise/mprotect in sub-2M
blocks, memory failure handling and probably a lot more. THP allocation might
fail. THP swapout+swapin might fail to allocate THPs.
Tackling COW handling when you don't even know that it's a real problem seems
premature.
> Maybe
> that can make THP more widely used in real deployed environment since the resource
> can become more controllable for the users :). That's why I was thinking maybe
> implementing it with setup switches is a reasonable solution?
No magical toggles.
>
>> Note that an application that does fork() could use MADV_COLLAPSE after fork()
>> to make sure that it immediately gets THPs back.
>>
>> There is also the option to just use MADV_DONTFORK to not even share ranges with
>> a child process in the first place, avoiding page copies entirely.
>>
>
> MADV_DONTFORK and MADV_COLLAPSE are nice and great options :), but the former one seems
> to be a little wasteful :).
It's actually the right thing to do (tm) if you care about fork() performance
and know that your child will not actually need certain memory areas.
For example, in QEMU we use it to exclude all guest memory from fork(), heavily
improving fork() performance. [there are not a lot of fork() use cases left in
QEMU today, fortunately]
--
Cheers,
David
^ permalink raw reply
* [PATCH v1] docs: Remove icn= ISDN parameter
From: Costa Shulyupin @ 2026-05-01 18:26 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Andrew Morton, Borislav Petkov (AMD),
Randy Dunlap, Dave Hansen, Dapeng Mi, Kees Cook, Marco Elver,
Jakub Kicinski, Li RongQing, Eric Biggers, Paul E. McKenney,
linux-doc, linux-kernel
Cc: Costa Shulyupin
The ICN ISDN driver was removed in commit 02bbd9802da7
("staging: i4l: delete the whole thing"), but the icn= kernel
parameter documentation was left behind.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
---
Documentation/admin-guide/kernel-parameters.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 41c657cd362c..6e21d8638d77 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2245,9 +2245,6 @@ Kernel parameters
syscalls, essentially overriding IA32_EMULATION_DEFAULT_DISABLED at
boot time. When false, unconditionally disables IA32 emulation.
- icn= [HW,ISDN]
- Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
-
idle= [X86,EARLY]
Format: idle=poll, idle=halt, idle=nomwait
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 02/11] PCI: liveupdate: Track outgoing preserved PCI devices
From: David Matlack @ 2026-05-01 18:25 UTC (permalink / raw)
To: Samiullah Khawaja
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Shuah Khan, Will Deacon, William Tu, Yi Liu
In-Reply-To: <afTgOXpUNWMapPAS@google.com>
On Fri, May 1, 2026 at 11:17 AM Samiullah Khawaja <skhawaja@google.com> wrote:
>
> On Thu, Apr 30, 2026 at 09:15:14PM +0000, David Matlack wrote:
> >On 2026-04-28 05:24 PM, Samiullah Khawaja wrote:
> >> On Thu, Apr 23, 2026 at 09:23:06PM +0000, David Matlack wrote:
> >
> >> > + for (i = 0; i < ser->max_nr_devices; i++) {
> >> > + /*
> >> > + * Start searching at index ser->nr_devices. This should result
> >> > + * in a constant time search under expected conditions (devices
> >> > + * are not getting unpreserved).
> >> > + */
> >> > + int index = (ser->nr_devices + i) % ser->max_nr_devices;
> >> > + struct pci_dev_ser *dev_ser = &ser->devices[index];
> >>
> >> nit: Maybe we can move this logic in a separate function as down the road
> >> when we expand this to add VFs and Hotpluggable devices, this might
> >> change significantly? It's good if it is self-contained.
> >
> >Did you mean to leave this comment on pci_flb_preserve() where it
> >decides how many devices to allocate room for?
>
> I was talking about this one, as I think depending on the scheme we take
> this might change significantly. Just a nit, you can ignore it.
It would depend on if userspace is doing a lot of unpreserving as
well... I'll see what I can do in v5.
> >
> >> > +static inline struct pci_dev_ser *pci_liveupdate_outgoing(struct pci_dev *dev)
> >> > +{
> >> > + return dev->liveupdate_outgoing;
> >> > +}
> >>
> >> Is this expected to be called under the outgoing lock?
> >
> >For now this API is only used during shutdown, at which point userspace
> >should have already been stopped so drivers should not be changing the
> >preservation status of an outgoing device. So I don't think this needs
> >to be under the outgoing lock, but it would be nice to have some more
> >explicit synchronization.
>
> Ok that makes sense. I have similar cases in my series, but maybe we can
> add kdoc regarding these stating in which context this is expected to be
> used?
Yes will do. I'll add some documentation and also restrict it to avoid
misuse (move to internal pci.h, return a bool instead of pointer, and
use READ_ONCE()).
^ permalink raw reply
* Re: [PATCH v4 02/11] PCI: liveupdate: Track outgoing preserved PCI devices
From: Samiullah Khawaja @ 2026-05-01 18:17 UTC (permalink / raw)
To: David Matlack
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Shuah Khan, Will Deacon, William Tu, Yi Liu
In-Reply-To: <afPGYp145FbrvURR@google.com>
On Thu, Apr 30, 2026 at 09:15:14PM +0000, David Matlack wrote:
>On 2026-04-28 05:24 PM, Samiullah Khawaja wrote:
>> On Thu, Apr 23, 2026 at 09:23:06PM +0000, David Matlack wrote:
>
>> > + for (i = 0; i < ser->max_nr_devices; i++) {
>> > + /*
>> > + * Start searching at index ser->nr_devices. This should result
>> > + * in a constant time search under expected conditions (devices
>> > + * are not getting unpreserved).
>> > + */
>> > + int index = (ser->nr_devices + i) % ser->max_nr_devices;
>> > + struct pci_dev_ser *dev_ser = &ser->devices[index];
>>
>> nit: Maybe we can move this logic in a separate function as down the road
>> when we expand this to add VFs and Hotpluggable devices, this might
>> change significantly? It's good if it is self-contained.
>
>Did you mean to leave this comment on pci_flb_preserve() where it
>decides how many devices to allocate room for?
I was talking about this one, as I think depending on the scheme we take
this might change significantly. Just a nit, you can ignore it.
>
>> > +static inline struct pci_dev_ser *pci_liveupdate_outgoing(struct pci_dev *dev)
>> > +{
>> > + return dev->liveupdate_outgoing;
>> > +}
>>
>> Is this expected to be called under the outgoing lock?
>
>For now this API is only used during shutdown, at which point userspace
>should have already been stopped so drivers should not be changing the
>preservation status of an outgoing device. So I don't think this needs
>to be under the outgoing lock, but it would be nice to have some more
>explicit synchronization.
Ok that makes sense. I have similar cases in my series, but maybe we can
add kdoc regarding these stating in which context this is expected to be
used?
^ permalink raw reply
* [PATCH v2] arm64: errata: Reformat table for IDs
From: Robin Murphy @ 2026-05-01 17:52 UTC (permalink / raw)
To: will, catalin.marinas; +Cc: linux-arm-kernel, linux-doc
We have some inconsistency where multiple errata for the same component
share the same Kconfig workaround; some are one ID per line, some are
smooshed together, and some are entirely separate entries. Standardise
on the single entry, one ID per line format so that things render nice
and consistently in the HTML docs, and it's simple and clear to add new
IDs to existing workarounds without churning the table too much.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Rebase for 7.0-rc1
One last tilt at this windmill - at least I did remember! :)
Documentation/arch/arm64/silicon-errata.rst | 47 +++++++++++----------
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 211119ce7adc..046a7fa47063 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -116,7 +116,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
+| ARM | Cortex-A76 | #1188873, | ARM64_ERRATUM_1418040 |
+| | | #1418040 | |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
+----------------+-----------------+-----------------+-----------------------------+
@@ -136,7 +137,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A78 | #3324344 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A78C | #3324346,3324347| ARM64_ERRATUM_3194386 |
+| ARM | Cortex-A78C | #3324346, | ARM64_ERRATUM_3194386 |
+| | | #3324347 | |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
+----------------+-----------------+-----------------+-----------------------------+
@@ -172,11 +174,11 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X925 | #3324334 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
+| ARM | Neoverse-N1 | #1188873, | ARM64_ERRATUM_1418040 |
+| | | #1418040 | |
+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N1 | #1349291 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N1 | #1490853 | N/A |
+| ARM | Neoverse-N1 | #1349291, | N/A |
+| | | #1490853 | |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
+----------------+-----------------+-----------------+-----------------------------+
@@ -204,10 +206,13 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | C1-Pro | #4193714 | ARM64_ERRATUM_4193714 |
+----------------+-----------------+-----------------+-----------------------------+
-| ARM | MMU-500 | #841119,826419 | ARM_SMMU_MMU_500_CPRE_ERRATA|
-| | | #562869,1047329 | |
+| ARM | MMU-500 | #562869, | ARM_SMMU_MMU_500_CPRE_ERRATA|
+| | | #841119, | |
+| | | #826419, | |
+| | | #1047329 | |
+----------------+-----------------+-----------------+-----------------------------+
-| ARM | MMU-600 | #1076982,1209401| N/A |
+| ARM | MMU-600 | #1076982, | N/A |
+| | | #1209401 | |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-700 | #2133013, | N/A |
| | | #2268618, | |
@@ -230,11 +235,13 @@ stable kernels.
| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 |
+| Cavium | ThunderX ITS | #22375, | CAVIUM_ERRATUM_22375 |
+| | | #24313 | |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX GICv3 | #23154,38545 | CAVIUM_ERRATUM_23154 |
+| Cavium | ThunderX GICv3 | #23154, | CAVIUM_ERRATUM_23154 |
+| | | #38545 | |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX GICv3 | #38539 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
@@ -244,9 +251,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX2 SMMUv3| #74 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX2 SMMUv3| #126 | N/A |
+| Cavium | ThunderX2 SMMUv3| #74, | N/A |
+| | | #126 | |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
+----------------+-----------------+-----------------+-----------------------------+
@@ -258,11 +264,9 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
-| NVIDIA | T241 MPAM | T241-MPAM-1 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| NVIDIA | T241 MPAM | T241-MPAM-4 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| NVIDIA | T241 MPAM | T241-MPAM-6 | N/A |
+| NVIDIA | T241 MPAM | T241-MPAM-1, | N/A |
+| | | T241-MPAM-4, | |
+| | | T241-MPAM-6 | |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
@@ -270,9 +274,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip0{6,7} | #161010701 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip0{6,7} | #161010803 | N/A |
+| Hisilicon | Hip0{6,7} | #161010701, | N/A |
+| | | #161010803 | |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
+----------------+-----------------+-----------------+-----------------------------+
--
2.54.0.dirty
^ permalink raw reply related
* Re: [PATCH v4 01/11] PCI: liveupdate: Set up FLB handler for the PCI core
From: David Matlack @ 2026-05-01 16:57 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Pasha Tatashin, Pratyush Yadav, iommu, kexec, linux-doc,
linux-kernel, linux-mm, linux-pci, Adithya Jayachandran,
Alexander Graf, Alex Williamson, Bjorn Helgaas, Chris Li,
David Rientjes, Jacob Pan, Jason Gunthorpe, Joerg Roedel,
Jonathan Corbet, Josh Hilke, Leon Romanovsky, Lukas Wunner,
Mike Rapoport, Parav Pandit, Pranjal Shrivastava, Robin Murphy,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Will Deacon,
William Tu, Yi Liu
In-Reply-To: <20260430210642.GA439800@bhelgaas>
On Thu, Apr 30, 2026 at 2:06 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Tue, Apr 28, 2026 at 11:47:23PM +0000, David Matlack wrote:
> > On 2026-04-28 05:50 PM, Pasha Tatashin wrote:
> > > This is the way we agreed to handle kexec changes: Baoquan He is the
> > > maintainer, and without his Reviewed-by tag, we won't take changes to
> > > kexec. This is the approach we follow with MM for KHO changes to
> > > memblock and memfd preservation, as well as the upcoming
> > > hugetlb/guestmemfd preservation.
> > >
> > > This is also the approach we should continue using when adding LUO
> > > support to other components like PCI, VFIO, IOMMU, and KVM. It keeps
> > > life easier for the core component maintainers and ensures we do not
> > > regress LU by staging everything in the same tree and sending LU merge
> > > requests from a single tree.
> >
> > Ok it sounds like we are aligned on keeping drivers/pci/liveupdate.c,
> > include/linux/kho/abi/pci.h, and Documentation/PCI/liveupdate.rst in the
> > PCI LIVE UPDATE entry and not duplicating them in the LIVE UPDATE entry.
> >
> > I think the only open question is what tree to use for the PCI LIVE
> > UPDATE entry, PCI tree or Live Update tree. You are proposing the Live
> > Update tree.
> >
> > Bjorn are you ok with that approach?
>
> Yes, I think that makes sense, at least to start. In early days, it
> would probably be a headache to coordinate LU things across multiple
> trees.
Sounds good. I will swap the trees in v5. Thanks all.
^ permalink raw reply
* Re: [PATCH 0/5] mm: Support selecting doing direct COW for anonymous pmd entry
From: Luka Bai @ 2026-05-01 16:16 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-mm, Jonathan Corbet, Shuah Khan, Andrew Morton,
Lorenzo Stoakes, Zi Yan, Baolin Wang, Liam R. Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Jann Horn,
Arnd Bergmann, Kairui Song, linux-kernel, linux-arch, linux-doc,
Luka Bai
In-Reply-To: <b5379cd3-f7bf-47f9-8a60-c7300b4415a2@kernel.org>
在 Fri, May 01, 2026 at 09:07:49AM +0200，David Hildenbrand (Arm) 写道：
Hi David,
Thanks for your review and opinion :) I really appreciate it!
I'm sorry that I'm not that familiar with the mail sending in lore, so my
earlier reply in
https://lore.kernel.org/all/8F6F0691-91A1-4645-A218-2219DE6047AD@icloud.com/
may be in a wrong format, if you haven't read it, just ignore it, and read
this mail instead, I also revised the reply a little in this mail. thanks. :)
> On 5/1/26 07:55, Luka Bai wrote:
>
> Hi,
>
> > Copy on write support for anonymous pmd level THP is simple right now:
> > firstly we'll check whether the folio can be exclusively used by the
> > faulting process, if we can (when the ref of the folio is only 1 after
> > trying to free swapcache or the page flag AnonExclusive is setup) we'll
> > directly use it with few further handling. If we cannot, then we'll
> > split the pmd into 512 4K ptes, and do copy on write only for the
> > specific 4K page that we faulted on.
> >
> > This logic is truly memory efficient since for most workloads we don't
> > want to allocate 2M new memory simply on a small write. However, it also
> > makes the original 2M page for the process suddenly splitted on a
> > write which will generate some performance thrashing. For example, if
> > process A and process B share an anonymous 2M pmd, if process B chooses
> > to do a writing, then its page table mapping will be changed from 1
> > pmd entry into 512 4K pte entries at once, so the tlb benifit will
> > suddenly just "vanish" for process B, which sometimes may cause a
> > observable performance degeneration. After that, we can only wait for
> > khugepaged to do the collapse for this area and merge the pmd back, which
> > is not easy to happen.
>
> You probably know that, historically, we did exactly what you describe in this
> patch set. It was rather bad regarding memory waste and COW latency, so we
> switched to the current model.
>
> Note that there was a recent related discussion for executable, which was rejected:
>
> https://lore.kernel.org/r/20251226100337.4171191-1-zhangqilong3@huawei.com
>
Yes, I know this history, and I know that it will cost some memory or latency,
That’s why I was wondering maybe I can add a switch to it to make it
configurable :). But I don’t know the existence of the discussion in
https://lore.kernel.org/r/20251226100337.4171191-1-zhangqilong3@huawei.com,
I’ll check it out, thanks for informing me that :).
> >
> > In addition to the problem above, this logic can also generate some
> > deficiency for THP itself. Currently THP is just a "best-effort" choice
> > with no "certainty". THP is easily splitted into multiple small pages
> > on common calling path like reclaiming, COW. A transparent splitting
> > can cause throughput fluctuation for some workloads. For these workloads,
> > we may want to give THP some "certainty" just like hugetlbfs,
>
> There are no such guarantees, though. And We wouldn't want to commit to any such
> guarantees today. For example, simple page migration can split the folio.
> Allocation failures will fallback to small pages etc.
>
> If you need guarantees, use hugetlb for now.
>
The reason why I want to use THP over hugetlb is that I need reclamation for my
workload :). There are many processes in my workload that need 2M
aligned folios for better performance, and we want to reclaim them back automatically
when the process doesn’t need the folios. But hugetlbfs cannot do passive reclamation
from what I know (except doing active madvise by the processes themselves). And using
THP can easily split the hugepages. So that’s why I would like to add certainty for THP,
and use THP for these processes as backend, because THP is very well integrated with
the swap system and other filesystems. And from what I checked,
it seems the most common case for splitting a THP is COW and swapping so I am trying
to handle these two scenarios (But coincidentally, PMD swapping is committed in
https://lore.kernel.org/all/D3F08F85-76E0-4C5A-ABA1-537C68E038B8@nvidia.com/
a few days before, which is a great implementation :) ).
> > The effect
> > we want is: after some customized setup, if only the system has usable
> > folio, and the virtual memory alignment permits (or we setup to), we can
> > make sure we always use THP for it, the system will never split it except
> > the user wants to do so.
> >
> > This patchset is about both two things above, firstly we add pmd level
> > THP COW support by revising the code in do_huge_pmd_wp_page, we added
> > switch for it because different workloads may need different resources,
>
> The switch is bad, and we won't accept any toggle like that. A system-wide
> setting does not make sense for such behavior.
>
Oh, the reason why I added a switch globally is also because the scenario I mentioned
above, I want those processes to always use PMD sized folios as backend to make sure
performance. COW is truly not that common like swap out/swap in, it just can happen
sometimes, which I guess the reason may be about image duplication. Setting the system
globally is more convenient for my situation :). I can go without this global switch
if it's more reasonable.
> A per-VMA flag? Maybe, but I expect pushback as well, as it is way too specific.
> So we'd have to find some concept that abstracts these semantics. But I expect
> pushback as well.
>
> We messed up enough with toggles in THP space, unfortunately.
>
> Also, anything that only works for PMD-sized THPs is a warning sign in 2026 :)
>
And for PMD-sized THPs, actually, I’m also considering adding more support for
COW to mTHP if the upstream consider it useful. And also for pud sized THPs
also. But I guess I have to firstly handle stage 1: PMD level COW now :).
And also, since PMD sized folio is commonly used in my workload, I'm also wondering
digging into pmd sized KSM in the future, in which I think pmd sized COW may
be more useful then :).
> You don't really raise any concrete use cases or performance numbers for these
> use cases. Some details about applications that use fork() and rely on such
> behavior would be helpful.
>
Sorry for that, the concrete workload itself hasn't been finished yet. Now it just
can happen sometimes in my multi-2M-sized-processes workload test. But the user
of our 2M sized folio schema is actually not necessarily myself but also can be the
userspace developers. I cannot guarantee that fork will not be used in the
performance test of their workload since that is a normal posix call. Maybe a little
overthinking? :)
I just think swap and COW are two main scenarios that may transparently split pmd sized
folios, so maybe we can solve it and make THP both reclaimable and stable. Maybe
that can make THP more widely used in real deployed environment since the resource
can become more controllable for the users :). That's why I was thinking maybe
implementing it with setup switches is a reasonable solution?
> Note that an application that does fork() could use MADV_COLLAPSE after fork()
> to make sure that it immediately gets THPs back.
>
> There is also the option to just use MADV_DONTFORK to not even share ranges with
> a child process in the first place, avoiding page copies entirely.
>
MADV_DONTFORK and MADV_COLLAPSE are nice and great options :), but the former one seems
to be a little wasteful :). And the latter one can greatly solve fork situation, but
we have to recognize all the possible regions that may be accessed in performance
test and collapse them. And it's also not easy to solve the situation like pmd swap in
for pmd pages mapped by more than two processes. :)
> --
> Cheers,
>
> David
Look forward to your further opionion, thanks!
Best,
Luka
^ permalink raw reply
* [PATCH v2] scripts/kernel-doc: Detect mismatched inline member documentation tags
From: Shuicheng Lin @ 2026-05-01 16:08 UTC (permalink / raw)
To: linux-doc; +Cc: Shuicheng Lin, Jani Nikula, linux-kernel, intel-xe
Add validation in check_sections() to verify that inline member
documentation tags (/** @member: description */) match actual struct/union
member names. Previously, kernel-doc only validated section headers against
the parameter list, but inline doc tags stored in parameterdescs were never
cross-checked, allowing stale or mistyped member names to go undetected.
The new check iterates over parameterdescs keys and warns about any that
don't appear in the parameter list, catching issues like renamed struct
members where the documentation tag was not updated to match.
This catches real issues such as:
- xe_bo_types.h: @atomic_access (missing struct prefix, should be
@attr.atomic_access)
- xe_device_types.h: @usm.asid (member is actually asid_to_vm)
Variadic arguments documented as ``@args...:`` are stored in
parameterdescs under the unstripped key (e.g. ``args...``), while
push_parameter() strips the trailing ``...`` before appending to
parameterlist (e.g. ``args``). Treat the stripped form as a match so
the new loop doesn't emit a false-positive excess-parameter warning for
a properly documented named variadic parameter. The bare ``@...:`` form
is unaffected because push_parameter() does not strip when the name is
exactly three characters.
v2: Skip variadic parameters whose documented key ends with ``...`` and
whose stripped name is in parameterlist, to avoid false-positive
"Excess function parameter 'args...'" warnings on macros like
``#define foo(fmt, args...)`` documented with ``@args...:``.
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
---
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-xe@lists.freedesktop.org
---
tools/lib/python/kdoc/kdoc_parser.py | 36 ++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/tools/lib/python/kdoc/kdoc_parser.py b/tools/lib/python/kdoc/kdoc_parser.py
index ca00695b47b3..884c6bf56d25 100644
--- a/tools/lib/python/kdoc/kdoc_parser.py
+++ b/tools/lib/python/kdoc/kdoc_parser.py
@@ -673,6 +673,42 @@ class KernelDoc:
self.emit_msg(ln,
f"Excess {dname} '{section}' description in '{decl_name}'")
+ #
+ # Check that documented parameter names (from doc comments, including
+ # inline ``/** @member: */`` tags) actually match real members in
+ # the declaration. This catches mismatched or stale kernel-doc
+ # member tags that don't correspond to any actual struct/union
+ # member or function parameter.
+ #
+ for param_name, desc in self.entry.parameterdescs.items():
+ # Skip auto-generated entries from push_parameter()
+ if desc == self.undescribed:
+ continue
+ if desc in ("no arguments", "anonymous\n", "variable arguments"):
+ continue
+ if param_name.startswith("{unnamed_"):
+ continue
+ if param_name in self.entry.parameterlist:
+ continue
+ #
+ # Variadic arguments documented as ``@args...:`` are stored in
+ # parameterdescs under the unstripped key (e.g. ``args...``),
+ # while push_parameter() strips the trailing ``...`` before
+ # appending to parameterlist (e.g. ``args``). Treat the
+ # stripped form as a match so this loop doesn't emit a false
+ # positive for a properly documented variadic parameter.
+ #
+ if param_name.endswith("...") and \
+ param_name[:-3] in self.entry.parameterlist:
+ continue
+
+ if decl_type == 'function':
+ dname = f"{decl_type} parameter"
+ else:
+ dname = f"{decl_type} member"
+ self.emit_msg(ln,
+ f"Excess {dname} '{param_name}' description in '{decl_name}'")
+
def check_return_section(self, ln, declaration_name, return_type):
"""
If the function doesn't return void, warns about the lack of a
--
2.43.0
^ permalink raw reply related
* PGP Web of Trust and identity verification for the pt_BR Documentation Maintainer
From: Daniel Pereira @ 2026-05-01 15:52 UTC (permalink / raw)
To: linux-doc
Hi everyone,
I am Daniel, the current maintainer for the Portuguese (Brazilian)
translations of the Linux kernel documentation, as officially listed
in the MAINTAINERS file.
I am reaching out to begin the process of establishing my PGP Web of
Trust. My goal is to eventually apply for a @kernel.org alias to
further professionalize my workflow and contributions.
Beyond my maintenance work, I frequently deliver lectures and organize
mentorship programs focused on the Linux Kernel in Brazil. Having an
official @kernel.org identity is crucial for these activities, as it
provides the necessary credibility when representing the community and
encouraging new Brazilian developers to contribute to the mainline.
Since I am based in South America and physical key-signing
opportunities are limited, I would like to ask if any maintainers from
the documentation subsystem would be open to a remote identity
verification (e.g., via video call) or if there are other recommended
procedures for maintainers in my region.
Once someone is available to help with the verification, I will
provide my PGP fingerprint and key server details.
Recent activity reference:
https://git.kernel.org/pub/scm/linux/kernel/git/docs/linux.git/log/?h=docs-next&qt=grep&q=Daniel+Pereira
Thank you for your time and for all the support regarding the pt_BR
documentation branch.
Best regards,
Daniel Pereira Maintainer: PORTUGUESE (BRAZILIAN) TRANSLATION
^ permalink raw reply
* Re: [PATCH 5/5] mm: support choosing to do THP COW for anonymous pmd entry.
From: Luka Bai @ 2026-05-01 15:01 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-mm, Jonathan Corbet, Shuah Khan, Andrew Morton,
Lorenzo Stoakes, Zi Yan, Baolin Wang, Liam R. Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Jann Horn,
Arnd Bergmann, Kairui Song, linux-kernel, linux-arch, linux-doc,
Luka Bai
In-Reply-To: <c580340a-48c3-4cfa-92bd-593a95d0090f@kernel.org>
在 Fri, May 01, 2026 at 09:11:42AM +0200，David Hildenbrand (Arm) 写道：
>
> > - /*
> > - * See do_wp_page(): we can only reuse the folio exclusively if
> > - * there are no additional references. Note that we always drain
> > - * the LRU cache immediately after adding a THP.
> > - */
> > - if (folio_ref_count(folio) >
> > - 1 + folio_test_swapcache(folio) * folio_nr_pages(folio))
> > - goto unlock_fallback;
> > if (folio_test_swapcache(folio))
>
> I don't see why you would want to remove this check, really. Instead of
> "fallback", you might want to try copying the PMD.
>
> --
> Cheers,
>
> David
Sorry I didn't notice this thread earlier. That is a great suggestion! I can keep
this branch and do the folio copying instead of fallback, that actually helps
to avoid the extra checking about swapcache when the refs is definitely not
suitable for exclusive use. Thanks! :)
Best,
Luka
^ permalink raw reply
* Re: [PATCH v2 0/8] x86/resctrl: Support for AMD Global (Slow) Memory Bandwidth Allocation
From: Moger, Babu @ 2026-05-01 14:38 UTC (permalink / raw)
To: Reinette Chatre, Babu Moger, corbet, tony.luck, tglx, mingo, bp,
dave.hansen
Cc: skhan, x86, Dave.Martin, james.morse, hpa, akpm, rdunlap,
dapeng1.mi, kees, elver, lirongqing, ebiggers, paulmck, seanjc,
pawan.kumar.gupta, nikunj, yazen.ghannam, peterz, chang.seok.bae,
kim.phillips, thomas.lendacky, naveen, elena.reshetova, xin,
linux-doc, linux-kernel, eranian, peternewman
In-Reply-To: <8939476b-1e1b-4aed-88a3-5b8764a63030@intel.com>
Hi Reinette,
On 4/30/2026 6:40 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 4/30/26 4:04 PM, Moger, Babu wrote:
>> Hi Reinette,
>>
>> On 4/29/2026 5:34 PM, Reinette Chatre wrote:
>>> Hi Babu,
>>>
>>> On 4/23/26 6:41 PM, Babu Moger wrote:
>>>>
>>>> This series adds resctrl support for two new AMD memory-bandwidth
>>>> allocation features:
>>>>
>>>> - GMBA - Global Memory Bandwidth Allocation (hardware name: GLBE).
>>>> Bounds DRAM bandwidth for groups of threads that span
>>>> multiple L3 QoS domains, rather than being per-L3 like MBA.
>>>>
>>>> - GSMBA - Global Slow Memory Bandwidth Allocation (hardware name:
>>>> GLSBE). The CXL.memory / slow-memory counterpart of GMBA,
>>>> analogous to how SMBA relates to MBA.
>>>>
>>>> Both features share a new "NPS-node" control domain: a set of QoS (L3)
>>>> domains grouped together and aligned to the system's NPS (Nodes Per
>>>> Socket) BIOS configuration. Although the control domain is NPS-scoped,
>>>> the underlying bandwidth-limit MSRs (MSR_IA32_GMBA_BW_BASE 0xc0000600,
>>>> MSR_IA32_GSMBA_BW_BASE 0xc0000680) are instantiated per L3. Programming
>>>> a single control domain therefore requires writing the MSR on one CPU
>>>> per L3 that the domain spans - a new pattern for resctrl. Patches 2/8
>>>> and 3/8 introduce that infrastructure so the new resources can reuse
>>>> it.
>>>>
>>>> The features are documented in:
>>>>
>>>> AMD64 Zen6 Platform Quality of Service (PQOS) Extensions,
>>>> Publication # 69193 Revision 1.00, Issue Date March 2026
>>>>
>>>> available at https://bugzilla.kernel.org/show_bug.cgi?id=206537
>>>>
>>>> Series overview
>>>> ---------------
>>>>
>>>> Patches 1-5 to enable GMBA:
>>>>
>>>> 1/8 x86,fs/resctrl: Add support for Global Bandwidth Enforcement (GLBE)
>>>>
>>>> 2/8 x86/resctrl: Add RESCTRL_NPS_NODE scope for AMD NPS-aligned domains
>>>> Add a new ctrl_scope value for resctrl resources whose control
>>>> domain spans multiple L3s within an NPS node.
>>>>
>>>> 3/8 x86/resctrl: Update control MSRs per L3 for NPS-scoped resources
>>>> Add resctrl_arch_update_nps(): builds a cpumask with one CPU per
>>>> distinct L3 in the domain, then issues rdt_ctrl_update() via
>>>> smp_call_function_many() on that mask. Falls back to the full
>>>> domain mask if the scratch masks cannot be built. Route
>>>> resctrl_arch_update_domains() and resctrl_arch_reset_all_ctrls()
>>>> through this helper when ctrl_scope == RESCTRL_NPS_NODE.
>>>>
>>>> 4/8 x86,fs/resctrl: Add the resource for Global Memory Bandwidth Allocation
>>>> Register RDT_RESOURCE_GMBA in rdt_resources_all[] with
>>>> ctrl_scope=RESCTRL_NPS_NODE and schema_fmt=RANGE, add commands to
>>>> discover feature details.
>>>>
>>>> 5/8 fs/resctrl: Add the documentation for Global Memory Bandwidth Allocation
>>>> Add examples in Documentation/filesystems/resctrl.rst.
>>>>
>>>> Patches 6-8 to enable GSMBA in the same shape:
>>>>
>>>> 6/8 x86,fs/resctrl: Add support for Global Slow Memory Bandwidth Allocation
>>>>
>>>> 7/8 x86,fs/resctrl: Add the resource for Global Slow Memory Bandwidth Allocation
>>>> Register RDT_RESOURCE_GSMBA with ctrl_scope=RESCTRL_NPS_NODE.
>>>>
>>>> 8/8 fs/resctrl: Add the documentation for Global Slow Memory Bandwidth Allocation
>>>> Add examples in Documentation/filesystems/resctrl.rst.
>>>>
>>>> Changes since v1
>>>> ----------------
>>>> - Earlier sent RFC(v1) with Global Bandwidth Enforcement (GLBE) and
>>>> Privilege Level Zero Association (PLZA). This series only handles
>>>> Global Memory Bandwidth Allocation. Both the features are sent separately.
>>>>
>>>> - Documentation
>>>> * Fixed grammar in the GMBA / GSMBA sections of resctrl.rst.
>>>> * Added examples to update GMBA and GSMBA in resctrl.rst documentation.
>>>>
>>>> - Major changes are releated to RESCTRL_NPS_NODE scope handling.
>>>>
>>>> - Commit messages
>>>> * Reworked the changelogs in all the patches.
>>>>
>>>> Previous Revisions:
>>>> v1 : https://lore.kernel.org/lkml/cover.1769029977.git.babu.moger@amd.com/
>>>
>>> What are your expectations from this submission? From what I can tell this ignores
>>> v1 feedback in several ways:
>>> - It introduces two new resources, GMBA and GSMBA, when the previous discussion agreed that
>>> these are not actually new resources but instead new controls for the existing MBA/SMBA resources.
>>> - It does not mention or attempt to address dependency on new resource schema descriptions [1]
>>> to support user space in understanding how to interact with the new GMBA/GSMBA controls but
>>> instead defers that to a snippet in the documentation that user space needs to
>>> parse to know this control operates at multiples of 1GB/s.
>>>
>>> Apart from ignoring v1 feedback this new version appears to complicate user interface even more
>>> since now it is possible for there to be a single control that may operate at different scopes but from
>>> what I can tell there is nothing that helps user understand whether, for example, domain "0" means
>>> the whole system or a NUMA node?
>>>
>>> We have discussed several times now how resctrl interface needs to be enhanced to support
>>> this and other upcoming features from Intel, RISC-V, Arm MPAM, and NVidia. It is thus
>>> unexpected that this submission ignores all the previous discussions.
>>
>> I think there may be some misunderstanding on this topic.
>>
>> Yes, we discussed it earlier. It depends on other requirements (region-aware aspects), so I assumed it would be handled by someone with full context and addressed as a separate feature. I didn’t have complete visibility into all the requirements.
>
> Please read https://lore.kernel.org/lkml/06a237bd-c370-4d3f-99de-124e8c50e711@intel.com/ again.
>
> You should have complete visibility into the foundation of this work since one of the
> primary goals is to address the resctrl interface breakage that came with the initial AMD
> support for MBA that resctrl has been living with until now.
>
> With this series you completely disregard attempts to support users in understanding
> how to interact with the schemata file and instead introduce *another* obfuscated control. I
> will not support this.
>
> Also, no, this does not depend on region-aware work. Needing to support multiple controls for
> a single resource is independent from region-aware.
>
>>> Since there are so many dependencies on the new schema format support I am prioritizing this
>>> and created a PoC that I am currently refining and hope to share soon. We can collaborate on this
>>> to ensure that it provides a good foundation for the GMBA and GSMBA support.
>>
>> That is good to know. Let me know when you are ready.
>>
>> Could you please share which parts of the feature (e.g., Part 1, Part 2, etc.) you are planning to cover in your PoC?
>
> All three parts mentioned in https://lore.kernel.org/lkml/06a237bd-c370-4d3f-99de-124e8c50e711@intel.com/
>
> This does not address all the features discussed, for example it does not support emulated controls,
> but I hope it is enough of a foundation to build on.
Please share your code when you are ready. I can build GMB and GSMBA on
top of your patches. Hopefully, I can reuse some of the code from this
series.
Thanks
Babu
^ permalink raw reply
* Re: [PATCH net-next 2/2] ne2k: fold drivers/net/Space.c into ne.c
From: Simon Horman @ 2026-05-01 14:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jonathan Corbet, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Arnd Bergmann, Shuah Khan,
Andrew Morton, Borislav Petkov (AMD), linux-doc, linux-kernel,
netdev
In-Reply-To: <20260429145624.2948432-2-arnd@kernel.org>
On Wed, Apr 29, 2026 at 04:55:46PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> drivers/net/Space.c is the last remnant of the linux-2.4.x driver model
> that required each subsystem and device driver init function to be called
> from init/main.c explicitly, before the introduction of initcall levels.
>
> In linux-7.0, this was only used for a handful of ISA network drivers,
> with the ne2000 driver being the last one.
>
> Fold the code into ne.c directly, with minimal changes to preserve
> the existing command line parsing.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks Arnd,
FTR, that there is an AI generated review of this patch available on
sashkio.dev. I believe that covers only pre-existing issues. And I do not
believe that review should block progress of this patch.
Reviewed-by: Simon Horman <horms@kernel.org>
...
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: cs89x0: remove ISA bus probing
From: Simon Horman @ 2026-05-01 14:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Andrew Lunn, Arnd Bergmann, Andrew Morton,
Shuah Khan, Mengyuan Lou, netdev, linux-doc, linux-kernel
In-Reply-To: <20260429145624.2948432-1-arnd@kernel.org>
On Wed, Apr 29, 2026 at 04:55:45PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The cs89x0 driver is really two in one, and they are mutually exclusive:
>
> - the ISA driver was used on 486-era PCs. It likely has no remaining
> users, like the other ethernet drivers that got removed in
> linux-7.1. The DMA support in here is the last device driver use of
> the deprecated isa_bus_to_virt() interface, all other users are either
> x86 specific or or got converted to the normal dma-mapping interface.
> The driver was maintained by Andrew Morton at the time, based on
> the linux-2.2 vendor driver from Cirrus Logic.
>
> - the platform_driver instance was used on some embedded Arm boards
> around the same time, such as the EP7211 Development Kit. This
> is the same chip, but uses modern devicetree based probing and no DMA.
> This was added by Alexander Shiyan.
>
> Remove the ISA driver as a cleanup, including all of the outdated
> documentation referring to its configuration.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks Arnd,
With the increase in both AI generated patches and review,
and the maintainer effort required to process these, the
cost of maintaining unused code has become entirely non-negligible.
So I welcome efforts to reduce that surface.
I note that there is an AI generated review of this patch available on
sashkio.dev. I believe that covers only pre-existing issues. And I
illustrates the point I've made above. I do not believe that review should
block progress of this patch.
Reviewed-by: Simon Horman <horms@kernel.org>
...
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: Nhat Pham @ 2026-05-01 14:16 UTC (permalink / raw)
To: Kairui Song
Cc: Yosry Ahmed, Liam R . Howlett, akpm, Alistair Popple,
Axel Rasmussen, Barry Song, Baolin Wang, Baoquan He,
Byungchul Park,
open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG),
Chengming Zhou, Chris Li, Jonathan Corbet, David Hildenbrand,
Dev Jain, Gregory Price, Johannes Weiner, Hugh Dickins, Jann Horn,
Joshua Hahn, Lance Yang, lenb, linux-doc, LKML, linux-mm,
open list:SUSPEND TO RAM, Lorenzo Stoakes, Matthew Brost,
Michal Hocko, Muchun Song, Mariano Pache, Pavel Machek, Peter Xu,
Peter Zijlstra, Pedro Falcato, Rafael J. Wysocki (Intel),
Rakie Kim, Roman Gushchin, Mike Rapoport, Ryan Roberts,
Shakeel Butt, Kemeng Shi, Suren Baghdasaryan, tglx,
Vlastimil Babka, Wei Xu, Huang, Ying, Yosry Ahmed, Yuanchu Xie,
Qi Zheng, Zi Yan, Meta kernel team, Rik van Riel
In-Reply-To: <CAMgjq7A4+Sac9-CYkig1LFfEh5rq-4vLka8AXREei_m3svzJ7w@mail.gmail.com>
On Fri, Apr 24, 2026 at 8:52 PM Kairui Song <ryncsn@gmail.com> wrote:
>
> On Sat, Apr 25, 2026 at 3:12 AM Yosry Ahmed <yosry@kernel.org> wrote
> > > https://lore.kernel.org/linux-mm/20260421055323.940344-1-youngjun.park@lge.com/
> >
> > Does this do promotion/demotion of swap entries?
>
> Not yet, let's do things step by step.
>
> > > For example just reserve a type (e.g. type 0) as the virtual type?
> > > (type is really a bad naming though).
> > >
> > > The that swap file (or swap mapping) will be
> > >
> > > I was trying that based on this:
> > > https://lore.kernel.org/linux-mm/20260220-swap-table-p4-v1-15-104795d19815@tencent.com/
> > >
> > > It seems to work and the only thing we need is actually just something
> > > like this one in VSS:
> > > https://lore.kernel.org/linux-mm/20260320192735.748051-15-nphamcs@gmail.com/
> > >
> > > This part:
> > > + /* fall back to physical swap device */
> > > + if (!vswap_alloc_swap_slot(folio)) {
> > >
> > > We do a folio_realloc_swap if folio->swap have type 0.
> > >
> > > Which means, if there is no virtual device / mapping / file / space
> > > (I'm not sure how to name it at this point :) ), the ordinary swap
> > > routine is just still there untouched.
> > >
> > > If there is one, and it's being used, then, it is still the ordinary
> > > swap routine, just do an extra allocation (and the extra allocation
> > > strictly follows YoungJun's tier rule), which is same with VSS, but
> > > everything is reused. From a user or high level interface perspective,
> > > this can be designed with no difference as VSS. Just with a few
> > > bonuses: being per memcg / task / runtime optional, zero overhead if
> > > not enabled, and reusing all the infra.
> > >
> > > BTW this deferred allocation (in VSS or dynamic swap mapping, similar
> > > thing) is actually a bit concerning to me as well. It changes the
> > > common swapout routine and maybe worth reconsideration (e.g.
> > > activate_locked_split and mTHP stats is now ignored?), being optional
> > > for now also seems safer.
> >
> > I am not sure if I understand you correctly. I think what you're proposing is:
> >
> > - Page tables either point directly to a swap slot, or to a virtual swap entry.
> > - By default, page tables just point to swap slots maintaining current behavior.
>
> I mean, they are all swap entries, nothing special from the page table
> side. Swap subsystems handle things internally.
>
> > - If we have multiple backends (e.g. zswap or tiering), we use virtual
> > swap entry instead.
>
> Actually that can just follow the swap priority, or tier rule. Even if
> virtual mapping exists, it can be bypassed. e.g. you have a large NBD
> and don't care about either fragmentation or compression for offline
> workload cgroups, then why use a virtual layer for them which could
> double the kmem usage or spend more CPU? Setup is a different issue
> which can be discussed.
I assume NBD == network block device here?
If you use a NBD, I think vswap overhead is not going to be the
bottleneck here :)
And, what about reliability. Say you allocate a slot on the NBD, unmap
the page from the PTEs, then proceed to swap_writeout(). What if the
NBD device is no longer available? What if IO fails? If you already
encode the physical swap slot location in the PTEs, then it's very
expensive to correct this mistake. Whereas with vswap, you can fall
back to another device if you so choose, and all it takes is just a
simple backend change at the vswap layer.
Another issue with the current physical swapfile allocator is that
induces physical contiguity where it's absolutely not needed. I don't
know if this is the case with an NBD, but for flash device for e.g,
obviously contiguity makes thing more efficient, but it would be nice
if we can fallback to discontiguous swapout as a fallback.
I feel like NBD is an argument FOR virtualization, not against.
>
> > - The physical swapfile has clusters and swap tables (status quo).
> > - Virtual swap is implemented with clusters and swap tables in a
> > virtual space, and each table entry points to an underlying swap slot
> > or zswap entry.
> > - If a page table has a physical swap slot, and we need to do tiering,
> > we basically "make it virtual" by making the swap table of the
> > physical swapfile point at a virtual swap entry? or another physical
> > swapfile? Not sure.
>
> They are still ordinary swap entries, nothing special. The virtual
> space is also just a ordinary swap file (or swap mapping), which is
> easy to do:
> https://lore.kernel.org/linux-mm/20260220-swap-table-p4-v1-15-104795d19815@tencent.com/
>
> Then its virtual_table will have a different set of swap entries. (I
> left that part undone though).
>
> > > Right... I mean with two layers you will likely have >16 bytes
> > > overhead, and double lookup.
> >
> > Why >16 bytes? Do we need anything extra other than the reverse
> > mapping? Also why do we need a double lookup?
>
> You will have to store at least the following info: memcg (2 bytes),
> shadow (8 bytes), count (at least 1 bytes), and revert mapping (8
> bytes, since you have to address a full virtual swap space). And some
> type info is also needed. Part of them can be shrinked but still,
> scientifically, merging two layers into one is considered a kind of
> optimization.
Optimization is always a worthwhile pursuit of course. But you have to
gauge it with what we can buy with a more flexbility design, which
might end up buying us more performance win down the line
In the immediate term, vswap buys you a dynamic compressed layer +
maintain the ability to write back.
Looking a bit longer term, I don't think you can do the following
without a layer of indirection here:
1. Compressed writeback.
2. Discontiguous swapouts. I think we need this as a fallback for THP
swapping (see [1] for the discussion).
3. Mixed backend swapin.
4. Optimizing swap IO - if sequential patterns matter for example, you
need the ability to delay or change backend allocation. The current
model is way too inflexible to allow for that.
5. Adding new swap backends. We want to decouple what the MM subsystem
needs (which is minimally captured in the virtual layer), with what
the backend itself wants.
Youngjun's paper is a case study for what you can buy with virtualization:
[1]: https://lore.kernel.org/all/6869b7f0-84e1-fb93-03f1-9442cdfe476b@google.com/
[2]: https://ieeexplore.ieee.org/document/8662047
>
> You need lookup the virtual layer, then the lower layer for many
> decision making, is was discussed before to introduce more cache bit
> or things like that and I think that is getting over complex, reminds
> me of the slot cache or HAS_CACHE thing...:
> https://lore.kernel.org/linux-mm/CAMgjq7DJrtE-jARik849kCufd0qNnZQs7C8fcyzVOKE14-O+Dw@mail.gmail.com/
>
> > I don't think I quite understand it yet, maybe I am the problem :)
>
> Haha, not at all! Blame me for the poor explanation. To be honest, the
> design is still evolving and there are definitely details that need to
> be improved. It's hard to discuss these abstractions purely in theory,
> so it's probably best just keep the works moving forward in a clean
> way, and make things simpler and better be opt-in first.
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-01 13:57 UTC (permalink / raw)
To: Greg KH
Cc: leon, security, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <2026042945-duress-extenuate-939f@gregkh>
Hi Greg,
On Wed, Apr 29, 2026 at 12:10:51AM -0600, Greg KH wrote:
> On Wed, Apr 29, 2026 at 05:09:43AM +0200, Willy Tarreau wrote:
> > On Tue, Apr 28, 2026 at 03:13:01PM -0600, Greg KH wrote:
> > > > > We can point at other files, as this list is going to get long over
> > > > > time, which is a good thing.
> > > >
> > > > Sure. I'm just unsure where this could be enumerated, as it's likely
> > > > that there would be just one or two lines max per subsystem for the
> > > > majority of them. Or we could have a totally separate file, "threat
> > > > model", that goes into great lengths detailing all this with sections
> > > > per category or subsystem when they start to grow maybe, and refer only
> > > > to that one from security-bugs ?
> > >
> > > I think a separate file is good, I know I need to write up what the USB
> > > model is, and it's different from PCI, and different from other
> > > subsystems. All should probably be documented eventually.
> >
> > Would you be interested in me trying to initiate a new "threat-model.rst"
> > file that tries to unroll the points mentioned in the list ? I'm concerned
> > that that withuot having many details initially, it could look a bit odd,
> > because the list we currently have would be more suitable for an "other"
> > section.
>
> Sure, a small file to start with would be good for people to work off
> of and add to.
I'm appending below what I came up with today. It's not a patch, just
a dump of what I've been typing for 3 hours and should go into
process/threat-model.rst I think. If you think it constitutes a good
starting point, then I can make a patch to add it, and update my other
patch to reference it by basically saying "what is excluded from the
kernel threat model in threat-model.rst does not have to be reported
as a security issue".
cheers,
Willy
---
.. _threatmodel:
The Linux Kernel threat model
=============================
There are a lot of assumptions regarding what the kernel protects against and
what it does not protect against. These assumptions tend to cause confusion for
bug reports (security-related ones vs non-security ones), and can complicate
security enforcement when the responsibilities for some boundaries is not clear
between the kernel, distros, administrators and users.
This document tries to clarify the responsibilities of the kernel in this
domain.
The kernel's responsibilities
-----------------------------
The kernel abstracts access to local hardware resources and to remote systems
in a way that allows multiple local users to get a fair share of the available
resources granted to them, and, when the underlying hardware permits, to assign
a level of confidentiality to their communications and to the data they are
processing or storing.
The kernel assumes that the underlying hardware behaves according to its
specifications. This includes the integrity of the CPU's instruction set, the
transparency of the branch prediction unit and the cache units, the consistency
of the Memory Management Unit (MMU), the isolation of DMA-capable peripherals
(e.g., via IOMMU), state transitions in controllers, ranges of values read from
registers, the respect of documented hardware limitations, etc.
When hardware fails to maintain its specified isolation (e.g., CPU bugs,
side-channels, hardware response to unexpected inputs), the kernel will usually
attempt to implement reasonable mitigations. These are best-effort measures
intended to reduce the attack surface or elevate the cost of an attack within
the limits of the hardware's facilities; they do not constitute a
kernel-provided safety guarantee.
Users always perform their activities under the authority of an administrator
who is able to grant or deny various types of permissions that may affect how
users benefit from available resources, or the level of confidentiality of
their activities. Administrators may also delegate all or part of their own
permissions to some users, particularly via capabilities but not only. All this
is performed via configuration (sysctl, file-system permissions etc).
The Linux Kernel applies a certain collection of default settings that match
its threat model. Distros have their own threat model and will come with their
own configuration presets, that the administrator may have to adjust to better
suit their expectations (relax or restrict).
By default, the Linux Kernel guarantees the following protections when running
on common processors featuring privilege levels and memory management units:
- user-based isolation: an unprivileged user may restrict access to their own
data from other unprivileged users running on the same system. This includes:
* stored data, via file system permissions
* in-memory data (pages are not accessible by default to other users)
* process activity (ptrace is not permitted to other users)
* inter-process communication (other users may not observe data exchanged via
UNIX domain sockets or other IPC mechanisms)
* network communications within the same or with other systems
- capability-based protection:
* users not having the CAP_SYS_ADMIN capability may not alter the kernel's
configuration, memory nor state, change other users' view of the file
system layout, grant any user capabilities they do not have, nor affect the
system's availability (shutdown, reboot, panic, hang, or making the system
unresponsive via unbounded resource exhaustion).
* users not having the CAP_NET_ADMIN capability may not alter the network
configuration, intercept nor spoof network communications from other
users nor systems.
* users not having CAP_SYS_PTRACE may not observe other users' processes
activities.
When CONFIG_USER_NS is set, the kernel also permits unprivileged users to
create their own user namespace in which they have all capabilities, but with a
number of restrictions (they may not perform actions that have impacts on the
initial user namespace, such as changing time, loading modules or mounting
block devices). Please refer to user_namespaces(7) for more details, the
possibilities of user namespaces are not covered in this document.
The kernel also offers a lot of troubleshooting and debugging facilities, which
can constitute attack vectors when placed in wrong hands. While some of them
are designed to be accessible to regular local users with a low risk (e.g.
kernel logs via /proc/kmsg), some would expose enough information to represent
a risk in most places and the decision to expose them is under the
administrator's responsibility (perf events, traces), and others are not
designed to be accessed by non-privileged users (e.g. debugfs). Access to these
facilities by a user who has been explicitly granted permission by an
administrator does not constitute a security breach.
Bugs that permit to violate the principles above constitute security breaches.
However, bugs that permit one violation only once another one was already
achieved are only weaknesses. The kernel applies a number of self-protection
measures whose purpose is to avoid crossing a security boundary when certain
classes of bugs are found, but a failure of these extra protections do not
constitute a vulnerability alone.
What does not constitute a security bug
--------------------------------------
In the Linux kernel's threat model, the following classes of problems are
**NOT** considered as Linux Kernel security bugs. However, when it is believed
that the kernel could do better, they should be reported, so that they can be
reviewed and fixed where reasonably possible, but they will be handled as any
regular bug:
- configuration:
* outdated kernels and particularly end-of-life branches are out of the scope
of the kernel's threat model: administrators are responsible for keeping
their system up to date. For a bug to qualify as a security bug, it must be
demonstrated that it affects actively maintained versions.
* build-level: changes to the kernel configuration that are explicitly
documented as lowering the security level (e.g. CONFIG_NOMMU), or targeted
at developers only.
* OS-level: changes to command line parameters, sysctls, filesystem
permissions, user capabilities, exposure of privileged interfaces, that
explicitly increase exposure by either offering non-default access to
unprivileged users, or reduce the kernel's ability to enforce some
protections or mitigations. Example: write access to procfs or debugfs.
* issues triggered only when using features intended for development or
debugging (e.g., lockdep, KASAN, fault-injection): these features are known
to introduce overhead and potential instability and are not intended for
production use.
* loading of explicitly insecure/broken/staging modules, and generally any
using any subsystem marked as experimental or not intended for production
use.
* running out-of-tree modules or unofficial kernel forks; these should be
reported to the relevant vendor.
- excess of initial privileges:
* actions performed by a user already possessing the privileges required to
perform that action or modify that state (e.g. CAP_SYS_ADMIN, CAP_NET_ADMIN,
CAP_SYS_RAWIO, CAP_SYS_MODULE with no further boundary being crossed).
* actions performed in user namespace without permitting anything in the
initial namespace that was not already permitted to the same user there.
* anything performed by the root user in the initial namespace (e.g. kernel
oops when writing to a privileged device).
- out of production use:
This covers theoretical/probabilistic attacks that rely on laboratory
conditions with zero system noise, or those requiring an unrealistic number
of attempts (e.g., billions of trials) that would be detected by standard
system monitoring long before success, such as:
* prediction of random numbers that only works in a totally silent
environment (such as IP ID, TCP ports or sequence numbers that can only be
guessed in a lab).
* activity observation and information leaks based on probabilistic
approaches that are prone to measurement noise and not realistically
reproducible on a production system.
* issues that can only be triggered by heavy attacks (e.g. brute force) whose
impact on the system makes it unlikely or impossible to remain undetected
before they succeed (e.g. consuming all memory before succeeding).
* problems seen only under development simulators, emulators, or combinations
that do not exist on real systems at the time of reporting (issues
involving tens of millions of threads, tens of thousands of CPUs,
unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds.
* issues whose reproduction requires hardware modification or emulation,
including fake USB devices that pretend to be another one.
* as well as issues that can be triggered at a cost that is orders of
magnitude higher than the expected benefits (e.g. fully functional keyboard
emulator only to retrieve 7 uninitialized bytes in a structure, or
brute-force method involving millions of connection attempts to guess a
port number).
- hardening failures:
* ability to bypass some of the kernel's hardening measures with no
demonstrable exploit path (e.g. ASLR bypass, events timing or probing with
no demonstrable consequence). These are just weaknesses, not
vulnerabilities.
* missing argument checks and failure to report certain errors with no
immediate consequence.
- random information leaks:
This concerns information leaks of small data parts that happen to be there
and that cannot be chosen by the attacker, or face access restrictions:
* structure padding reported by syscalls or other interfaces.
* identifiers, partial data, non-terminated strings reported in error
messages.
* Leaks of kernel memory addresses/pointers do not constitute an immediately
exploitable vector and are not security bugs, though they must be reported
and fixed.
- crafted file system images:
* bugs triggered by mounting a corrupted or maliciously crafted file system
image are generally not security bugs, as the kernel assumes the underlying
storage media is under the administrator's control, unless the filesystem
driver is specifically documented as being hardened against untrusted media.
* issues that are resolved, mitigated, or detected by running a filesystem
consistency check (fsck) on the image prior to mounting.
- physical access:
Issues that require physical access to the machine, hardware modification, or
the use of specialized hardware (e.g., logic analyzers, DMA-attack tools over
PCI-E/Thunderbolt) are out of scope unless the system is explicitly
configured with technologies meant to defend against such attacks
(e.g. IOMMU).
- functional and performance regressions:
Any issue that can be mitigated by setting proper permissions and limits
doesn't qualify as a security bug.
---
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: Nhat Pham @ 2026-05-01 13:42 UTC (permalink / raw)
To: Kairui Song
Cc: Yosry Ahmed, Liam R . Howlett, akpm, Alistair Popple,
Axel Rasmussen, Barry Song, Baolin Wang, Baoquan He,
Byungchul Park,
open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG),
Chengming Zhou, Chris Li, Jonathan Corbet, David Hildenbrand,
Dev Jain, Gregory Price, Johannes Weiner, Hugh Dickins, Jann Horn,
Joshua Hahn, Lance Yang, lenb, linux-doc, LKML, linux-mm,
open list:SUSPEND TO RAM, Lorenzo Stoakes, Matthew Brost,
Michal Hocko, Muchun Song, Mariano Pache, Pavel Machek, Peter Xu,
Peter Zijlstra, Pedro Falcato, Rafael J. Wysocki (Intel),
Rakie Kim, Roman Gushchin, Mike Rapoport, Ryan Roberts,
Shakeel Butt, Kemeng Shi, Suren Baghdasaryan, tglx,
Vlastimil Babka, Wei Xu, Huang, Ying, Yosry Ahmed, Yuanchu Xie,
Qi Zheng, Zi Yan, Meta kernel team, Rik van Riel
In-Reply-To: <CAMgjq7BZpU5K1xHyFiqpsjeFe6CZUouGY_gOGMwbkM2Duq-vGg@mail.gmail.com>
On Tue, Apr 28, 2026 at 7:46 PM Kairui Song <ryncsn@gmail.com> wrote:
>
> On Tue, Apr 28, 2026 at 2:23 AM Yosry Ahmed <yosry@kernel.org> wrote:
> >
> > On Fri, Apr 24, 2026 at 12:52 PM Kairui Song <ryncsn@gmail.com> wrote:
> > >
> > > On Sat, Apr 25, 2026 at 3:12 AM Yosry Ahmed <yosry@kernel.org> wrote
> > > > Why >16 bytes? Do we need anything extra other than the reverse
> > > > mapping? Also why do we need a double lookup?
> > >
> > > You will have to store at least the following info: memcg (2 bytes),
> > > shadow (8 bytes), count (at least 1 bytes), and revert mapping (8
> > > bytes, since you have to address a full virtual swap space). And some
> > > type info is also needed. Part of them can be shrinked but still,
> > > scientifically, merging two layers into one is considered a kind of
> > > optimization.
> > >
> > > You need lookup the virtual layer, then the lower layer for many
> > > decision making, is was discussed before to introduce more cache bit
> > > or things like that and I think that is getting over complex, reminds
> > > me of the slot cache or HAS_CACHE thing...:
> > > https://lore.kernel.org/linux-mm/CAMgjq7DJrtE-jARik849kCufd0qNnZQs7C8fcyzVOKE14-O+Dw@mail.gmail.com/
> >
> > I think that's where the disconnect is. You are considering these two
> > separate layers, each with its own metadata. The metadata should only
> > live in one place.
> >
> > If we only have swap tables in the virtual swap layer (with the
> > metadata), backends do not have to carry the metadata. In this case,
> > backends should only have a reverse mapping (if needed), and some
> > internal data structure (e.g. bitmaps) to track usage.
>
> Ah, you are right. This is currently an intermediate state, that
> problem might be gone if we unified everything.
What do you mean here?
>
> > This is difficult to achieve if the virtual swap layer is optional,
> > because then the metadata can live in different places. This is why I
>
> But that's not difficult to achieve at all with an optional layer, and
> actually will be achieved naturally without any design change with the
> RFC I posted. Swap count / cgroup / shadow all stay in the top layer,
> lower layer is "reverse map" only (the undone part though, it will
> require to move the cluster cache from global to device level, which
> is also required for YoungJun's tier or any functional tiering to
> work, we may run into more and more detail issue like this).
>
> Might even be easier that way, it's pretty close to the unified states I think.
I feel like you're moving towards the other direction, no? Seems like
you are unifying swap metadata, which is good (vswap will also want to
do this), but the problem is, the lower layer will have to allocate
memory for these metadata too...
Say vswap is optional and runtime enabled. How do you structure a
physical swap device's metadata? Some of the slots might be directly
mapped to PTEs, some might back vswap slots. These two cases require a
two completely different set of metadata: the former needs reference
count, swap cache, swap cgroup etc., whereas the latter only needs
reverse mapping...
I don't think we should mix vswap and non vswap slots in the same
type/address space.
^ permalink raw reply
* Re: [PATCH 12/14] userfaultfd: add UFFDIO_SET_MODE for runtime sync/async toggle
From: Kiryl Shutsemau @ 2026-05-01 13:12 UTC (permalink / raw)
To: akpm, rppt, peterx, david
Cc: ljs, surenb, vbabka, Liam.Howlett, ziy, corbet, skhan, seanjc,
pbonzini, jthoughton, aarcange, sj, usama.arif, linux-mm,
linux-kernel, linux-doc, linux-kselftest, kvm, kernel-team
In-Reply-To: <20260427114607.4068647-13-kas@kernel.org>
sashiko.dev -- https://sashiko.dev/#/patchset/20260427114607.4068647-1-kas@kernel.org -- wrote:
> Since ctx->mm can be an external mm_struct, is it possible for the target
> process to have encountered an OOM-reap or a failed dup_mmap() and be
> marked MMF_UNSTABLE?
> If so, should there be a call to check_stable_address_space(mm) after
> acquiring the mmap lock to avoid iterating over a maple tree that might
> contain XA_ZERO_ENTRY markers?
This is the same pattern as userfaultfd_register() and
userfaultfd_unregister(), which acquire mmap_write_lock(mm) after a
successful mmget_not_zero() and walk the VMA tree without
check_stable_address_space().
The OOM reaper takes mmap_read_lock, so it is excluded once we hold the
write lock; failed dup_mmap() unwinds its partial tree before returning.
> The commit message notes that fdinfo reads ctx->features with READ_ONCE to
> avoid seeing a mid-RMW intermediate value. Are there other lockless readers
> of ctx->features that also need this annotation?
[ ... ]
> Could executing UFFDIO_SET_MODE concurrently with these paths cause a data
> race on ctx->features?
Confirmed. userfaultfd_is_initialized() is reached from
userfaultfd_poll(), userfaultfd_read_iter(), and userfaultfd_ioctl()
with no mm lock held, so SET_MODE's mmap_write_lock + vma_start_write()
drain does not exclude them. The INITIALIZED bit is never modified by
SET_MODE so the value is functionally stable, but READ_ONCE pairing is
still the right thing for KCSAN.
Will fold into 12/14 a small helper plus conversions:
static unsigned int userfaultfd_features(struct userfaultfd_ctx *ctx)
{
return READ_ONCE(ctx->features);
}
with userfaultfd_is_initialized(), userfaultfd_wp_async_ctx(),
userfaultfd_rwp_async_ctx(), userfaultfd_wp_unpopulated(), and the
fdinfo printer reading through the helper. Hot-path reads inside
handle_userfault() and friends stay plain -- they run under the
per-VMA lock or mmap_read_lock that SET_MODE drains before the RMW.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH 11/14] userfaultfd: add UFFD_FEATURE_RWP_ASYNC for async fault resolution
From: Kiryl Shutsemau @ 2026-05-01 10:49 UTC (permalink / raw)
To: akpm, rppt, peterx, david
Cc: ljs, surenb, vbabka, Liam.Howlett, ziy, corbet, skhan, seanjc,
pbonzini, jthoughton, aarcange, sj, usama.arif, linux-mm,
linux-kernel, linux-doc, linux-kselftest, kvm, kernel-team
In-Reply-To: <20260427114607.4068647-12-kas@kernel.org>
sashiko.dev -- https://sashiko.dev/#/patchset/20260427114607.4068647-1-kas@kernel.org -- wrote:
> commit 069c98442d3532bbf015817229b8db505210e97d
> Author: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Subject: userfaultfd: add UFFD_FEATURE_RWP_ASYNC for async fault resolution
[ ... ]
> Does this sequence create a clean but writable PMD?
> [ ... ] Could this result in modified data being silently discarded
> instead of written back during page reclaim?
> Usually, code paths establishing writable entries set the dirty bit
> together with the write bit, for instance by using
> pmd_mkwrite(pmd_mkdirty(pmd)).
The pattern intentionally mirrors do_numa_page() / numa_rebuild_single_mapping()
which has been in the kernel for years using the same sequence:
pte = pte_modify(old_pte, vma->vm_page_prot);
pte = pte_mkyoung(pte);
if (writable)
pte = pte_mkwrite(pte, vma);
with no pte_mkdirty(). The "writable" decision is fenced by
can_change_pte_writable(), which keeps the result safe in both the
shared and private cases:
- Private (can_change_private_pte_writable): only allows the upgrade
for PageAnonExclusive pages.
- Shared (can_change_shared_pte_writable): returns true only when
pte_dirty(pte). The dirty bit lives in _PAGE_CHG_MASK, so the
earlier pte_modify(pte, vma->vm_page_prot) preserves it; the final
PTE is writable + dirty.
The same applies to the PMD path through can_change_pmd_writable().
There is no "clean + writable" PTE/PMD escaping either branch.
> Similarly, does this create a clean but writable PTE?
> If the PTE is made writable without calling pte_mkdirty(), it might
> violate the invariant that writable PTEs must be dirty, [ ... ]
The "writable PTEs must be dirty" invariant is not a kernel-wide rule;
it depends on the architecture and the code path. Where the kernel
relies on pte_mkdirty() being called explicitly, can_change_pte_writable()
returns false and this path is not taken. do_uffd_rwp() is the same
shape as do_numa_page() and inherits its correctness arguments.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ 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