* Re: [PATCH v5 01/10] ACPI: APEI: GHES: share macros via a private header
From: Jonathan Cameron @ 2026-05-29 15:52 UTC (permalink / raw)
To: Ahmed Tiba
Cc: will, xueshuai, saket.dumbre, mchehab, dave, djbw, bp, tony.luck,
guohanjun, lenb, skhan, vishal.l.verma, rafael, corbet, ira.weiny,
dave.jiang, krzk+dt, robh, catalin.marinas, alison.schofield,
conor+dt, linux-arm-kernel, Michael.Zhao2, linux-doc,
linux-kernel, linux-cxl, Dmitry.Lamerov, devicetree, linux-acpi,
linux-edac, acpica-devel
In-Reply-To: <20260529-topics-ahmtib01-ras_ffh_arm_internal_review-v5-1-2e0500d42642@arm.com>
On Fri, 29 May 2026 10:50:41 +0100
Ahmed Tiba <ahmed.tiba@arm.com> wrote:
> Carve the CPER helper macros out of ghes.c and place them in a private
> header so they can be shared with upcoming helper files. This is a
> mechanical include change with no functional differences.
>
> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
I'm not sure there is a 'right' way to handle the use of ACPI deifned stuff
outside of ACPI, but this seems reasonable to me.
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 02/10] ACPI: APEI: GHES: move CPER read helpers
From: Jonathan Cameron @ 2026-05-29 15:51 UTC (permalink / raw)
To: Ahmed Tiba
Cc: will, xueshuai, saket.dumbre, mchehab, dave, djbw, bp, tony.luck,
guohanjun, lenb, skhan, vishal.l.verma, rafael, corbet, ira.weiny,
dave.jiang, krzk+dt, robh, catalin.marinas, alison.schofield,
conor+dt, linux-arm-kernel, Michael.Zhao2, linux-doc,
linux-kernel, linux-cxl, Dmitry.Lamerov, devicetree, linux-acpi,
linux-edac, acpica-devel
In-Reply-To: <20260529-topics-ahmtib01-ras_ffh_arm_internal_review-v5-2-2e0500d42642@arm.com>
On Fri, 29 May 2026 10:50:42 +0100
Ahmed Tiba <ahmed.tiba@arm.com> wrote:
> Relocate the CPER buffer mapping, peek, and clear helpers from ghes.c into
> ghes_cper.c so they can be shared with other firmware-first providers.
> This commit only shuffles code; behavior stays the same.
>
> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
A couple of things I noticed whilst quickly scan through what was moved inline.
Move itself looks fine to me.
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
> diff --git a/drivers/acpi/apei/ghes_cper.c b/drivers/acpi/apei/ghes_cper.c
> new file mode 100644
> index 000000000000..7bb72fe57838
> --- /dev/null
> +++ b/drivers/acpi/apei/ghes_cper.c
> @@ -0,0 +1,195 @@
> +
> +/* Check the top-level record header has an appropriate size. */
> +int __ghes_check_estatus(struct ghes *ghes,
> + struct acpi_hest_generic_status *estatus)
> +{
> + u32 len = cper_estatus_len(estatus);
> + u32 max_len = min(ghes->generic->error_block_length,
> + ghes->estatus_length);
> +
> + if (len < sizeof(*estatus)) {
> + pr_warn_ratelimited(FW_WARN GHES_PFX "Truncated error status block!\n");
> + return -EIO;
> + }
> +
> + if (!len || len > max_len) {
Obviously this is just a move, but that if !len is silly given that will have failed
the previous check as 0 is definitely less than sizeof(*estatus)
Maybe add a trivial patch to tidy this up and any similar oddities.
> + pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid error status block length!\n");
> + return -EIO;
> + }
> +
> + if (cper_estatus_check_header(estatus)) {
> + pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid CPER header!\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +/* Read the CPER block, returning its address, and header in estatus. */
> +int __ghes_peek_estatus(struct ghes *ghes,
> + struct acpi_hest_generic_status *estatus,
> + u64 *buf_paddr, enum fixed_addresses fixmap_idx)
> +{
> + struct acpi_hest_generic *g = ghes->generic;
> + int rc;
> +
> + rc = apei_read(buf_paddr, &g->error_status_address);
> + if (rc) {
> + *buf_paddr = 0;
> + pr_warn_ratelimited(FW_WARN GHES_PFX
> + "Failed to read error status block address for hardware error source: %d.\n",
> + g->header.source_id);
Whilst you are here I don't think anyone would mind if you fix the alignment.
Looks like it's one space short.
> + return -EIO;
> + }
> + if (!*buf_paddr)
> + return -ENOENT;
> +
> + ghes_copy_tofrom_phys(estatus, *buf_paddr, sizeof(*estatus), 1,
> + fixmap_idx);
> + if (!estatus->block_status) {
> + *buf_paddr = 0;
> + return -ENOENT;
> + }
> +
> + return 0;
> +}
^ permalink raw reply
* Re: [PATCH] docs/zh_CN: update admin-guide/index.rst translation
From: Yan Zhu @ 2026-05-29 15:40 UTC (permalink / raw)
To: Dongliang Mu, corbet, alexs, si.yanteng, kees
Cc: skhan, tony.luck, gpiccoli, frederic, jani.nikula, longman,
mchehab+huawei, linux-doc, linux-kernel
In-Reply-To: <09fb5801-dd23-4ad4-aebf-fa4216b7527e@hust.edu.cn>
On 5/28/2026 10:46 PM, Dongliang Mu wrote:
>
> On 5/10/26 2:48 PM, Yan Zhu wrote:
>> update Documentation/admin-guide/index.rst Chinese translation
>>
>> Update the translation through commit f0efd29aa60c
>> ("doc: Add CPU Isolation documentation")
>>
>> Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
>> ---
>> .../translations/zh_CN/admin-guide/index.rst | 209 +++++++++++++-----
>> 1 file changed, 159 insertions(+), 50 deletions(-)
>>
>> diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/
>> Documentation/translations/zh_CN/admin-guide/index.rst
>> index 15d9ab5993a7..575449b91916 100644
>> --- a/Documentation/translations/zh_CN/admin-guide/index.rst
>> +++ b/Documentation/translations/zh_CN/admin-guide/index.rst
>> @@ -1,7 +1,13 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> .. include:: ../disclaimer-zh_CN.rst
>> -:Original: :doc:`../../../admin-guide/index`
>> -:Translator: Alex Shi <alex.shi@linux.alibaba.com>
>> +:Original: Documentation/admin-guide/index.rst
>> +
>> +:翻译:
>> +
>> + 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
>> +
>> + 朱岩 Yan Zhu <zhuyan2015@qq.com>
>> Linux 内核用户和管理员指南
>> @@ -11,7 +17,11 @@ Linux 内核用户和管理员指南
>> 整体的顺序或组织 - 这些材料不是一个单一的，连贯的文件！幸运的话，情
>> 况会随着
>> 时间的推移而迅速改善。
>> -这个初始部分包含总体信息，包括描述内核的README， 关于内核参数的文档等。
>> +
>> +内核管理通用指南
>> +----------------
>> +
>> +本节包含总体信息，包括描述内核整体的 README 文件、内核参数文档等。
>> .. toctree::
>> :maxdepth: 1
>> @@ -20,17 +30,55 @@ Linux 内核用户和管理员指南
>> Todolist:
>> -* kernel-parameters
>> * devices
>> +* features
>> +
>> +内核管理接口的重要组成部分是 /proc 和 sysfs 虚拟文件系统；这些文档描
>> 述了如何
>> +与之交互。
>> +
>> +.. toctree::
>> + :maxdepth: 1
>> +
>> + cputopology
>> +
>> +
>> +Todolist:
> Add a blank line here.
I have fixed it in patch v2.
>> +* sysfs-rules
>> * sysctl/index
>> +* abi
>> +
>> +安全相关文档：
>> +
>> +.. toctree::
>> + :maxdepth: 1
>> -本节介绍CPU漏洞及其缓解措施。
>> Todolist:
>> * hw-vuln/index
>> +* LSM/index
>> +* perf-security
>> +
>> +
>> +内核启动
>> +--------
>> +
>> +.. toctree::
>> + :maxdepth: 1
>> +
>> + bootconfig
>> +
>> +Todolist:
>> +
>> +* kernel-parameters
>> +* efi-stub
>> +* initrd
>> +
>> +
>> +追踪和识别问题
>> +--------------
>> -下面的一组文档，针对的是试图跟踪问题和bug的用户。
>> +以下是一组面向试图追踪特定问题和 bug 的用户的文档。
>> .. toctree::
>> :maxdepth: 1
>> @@ -39,94 +87,155 @@ Todolist:
>> reporting-regressions
>> bug-hunting
>> bug-bisect
>> - tainted-kernels
>> init
>> + clearing-warn-once
>> + lockup-watchdogs
>> + sysrq
>> Todolist:
>> +* quickly-build-trimmed-linux
>> +* verify-bugs-and-bisect-regressions
>> +* tainted-kernels
>> * ramoops
>> * dynamic-debug-howto
>> * kdump/index
>> * perf/index
>> +* pstore-blk
>> +* kernel-per-CPU-kthreads
>> +* RAS/index
>> +
>> +
>> +核心内核子系统
>> +--------------
>> +
>> +这些文档描述了核心内核管理接口，这些接口几乎在任何系统上都值得关注。
>> +
>> +.. toctree::
>> + :maxdepth: 1
>> +
>> + cpu-load
>> + mm/index
>> + module-signing
>> + numastat
>> -这是应用程序开发人员感兴趣的章节的开始。可以在这里找到涵盖内核ABI各个
>> -方面的文档。
>> Todolist:
>> -* sysfs-rules
>> +* cgroup-v2
>> +* cgroup-v1/index
>> +* namespaces/index
>> +* pm/index
>> +* syscall-user-dispatch
>> -本手册的其余部分包括各种指南，介绍如何根据您的喜好配置内核的特定行为。
>> +对非原生二进制格式的支持。请注意，其中一些文档相当古老。
> I think you can emphasize 古老 with bold in RST, which can match the
> English documentation.
I have fixed it in patch v2.
>> +
>> +.. toctree::
>> + :maxdepth: 1
>> +
>> +
>> +Todolist:
>> +
>> +* binfmt-misc
>> +* java
>> +* mono
>> +
>> +
>> +块设备和文件系统管理
>> +--------------------
>> .. toctree::
>> :maxdepth: 1
>> - bootconfig
>> - clearing-warn-once
>> - cpu-load
>> - cputopology
>> - lockup-watchdogs
>> - numastat
>> - unicode
>> - sysrq
>> - mm/index
>> Todolist:
>> -* acpi/index
>> -* aoe/index
>> -* auxdisplay/index
>> * bcache
>> * binderfs
>> -* binfmt-misc
>> * blockdev/index
>> -* braille-console
>> -* btmrvl
>> -* cgroup-v1/index
>> -* cgroup-v2
>> * cifs/index
>> -* dell_rbu
>> * device-mapper/index
>> -* edid
>> -* efi-stub
>> * ext4
>> +* filesystem-monitoring
>> * nfs/index
>> -* gpio/index
>> -* highuid
>> -* hw_random
>> -* initrd
>> * iostats
>> -* java
>> * jfs
>> -* kernel-per-CPU-kthreads
>> +* md
>> +* ufs
>> +* xfs
>> +
>> +
>> +专用设备指南
>> +------------
>> +
>> +如何在 Linux 系统中配置硬件。
>> +
>> +.. toctree::
>> + :maxdepth: 1
>> +
>> +
> Remove one blank line. Only keep one blank line here.
>> +Todolist:
>> +
>> +* acpi/index
>> +* aoe/index
>> +* auxdisplay/index
>> +* braille-console
>> +* btmrvl
>> +* dell_rbu
>> +* edid
>> +* gpio/index
>> +* hw_random
>> * laptops/index
>> * lcd-panel-cgram
>> -* ldm
>> -* LSM/index
>> -* md
>> * media/index
>> -* module-signing
>> -* mono
>> -* namespaces/index
>> +* nvme-multipath
>> * parport
>> -* perf-security
>> -* pm/index
>> * pnp
>> * rapidio
>> -* ras
>> * rtc
>> * serial-console
>> * svga
>> +* thermal/index
>> * thunderbolt
>> -* ufs
>> * vga-softcursor
>> * video-output
>> -* xfs
>> +
>> +
>> +工作负载分析
>> +------------
>> +
>> +这是一个章节的开始，其中包含对从事 Linux 内核安全关键性分析的应用程序
>> 开发人员
>> +和系统集成商感兴趣的信息。这里可以找到支持分析内核与应用程序交互以及
>> 关键内核
>> +子系统预期的文档。
>> +
>> +.. toctree::
>> + :maxdepth: 1
>> +
>> +
> Remove one blank line. Only keep one blank line here.
I have removed it in patch v2.
>> +Todolist:
>> +
>> +* workload-tracing
>> +
>> +
>> +其他内容
>> +--------
>> +
>> +一些难以分类且通常已过时的文档。
>> +
>> +.. toctree::
>> + :maxdepth: 1
>> +
>> +
>> +Todolist:
>> +
>> +* highuid
>> +* ldm
>> +* unicode
>> .. only:: subproject and html
>> - Indices
>> - =======
>> + 索引
>> + ====
>> * :ref:`genindex`
--
Thanks
Yan Zhu
^ permalink raw reply
* [PATCH v2] docs/zh_CN: update admin-guide/index.rst translation
From: Yan Zhu @ 2026-05-29 15:37 UTC (permalink / raw)
To: corbet, alexs, si.yanteng, kees
Cc: skhan, dzm91, tony.luck, gpiccoli, frederic, jani.nikula, longman,
mchehab+huawei, linux-doc, linux-kernel, Yan Zhu
update Documentation/admin-guide/index.rst Chinese translation
Update the translation through commit f0efd29aa60c
("doc: Add CPU Isolation documentation")
Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
---
v1->v2:
- Remove any unnecessary blank lines.
- Add necessary blank lines.
---
.../translations/zh_CN/admin-guide/index.rst | 202 +++++++++++++-----
1 file changed, 152 insertions(+), 50 deletions(-)
diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst
index 15d9ab5993a7..bd01cf6474c8 100644
--- a/Documentation/translations/zh_CN/admin-guide/index.rst
+++ b/Documentation/translations/zh_CN/admin-guide/index.rst
@@ -1,7 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
.. include:: ../disclaimer-zh_CN.rst
-:Original: :doc:`../../../admin-guide/index`
-:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+:Original: Documentation/admin-guide/index.rst
+
+:翻译:
+
+ 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
+
+ 朱岩 Yan Zhu <zhuyan2015@qq.com>
Linux 内核用户和管理员指南
@@ -11,7 +17,11 @@ Linux 内核用户和管理员指南
整体的顺序或组织 - 这些材料不是一个单一的，连贯的文件！幸运的话，情况会随着
时间的推移而迅速改善。
-这个初始部分包含总体信息，包括描述内核的README， 关于内核参数的文档等。
+
+内核管理通用指南
+----------------
+
+本节包含总体信息，包括描述内核整体的 README 文件、内核参数文档等。
.. toctree::
:maxdepth: 1
@@ -20,17 +30,54 @@ Linux 内核用户和管理员指南
Todolist:
-* kernel-parameters
* devices
+* features
+
+内核管理接口的重要组成部分是 /proc 和 sysfs 虚拟文件系统；这些文档描述了如何
+与之交互。
+
+.. toctree::
+ :maxdepth: 1
+
+ cputopology
+
+Todolist:
+
+* sysfs-rules
* sysctl/index
+* abi
-本节介绍CPU漏洞及其缓解措施。
+安全相关文档：
+
+.. toctree::
+ :maxdepth: 1
Todolist:
* hw-vuln/index
+* LSM/index
+* perf-security
+
+
+内核启动
+--------
+
+.. toctree::
+ :maxdepth: 1
+
+ bootconfig
+
+Todolist:
+
+* kernel-parameters
+* efi-stub
+* initrd
+
-下面的一组文档，针对的是试图跟踪问题和bug的用户。
+追踪和识别问题
+--------------
+
+以下是一组面向试图追踪特定问题和 bug 的用户的文档。
.. toctree::
:maxdepth: 1
@@ -39,94 +86,149 @@ Todolist:
reporting-regressions
bug-hunting
bug-bisect
- tainted-kernels
init
+ clearing-warn-once
+ lockup-watchdogs
+ sysrq
Todolist:
+* quickly-build-trimmed-linux
+* verify-bugs-and-bisect-regressions
+* tainted-kernels
* ramoops
* dynamic-debug-howto
* kdump/index
* perf/index
+* pstore-blk
+* kernel-per-CPU-kthreads
+* RAS/index
+
+
+核心内核子系统
+--------------
+
+这些文档描述了核心内核管理接口，这些接口几乎在任何系统上都值得关注。
+
+.. toctree::
+ :maxdepth: 1
-这是应用程序开发人员感兴趣的章节的开始。可以在这里找到涵盖内核ABI各个
-方面的文档。
+ cpu-load
+ mm/index
+ module-signing
+ numastat
Todolist:
-* sysfs-rules
+* cgroup-v2
+* cgroup-v1/index
+* namespaces/index
+* pm/index
+* syscall-user-dispatch
-本手册的其余部分包括各种指南，介绍如何根据您的喜好配置内核的特定行为。
+对非原生二进制格式的支持。请注意，其中一些文档相当 **古老**。
.. toctree::
:maxdepth: 1
- bootconfig
- clearing-warn-once
- cpu-load
- cputopology
- lockup-watchdogs
- numastat
- unicode
- sysrq
- mm/index
+Todolist:
+
+* binfmt-misc
+* java
+* mono
+
+
+块设备和文件系统管理
+--------------------
+
+.. toctree::
+ :maxdepth: 1
Todolist:
-* acpi/index
-* aoe/index
-* auxdisplay/index
* bcache
* binderfs
-* binfmt-misc
* blockdev/index
-* braille-console
-* btmrvl
-* cgroup-v1/index
-* cgroup-v2
* cifs/index
-* dell_rbu
* device-mapper/index
-* edid
-* efi-stub
* ext4
+* filesystem-monitoring
* nfs/index
-* gpio/index
-* highuid
-* hw_random
-* initrd
* iostats
-* java
* jfs
-* kernel-per-CPU-kthreads
+* md
+* ufs
+* xfs
+
+
+专用设备指南
+------------
+
+如何在 Linux 系统中配置硬件。
+
+.. toctree::
+ :maxdepth: 1
+
+Todolist:
+
+* acpi/index
+* aoe/index
+* auxdisplay/index
+* braille-console
+* btmrvl
+* dell_rbu
+* edid
+* gpio/index
+* hw_random
* laptops/index
* lcd-panel-cgram
-* ldm
-* LSM/index
-* md
* media/index
-* module-signing
-* mono
-* namespaces/index
+* nvme-multipath
* parport
-* perf-security
-* pm/index
* pnp
* rapidio
-* ras
* rtc
* serial-console
* svga
+* thermal/index
* thunderbolt
-* ufs
* vga-softcursor
* video-output
-* xfs
+
+
+工作负载分析
+------------
+
+这是一个章节的开始，其中包含对从事 Linux 内核安全关键性分析的应用程序开发人员
+和系统集成商感兴趣的信息。这里可以找到支持分析内核与应用程序交互以及关键内核
+子系统预期的文档。
+
+.. toctree::
+ :maxdepth: 1
+
+Todolist:
+
+* workload-tracing
+
+
+其他内容
+--------
+
+一些难以分类且通常已过时的文档。
+
+.. toctree::
+ :maxdepth: 1
+
+Todolist:
+
+* highuid
+* ldm
+* unicode
.. only:: subproject and html
- Indices
- =======
+ 索引
+ ====
* :ref:`genindex`
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 12/13] ima: Return error on deleting measurements already copied during kexec
From: Roberto Sassu @ 2026-05-29 14:59 UTC (permalink / raw)
To: Mimi Zohar, corbet, skhan, dmitry.kasatkin, eric.snowberg, paul,
jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, chenste, nramas, Roberto Sassu
In-Reply-To: <ea886419ef3047ede1885504fad8f865cdcc5ce3.camel@linux.ibm.com>
On Tue, 2026-05-26 at 10:02 -0400, Mimi Zohar wrote:
> On Wed, 2026-04-29 at 18:03 +0200, Roberto Sassu wrote:
> > From: Roberto Sassu <roberto.sassu@huawei.com>
> >
> > Refuse to delete staged or active list measurements, if a kexec racing with
> > the deletion already copied those measurements in the kexec buffer. In this
> > way, user space becomes aware that those measurements are going to appear
> > in the secondary kernel, and thus they don't have to be saved twice.
>
> There are two reboot notifiers: one to prevent additional measurements extending
> the TPM, while the other copies the measurements for kexec. This patch prevents
> deleting the staged measurements after the latter notifier.
>
> Instead of introducing a specific method for detecting whether the measurement
> list has been copied, rely on one of the two existing reboot notifiers. The
> simplest method would test "ima_measurements_suspended", which would prevent
> deleting the staged measurements a bit earlier.
Testing that the reboot notifier fired (with the
ima_measurements_suspended variable) is not enough to know whether the
measurements dump took place or not.
We need a flag (one is enough) protected by ima_extend_list_mutex, so
that we know reliably which event occurred first, or the dump or the
staging/delete (which are also protected by ima_extend_list_mutex).
Roberto
^ permalink raw reply
* Re: [PATCH v2 1/2] mm/memcontrol: add dmem charge/uncharge functions
From: Michal Koutný @ 2026-05-29 14:56 UTC (permalink / raw)
To: Eric Chanudet
Cc: Johannes Weiner, Michal Hocko, Roman Gushchin, Shakeel Butt,
Muchun Song, Andrew Morton, Maarten Lankhorst, Maxime Ripard,
Natalie Vock, Tejun Heo, Jonathan Corbet, Shuah Khan, cgroups,
linux-mm, linux-kernel, dri-devel, T.J. Mercier,
Christian König, Maxime Ripard, Albert Esteve, Dave Airlie,
linux-doc
In-Reply-To: <20260519-cgroup-dmem-memcg-double-charge-v2-1-db4d1407062b@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
On Tue, May 19, 2026 at 11:59:01AM -0400, Eric Chanudet <echanude@redhat.com> wrote:
> +/**
> + * mem_cgroup_dmem_uncharge - uncharge memcg from a dmem pool allocation
> + * @cgrp: cgroup of the dmem pool
> + * @nr_pages: number of pages to uncharge
> + */
> +void mem_cgroup_dmem_uncharge(struct cgroup *cgrp, unsigned int nr_pages)
> +{
> + struct cgroup_subsys_state *mem_css;
> + struct mem_cgroup *memcg;
> +
> + /* CGROUP_DMEM and MEMCG guarantees this cannot be NULL. */
> + mem_css = cgroup_get_e_css(cgrp, &memory_cgrp_subsys);
> +
> + memcg = mem_cgroup_from_css(mem_css);
> + if (!memcg || mem_cgroup_is_root(memcg)) {
> + css_put(mem_css);
> + return;
> + }
> +
> + mod_memcg_state(memcg, MEMCG_DMEM, -nr_pages);
> + refill_stock(memcg, nr_pages);
This doesn't look right.
Here should be memcg_uncharge().
Regards,
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] mm/memcontrol: add dmem charge/uncharge functions
From: Michal Koutný @ 2026-05-29 14:52 UTC (permalink / raw)
To: Eric Chanudet
Cc: Shakeel Butt, Johannes Weiner, Michal Hocko, Roman Gushchin,
Muchun Song, Andrew Morton, Maarten Lankhorst, Maxime Ripard,
Natalie Vock, Tejun Heo, Jonathan Corbet, Shuah Khan, cgroups,
linux-mm, linux-kernel, dri-devel, T.J. Mercier,
Christian König, Maxime Ripard, Albert Esteve, Dave Airlie,
linux-doc
In-Reply-To: <ahWfypvuTVsB-pHQ@x1nano>
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]
On Wed, May 27, 2026 at 03:10:47PM -0400, Eric Chanudet <echanude@redhat.com> wrote:
> but that made me realize there is a catch with
> this patch set, with something like:
> A: +memory{max:32M}/+dmem
> A/B: +memory{max:16M}
>
> It gets the CSS from the dmem's cgroup with
> cgroup_get_e_css(cgrp, &memory_cgrp_subsys);
> mem_cgroup_from_css(mem_css);
>
> Which would resolve to A's memcg and not enforce the memory.max limit
> set in B when dmem.memcg is set for that region.
One perspective is that this is in accordance with dmem's limit granularity.
If the user wanted to distinguish dmem charges below A, they need to
enable the controller there too. IOW, the depends_on in one direction is
correct. dmem is primary when it comes to those charges and memcg
secondary.
Another possibility would be to always use the highest precision
available (wrt where current resides) and then the API should refer to
struct cgroup from task_dfl_cgroup(current) (and make this only
available on v2), or to struct css_set and extract respective subsys
csses in the double charging function.
In either case, it's worth mentioning the behavior in the dmem docs.
HTH,
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/3] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
From: Stanislav Kinsburskii @ 2026-05-29 14:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Liam.Howlett, david, jgg, corbet, leon, ljs, mhocko, rppt, shuah,
skhan, surenb, vbabka, linux-doc, linux-kernel, linux-kselftest,
linux-mm
In-Reply-To: <20260528131115.184c178d03d516e11248a1ae@linux-foundation.org>
On Thu, May 28, 2026 at 01:11:15PM -0700, Andrew Morton wrote:
> On Thu, 28 May 2026 12:53:59 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
>
> > A gentle reminder as requested: do you think this change could be taken into
> > the mm tree?
> > It's beneficial not only for the MSHV driver, but can be used for
> > post-copy live migration of GPU states in future.
>
> Still no review, alas. It's not a trivial thing, affecting both hmm
> and userfaultfd. And we're closing in on -rc6.
>
> I'd prefer that we revisit in the next cycle, please. Refresh retest
> and resend after -rc1?
>
Sure, will do.
Thanks,
Stanislav
^ permalink raw reply
* Re: [PATCH v2] drm/xe/hwmon: document DG2 fan speed reporting quirk
From: 占wei @ 2026-05-29 14:05 UTC (permalink / raw)
To: Matthew Brost, Thomas Hellström, Rodrigo Vivi
Cc: Jonathan Corbet, Shuah Khan, intel-xe, dri-devel, linux-doc,
linux-kernel, Raag Jadav
In-Reply-To: <20260529135028.20763-1-zhanwei919@gmail.com>
+Cc Raag, who authored the fan support and reviewed v1.
Thanks for your help, this v2 drops the code change and documents the
DG2 shared-tach behaviour instead, per your feedback on v1.
Zhan Wei <zhanwei919@gmail.com> 于2026年5月29日周五 21:50写道：
>
> The number of fanN_input attributes on DG2 is hardcoded to two because
> FSC_READ_NUM_FANS returns an incorrect value on some boards. How the
> physical fans map onto the tach channels is left to the board vendor:
> some OEMs route multiple physical fans through a single shared tach
> line, in which case the unwired channel's pulse counter never
> accumulates and fanN_input reads a constant 0 RPM.
>
> This is expected behaviour for such boards rather than a driver fault,
> and the driver has no reliable way to distinguish a shared-tach layout
> from a genuinely silent fan. Document this so the flat DG2 fan count is
> not mistaken for a bug and "fixed" by lowering it, which would hide a
> working fan2 on boards that do wire two tach lines.
>
> Signed-off-by: Zhan Wei <zhanwei919@gmail.com>
> ---
> v1 -> v2: Drop the code change. As pointed out in review, the same PCI
> device ID ships with both shared-tach (multiple physical fans on one
> channel) and 1:1 fan wiring, and FSC_READ_NUM_FANS is unreliable on
> some boards, so the DG2 fan count cannot be lowered without hiding a
> working fan2 on boards that do wire two tach lines. Document the
> behaviour instead of changing the reported fan count.
>
> v1: https://lore.kernel.org/intel-xe/20260527115311.13398-1-zhanwei919@gmail.com/
>
> Documentation/gpu/xe/index.rst | 1 +
> Documentation/gpu/xe/xe_hwmon.rst | 48 +++++++++++++++++++++++++++++++
> 2 files changed, 49 insertions(+)
> create mode 100644 Documentation/gpu/xe/xe_hwmon.rst
>
> diff --git a/Documentation/gpu/xe/index.rst b/Documentation/gpu/xe/index.rst
> index 874ffcb6da3a..3c14cdcaa8a6 100644
> --- a/Documentation/gpu/xe/index.rst
> +++ b/Documentation/gpu/xe/index.rst
> @@ -30,3 +30,4 @@ DG2, etc is provided to prototype the driver.
> xe-drm-usage-stats.rst
> xe_configfs
> xe_gt_stats
> + xe_hwmon
> diff --git a/Documentation/gpu/xe/xe_hwmon.rst b/Documentation/gpu/xe/xe_hwmon.rst
> new file mode 100644
> index 000000000000..8cd48df59386
> --- /dev/null
> +++ b/Documentation/gpu/xe/xe_hwmon.rst
> @@ -0,0 +1,48 @@
> +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +=================
> +Xe HWMON support
> +=================
> +
> +The xe driver exposes hardware monitoring sensors (power, energy,
> +temperature, voltage and fan speed) through the kernel hwmon subsystem,
> +typically consumed via ``/sys/class/hwmon/hwmonX/`` or tools such as
> +``sensors``.
> +
> +Fan speed reporting
> +===================
> +
> +Fan speed (``fanN_input``) is reported in RPM and computed from a tach
> +pulse counter: the driver reads an accumulating pulse register, divides
> +the delta between two subsequent readings by two pulses per rotation,
> +and time-averages the result.
> +
> +Number of fan channels
> +-----------------------
> +
> +The number of ``fanN_input`` attributes exposed in sysfs is the fan
> +count returned by the ``FSC_READ_NUM_FANS`` pcode command. On DG2 this
> +command has been found to return an incorrect value on some boards, so
> +the driver hardcodes a fan count of two there. As a result up to
> +``fan1_input`` and ``fan2_input`` are always exposed on DG2 regardless
> +of how many tach lines are actually wired.
> +
> +Zero RPM on DG2 is not necessarily a bug
> +----------------------------------------
> +
> +How physical fans map onto the tach channels is left to the board
> +vendor. Some OEMs route several physical fans through a single shared
> +tach line, while others wire each fan to its own channel 1:1. The
> +driver has no reliable way to tell these layouts apart, and the same PCI
> +device ID can ship in either configuration.
> +
> +When a channel has no tach line driving it, its pulse counter never
> +accumulates, so the corresponding ``fanN_input`` reads a constant 0 RPM.
> +On DG2 this is most often seen on ``fan2_input`` for boards that drive
> +both physical fans from a single tach line. This is expected behaviour
> +for such boards, not a driver fault, and reflects the board wiring
> +rather than a missing or stalled fan.
> +
> +For this reason the fan count on DG2 is intentionally left at a flat
> +value rather than tracked per board: there is no driver-visible signal
> +that distinguishes a shared-tach layout from a genuinely silent fan.
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v5 08/18] mm: add VM_UFFD_RWP VMA flag
From: Lorenzo Stoakes @ 2026-05-29 14:00 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: akpm, rppt, peterx, david, 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: <ahmM8LzrzX-qP_5s@thinkstation>
On Fri, May 29, 2026 at 02:07:16PM +0100, Kiryl Shutsemau wrote:
> On Fri, May 29, 2026 at 08:24:55AM +0100, Lorenzo Stoakes wrote:
> > On Tue, May 26, 2026 at 02:04:56PM +0100, Kiryl Shutsemau wrote:
> > > From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
> > >
> > > Preparatory patch for userfaultfd read-write protection (RWP). RWP
> > > extends userfaultfd protection from plain write-protection (WP) to
> > > full read-write protection: accesses to an RWP-protected range --
> > > reads as well as writes -- trap through userfaultfd.
> > >
> > > Reserve VM_UFFD_RWP, add the userfaultfd_rwp() and
> > > userfaultfd_protected() helpers, and wire up the smaps "ur" entry and
> > > the trace-flag table the rest of the series will use. The flag is
> > > gated on CONFIG_USERFAULTFD_RWP, which is introduced together with the
> > > UAPI in a later patch; until then VM_UFFD_RWP aliases VM_NONE and
> > > every downstream check folds to dead code.
> > >
> > > Nothing sets or queries the flag yet.
> > >
> > > Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> > > Assisted-by: Claude:claude-opus-4-6
> >
> > Hm, if you've just used claude to bounce ideas off, I'm really not sure if
> > it's necessary to disclose, though I respect your thoroughness for doing so
> > :)
>
> I've elaborated on how I used Claude in reply to Andrew:
>
> https://lore.kernel.org/all/af5eALk9yO8pPcHv@thinkstation
>
> It is more than bouncing ideas.
Ah interesting! Fair enough then.
>
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index 71b11945e4fc..6499cfb61dc4 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -362,6 +362,7 @@ enum {
> > > #endif
> > > DECLARE_VMA_BIT(UFFD_MINOR, 41),
> > > DECLARE_VMA_BIT(SEALED, 42),
> > > + DECLARE_VMA_BIT(UFFD_RWP, 43),
> >
> > I'm guessing CONFIG_USERFAULTFD_RWP is predicated on CONFIG_64BIT?
>
> Yes:
> depends on 64BIT && ARCH_HAS_PTE_PROTNONE && HAVE_ARCH_USERFAULTFD_WP
> >
> > It's a silly situation and once my VMA flags stuff is done it'll be
> > eliminated but for now... :)
>
> Yeah. I actually would appreciate your take on 04/18. It is related.
I'll reply there.
>
> > > diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
> > > index f4cf5763f92c..0aef628514df 100644
> > > --- a/include/linux/userfaultfd_k.h
> > > +++ b/include/linux/userfaultfd_k.h
> > > @@ -21,10 +21,11 @@
> > > #include <linux/hugetlb_inline.h>
> > >
> > > /* The set of all possible UFFD-related VM flags. */
> > > -#define __VM_UFFD_FLAGS (VM_UFFD_MISSING | VM_UFFD_WP | VM_UFFD_MINOR)
> > > +#define __VM_UFFD_FLAGS (VM_UFFD_MISSING | VM_UFFD_MINOR | \
> > > + VM_UFFD_WP | VM_UFFD_RWP)
> > >
> > > #define __VMA_UFFD_FLAGS mk_vma_flags(VMA_UFFD_MISSING_BIT, VMA_UFFD_WP_BIT, \
> > > - VMA_UFFD_MINOR_BIT)
> > > + VMA_UFFD_MINOR_BIT, VMA_UFFD_RWP_BIT)
> > >
> > > /*
> > > * CAREFUL: Check include/uapi/asm-generic/fcntl.h when defining
> > > @@ -178,7 +179,7 @@ static inline bool is_mergeable_vm_userfaultfd_ctx(struct vm_area_struct *vma,
> > > */
> > > static inline bool uffd_disable_huge_pmd_share(struct vm_area_struct *vma)
> > > {
> > > - return vma->vm_flags & (VM_UFFD_WP | VM_UFFD_MINOR);
> > > + return vma->vm_flags & (VM_UFFD_MINOR | VM_UFFD_WP | VM_UFFD_RWP);
> >
> > While we're here we might as well switch to using the new API?
> >
> > Can do:
> >
> > return vma_test_any_mask(vma, __VMA_UFFD_FLAGS);
> >
> > One unfortunate thing is using bit values means we can't do the VM_NONE
> > trick, but if !CONFIG_USERFAULTFD_RWP then VMA_UFFD_RWP_BIT wouldn't be set
> > anyway, same for minor so this should be fine?
>
> I think we need to decide first if the 04/18 direction is right.
> We can define VMA_UFFD_RWP_BIT to VMA_NO_BIT if !CONFIG_USERFAULTFD_RWP.
Yeah I don't think that approach is workable unfortunately (see my reply
there).
But I suggest some workarounds there with VMA_UFFD_RWP.
>
> > > }
> > >
> > > /*
> > > @@ -208,6 +209,16 @@ static inline bool userfaultfd_minor(struct vm_area_struct *vma)
> > > return vma->vm_flags & VM_UFFD_MINOR;
> > > }
> > >
> > > +static inline bool userfaultfd_rwp(struct vm_area_struct *vma)
> > > +{
> > > + return vma->vm_flags & VM_UFFD_RWP;
> > > +}
> >
> > Can be:
> >
> > return vma_test(vma, VMA_UFFD_RWP_BIT);
>
> Yep.
With the approach suggested in 04/18 we could do this as:
return vma_test_any_mask(vma, VMA_UFFD_RWP);
Which is a bit fugly but will work.
>
>
> --
> Kiryl Shutsemau / Kirill A. Shutemov
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v5 04/18] mm: skip out-of-range bits in mk_vma_flags()
From: Lorenzo Stoakes @ 2026-05-29 14:00 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: akpm, rppt, peterx, david, 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, Kiryl Shutsemau (Meta), stable
In-Reply-To: <20260526130509.2748441-5-kirill@shutemov.name>
On Tue, May 26, 2026 at 02:04:52PM +0100, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> vma_flags_t is one unsigned long on 32-bit -- NUM_VMA_FLAG_BITS ==
> BITS_PER_LONG by design, so VM_xxx-declared bits sit in the first
> word and hit the single-long fast path. But the bit enum declares
> some bits unconditionally above BITS_PER_LONG (VMA_UFFD_MINOR_BIT
> == 41 today, with VM_UFFD_MINOR == VM_NONE on 32-bit so no VMA
> actually carries the bit).
Yeah ugh.
>
> Passing such a bit to mk_vma_flags() goes through __set_bit(41,
> &one_long) and writes one word past the end. The compiler folds
> the OOB store with wraparound (1UL << (41 % 32) == bit 9) into
> the first word. Bit 9 is already in __VMA_UFFD_FLAGS so the mask
> happens to come out right today, but any high-numbered bit whose
That is... helpful :) but not great that this is the situation, an
oversight, clearly! How I hate 32-bit kernels :)
> mod-BITS_PER_LONG position is otherwise unused would silently OR
> an extra bit into the mask.
>
> Add VMA_NO_BIT and have DECLARE_VMA_BIT() resolve any bitnum out
> of range to it. vma_flags_set_flag() drops negative bit values.
> The ternary collapses at compile time, the runtime check folds
> away when the bit is in range, and the common path is unchanged.
Hmm are you sure it does?
A key design goal was that mk_vma_flags() generates compile-time constants
the same as if the bitmap were constructed independently.
This surely must generate code? Or at least runs a significant risk of it?
Setting a precedent here would probably lead to VMA_NO_BIT being used more
and therefore generating code in more places I think.
And I'm not sure I really want to bend over backwards here to work around
issues with 32-bit kernels when in the long run the intent is that we move
to making these values 64-bit anyway.
Perhaps it's even wise possibly to just make these values 64-bit already,
ahead of time?
(I did look at this in terms of wanting something like a VMA_NO_BIT so we
could get VM_NONE-like behaviour but nothing I tried failed to generate
code.)
A simple solution that doesn't require change to the core is to just uglify
userfaultfd_k.h a bit with:
#ifdef HAVE_ARCH_USERFAULTFD_MINOR
#define __VMA_UFFD_FLAGS mk_vma_flags(VMA_UFFD_MISSING_BIT, VMA_UFFD_WP_BIT, \
VMA_UFFD_MINOR_BIT)
#else
#define __VMA_UFFD_FLAGS mk_vma_flags(VMA_UFFD_MISSING_BIT, VMA_UFFD_WP_BIT)
#endif
But of course that becomes much more horrible with your changes...
Another alternative, which I used for VMA_DROPPABLE is to add something
like this in mm.h:
#ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR
#define VM_UFFD_MINOR INIT_VM_FLAG(UFFD_MINOR)
+define VMA_UFFD_MINOR mk_vma_flags(VMA_UFFD_MINOR_BIT)
#else
#define VM_UFFD_MINOR VM_NONE
+define VMA_UFFD_MINOR EMPTY_VMA_FLAGS
#endif
Then we can do:
#define __VMA_UFFD_FLAGS append_vma_flags(VMA_MINOR, VMA_UFFD_MISSING_BIT, \
VMA_UFFD_WP_BIT)
With you changes in 08/18 on top it'd get hairier, but we could make our
life easier by implementing something like:
static __always_inline vma_flags_t __mk_vma_flags_from_masks(size_t count,
const vma_flags_t *masks)
{
vma_flags_t flags = EMPTY_VMA_FLAGS;
int i;
for (i = 0; i < count; i++)
mask = vma_flags_set_mask(&flags, masks[i]);
return flags;
}
#define mk_vma_flags_from_masks(...) __mk_vma_flags_from_masks(, \
COUNT_ARGS(__VA_ARGS__), (const vma_flags_t []){__VA_ARGS__})
(untested code - you would need to ensure it generated equivalent
constants as VM_xxx would now :)
Then you could get VMA_UFFD_RWP with:
#ifdef CONFIG_USERFAULTFD_RWP
#define VMA_UFFD_RWP mk_vma_flags(VMA_UFFD_RWP_BIT)
#else
#define VMA_UFFD_RWP EMPTY_VMA_FLAGS
#endif
And then:
/* Always available if CONFIG_USERFAULTFD set. */
#define __VMA_UFFD_DEFAULT_FLAGS \
mk_vma_flags(VMA_UFFD_MISSING_BIT, VMA_UFFD_WP_BIT)
#define __VMA_UFFD_FLAGS mk_vma_flags_from_masks(__VMA_UFFD_DEFAULT_FLAGS \
VMA_MINOR, VMA_RWP)
Which is kind ok-ish right? I mean it's all a bit fugly obviously.
>
> Bits declared in the enum are now safe to pass to mk_vma_flags()
> regardless of arch.
I mean another issue here is we're then codifying behaviour that's legacy
ahead of time. I really want to avoid that.
>
> Fixes: 9ea35a25d51b ("mm: introduce VMA flags bitmap type")
> Cc: stable@vger.kernel.org
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> ---
> include/linux/mm.h | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 0f2612a70fb1..71b11945e4fc 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -286,8 +286,17 @@ extern unsigned int kobjsize(const void *objp);
> */
> typedef int __bitwise vma_flag_t;
>
> -#define DECLARE_VMA_BIT(name, bitnum) \
> - VMA_ ## name ## _BIT = ((__force vma_flag_t)bitnum)
> +/*
> + * VMA_NO_BIT means "no bit"; mk_vma_flags() skips it. DECLARE_VMA_BIT()
> + * below uses it for any bit number that doesn't fit in the bitmap, so
> + * callers don't need to track which bits are valid on the current build.
> + */
> +#define VMA_NO_BIT ((__force vma_flag_t)-1)
> +
> +#define DECLARE_VMA_BIT(name, bitnum) \
> + VMA_ ## name ## _BIT = (((bitnum) < NUM_VMA_FLAG_BITS) ? \
> + ((__force vma_flag_t)(bitnum)) : \
> + VMA_NO_BIT)
> #define DECLARE_VMA_BIT_ALIAS(name, aliased) \
> VMA_ ## name ## _BIT = (VMA_ ## aliased ## _BIT)
> enum {
> @@ -1081,6 +1090,8 @@ static __always_inline void vma_flags_set_flag(vma_flags_t *flags,
> {
> unsigned long *bitmap = flags->__vma_flags;
>
> + if ((__force int)bit < 0)
> + return;
> __set_bit((__force int)bit, bitmap);
> }
>
> --
> 2.54.0
>
Either way, I think we should break out any fix like this from the series.
Andrew is I think also not a fan of fixes patches in the middle of series
anyway :P
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH 1/3] net: Remove support for AIO on sockets
From: Christoph Hellwig @ 2026-05-29 13:59 UTC (permalink / raw)
To: Jens Axboe
Cc: Christoph Hellwig, demiobenour, Herbert Xu, David S. Miller,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
Jakub Kicinski, Simon Horman, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Jonathan Corbet, Shuah Khan, Eric Biggers,
Ard Biesheuvel, linux-crypto, linux-kernel, io-uring, netdev,
linux-perf-users, linux-doc, Toke Høiland-Jørgensen,
linux-api, David Howells
In-Reply-To: <2cfd6455-7b5b-4974-b8a1-4a0abca69768@kernel.dk>
On Thu, May 28, 2026 at 10:56:06AM -0600, Jens Axboe wrote:
> > Where? And how do make that available to in-kernel users like
> > storage protocols and network file system, which really suffer from
> > the current MSG_SPLICE_PAGES semantics.
>
> For zero copy, on both the receive and send side. Since we have a proper
> notification channel, that's what we use rather than the hack that is
> the error queue.
Can you point me to that notification channel?
> >> , and without needing msg_kiocb or the
> >
> > What do you think is the downside of using a kiocb here like for
> > everything else with async notifications?
>
> Where would the notifications go?
For userspace: io_uring or the error queue for the synchronous calls.
For in-kernel APIs whatever the callers wants to do by doing it from
ki_complete.
> You'd end up inventing something new
> to propagate them to userspace then.
The main aim here is to have a way to get these completions from
kernelspace to get rid of the current horrors around MSG_SPLICE_PAGES.
> The io_uring side does not rely on
> using msg_kiocb, and iirc that part was only ever used for the crypto
> stuff and largely broken. Which is why I do agree with just yanking it
> out.
I'm not arguing for how msg_kiocb as that is a mess. But having an
explicit kiocb API like all the other async file operations would
make things a lot simpler.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: update ndesaulniers
From: Will Deacon @ 2026-05-29 13:57 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Nathan Chancellor, Bill Wendling, Justin Stitt, Kees Cook,
Jonathan Corbet, Shuah Khan, Carlos Bilbao, Avadhut Naik,
linux-kernel, workflows, linux-doc, llvm, gosst-kernel,
android-kernel-team, kernel-dynamic-tools
In-Reply-To: <20260528-im_back_baby-v1-1-25d355efdbae@google.com>
On Thu, May 28, 2026 at 02:38:41PM -0700, Nick Desaulniers wrote:
> I'm coming back. I will return. I will possess your body, and I'll
> make LKML burn.
>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
> .mailmap | 1 -
> Documentation/process/embargoed-hardware-issues.rst | 2 +-
> Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst | 2 +-
> MAINTAINERS | 2 +-
> 4 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/.mailmap b/.mailmap
> index a009f73d7ea5..f863781b0102 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -634,7 +634,6 @@ Nicholas Piggin <npiggin@gmail.com> <npiggin@kernel.dk>
> Nicholas Piggin <npiggin@gmail.com> <npiggin@suse.de>
> Nicholas Piggin <npiggin@gmail.com> <nickpiggin@yahoo.com.au>
> Nicholas Piggin <npiggin@gmail.com> <piggin@cyberone.com.au>
> -Nick Desaulniers <nick.desaulniers+lkml@gmail.com> <ndesaulniers@google.com>
> Nicolas Ferre <nicolas.ferre@microchip.com> <nicolas.ferre@atmel.com>
> Nicolas Pitre <nico@fluxnic.net> <nicolas.pitre@linaro.org>
> Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
> diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst
> index 34e00848e0da..d07f16c3c7b8 100644
> --- a/Documentation/process/embargoed-hardware-issues.rst
> +++ b/Documentation/process/embargoed-hardware-issues.rst
> @@ -308,7 +308,7 @@ an involved disclosed party. The current ambassadors list:
>
> Google Kees Cook <keescook@chromium.org>
>
> - LLVM Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
> + LLVM Nick Desaulniers <ndesaulniers@google.com>
> ============= ========================================================
>
> If you want your organization to be added to the ambassadors list, please
> diff --git a/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst b/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst
> index 9d444b9c46d3..7d4d694967c7 100644
> --- a/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst
> +++ b/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst
> @@ -287,7 +287,7 @@ revelada involucrada. La lista de embajadores actuales:
>
> Google Kees Cook <keescook@chromium.org>
>
> - LLVM Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
> + LLVM Nick Desaulniers <ndesaulniers@google.com>
> ============= ========================================================
>
> Si quiere que su organización se añada a la lista de embajadores, por
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 461a3eed6129..2f06cc2e463c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6259,7 +6259,7 @@ F: .clang-format
>
> CLANG/LLVM BUILD SUPPORT
> M: Nathan Chancellor <nathan@kernel.org>
> -R: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
> +R: Nick Desaulniers <ndesaulniers@google.com>
> R: Bill Wendling <morbo@google.com>
> R: Justin Stitt <justinstitt@google.com>
> L: llvm@lists.linux.dev
Hallowed be thy name.
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* [PATCH v2] drm/xe/hwmon: document DG2 fan speed reporting quirk
From: Zhan Wei @ 2026-05-29 13:50 UTC (permalink / raw)
To: Matthew Brost, Thomas Hellström, Rodrigo Vivi
Cc: Jonathan Corbet, Shuah Khan, intel-xe, dri-devel, linux-doc,
linux-kernel, Zhan Wei
In-Reply-To: <20260527115311.13398-1-zhanwei919@gmail.com>
The number of fanN_input attributes on DG2 is hardcoded to two because
FSC_READ_NUM_FANS returns an incorrect value on some boards. How the
physical fans map onto the tach channels is left to the board vendor:
some OEMs route multiple physical fans through a single shared tach
line, in which case the unwired channel's pulse counter never
accumulates and fanN_input reads a constant 0 RPM.
This is expected behaviour for such boards rather than a driver fault,
and the driver has no reliable way to distinguish a shared-tach layout
from a genuinely silent fan. Document this so the flat DG2 fan count is
not mistaken for a bug and "fixed" by lowering it, which would hide a
working fan2 on boards that do wire two tach lines.
Signed-off-by: Zhan Wei <zhanwei919@gmail.com>
---
v1 -> v2: Drop the code change. As pointed out in review, the same PCI
device ID ships with both shared-tach (multiple physical fans on one
channel) and 1:1 fan wiring, and FSC_READ_NUM_FANS is unreliable on
some boards, so the DG2 fan count cannot be lowered without hiding a
working fan2 on boards that do wire two tach lines. Document the
behaviour instead of changing the reported fan count.
v1: https://lore.kernel.org/intel-xe/20260527115311.13398-1-zhanwei919@gmail.com/
Documentation/gpu/xe/index.rst | 1 +
Documentation/gpu/xe/xe_hwmon.rst | 48 +++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+)
create mode 100644 Documentation/gpu/xe/xe_hwmon.rst
diff --git a/Documentation/gpu/xe/index.rst b/Documentation/gpu/xe/index.rst
index 874ffcb6da3a..3c14cdcaa8a6 100644
--- a/Documentation/gpu/xe/index.rst
+++ b/Documentation/gpu/xe/index.rst
@@ -30,3 +30,4 @@ DG2, etc is provided to prototype the driver.
xe-drm-usage-stats.rst
xe_configfs
xe_gt_stats
+ xe_hwmon
diff --git a/Documentation/gpu/xe/xe_hwmon.rst b/Documentation/gpu/xe/xe_hwmon.rst
new file mode 100644
index 000000000000..8cd48df59386
--- /dev/null
+++ b/Documentation/gpu/xe/xe_hwmon.rst
@@ -0,0 +1,48 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=================
+Xe HWMON support
+=================
+
+The xe driver exposes hardware monitoring sensors (power, energy,
+temperature, voltage and fan speed) through the kernel hwmon subsystem,
+typically consumed via ``/sys/class/hwmon/hwmonX/`` or tools such as
+``sensors``.
+
+Fan speed reporting
+===================
+
+Fan speed (``fanN_input``) is reported in RPM and computed from a tach
+pulse counter: the driver reads an accumulating pulse register, divides
+the delta between two subsequent readings by two pulses per rotation,
+and time-averages the result.
+
+Number of fan channels
+-----------------------
+
+The number of ``fanN_input`` attributes exposed in sysfs is the fan
+count returned by the ``FSC_READ_NUM_FANS`` pcode command. On DG2 this
+command has been found to return an incorrect value on some boards, so
+the driver hardcodes a fan count of two there. As a result up to
+``fan1_input`` and ``fan2_input`` are always exposed on DG2 regardless
+of how many tach lines are actually wired.
+
+Zero RPM on DG2 is not necessarily a bug
+----------------------------------------
+
+How physical fans map onto the tach channels is left to the board
+vendor. Some OEMs route several physical fans through a single shared
+tach line, while others wire each fan to its own channel 1:1. The
+driver has no reliable way to tell these layouts apart, and the same PCI
+device ID can ship in either configuration.
+
+When a channel has no tach line driving it, its pulse counter never
+accumulates, so the corresponding ``fanN_input`` reads a constant 0 RPM.
+On DG2 this is most often seen on ``fan2_input`` for boards that drive
+both physical fans from a single tach line. This is expected behaviour
+for such boards, not a driver fault, and reflects the board wiring
+rather than a missing or stalled fan.
+
+For this reason the fan count on DG2 is intentionally left at a flat
+value rather than tracked per board: there is no driver-visible signal
+that distinguishes a shared-tach layout from a genuinely silent fan.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next] Documentation: networking: Add a test plan for ethtool pause validation
From: Maxime Chevallier @ 2026-05-29 13:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni, Simon Horman,
Russell King, Heiner Kallweit, Jonathan Corbet, Shuah Khan,
Oleksij Rempel, Vladimir Oltean, Florian Fainelli,
thomas.petazzoni, netdev, linux-kernel, linux-doc
In-Reply-To: <b7de216a-fd1a-42a0-8711-d822a1ad9319@lunn.ch>
On 5/29/26 14:59, Andrew Lunn wrote:
>> I think that
>>
>> ethtool -s <iface> duplex half autoneg on
>>
>> should be enough, the link should still establish at 100M, I've tested
>> that on a 1G/FULL 100MHalf+Full interface and this is the result we
>> get :)
>
> Nice.
>
> But i still think the test should check the autoneg result and do
> something sensible if the link does not come up. This probably applies
> to all cases where we trigger auto neg.
Yes indeed, we need some sets of helpers to deal with link management,
especially for this kind of ethtool tests, with ways to recover a known
working configuration.
>
>> That said I've tested the following on mcbin, and it seems that acually
>> nothing in the code currently deals with Half duplex / Pause interaction,
>> and we don't get any EOPNOTSUPP.
>>
>> So the broader question is, should we reflect the current behaviour or
>> an ideal one ?
>
> What 802.3 says.
Ok, this is what I've been using to define the documented cases so far:)
> If we come across cases where phylib/phylink is
> broken, let me know, and i will fix it. But we will leave driver bugs
> to individual driver developers.
>
> But we also need to consider that for some APIs, we have decided that
> a configuration can be set now, which does not actually apply in our
> current conditions, but it will be stored away for when conditions
> change and it is applicable. The half duplex case could fit that. When
> the link is currently half duplex, you can configure pause, but you
> don't expect it to actually change the current behaviour. It only
> kicks in when the link renegotiates to full duplex sometime in the
> future. We have to also consider this the other way around. The link
> is full duplex and pause is configured by the user. Something happens
> with the LP and the link renegotiates to half duplex. The local end
> should not throw away the configuration, it simply cannot apply it
> given the current situation.
>
True, so the end result is that we must not error out when changing the
pause params while the link is in half duplex, but store the user intent.
Maybe an exception is if we only advertise HD modes ? i.e. HW can't do
FD, or user forced HD modes ? even then, ethtool will show that we
aren't advertising any Pause modes, so maybe that's enough.
OK maybe in the end the best course of action is to leave this
discussion here and I followup with :
- Well defined test cases in a machine-readable (or human readable but
with much more details) format, including start conditions, a
decision tree based on the "supported" fields
- A list of identified corner cases that may be ill-defined (such as
this HD topic) that we can openly discuss and potentially followup
with code fixes
- Human readable doc for developpers and AI to ingest
Maxime
^ permalink raw reply
* Re: [PATCH v5 08/18] mm: add VM_UFFD_RWP VMA flag
From: Kiryl Shutsemau @ 2026-05-29 13:07 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: akpm, rppt, peterx, david, 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: <ahk60ViRq4q2g4uz@lucifer>
On Fri, May 29, 2026 at 08:24:55AM +0100, Lorenzo Stoakes wrote:
> On Tue, May 26, 2026 at 02:04:56PM +0100, Kiryl Shutsemau wrote:
> > From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
> >
> > Preparatory patch for userfaultfd read-write protection (RWP). RWP
> > extends userfaultfd protection from plain write-protection (WP) to
> > full read-write protection: accesses to an RWP-protected range --
> > reads as well as writes -- trap through userfaultfd.
> >
> > Reserve VM_UFFD_RWP, add the userfaultfd_rwp() and
> > userfaultfd_protected() helpers, and wire up the smaps "ur" entry and
> > the trace-flag table the rest of the series will use. The flag is
> > gated on CONFIG_USERFAULTFD_RWP, which is introduced together with the
> > UAPI in a later patch; until then VM_UFFD_RWP aliases VM_NONE and
> > every downstream check folds to dead code.
> >
> > Nothing sets or queries the flag yet.
> >
> > Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> > Assisted-by: Claude:claude-opus-4-6
>
> Hm, if you've just used claude to bounce ideas off, I'm really not sure if
> it's necessary to disclose, though I respect your thoroughness for doing so
> :)
I've elaborated on how I used Claude in reply to Andrew:
https://lore.kernel.org/all/af5eALk9yO8pPcHv@thinkstation
It is more than bouncing ideas.
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 71b11945e4fc..6499cfb61dc4 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -362,6 +362,7 @@ enum {
> > #endif
> > DECLARE_VMA_BIT(UFFD_MINOR, 41),
> > DECLARE_VMA_BIT(SEALED, 42),
> > + DECLARE_VMA_BIT(UFFD_RWP, 43),
>
> I'm guessing CONFIG_USERFAULTFD_RWP is predicated on CONFIG_64BIT?
Yes:
depends on 64BIT && ARCH_HAS_PTE_PROTNONE && HAVE_ARCH_USERFAULTFD_WP
>
> It's a silly situation and once my VMA flags stuff is done it'll be
> eliminated but for now... :)
Yeah. I actually would appreciate your take on 04/18. It is related.
> > diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
> > index f4cf5763f92c..0aef628514df 100644
> > --- a/include/linux/userfaultfd_k.h
> > +++ b/include/linux/userfaultfd_k.h
> > @@ -21,10 +21,11 @@
> > #include <linux/hugetlb_inline.h>
> >
> > /* The set of all possible UFFD-related VM flags. */
> > -#define __VM_UFFD_FLAGS (VM_UFFD_MISSING | VM_UFFD_WP | VM_UFFD_MINOR)
> > +#define __VM_UFFD_FLAGS (VM_UFFD_MISSING | VM_UFFD_MINOR | \
> > + VM_UFFD_WP | VM_UFFD_RWP)
> >
> > #define __VMA_UFFD_FLAGS mk_vma_flags(VMA_UFFD_MISSING_BIT, VMA_UFFD_WP_BIT, \
> > - VMA_UFFD_MINOR_BIT)
> > + VMA_UFFD_MINOR_BIT, VMA_UFFD_RWP_BIT)
> >
> > /*
> > * CAREFUL: Check include/uapi/asm-generic/fcntl.h when defining
> > @@ -178,7 +179,7 @@ static inline bool is_mergeable_vm_userfaultfd_ctx(struct vm_area_struct *vma,
> > */
> > static inline bool uffd_disable_huge_pmd_share(struct vm_area_struct *vma)
> > {
> > - return vma->vm_flags & (VM_UFFD_WP | VM_UFFD_MINOR);
> > + return vma->vm_flags & (VM_UFFD_MINOR | VM_UFFD_WP | VM_UFFD_RWP);
>
> While we're here we might as well switch to using the new API?
>
> Can do:
>
> return vma_test_any_mask(vma, __VMA_UFFD_FLAGS);
>
> One unfortunate thing is using bit values means we can't do the VM_NONE
> trick, but if !CONFIG_USERFAULTFD_RWP then VMA_UFFD_RWP_BIT wouldn't be set
> anyway, same for minor so this should be fine?
I think we need to decide first if the 04/18 direction is right.
We can define VMA_UFFD_RWP_BIT to VMA_NO_BIT if !CONFIG_USERFAULTFD_RWP.
> > }
> >
> > /*
> > @@ -208,6 +209,16 @@ static inline bool userfaultfd_minor(struct vm_area_struct *vma)
> > return vma->vm_flags & VM_UFFD_MINOR;
> > }
> >
> > +static inline bool userfaultfd_rwp(struct vm_area_struct *vma)
> > +{
> > + return vma->vm_flags & VM_UFFD_RWP;
> > +}
>
> Can be:
>
> return vma_test(vma, VMA_UFFD_RWP_BIT);
Yep.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH net-next v2 10/10] net: ethernet: adi: Add a driver for the ADIN1140 MACPHY
From: Andrew Lunn @ 2026-05-29 13:03 UTC (permalink / raw)
To: Nuno Sá
Cc: ciprian.regus, Parthiban Veerasooran, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Heiner Kallweit,
Russell King, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
netdev, linux-kernel, linux-doc, devicetree
In-Reply-To: <ahlY8WSRO_HPmGtK@nsa>
Hi Nuno
> > +static void adin1140_stats_work(struct work_struct *work)
> > +{
> > + struct delayed_work *dwork = to_delayed_work(work);
> > + u64 stat_buff[ADIN1140_STATS_CNT] = {};
> > + struct adin1140_priv *priv;
> > + u32 reg_val;
> > + int ret;
> > + u32 i;
> > +
> > + priv = container_of(dwork, struct adin1140_priv, stats_work);
> > +
> > + for (i = 0; i < ARRAY_SIZE(adin1140_stat_regs); i++) {
> > + ret = oa_tc6_read_register(priv->tc6, adin1140_stat_regs[i],
> > + ®_val);
> > + if (ret)
> > + break;
> > +
> > + stat_buff[i] = reg_val;
> > + }
> > +
> > + spin_lock(&priv->stat_lock);
>
> Maybe consider using scoped_guard() and similar for other places?
> Marginal win though so up to you.
Please trim the text when replying so just the needed context is
provided. It is easy to miss comments when you need to repeatedly page
down, page down, page down to find something.
> > + ret = register_netdev(netdev);
> > + if (ret) {
> > + dev_err(&spi->dev, "Failed to register netdev (%d)", ret);
>
> If we go to devm, this could be return dev_err_probe().
dev_err_probe() is not really about devm, but handling EPROBE_DEFFER,
and not issues an error message when it is not wanted. I don't think
register_netdev() can return EPROBE_DEFFER, so it probably does not
apply here.
Andrew
^ permalink raw reply
* Re: [PATCH v3] cgroup/dmem: introduce a peak file
From: Michal Koutný @ 2026-05-29 13:01 UTC (permalink / raw)
To: Maarten Lankhorst
Cc: Thadeu Lima de Souza Cascardo, Tejun Heo, Johannes Weiner,
Michal Hocko, Roman Gushchin, Shakeel Butt, Muchun Song,
Andrew Morton, Jonathan Corbet, Shuah Khan, Maxime Ripard,
Natalie Vock, Tvrtko Ursulin, cgroups, linux-kernel, linux-mm,
linux-doc, dri-devel, kernel-dev
In-Reply-To: <89901220-0a43-4668-9d20-aaecc72c58dd@lankhorst.se>
[-- Attachment #1: Type: text/plain, Size: 282 bytes --]
On Fri, May 29, 2026 at 09:34:28AM +0200, Maarten Lankhorst <dev@lankhorst.se> wrote:
> > Reviewed-by: Michal Koutný <mkoutny@suse.com>
> Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
>
> With your r-b it's ok to push it to the dmemcg tree?
Please go for it.
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] Documentation: networking: Add a test plan for ethtool pause validation
From: Andrew Lunn @ 2026-05-29 12:59 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni, Simon Horman,
Russell King, Heiner Kallweit, Jonathan Corbet, Shuah Khan,
Oleksij Rempel, Vladimir Oltean, Florian Fainelli,
thomas.petazzoni, netdev, linux-kernel, linux-doc
In-Reply-To: <adb69dee-2737-46ca-a92b-aae1ea7f5989@bootlin.com>
> I think that
>
> ethtool -s <iface> duplex half autoneg on
>
> should be enough, the link should still establish at 100M, I've tested
> that on a 1G/FULL 100MHalf+Full interface and this is the result we
> get :)
Nice.
But i still think the test should check the autoneg result and do
something sensible if the link does not come up. This probably applies
to all cases where we trigger auto neg.
> That said I've tested the following on mcbin, and it seems that acually
> nothing in the code currently deals with Half duplex / Pause interaction,
> and we don't get any EOPNOTSUPP.
>
> So the broader question is, should we reflect the current behaviour or
> an ideal one ?
What 802.3 says. If we come across cases where phylib/phylink is
broken, let me know, and i will fix it. But we will leave driver bugs
to individual driver developers.
But we also need to consider that for some APIs, we have decided that
a configuration can be set now, which does not actually apply in our
current conditions, but it will be stored away for when conditions
change and it is applicable. The half duplex case could fit that. When
the link is currently half duplex, you can configure pause, but you
don't expect it to actually change the current behaviour. It only
kicks in when the link renegotiates to full duplex sometime in the
future. We have to also consider this the other way around. The link
is full duplex and pause is configured by the user. Something happens
with the LP and the link renegotiates to half duplex. The local end
should not throw away the configuration, it simply cannot apply it
given the current situation.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] Documentation: networking: Add a test plan for ethtool pause validation
From: Andrew Lunn @ 2026-05-29 12:30 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni, Simon Horman,
Russell King, Heiner Kallweit, Jonathan Corbet, Shuah Khan,
Oleksij Rempel, Vladimir Oltean, Florian Fainelli,
thomas.petazzoni, netdev, linux-kernel, linux-doc
In-Reply-To: <452cb18a-29e7-4fc6-bf74-e9d67e7d4c70@bootlin.com>
> From what I get from Andrew and you, the test definitions is lacking in
> details w.r.t the start conditions, the return code handling as well.
>
> Having that in the doc is going to be too verbose, but in some python test
> that could really be great.
My experience with such documents is that they are verbose, very much
cut/paste repeated text, with just one parameter changed between test
variants, and a slight different expected result. And i personally
tend to make a lot of cut/paste errors :-(
Return code handling is also important, so i think it should be
stated. It is also potentially the most complex part of it. It happens
in all the corner cases which are going to get the least testing when
implementing the tests. They only really get exercised when the tests
are thrown at oddball hardware by developers trying to validate their
hardware.
There are also cases where the hardware reports it can do something,
and then returns EOPNOTSUPP when asked to do it, which is a bug. So
the tests becomes a sort of decision tree. The hardware reports it can
only do symmetric pause. We go down the branch that makes sure
symmetric pause passes, but asymmetric reports EOPNOTSUPP, etc.
There are a lot of combinations/permutations, and limited resources,
so it could be we cannot actually test everything. We might need to
accept EOPNOTSUPP at any stage as a pass, simply because we don't have
the resources to test all the corner cases.
I would normally actually concentrate on the corner cases, because
developers should have tested the happy path cases themselves.
However, for pause, we often see the happy path being very wrong, so
we should spend more time testing the happy path, and less on the
corner cases.
And that is probably true for all the testing we are doing at the
moment, because we are concentrating on subjects where developers
often get the basics wrong.
Andrew
^ permalink raw reply
* Re: [PATCH v4 1/2] rust: task: clarify comments on task UID accessors
From: Gary Guo @ 2026-05-29 12:17 UTC (permalink / raw)
To: Alice Ryhl, Paul Moore, Serge Hallyn, Jonathan Corbet,
Greg Kroah-Hartman, Shuah Khan, Alex Shi, Yanteng Si,
Dongliang Mu
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Jann Horn, linux-security-module, linux-doc, linux-kernel,
rust-for-linux
In-Reply-To: <20260529-remove-task-euid-v4-1-07cbdf3af980@google.com>
On Fri May 29, 2026 at 10:33 AM BST, Alice Ryhl wrote:
> From: Jann Horn <jannh@google.com>
>
> Linux has separate subjective and objective task credentials, see the
> comment above `struct cred`. Clarify which accessor functions operate on
> which set of credentials.
>
> Also document that Task::euid() is a very weird operation. You can see how
> weird it is by grepping for task_euid() - binder is its only user.
> Task::euid() obtains the objective effective UID - it looks at the
> credentials of the task for purposes of acting on it as an object, but then
> accesses the effective UID (which the credentials.7 man page describes as
> "[...] used by the kernel to determine the permissions that the process
> will have when accessing shared resources [...]").
>
> For context:
> Arguably, binder's use of task_euid() is a theoretical security problem,
> which only has no impact on Android because Android has no setuid binaries
> executable by apps.
> commit 29bc22ac5e5b ("binder: use euid from cred instead of using task")
> fixed that by removing that only user of task_euid(), but the fix got
> reverted in commit c21a80ca0684 ("binder: fix test regression due to
> sender_euid change") because some Android test started failing.
>
> Signed-off-by: Jann Horn <jannh@google.com>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Originally sent as:
> https://lore.kernel.org/r/20260212-rust-uid-v1-1-deff4214c766@google.com
> ---
> rust/kernel/task.rs | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Ritesh Harjani @ 2026-05-29 11:53 UTC (permalink / raw)
To: Amit Machhiwal
Cc: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan, Vaibhav Jain,
Anushree Mathur, Paolo Bonzini, Nicholas Piggin, Michael Ellerman,
Christophe Leroy (CS GROUP), Jonathan Corbet, Shuah Khan, kvm,
linux-kernel, linux-doc, lkp
In-Reply-To: <20260529141530.fc225a67-e9-amachhiw@linux.ibm.com>
Amit Machhiwal <amachhiw@linux.ibm.com> writes:
> So, we would still want to prioritize the whole series
> instead of just this one patch.
>
Patch-1 could go as a bug fix even in 7.1-rc6 (or maybe with 7.2
bug fixes). - Maddy?
So, you may want to add a fixes tag and maybe even cc stable if you are
seeing this issue from older kernels maybe when nestedv2 got introduced?
However the new UAPI discussion might still require more discussion with
the community and I don't think it is ready for 7.2 yet ;)
-ritesh
^ permalink raw reply
* Re: [PATCH v2] docs: gpu: todo: fix spelling of "fucntion"
From: Thomas Zimmermann @ 2026-05-29 11:50 UTC (permalink / raw)
To: Godswill Onwusilike, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Jonathan Corbet
Cc: Shuah Khan, dri-devel, linux-doc, linux-kernel
In-Reply-To: <20260528223715.26645-1-onwusilikegodswill@gmail.com>
Hi,
thanks. I merged this patch and the other doc fix you sent.
Best regards
Thomas
Am 29.05.26 um 00:37 schrieb Godswill Onwusilike:
> Correct the spelling of "fucntion" to "function" in
> Documentation/gpu/todo.rst.
>
> v2:
>
> Fix the actual typo instead of newline-only change
>
> Signed-off-by: Godswill Onwusilike <onwusilikegodswill@gmail.com>
> ---
> Documentation/gpu/todo.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index bc9f14c8a2ec..841e4e986c48 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -55,7 +55,7 @@ There are still drivers that use drm_simple_display_pipe. The task here is to
> convert them to use regular atomic helpers. Search for a driver that calls
> drm_simple_display_pipe_init() and inline all helpers from drm_simple_kms_helper.c
> into the driver, such that no simple-KMS interfaces are required. Please also
> -rename all inlined fucntions according to driver conventions.
> +rename all inlined functions according to driver conventions.
>
> Contact: Thomas Zimmermann, respective driver maintainer
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 00/11] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Loic Poulain @ 2026-05-29 11:43 UTC (permalink / raw)
To: jackbb_wu
Cc: Sergey Ryazanov, Johannes Berg, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Wen-Zhi Huang,
Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, linux-doc
In-Reply-To: <20260529-t9xx_driver_v1-v1-0-bdbfe2c01e57@compal.com>
Hi Jack,
On Fri, May 29, 2026 at 12:31 PM Jack Wu via B4 Relay
<devnull+jackbb_wu.compal.com@kernel.org> wrote:
>
> T9XX is the PCIe host device driver for MediaTek's
> t900 modem. The driver uses the WWAN framework
> infrastructure to create the following control ports
> and network interfaces for data transactions.
> * /dev/wwan0at0 - Interface that supports AT commands.
> * /dev/wwan0mbim0 - Interface conforming to the MBIM
> protocol.
> * wwan0-X - Primary network interface for IP traffic.
>
> The main blocks in the T9XX driver are:
> * HW layer - Abstracts the hardware bus operations for
> the device, and provides generic interfaces for the
> transaction layer to get the device's information and
> control the device's behavior. It includes:
>
> * PCIe - Implements probe, removal and interrupt
> handling.
> * MHCCIF (Modem Host Cross-Core Interface) - Provides
> interrupt channels for bidirectional event
> notification such as handshake and port enumeration.
>
> * Transaction layer - Implements data transactions for
> the control plane and the data plane. It includes:
>
> * DPMAIF (Data Plane Modem AP Interface) - Controls
> the hardware that provides uplink and downlink
> queues for the data path. The data exchange takes
> place using circular buffers to share data buffer
> addresses and metadata to describe the packets.
> * CLDMA (Cross Layer DMA) - Manages the hardware
> used by the port layer to send control messages to
> the device using MediaTek's CCCI (Cross-Core
> Communication Interface) protocol.
> * TX Services - Dispatch packets from the port layer
> to the device.
> * RX Services - Dispatch packets to the port layer
> when receiving packets from the device.
>
> * Port layer - Provides control plane and data plane
> interfaces to userspace. It includes:
>
> * Control Plane - Provides device node interfaces
> for controlling data transactions.
> * Data Plane - Provides network link interfaces
> wwanX (0, 1, 2...) for IP data transactions.
>
> * Core logic - Contains the core logic to keep the
> device working. It includes:
>
> * FSM (Finite State Machine) - Monitors the state
> of the device, and notifies each module when the
> state changes.
>
> The compilation of the T9XX driver is enabled by the
> CONFIG_MTK_T9XX and CONFIG_MTK_T9XX_PCI config option
> which depends on CONFIG_WWAN.
Can you specify which userspace counterpart you need (e.g., a
ModemManager version or a link to the relevant patch series)?
>
> ---
> Jack Wu (11):
> net: wwan: t9xx: Add PCIe core
> net: wwan: t9xx: Add control plane transaction layer
> net: wwan: t9xx: Add control DMA interface
> net: wwan: t9xx: Add control port
> net: wwan: t9xx: Add FSM thread
> net: wwan: t9xx: Add AT & MBIM WWAN ports
> net: wwan: t9xx: Introduce data plane hardware
> net: wwan: t9xx: Add data plane transaction layer
> net: wwan: t9xx: Introduce WWAN interface
> net: wwan: t9xx: Add power management support
> net: wwan: t9xx: Add maintainers and documentation
>
> .../networking/device_drivers/wwan/t9xx.rst | 48 +
> MAINTAINERS | 10 +
> drivers/net/wwan/Kconfig | 17 +
> drivers/net/wwan/Makefile | 1 +
> drivers/net/wwan/t9xx/Makefile | 16 +
> drivers/net/wwan/t9xx/mtk_ctrl_plane.c | 95 +
> drivers/net/wwan/t9xx/mtk_ctrl_plane.h | 88 +
> drivers/net/wwan/t9xx/mtk_data_plane.c | 104 +
> drivers/net/wwan/t9xx/mtk_data_plane.h | 105 +
> drivers/net/wwan/t9xx/mtk_dev.c | 55 +
> drivers/net/wwan/t9xx/mtk_dev.h | 114 +
> drivers/net/wwan/t9xx/mtk_fsm.c | 931 +++++++
> drivers/net/wwan/t9xx/mtk_fsm.h | 140 +
> drivers/net/wwan/t9xx/mtk_port.c | 967 +++++++
> drivers/net/wwan/t9xx/mtk_port.h | 176 ++
> drivers/net/wwan/t9xx/mtk_port_io.c | 576 +++++
> drivers/net/wwan/t9xx/mtk_port_io.h | 41 +
> drivers/net/wwan/t9xx/mtk_utility.h | 33 +
> drivers/net/wwan/t9xx/mtk_wwan.c | 475 ++++
> drivers/net/wwan/t9xx/mtk_wwan.h | 17 +
> drivers/net/wwan/t9xx/pcie/Makefile | 19 +
> drivers/net/wwan/t9xx/pcie/mtk_cldma.c | 1527 +++++++++++
> drivers/net/wwan/t9xx/pcie/mtk_cldma.h | 176 ++
> drivers/net/wwan/t9xx/pcie/mtk_cldma_drv.c | 373 +++
> drivers/net/wwan/t9xx/pcie/mtk_cldma_drv.h | 174 ++
> drivers/net/wwan/t9xx/pcie/mtk_cldma_drv_m9xx.c | 177 ++
> drivers/net/wwan/t9xx/pcie/mtk_cldma_drv_m9xx.h | 101 +
> drivers/net/wwan/t9xx/pcie/mtk_ctrl_cfg_m9xx.c | 55 +
> drivers/net/wwan/t9xx/pcie/mtk_dpmaif.c | 2714 ++++++++++++++++++++
> drivers/net/wwan/t9xx/pcie/mtk_dpmaif.h | 16 +
> drivers/net/wwan/t9xx/pcie/mtk_dpmaif_drv.c | 1586 ++++++++++++
> drivers/net/wwan/t9xx/pcie/mtk_dpmaif_drv.h | 268 ++
> drivers/net/wwan/t9xx/pcie/mtk_dpmaif_drv_m9xx.c | 687 +++++
> drivers/net/wwan/t9xx/pcie/mtk_dpmaif_reg.h | 387 +++
> drivers/net/wwan/t9xx/pcie/mtk_dpmaif_reg_m9xx.h | 37 +
> drivers/net/wwan/t9xx/pcie/mtk_dpmaif_ring.c | 168 ++
> drivers/net/wwan/t9xx/pcie/mtk_dpmaif_ring.h | 161 ++
> drivers/net/wwan/t9xx/pcie/mtk_pci.c | 1067 ++++++++
> drivers/net/wwan/t9xx/pcie/mtk_pci.h | 219 ++
> drivers/net/wwan/t9xx/pcie/mtk_pci_drv_m9xx.c | 70 +
> drivers/net/wwan/t9xx/pcie/mtk_pci_reg.h | 72 +
> drivers/net/wwan/t9xx/pcie/mtk_trans_ctrl.c | 593 +++++
> drivers/net/wwan/t9xx/pcie/mtk_trans_ctrl.h | 105 +
> 43 files changed, 14761 insertions(+)
> ---
> base-commit: eb3f4b7426cfd2b79d65b7d37155480b32259a11
> change-id: 20260529-t9xx_driver_v1-1744f8af7739
>
> Best regards,
> --
> Jack Wu <jackbb_wu@compal.com>
>
>
^ permalink raw reply
* Re: [PATCH] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: Dongliang Mu @ 2026-05-29 11:33 UTC (permalink / raw)
To: 葉宸佑
Cc: Hu Haowen, Jonathan Corbet, Shuah Khan, linux-doc, linux-kernel,
慕冬亮
In-Reply-To: <CAKspUh+5h+MeMVEEGy4Oc+HJteaTE1Ft1XXhDPJEmL-218T4Jg@mail.gmail.com>
On Fri, May 29, 2026 at 7:26 PM 葉宸佑 <chenyou910331@gmail.com> wrote:
>
> Hi Dongliang,
>
> Thank you for reviewing this patch and for your careful observation!
>
> You raised a very valid point. In PRC terminology, "內核" (Kernel) and
> "核心" (Core) are distinctly separated. However, in Taiwan's official
> tech terminology (e.g., by the National Academy for Educational
> Research) and local academic/industry usage, "Kernel" is universally
> translated as "核心" (e.g., Linux Kernel -> Linux 核心, Kernel space ->
> 核心空間).
>
> It is true that "Core" is also translated as "核心" in Taiwan, which
> creates a lexical overlap. However, Taiwanese developers are entirely
> used to relying on the context to differentiate them. In the context
> of operating systems and Linux documentation, local developers will
> natively map "核心 API" to "Kernel API" without any confusion.
>
> If you feel it might still be too ambiguous, another common practice
> in Taiwan is to simply keep the English word for technical precision.
> We could change it to "Linux 核心 API" or just leave it as "kernel API".
>
> For local developers, the current translation "核心 API" is perfectly
> natural, but I am happy to send a v2 patch to adjust this specific
> phrase if you prefer. Please let me know your thoughts!
If local developers have no problem with this part, I am fine too.
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
>
> Best regards,
> Chen You
>
>
> Dongliang Mu <mudongliangabcd@gmail.com> 於 2026年5月29日週五 下午12:34寫道：
> >
> > On Thu, May 28, 2026 at 12:14 PM CHEN-YOU-0331 <chenyou910331@gmail.com> wrote:
> > >
> > > Translate PRC tech terms into Taiwanese tech terms (e.g.,
> > > 內核 -> 核心, 代碼 -> 程式碼, 軟件 -> 軟體) to improve
> > > readability for local developers. Also, rephrase several
> > > awkward sentences to make the document more fluent.
> >
> > I am not very familiar with Taiwanese tech terms. After checking with
> > LLMs, I am almost fine with these term changes, except one place.
> >
> > >
> > > Signed-off-by: CHEN-YOU-0331 <chenyou910331@gmail.com>
> > > ---
> > > .../zh_TW/process/8.Conclusion.rst | 45 +++++++++----------
> > > 1 file changed, 22 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/Documentation/translations/zh_TW/process/8.Conclusion.rst b/Documentation/translations/zh_TW/process/8.Conclusion.rst
> > > index d1634421b62c..823969cf793d 100644
> > > --- a/Documentation/translations/zh_TW/process/8.Conclusion.rst
> > > +++ b/Documentation/translations/zh_TW/process/8.Conclusion.rst
> > > @@ -14,42 +14,41 @@
> > >
> > > .. _tw_development_conclusion:
> > >
> > > -更多信息
> > > +更多資訊
> > > ========
> > >
> > > -關於Linux內核開發和相關主題的信息來源很多。首先是在內核源代碼分發中找到的
> > > -文檔目錄。頂級
> > > +關於Linux核心開發和相關主題的資訊來源很多。首先是在核心原始碼分發中找到的
> > > +文件目錄。頂級
> > > :ref:`Documentation/translations/zh_CN/process/howto.rst <tw_process_howto>`
> > > 文件是一個重要的起點；
> > > :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
> > > -也是所有內核開發人員都應該閱讀的內容。許多內部內核API都是使用kerneldoc機制
> > > -記錄的；“make htmldocs”或“make pdfdocs”可用於以HTML或PDF格式生成這些文檔
> > > -（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文檔）。
> > > -
> > > -不同的網站在各個細節層次上討論內核開發。本文作者想謙虛地建議用 https://lwn.net/
> > > -作爲來源；有關許多特定內核主題的信息可以通過以下網址的 LWN 內核索引找到：
> > > +也是所有核心開發人員都應該閱讀的內容。許多內部核心API都是使用kerneldoc機制
> >
> > "核心API" may cause confusion to me, which means "core API" other than
> > "kernel API".
> >
> > Dongliang Mu
> >
> > > +記錄的；“make htmldocs”或“make pdfdocs”可用於以HTML或PDF格式生成這些文件
> > > +（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文件）。
> > >
> > > +不同的網站在各個細節層次上討論核心開發。本文作者想謙虛地建議用 https://lwn.net/
> > > +作爲來源；有關許多特定核心主題的資訊可以通過以下網址的 LWN 核心索引找到:
> > > http://lwn.net/kernel/index/
> > >
> > > -除此之外，內核開發人員的一個寶貴資源是：
> > > +除此之外，核心開發人員的一個寶貴資源是：
> > >
> > > https://kernelnewbies.org/
> > >
> > > -當然，也不應該忘記 https://kernel.org/ ，這是內核發佈信息的最終位置。
> > > +當然，也不應該忘記 https://kernel.org/ ，這是核心發佈資訊的最終位置。
> > >
> > > -關於內核開發有很多書：
> > > +關於核心開發有很多書：
> > >
> > > 《Linux設備驅動程序》第三版（Jonathan Corbet、Alessandro Rubini和Greg Kroah Hartman）
> > > 線上版本在 http://lwn.net/kernel/ldd3/
> > >
> > > - 《Linux內核設計與實現》（Robert Love）
> > > + 《Linux核心設計與實現》（Robert Love）
> > >
> > > - 《深入理解Linux內核》(Daniel Bovet和Marco Cesati）
> > > + 《深入理解Linux核心》(Daniel Bovet和Marco Cesati）
> > >
> > > 然而，所有這些書都有一個共同的缺點：它們上架時就往往有些過時，而且已經上架
> > > -一段時間了。不過，在那裏還是可以找到相當多的好信息。
> > > +一段時間了。不過，在那裏還是可以找到相當多的好資訊。
> > >
> > > -有關git的文檔，請訪問：
> > > +有關git的文件，請訪問：
> > >
> > > https://www.kernel.org/pub/software/scm/git/docs/
> > >
> > > @@ -58,16 +57,16 @@
> > > 結論
> > > ====
> > >
> > > -祝賀所有通過這篇冗長的文檔的人。希望它能夠幫助您理解Linux內核是如何開發的，
> > > +祝賀所有通過這篇冗長的文件的人。希望它能夠幫助您理解Linux核心是如何開發的，
> > > 以及您如何參與這個過程。
> > >
> > > -最後，重要的是參與。任何開源軟件項目都不會超過其貢獻者投入其中的總和。Linux
> > > -內核的發展速度和以前一樣快，因爲它得到了大量開發人員的幫助，他們都在努力使它
> > > -變得更好。內核是一個最成功的例子，說明了當成千上萬的人爲了一個共同的目標一起
> > > +最後，重要的是參與。任何開源軟體專案都不會超過其貢獻者投入其中的總和。Linux
> > > +核心的發展速度和以前一樣快，因爲它得到了大量開發人員的幫助，他們都在努力使它
> > > +變得更好。核心是一個最成功的例子，說明了當成千上萬的人爲了一個共同的目標一起
> > > 工作時，可以做出什麼。
> > >
> > > -不過，內核總是可以從更大的開發人員基礎中獲益。總有更多的工作要做。但是同樣
> > > -重要的是，Linux生態系統中的大多數其他參與者可以通過爲內核做出貢獻而受益。使
> > > -代碼進入主線是提高代碼質量、降低維護和分發成本、提高對內核開發方向的影響程度
> > > +不過，核心總是可以從更大的開發人員基礎中獲益。總有更多的工作要做。但是同樣
> > > +重要的是，Linux生態系統中的大多數其他參與者可以通過爲核心做出貢獻而受益。使
> > > +程式碼進入主線是提高程式碼品質、降低維護和分發成本、提高對核心開發方向的影響程度
> > > 等的關鍵。這是一種共贏的局面。啓動你的編輯器，來加入我們吧；你會非常受歡迎的。
> > >
> > > --
> > > 2.43.0
> > >
> > >
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox