* Re: [PATCH v5 00/13] ima: Introduce staging mechanism
From: Lakshmi Ramasubramanian @ 2026-05-15 17:37 UTC (permalink / raw)
To: Roberto Sassu, steven chen, corbet, skhan, zohar, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, Roberto Sassu
In-Reply-To: <2302296a13b847960dbdbab3cf5518b275938838.camel@huaweicloud.com>
Thanks for the response Roberto.
On 5/12/2026 1:17 AM, Roberto Sassu wrote:
>>>
>>> This submission proposes two ways for log trimming:
>>>
>>> *Flavor 1:* Staging With Prompt
>>> *Flavor 2:* Stage and Delete N
>>>
>
> I'm happy to support your trimming method. Just does not fit with my
> use case. I would like to keep both.
>
If "Flavor 1: Staging With Prompt" would be beneficial to the Linux
kernel customers, in general, we should continue to review the change
and merge it eventually.
My request, then, would be to split this patch set into 2 parts:
Part 1: Implements "Staging With Prompt"
Part 2: Implements "Stage and Delete N"
I think that would make it easier for reviewing the code, test\validate,
and merge.
Thanks,
-lakshmi
^ permalink raw reply
* Re: (subset) [PATCH v3 00/28] vfs/nfsd: add support for CB_NOTIFY callbacks in directory delegations
From: Christian Brauner @ 2026-05-15 17:26 UTC (permalink / raw)
To: Jeff Layton, Chuck Lever
Cc: Christian Brauner, Alexander Viro, Jan Kara, Alexander Aring,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, NeilBrown, Olga Kornievskaia,
Dai Ngo, Tom Talpey, Trond Myklebust, Anna Schumaker,
Amir Goldstein, Calum Mackay, linux-fsdevel, linux-kernel,
linux-trace-kernel, linux-doc, linux-nfs
In-Reply-To: <20260428-dir-deleg-v3-0-5a0780ba9def@kernel.org>
On Tue, 28 Apr 2026 08:09:44 +0100, Jeff Layton wrote:
> Re-posting the set per Christian's request. The only difference in this
> version is a small error handling fix in alloc_init_dir_deleg(). The old
> version could crash since release_pages() can't handle an array with
> NULL pointers in it.
>
> ---------------------------------8<------------------------------------
>
> [...]
@Chuck, @Jeff, I've only merged the vfs specific changes into a stable branch.
You can pull it I won't touch it again. You can pull the nfsd work in in
whatever form you like. Same procedure I use with io_uring et al.
Let me know if that work for you.
---
Applied to the vfs-7.2.directory.delegations branch of the vfs/vfs.git tree.
Patches in the vfs-7.2.directory.delegations branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-7.2.directory.delegations
[01/28] filelock: pass current blocking lease to trace_break_lease_block() rather than "new_fl"
https://git.kernel.org/vfs/vfs/c/89330d3a60f7
[02/28] filelock: add support for ignoring deleg breaks for dir change events
https://git.kernel.org/vfs/vfs/c/24cbf43337f4
[03/28] filelock: add a tracepoint to start of break_lease()
https://git.kernel.org/vfs/vfs/c/e39026a86b48
[04/28] filelock: add an inode_lease_ignore_mask helper
https://git.kernel.org/vfs/vfs/c/95825fdcc0b0
[05/28] fsnotify: new tracepoint in fsnotify()
https://git.kernel.org/vfs/vfs/c/ad4489dcd08d
[06/28] fsnotify: add fsnotify_modify_mark_mask()
https://git.kernel.org/vfs/vfs/c/12ffbb117b64
[07/28] fsnotify: add FSNOTIFY_EVENT_RENAME data type
https://git.kernel.org/vfs/vfs/c/010043003c0c
^ permalink raw reply
* [PATCH 2/2] module: restrict autoload to CAP_SYS_ADMIN if CONFIG_MODULE_RESTRICT_AUTOLOAD
From: Michal Gorlas @ 2026-05-15 17:20 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin
Cc: linux-doc, linux-kernel, linux-modules, Michal Gorlas
In-Reply-To: <20260515-autoload_restrict-v1-0-40b7c03ddd04@9elements.com>
Restrict module auto-loading to CAP_SYS_ADMIN if
CONFIG_MODULE_RESTRICT_AUTOLOAD is enabled, cmdline parameter
modrestrict=true, or kernel.modrestrict=1 is set with sysctl.
Signed-off-by: Michal Gorlas <michal.gorlas@9elements.com>
---
kernel/module/internal.h | 1 +
kernel/module/kmod.c | 5 +++++
kernel/module/main.c | 11 +++++++++++
3 files changed, 17 insertions(+)
diff --git a/kernel/module/internal.h b/kernel/module/internal.h
index 061161cc79d9..496d8703f0c6 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -46,6 +46,7 @@ struct kernel_symbol {
extern struct mutex module_mutex;
extern struct list_head modules;
+extern bool module_autoload_restrict;
extern const struct module_attribute *const modinfo_attrs[];
extern const size_t modinfo_attrs_count;
diff --git a/kernel/module/kmod.c b/kernel/module/kmod.c
index a25dccdf7aa7..58b28c23f571 100644
--- a/kernel/module/kmod.c
+++ b/kernel/module/kmod.c
@@ -156,6 +156,11 @@ int __request_module(bool wait, const char *fmt, ...)
if (ret)
return ret;
+ if (module_autoload_restrict && !capable(CAP_SYS_ADMIN)) {
+ pr_alert("denied attempt to auto-load module %s\n", module_name);
+ return -EPERM;
+ }
+
ret = down_timeout(&kmod_concurrent_max, MAX_KMOD_ALL_BUSY_TIMEOUT * HZ);
if (ret) {
pr_warn_ratelimited("request_module: modprobe %s cannot be processed, kmod busy with %d threads for more than %d seconds now",
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 46dd8d25a605..a293b75ce9b7 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -130,6 +130,10 @@ static void mod_update_bounds(struct module *mod)
static int modules_disabled;
core_param(nomodule, modules_disabled, bint, 0);
+/* Restrict auto-loading? */
+bool module_autoload_restrict = IS_ENABLED(CONFIG_MODULE_RESTRICT_AUTOLOAD);
+core_param(modrestrict, module_autoload_restrict, bool, 0);
+
static const struct ctl_table module_sysctl_table[] = {
{
.procname = "modprobe",
@@ -148,6 +152,13 @@ static const struct ctl_table module_sysctl_table[] = {
.extra1 = SYSCTL_ONE,
.extra2 = SYSCTL_ONE,
},
+ {
+ .procname = "modrestrict",
+ .data = &module_autoload_restrict,
+ .maxlen = sizeof(bool),
+ .mode = 0644,
+ .proc_handler = proc_dobool,
+ },
};
static int __init init_module_sysctl(void)
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] module: add CONFIG_MODULE_RESTRICT_AUTOLOAD
From: Michal Gorlas @ 2026-05-15 17:20 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin
Cc: linux-doc, linux-kernel, linux-modules, Michal Gorlas
In-Reply-To: <20260515-autoload_restrict-v1-0-40b7c03ddd04@9elements.com>
Add CONFIG_MODULE_RESTRICT_AUTOLOAD and modrestrict parameter
documentation.
Signed-off-by: Michal Gorlas <michal.gorlas@9elements.com>
---
Documentation/admin-guide/kernel-parameters.txt | 5 +++++
kernel/module/Kconfig | 15 +++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 03a550630644..1013104f0943 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4185,6 +4185,11 @@ Kernel parameters
For details see:
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
+ modrestrict=<bool>
+ Control the restriction of module auto-loading to
+ CAP_SYS_ADMIN. If no <bool> value is specified, this
+ is set to the value of CONFIG_MODULE_RESTRICT_AUTOLOAD.
+
<module>.async_probe[=<bool>] [KNL]
If no <bool> value is specified or if the value
specified is not a valid <bool>, enable asynchronous
diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
index 43b1bb01fd27..c9e01bb848c0 100644
--- a/kernel/module/Kconfig
+++ b/kernel/module/Kconfig
@@ -337,6 +337,21 @@ config MODULE_SIG_HASH
endif # MODULE_SIG || IMA_APPRAISE_MODSIG
+config MODULE_RESTRICT_AUTOLOAD
+ bool "Restrict module auto-loading to privileged users"
+ default n
+ help
+ Restrict module auto-loading in response to use of some feature
+ implemented by an unloaded module to CAP_SYS_ADMIN. Enabling this
+ option helps reducing the attack surface where unprivileged users
+ can abuse auto-loading to cause a vulnerable module to load that is
+ then exploited.
+
+ Note that this option also prevents a benign use of auto-loading for
+ a non-root users. Thus if enabled, the root user should execute
+ modprobe manually if needed, or add the module to the list of modules
+ loaded at the boot by modifying init scripts.
+
config MODULE_COMPRESS
bool "Module compression"
help
--
2.54.0
^ permalink raw reply related
* [PATCH 0/2] module: restrict module auto-loading to privileged users
From: Michal Gorlas @ 2026-05-15 17:20 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin
Cc: linux-doc, linux-kernel, linux-modules, Michal Gorlas
Add option to restrict the module auto-loading to CAP_SYS_ADMIN.
This is heavily inspired by CONFIG_GRKERNSEC_MODHARDEN of the latest
available Grsecurity patches [1]. Instead of checking whether the
callers' UID is 0, check whether the calling process has CAP_SYS_ADMIN.
The reasoning here is that many modules are autoloaded by systemd
services which are running as privileged users, but do not have UID 0.
While systemd-udevd runs as root, systemd-network (which often
auto-loads a module) for example runs as system user (UID range 6 to
999).
When enabled, reduces attack surface where unprivileged users can trigger
vulnerable module to be auto-loaded, to then exploit it. Recent LPEs
(CopyFail [3], DirtyFrag [4]) for example, would have been mitigated
with this option enabled as long as the vulnerable modules are not built-in
(or already loaded at the point of running the exploit).
[1] - https://github.com/minipli/linux-unofficial_grsec/blob/linux-4.9.x-unofficial_grsec/kernel/kmod.c#L153
[2] - https://systemd.io/UIDS-GIDS/
[3] - https://github.com/theori-io/copy-fail-CVE-2026-31431
[4] - https://github.com/V4bel/dirtyfrag
Signed-off-by: Michal Gorlas <michal.gorlas@9elements.com>
---
Michal Gorlas (2):
module: add CONFIG_MODULE_RESTRICT_AUTOLOAD
module: restrict autoload to CAP_SYS_ADMIN if CONFIG_MODULE_RESTRICT_AUTOLOAD
Documentation/admin-guide/kernel-parameters.txt | 5 +++++
kernel/module/Kconfig | 15 +++++++++++++++
kernel/module/internal.h | 1 +
kernel/module/kmod.c | 5 +++++
kernel/module/main.c | 11 +++++++++++
5 files changed, 37 insertions(+)
---
base-commit: 663385f9155f27892a97a5824006f806a32eb8dc
change-id: 20260515-autoload_restrict-cfa6727c4d72
Best regards,
--
Michal Gorlas <michal.gorlas@9elements.com>
^ permalink raw reply
* Re: [PATCH v6 02/11] dt-bindings: extcon: document Samsung S2M series PMIC extcon device
From: Conor Dooley @ 2026-05-15 17:15 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński, linux-leds, devicetree,
linux-kernel, linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260515-s2mu005-pmic-v6-2-1979106992d4@disroot.org>
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
On Fri, May 15, 2026 at 04:08:58PM +0530, Kaustabh Chakraborty wrote:
> Certain Samsung S2M series PMICs have a MUIC device which reports
> various cable states by measuring the ID-GND resistance with an internal
> ADC. Document the devicetree schema for this device.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: mfd: add documentation for S2MU005 PMIC
From: Conor Dooley @ 2026-05-15 17:14 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński, linux-leds, devicetree,
linux-kernel, linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260515-s2mu005-pmic-v6-3-1979106992d4@disroot.org>
[-- Attachment #1: Type: text/plain, Size: 4515 bytes --]
On Fri, May 15, 2026 at 04:08:59PM +0530, Kaustabh Chakraborty wrote:
> Samsung's S2MU005 PMIC includes subdevices for a charger, an MUIC (Micro
> USB Interface Controller), and flash and RGB LED controllers.
>
> Add the compatible and documentation for the S2MU005 PMIC. Also, add an
> example for nodes for supported sub-devices, i.e. MUIC, flash LEDs, and
> RGB LEDs. Charger sub-device uses the node of the parent.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> .../bindings/mfd/samsung,s2mu005-pmic.yaml | 120 +++++++++++++++++++++
> 1 file changed, 120 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml
> new file mode 100644
> index 0000000000000..0e6afb7d2017b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml
> @@ -0,0 +1,120 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/samsung,s2mu005-pmic.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung S2MU005 Power Management IC
> +
> +maintainers:
> + - Kaustabh Chakraborty <kauschluss@disroot.org>
> +
> +description: |
> + The S2MU005 is a companion power management IC which includes subdevices for
> + a charger controller, an MUIC (Micro USB Interface Controller), and flash and
> + RGB LED controllers.
> +
> +allOf:
> + - $ref: /schemas/power/supply/power-supply.yaml#
> +
> +properties:
> + compatible:
> + const: samsung,s2mu005-pmic
> +
> + flash:
> + $ref: /schemas/leds/samsung,s2mu005-flash.yaml
> + description:
> + Child node describing flash LEDs.
> +
> + interrupts:
> + maxItems: 1
> +
> + muic:
> + $ref: /schemas/extcon/samsung,s2mu005-muic.yaml#
> + description:
> + Child node describing MUIC device.
> +
> + multi-led:
> + type: object
> +
> + allOf:
> + - $ref: /schemas/leds/leds-class-multicolor.yaml#
Does this need to be an allOf when the other refs are not?
> +
> + properties:
> + compatible:
> + const: samsung,s2mu005-rgb
> +
> + required:
> + - compatible
> +
> + unevaluatedProperties: false
> +
> + reg:
> + maxItems: 1
Move this above the child nodes please.
Otherwise, I think this looks good.
pw-bot: changes-requested
Thanks,
Conor.
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/leds/common.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pmic@3d {
> + compatible = "samsung,s2mu005-pmic";
> + reg = <0x3d>;
> + interrupt-parent = <&gpa2>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> +
> + monitored-battery = <&battery>;
> +
> + flash {
> + compatible = "samsung,s2mu005-flash";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led@0 {
> + reg = <0>;
> + color = <LED_COLOR_ID_WHITE>;
> + function = LED_FUNCTION_FLASH;
> + };
> +
> + led@1 {
> + reg = <1>;
> + color = <LED_COLOR_ID_WHITE>;
> + function = LED_FUNCTION_FLASH;
> + function-enumerator = <1>;
> + };
> + };
> +
> + muic {
> + compatible = "samsung,s2mu005-muic";
> +
> + connector {
> + compatible = "usb-b-connector";
> + label = "micro-USB";
> + type = "micro";
> + };
> +
> + port {
> + muic_to_usb: endpoint {
> + remote-endpoint = <&usb_to_muic>;
> + };
> + };
> + };
> +
> + multi-led {
> + compatible = "samsung,s2mu005-rgb";
> + color = <LED_COLOR_ID_RGB>;
> + function = LED_FUNCTION_INDICATOR;
> + linux,default-trigger = "pattern";
> + };
> + };
> + };
>
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 2/5] dma-heap: charge dma-buf memory via explicit memcg
From: T.J. Mercier @ 2026-05-15 17:06 UTC (permalink / raw)
To: Christian Brauner
Cc: Albert Esteve, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Sumit Semwal, Christian König,
Michal Hocko, Roman Gushchin, Shakeel Butt, Muchun Song,
Andrew Morton, Benjamin Gaignard, Brian Starkey, John Stultz,
Paul Moore, James Morris, Serge E. Hallyn, Stephen Smalley,
Ondrej Mosnacek, Shuah Khan, cgroups, linux-doc, linux-kernel,
linux-media, dri-devel, linaro-mm-sig, linux-mm,
linux-security-module, selinux, linux-kselftest, mripard,
echanude
In-Reply-To: <20260515-hinschauen-effizient-9e3a05a94f2e@brauner>
On Fri, May 15, 2026 at 6:53 AM Christian Brauner <brauner@kernel.org> wrote:
>
> On Tue, May 12, 2026 at 11:10:44AM +0200, Albert Esteve wrote:
> > On embedded platforms a central process often allocates dma-buf
> > memory on behalf of client applications. Without a way to
> > attribute the charge to the requesting client's cgroup, the
> > cost lands on the allocator, making per-cgroup memory limits
> > ineffective for the actual consumers.
> >
> > Add charge_pid_fd to struct dma_heap_allocation_data. When set to
>
> Please be aware that pidfds come in two flavors:
>
> thread-group pidfds and thread-specific pidfds. Make sure that your API
> doesn't implicitly depend on this distinction not existing.
Hi Christian,
Memcg is not a controller that supports "thread mode" so all threads
in a group should belong to the same memcg.
Checking the flags from pidfd_get_pid would be the best way for an
explicit check of the pidfd type?
> > a valid pidfd, DMA_HEAP_IOCTL_ALLOC resolves the target task's
> > memcg and charges the buffer there via mem_cgroup_charge_dmabuf()
> > inside dma_heap_buffer_alloc(). Without charge_pid_fd, and with
> > the mem_accounting module parameter enabled, the buffer is charged
> > to the allocator's own cgroup.
> >
> > Additionally, commit 3c227be90659 ("dma-buf: system_heap: account for
> > system heap allocation in memcg") adds __GFP_ACCOUNT to system-heap
> > page allocations. Keeping __GFP_ACCOUNT would charge the same pages
> > twice (once to kmem, once to MEMCG_DMABUF), thus remove it and route
> > all accounting through a single MEMCG_DMABUF path.
> >
> > Usage examples:
> >
> > 1. Central allocator charging to a client at allocation time.
> > The allocator knows the client's PID (e.g., from binder's
> > sender_pid) and uses pidfd to attribute the charge:
> >
> > pid_t client_pid = txn->sender_pid;
> > int pidfd = pidfd_open(client_pid, 0);
> >
> > struct dma_heap_allocation_data alloc = {
> > .len = buffer_size,
> > .fd_flags = O_RDWR | O_CLOEXEC,
> > .charge_pid_fd = pidfd,
> > };
> > ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, &alloc);
> > close(pidfd);
> > /* alloc.fd is now charged to client's cgroup */
> >
> > 2. Default allocation (no pidfd, mem_accounting=1).
> > When charge_pid_fd is not set and the mem_accounting module
> > parameter is enabled, the buffer is charged to the allocator's
> > own cgroup:
> >
> > struct dma_heap_allocation_data alloc = {
> > .len = buffer_size,
> > .fd_flags = O_RDWR | O_CLOEXEC,
> > };
> > ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, &alloc);
> > /* charged to current process's cgroup */
> >
> > Current limitations:
> >
> > - Single-owner model: a dma-buf carries one memcg charge regardless of
> > how many processes share it. Means only the first owner (and exporter)
> > of the shared buffer bears the charge.
> > - Only memcg accounting supported. While this makes sense for system
> > heap buffers, other heaps (e.g., CMA heaps) will require selectively
> > charging also for the dmem controller.
> >
> > Signed-off-by: Albert Esteve <aesteve@redhat.com>
> > ---
> > Documentation/admin-guide/cgroup-v2.rst | 5 ++--
> > drivers/dma-buf/dma-buf.c | 16 ++++---------
> > drivers/dma-buf/dma-heap.c | 42 ++++++++++++++++++++++++++++++---
> > drivers/dma-buf/heaps/system_heap.c | 2 --
> > include/uapi/linux/dma-heap.h | 6 +++++
> > 5 files changed, 53 insertions(+), 18 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> > index 8bdbc2e866430..824d269531eb1 100644
> > --- a/Documentation/admin-guide/cgroup-v2.rst
> > +++ b/Documentation/admin-guide/cgroup-v2.rst
> > @@ -1636,8 +1636,9 @@ The following nested keys are defined.
> > structures.
> >
> > dmabuf (npn)
> > - Amount of memory used for exported DMA buffers allocated by the cgroup.
> > - Stays with the allocating cgroup regardless of how the buffer is shared.
> > + Amount of memory used for exported DMA buffers allocated by or on
> > + behalf of the cgroup. Stays with the allocating cgroup regardless
> > + of how the buffer is shared.
> >
> > workingset_refault_anon
> > Number of refaults of previously evicted anonymous pages.
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index ce02377f48908..23fb758b78297 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -181,8 +181,11 @@ static void dma_buf_release(struct dentry *dentry)
> > */
> > BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
> >
> > - mem_cgroup_uncharge_dmabuf(dmabuf->memcg, PAGE_ALIGN(dmabuf->size) / PAGE_SIZE);
> > - mem_cgroup_put(dmabuf->memcg);
> > + if (dmabuf->memcg) {
> > + mem_cgroup_uncharge_dmabuf(dmabuf->memcg,
> > + PAGE_ALIGN(dmabuf->size) / PAGE_SIZE);
> > + mem_cgroup_put(dmabuf->memcg);
> > + }
> >
> > dmabuf->ops->release(dmabuf);
> >
> > @@ -764,13 +767,6 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
> > dmabuf->resv = resv;
> > }
> >
> > - dmabuf->memcg = get_mem_cgroup_from_mm(current->mm);
> > - if (!mem_cgroup_charge_dmabuf(dmabuf->memcg, PAGE_ALIGN(dmabuf->size) / PAGE_SIZE,
> > - GFP_KERNEL)) {
> > - ret = -ENOMEM;
> > - goto err_memcg;
> > - }
> > -
> > file->private_data = dmabuf;
> > file->f_path.dentry->d_fsdata = dmabuf;
> > dmabuf->file = file;
> > @@ -781,8 +777,6 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
> >
> > return dmabuf;
> >
> > -err_memcg:
> > - mem_cgroup_put(dmabuf->memcg);
> > err_file:
> > fput(file);
> > err_module:
> > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> > index ac5f8685a6494..ff6e259afcdc0 100644
> > --- a/drivers/dma-buf/dma-heap.c
> > +++ b/drivers/dma-buf/dma-heap.c
> > @@ -7,13 +7,17 @@
> > */
> >
> > #include <linux/cdev.h>
> > +#include <linux/cgroup.h>
> > #include <linux/device.h>
> > #include <linux/dma-buf.h>
> > #include <linux/dma-heap.h>
> > +#include <linux/memcontrol.h>
> > +#include <linux/sched/mm.h>
> > #include <linux/err.h>
> > #include <linux/export.h>
> > #include <linux/list.h>
> > #include <linux/nospec.h>
> > +#include <linux/pidfd.h>
> > #include <linux/syscalls.h>
> > #include <linux/uaccess.h>
> > #include <linux/xarray.h>
> > @@ -55,10 +59,12 @@ MODULE_PARM_DESC(mem_accounting,
> > "Enable cgroup-based memory accounting for dma-buf heap allocations (default=false).");
> >
> > static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> > - u32 fd_flags,
> > - u64 heap_flags)
> > + u32 fd_flags, u64 heap_flags,
> > + struct mem_cgroup *charge_to)
> > {
> > struct dma_buf *dmabuf;
> > + unsigned int nr_pages;
> > + struct mem_cgroup *memcg = charge_to;
> > int fd;
> >
> > /*
> > @@ -73,6 +79,22 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> > if (IS_ERR(dmabuf))
> > return PTR_ERR(dmabuf);
> >
> > + nr_pages = len / PAGE_SIZE;
> > +
> > + if (memcg)
> > + css_get(&memcg->css);
> > + else if (mem_accounting)
> > + memcg = get_mem_cgroup_from_mm(current->mm);
> > +
> > + if (memcg) {
> > + if (!mem_cgroup_charge_dmabuf(memcg, nr_pages, GFP_KERNEL)) {
> > + mem_cgroup_put(memcg);
> > + dma_buf_put(dmabuf);
> > + return -ENOMEM;
> > + }
> > + dmabuf->memcg = memcg;
> > + }
> > +
> > fd = dma_buf_fd(dmabuf, fd_flags);
> > if (fd < 0) {
> > dma_buf_put(dmabuf);
> > @@ -102,6 +124,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data)
> > {
> > struct dma_heap_allocation_data *heap_allocation = data;
> > struct dma_heap *heap = file->private_data;
> > + struct mem_cgroup *memcg = NULL;
> > + struct task_struct *task;
> > + unsigned int pidfd_flags;
> > int fd;
> >
> > if (heap_allocation->fd)
> > @@ -113,9 +138,20 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data)
> > if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
> > return -EINVAL;
> >
> > + if (heap_allocation->charge_pid_fd) {
> > + task = pidfd_get_task(heap_allocation->charge_pid_fd, &pidfd_flags);
>
> Will always get a thread-group leader pidfd and will fail if this is a
> thread-specific pidfd. pidfd_open(1234, PIDFD_THREAD) can be used to
> open a thread-specific pidfd.
>
> > + if (IS_ERR(task))
> > + return PTR_ERR(task);
> > +
> > + memcg = get_mem_cgroup_from_mm(task->mm);
> > + put_task_struct(task);
> > + }
> > +
> > fd = dma_heap_buffer_alloc(heap, heap_allocation->len,
> > heap_allocation->fd_flags,
> > - heap_allocation->heap_flags);
> > + heap_allocation->heap_flags,
> > + memcg);
> > + mem_cgroup_put(memcg);
> > if (fd < 0)
> > return fd;
> >
> > diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c
> > index 03c2b87cb1112..95d7688167b93 100644
> > --- a/drivers/dma-buf/heaps/system_heap.c
> > +++ b/drivers/dma-buf/heaps/system_heap.c
> > @@ -385,8 +385,6 @@ static struct page *alloc_largest_available(unsigned long size,
> > if (max_order < orders[i])
> > continue;
> > flags = order_flags[i];
> > - if (mem_accounting)
> > - flags |= __GFP_ACCOUNT;
> > page = alloc_pages(flags, orders[i]);
> > if (!page)
> > continue;
> > diff --git a/include/uapi/linux/dma-heap.h b/include/uapi/linux/dma-heap.h
> > index a4cf716a49fa6..e02b0f8cbc6a1 100644
> > --- a/include/uapi/linux/dma-heap.h
> > +++ b/include/uapi/linux/dma-heap.h
> > @@ -29,6 +29,10 @@
> > * handle to the allocated dma-buf
> > * @fd_flags: file descriptor flags used when allocating
> > * @heap_flags: flags passed to heap
> > + * @charge_pid_fd: optional pidfd of the process whose cgroup should be
> > + * charged for this allocation; 0 means charge the calling
> > + * process's cgroup
> > + * @__padding: reserved, must be zero
> > *
> > * Provided by userspace as an argument to the ioctl
> > */
> > @@ -37,6 +41,8 @@ struct dma_heap_allocation_data {
> > __u32 fd;
> > __u32 fd_flags;
> > __u64 heap_flags;
> > + __u32 charge_pid_fd;
> > + __u32 __padding;
> > };
> >
> > #define DMA_HEAP_IOC_MAGIC 'H'
> >
> > --
> > 2.53.0
> >
^ permalink raw reply
* Re: [PATCH] dm: fix dm-inlinecrypt docs warnings
From: Randy Dunlap @ 2026-05-15 16:49 UTC (permalink / raw)
To: Jonathan Corbet, linux-kernel
Cc: Linlin Zhang, Alasdair Kergon, Mike Snitzer, Mikulas Patocka,
Benjamin Marzinski, dm-devel, Shuah Khan, linux-doc
In-Reply-To: <878q9ksrpi.fsf@trenco.lwn.net>
On 5/15/26 6:55 AM, Jonathan Corbet wrote:
> Randy Dunlap <rdunlap@infradead.org> writes:
>
>> Add this file to the index and use a longer heading overline string
>> to eliminate warnings:
>>
>> Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst:1: WARNING: Title overline too short.
>> ========
>> dm-inlinecrypt
>> ========
>> Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst: WARNING: document isn't included in any toctree [toc.not_included]
>>
>> Fixes: b4a0774bd7fd ("dm: add documentation for dm-inlinecrypt target")
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> ---
>> Cc: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
>> Cc: Alasdair Kergon <agk@redhat.com>
>> Cc: Mike Snitzer <snitzer@kernel.org>
>> Cc: Mikulas Patocka <mpatocka@redhat.com>
>> Cc: Benjamin Marzinski <bmarzins@redhat.com>
>> Cc: dm-devel@lists.linux.dev
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> Cc: Shuah Khan <skhan@linuxfoundation.org>
>> Cc: linux-doc@vger.kernel.org
>>
>> Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst | 4 ++--
>> Documentation/admin-guide/device-mapper/index.rst | 1 +
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> This doesn't apply to docs-next, so I'm guessing it's intended for some
> other tree?
Right. It should go thru the device-mapper tree.
@Mikulas merged this file.
thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 0/8] x86/resctrl: Support for AMD Global (Slow) Memory Bandwidth Allocation
From: Reinette Chatre @ 2026-05-15 16:35 UTC (permalink / raw)
To: Moger, Babu, 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: <67782399-2d96-4207-8ee6-815bd0c4104b@amd.com>
Hi Babu,
On 5/15/26 8:31 AM, Moger, Babu wrote:
> On 5/1/2026 9:38 AM, Moger, Babu wrote:
>> On 4/30/2026 6:40 PM, Reinette Chatre wrote:
>>>>> 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.
Above is comment from me indicating plans to share the PoC and goal to have it provide a foundation
for GMBA and GSMBA.
>>>>
>>>> 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.
>
> I didn’t see your acknowledgment on my previous note, so I wanted to follow up to ensure we’re aligned.
I did not think a response was necessary since it essentially rephrased my earlier comment and did not contain
a question.
> Just to confirm—are you planning to share your PoC?
Yes. The fixes needed in existing resctrl code are taking higher priority though.
>
> My understanding is that I would build GMB/GSMBA on top of your patches. Please let me know if that’s correct.
That is my understanding also.
>
> There’s no urgency on the patches at this point; I mainly wanted to get some clarity on the plan.
Reinette
^ permalink raw reply
* Re: [PATCH v12 02/11] lib: kstrtox: add kstrtoudec64() and kstrtodec64()
From: Rodrigo Alencar @ 2026-05-15 16:05 UTC (permalink / raw)
To: Rodrigo Alencar, rodrigo.alencar, linux-kernel, linux-iio,
devicetree, linux-doc
Cc: Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan, David Laight
In-Reply-To: <kwjoyikbygik4futknqpua2tlzokradms25n2dmfa5czyj2uts@4rdfl6zlul2q>
On 26/05/13 10:41AM, Rodrigo Alencar wrote:
> On 26/05/10 01:42PM, Rodrigo Alencar via B4 Relay wrote:
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > Add helpers that parses decimal numbers into 64-bit number, i.e., decimal
> > point numbers with pre-defined scale are parsed into a 64-bit value (fixed
> > precision). After the decimal point, digits beyond the specified scale
> > are ignored.
>
> Hi Andy,
>
> I am starting over here, the other conversation is getting hard to follow.
> This is my new proposal...
+cc David
> ...
>
> > +static int _kstrtoudec64(const char *s, unsigned int scale, u64 *res)
> > +{
> > + u64 _res = 0, _frac = 0;
> > + unsigned int rv;
> > +
> > + if (scale > 19) /* log10(2^64) = 19.26 */
> > + return -EINVAL;
> > +
> > + if (*s != '.') {
> > + rv = _parse_integer(s, 10, &_res);
> > + if (rv & KSTRTOX_OVERFLOW)
> > + return -ERANGE;
> > + if (rv == 0)
> > + return -EINVAL;
> > + s += rv;
> > + }
> > +
> > + if (*s == '.' && scale) {
> > + s++; /* skip decimal point */
> > + rv = _parse_integer_limit(s, 10, &_frac, scale);
> > + if (rv & KSTRTOX_OVERFLOW)
> > + return -ERANGE;
> > + if (rv == 0)
> > + return -EINVAL;
> > + s += rv;
> > + if (rv < scale)
> > + _frac *= int_pow(10, scale - rv);
> > + while (isdigit(*s)) /* truncate */
> > + s++;
> > + }
> > +
> > + if (*s == '\n')
> > + s++;
> > + if (*s)
> > + return -EINVAL;
> > +
> > + if (check_mul_overflow(_res, int_pow(10, scale), &_res) ||
> > + check_add_overflow(_res, _frac, &_res))
> > + return -ERANGE;
> > +
> > + *res = _res;
> > + return 0;
> > +}
>
> This function now becomes:
>
> static int _kstrtoudec64(const char *s, unsigned int scale, u64 *res)
> {
> u64 _res = 0;
> unsigned int rv_int, rv_frac;
>
> rv_int = _parse_integer(s, 10, &_res);
> if (rv_int & KSTRTOX_OVERFLOW)
> return -ERANGE;
> s += rv_int;
>
> if (*s == '.')
> s++; /* skip decimal point */
>
> rv_frac = _parse_integer_limit_init(s, 10, _res, &_res, scale);
> if (rv_frac & KSTRTOX_OVERFLOW)
> return -ERANGE;
> s += rv_frac;
>
> if (!rv_int && !rv_frac && !isdigit(*s))
> return -EINVAL; /* no digits at all */
>
> while (isdigit(*s)) /* truncate digits */
> s++;
>
> if (*s == '\n')
> s++;
> if (*s)
> return -EINVAL;
>
> if (_res && (scale > (19 + rv_frac) || /* log10(2^64) = 19.26 */
> check_mul_overflow(_res, int_pow(10, scale - rv_frac), &_res)))
> return -ERANGE;
>
> *res = _res;
> return 0;
> }
>
> The new thing here is _parse_integer_limit_init(), which is a local modified
> helper that accepts an init value, so _parse_integer_limit() becomes:
>
> unsigned int _parse_integer_limit(const char *s, unsigned int base,
> unsigned long long *p, size_t max_chars)
> {
> return _parse_integer_limit_init(s, base, 0, p, max_chars);
> }
>
> with init = 0:
>
> static unsigned int _parse_integer_limit_init(const char *s, unsigned int base,
> unsigned long long init,
> unsigned long long *p,
> size_t max_chars)
> {
> unsigned long long res;
> unsigned int rv;
>
> res = init;
> /* ...
> * the rest is the same implementation as _parse_integer_limit()
> * ...
> */
> return rv;
> }
>
> That allows to accumulate the final value into the same variable, which makes
> things simpler and decreases the amount of overflow checks.
>
> The scale can now be a bigger value, like 0.00000000000000000000000000000000423
> can be parsed with scale = 35, resulting into 423.
>
> The truncation loop is still there... I think this implementation is better,
> and I am not sure what is the input limit that you would consider ok to allow
> non-zero digits to be truncated once the scale can now be something bigger than 19.
> As long as the output fits into a u64 variable, the parser still works.
The truncation loop is at least stricting the input on digits!
Any comments on that?
>
> I am also adding new test cases for that!
I have a v13 ready with this. I'll give it a go soon...
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH] docs: netlink: Correct buffer sizing info
From: Konstantin Shabanov @ 2026-05-15 15:57 UTC (permalink / raw)
To: kuba
Cc: corbet, davem, edumazet, horms, linux-doc, linux-kernel, mail,
netdev, pabeni, skhan
In-Reply-To: <20260512172757.10c43c86@kernel.org>
On Tue, 12 May 2026 17:27:57 -0700 Jakub Kicinski wrote:
> On Tue, 12 May 2026 17:30:53 +0700 Konstantin Shabanov wrote:
> > Update the docs to match the code (include/linux/netlink.h):
> >
> > /*
> > * skb should fit one page. This choice is good for headerless malloc.
> > * But we should limit to 8K so that userspace does not have to
> > * use enormous buffer sizes on recvmsg() calls just to avoid
> > * MSG_TRUNC when PAGE_SIZE is very large.
> > */
> > #if PAGE_SIZE < 8192UL
> > #define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(PAGE_SIZE)
> > #else
> > #define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(8192UL)
> > #endif
>
> You should explain what you think the problem is in the commit message.
> Maybe if you did you'd realize you're comparing kernel header comment
> to user space guidance which are (obviously?) the inverse of each
> other..
I thought that the comment is self-explaining:
* But we should limit to 8K so that userspace does not have to
* use enormous buffer sizes on recvmsg() calls just to avoid
* MSG_TRUNC when PAGE_SIZE is very large.
The problem is that according to the comment, kernel isn't going to send
more than 8K in a single reply and the documentation is currently recommends the opposite:
to create _at least_ 8K buffer what looks excessive.
Also, the logic in the comment is aligned with userspace libraries (libmnl [1]
and wireguard-tools [2]).
[1]: https://git.netfilter.org/libmnl/tree/include/libmnl/libmnl.h?id=54dea548d796653534645c6e3c8577eaf7d77411#n20
[2]: https://git.zx2c4.com/wireguard-tools/tree/src/netlink.h?id=a998407747005ea7e4e0258d96f105c97241e1d3#n70
^ permalink raw reply
* Re: [PATCH RFC v4 10/10] docs: iio: add documentation for ad9910 driver
From: Rodrigo Alencar @ 2026-05-15 15:47 UTC (permalink / raw)
To: Rodrigo Alencar, David Lechner, rodrigo.alencar, linux-iio,
devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan, Kees Cook,
Gustavo A. R. Silva
In-Reply-To: <wpoiyqezs6lus5o7smlibbxrxqudvijgqh3gwgft2xjpiirwa4@xtdwe3kzleku>
On 26/05/11 05:01PM, Rodrigo Alencar wrote:
> On 26/05/11 10:23AM, David Lechner wrote:
> > On 5/11/26 10:02 AM, Rodrigo Alencar wrote:
> > > On 26/05/11 09:46AM, David Lechner wrote:
> > >> On 5/10/26 4:30 AM, Rodrigo Alencar wrote:
> > >>> On 26/05/09 06:42PM, David Lechner wrote:
> > >>>> On 5/8/26 12:00 PM, Rodrigo Alencar via B4 Relay wrote:
> > >>>>> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > >>>>>
> > >>>>> Add documentation for the AD9910 DDS IIO driver, which describes channels,
> > >>>>> DDS modes, attributes and ABI usage examples.
...
> > >>>>> +Digital ramp generator (DRG)
> > >>>>> +----------------------------
> > >>>>> +
> > >>>>> +The DRG produces linear frequency, phase or amplitude sweeps using dedicated
> > >>>>> +hardware. It is controlled through three channels: a parent control channel
> > >>>>> +(``digital_ramp_generator``) and two child ramp channels
> > >>>>> +(``digital_ramp_up``, ``digital_ramp_down``). DRG destination is set when
> > >>>>> +ramp attributes are written, i.e. writing to ``frequency`` or ``frequency_roc``
> > >>>>> +sets the destination to frequency.
> > >>>>
> > >>>> Would it be better to say that the destination is set when the the
> > >>>> value is non-zero? Otherwise, how would one change the destination
> > >>>> once set?
> > >>>
> > >>> Destination is only one, so you just need to write phase or phase_roc, if you want
> > >>> to target phase then. Does that not sound intuitive?
> > >>
> > >> I was thinking about if you needed to change the configuration.
> > >> If you set it to phase, then want to change it to frequency, how
> > >> could you do that if 0 is a valid value for phase?
> > >>
> > >> Also how could you know which is selected by reading back the
> > >> values if 0 is a valid value?
> > >
> > > This is where Jonathan raised some concerns, so it is a good oportunity for you
> > > to provide your inputs! Right now, I am returning -EBUSY on read of an attribute
> > > where its destination is not selected. As pointed out, the destination selection
> > > is happening when writting to the attribute. In the previous patch, Jonathan
> > > suggested frequency_active, phase_active and scale_active to track mode priority,
> > > and It could be leveraged here for DRG destination selection. I havent gone for
> > > that because I was not willing to add that to all the channels given that it is
> > > mostly used for debugging, so I added frequency_source, phase_source and
> > > amplitude_source to debugfs instead.
> >
> > The "last write wins" with the others changing to EBUSY makes more sense to
> > me now. If the docs said that, I missed it. Otherwise, that would be a helpful
> > thing to add to the docs here.
> >
> > >
> > > Destination selection for RAM mode is firmware based at this point.
> >
> > Seems reasonable.
> >
> > > Destination selection for Parallel mode is still not clear... could use
> > > those *_active attributes or separate channels.
> >
> > Since there are _offset attributes proposed for parallel input already,
> > could we just make it the same where you have to write one of those
> > attributes?
>
> Different from the DRG, both RAM and Parallel mode has this extra polar
> destination, which targets both amplitude and phase at the same time.
>
> For parallel mode I have the attributes:
> - frequency_scale: applied when destination is frequency
> - frequency_offset: applied when destination is frequency
> - scale_offset: applied when destination is polar
> - phase_offset: applied when destination is polar
>
> In parallel mode, there aren't knobs like those for amplitude and phase
> destinations. With the *_active thing or similar, polar can be both
> phase_active and scale_active enabled at the same time. However, this
> would not behave the same way Jonathan suggested, i.e. to be used for
> mode priority indication... it would be used for destination configuration
> instead.
I was thinking, and it might be good to define this now because of the
fact I might need to create other 3 channels for the parallel mode (Maybe
that is fine and we can create them later if needed).
One thing to note is that in parallel mode, although the format pins (F0, F1)
that defines the parallel destination are synchronized with PDCLK (parallel port
clock), we cannot really send multiple formats in a single session, so we
cannot interleave destinations. Then, if having separate channels we would need
to contraint that (only one destination works at a time) with the available
scan masks.
Now, also related to the IIO backend support but for the DRG channel...
Anticipating new ABI for the IIO backend, currently I have the following to
expose ramp control from the FPGA IP:
- toggle_en: To allow the backend to control DRCTL pin, toggling it in response
to DROVER, according to the configured dwell modes.
- ramp_delay: the delay between ramp sweeps in seconds
- burst_count: amount of ramps in a burst of ramps
- burst_delay: delay between bursts in seconds (valid when burst_count > 0)
Would also be good if I can get a comment on those! Maybe toggle_en can be
removed as the other ones only make sense when there is dwell and when this
toggle is enabled. So toggle enabled can be set by default whenever we are
not in bidirectional continuous, i.e., we are dwelling at either max or min
limits (or both).
Just to summarize the motivation for those attributes... the idea to create
those ramp patterns is to allow a receiver that performs stretch processing
to assemble a "radar data cube" of data, where FFT applied to each dimension
gives different insights on the detected object: range, velocity and direction.
Each ramp would give a row, a burst gives a matrix, and with multiple antennas
one gets a 3D block of data.
...
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v2 0/8] x86/resctrl: Support for AMD Global (Slow) Memory Bandwidth Allocation
From: Moger, Babu @ 2026-05-15 15:31 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: <3bc59b3e-4506-4489-a424-6e7f91232af1@amd.com>
Hi Reinette,
On 5/1/2026 9:38 AM, Moger, Babu wrote:
> 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.
I didn’t see your acknowledgment on my previous note, so I wanted to
follow up to ensure we’re aligned.
Just to confirm—are you planning to share your PoC?
My understanding is that I would build GMB/GSMBA on top of your patches.
Please let me know if that’s correct.
There’s no urgency on the patches at this point; I mainly wanted to get
some clarity on the plan.
Thanks,
Babu
^ permalink raw reply
* Re: [PATCH] dcache: add fs.dentry-limit sysctl with negative-first reaper
From: kernel test robot @ 2026-05-15 15:09 UTC (permalink / raw)
To: Horst Birthelmer, Miklos Szeredi, Jonathan Corbet, Shuah Khan,
Alexander Viro, Christian Brauner, Jan Kara
Cc: llvm, oe-kbuild-all, linux-doc, linux-kernel, linux-fsdevel,
Horst Birthelmer
In-Reply-To: <20260514-limit-dentries-cache-v1-1-431b9eb0c530@ddn.com>
Hi Horst,
kernel test robot noticed the following build errors:
[auto build test ERROR on 5d6919055dec134de3c40167a490f33c74c12581]
url: https://github.com/intel-lab-lkp/linux/commits/Horst-Birthelmer/dcache-add-fs-dentry-limit-sysctl-with-negative-first-reaper/20260515-154600
base: 5d6919055dec134de3c40167a490f33c74c12581
patch link: https://lore.kernel.org/r/20260514-limit-dentries-cache-v1-1-431b9eb0c530%40ddn.com
patch subject: [PATCH] dcache: add fs.dentry-limit sysctl with negative-first reaper
config: s390-randconfig-002-20260515 (https://download.01.org/0day-ci/archive/20260515/202605152329.WHnEvZt7-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 5bac06718f502014fade905512f1d26d578a18f3)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260515/202605152329.WHnEvZt7-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/202605152329.WHnEvZt7-lkp@intel.com/
All errors (new ones prefixed by >>):
>> fs/dcache.c:1474:7: error: call to undeclared function 'get_nr_dentry'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
1474 | nr = get_nr_dentry();
| ^
fs/dcache.c:1474:7: note: did you mean 'retain_dentry'?
fs/dcache.c:835:20: note: 'retain_dentry' declared here
835 | static inline bool retain_dentry(struct dentry *dentry, bool locked)
| ^
fs/dcache.c:1519:6: error: call to undeclared function 'get_nr_dentry'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
1519 | if (get_nr_dentry() <= (long)limit)
| ^
2 errors generated.
vim +/get_nr_dentry +1474 fs/dcache.c
1463
1464 static void dentry_limit_worker_fn(struct work_struct *work)
1465 {
1466 struct dentry_limit_ctx ctx;
1467 unsigned long limit = READ_ONCE(sysctl_dentry_limit);
1468 unsigned int ms;
1469 long nr;
1470
1471 if (!limit)
1472 return;
1473
> 1474 nr = get_nr_dentry();
1475 if (nr <= (long)limit)
1476 return;
1477
1478 ctx.over = nr - (long)limit;
1479
1480 /* Phase 1: drain negative dentries across every superblock. */
1481 ctx.isolate = dentry_lru_isolate_negative;
1482 iterate_supers(dentry_limit_prune_sb, &ctx);
1483
1484 /* Phase 2: still over? Apply the ordinary LRU policy. */
1485 if (ctx.over > 0) {
1486 ctx.isolate = dentry_lru_isolate;
1487 iterate_supers(dentry_limit_prune_sb, &ctx);
1488 }
1489
1490 /*
1491 * Re-arm while still above the limit. Re-read the sysctls in
1492 * case the admin raised the cap or disabled the feature during
1493 * the walk.
1494 */
1495 limit = READ_ONCE(sysctl_dentry_limit);
1496 if (!limit || get_nr_dentry() <= (long)limit)
1497 return;
1498
1499 ms = READ_ONCE(sysctl_dentry_limit_interval_ms);
1500 queue_delayed_work(system_unbound_wq, &dentry_limit_work,
1501 msecs_to_jiffies(ms));
1502 }
1503
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] dcache: add fs.dentry-limit sysctl with negative-first reaper
From: kernel test robot @ 2026-05-15 15:09 UTC (permalink / raw)
To: Horst Birthelmer, Miklos Szeredi, Jonathan Corbet, Shuah Khan,
Alexander Viro, Christian Brauner, Jan Kara
Cc: oe-kbuild-all, linux-doc, linux-kernel, linux-fsdevel,
Horst Birthelmer
In-Reply-To: <20260514-limit-dentries-cache-v1-1-431b9eb0c530@ddn.com>
Hi Horst,
kernel test robot noticed the following build errors:
[auto build test ERROR on 5d6919055dec134de3c40167a490f33c74c12581]
url: https://github.com/intel-lab-lkp/linux/commits/Horst-Birthelmer/dcache-add-fs-dentry-limit-sysctl-with-negative-first-reaper/20260515-154600
base: 5d6919055dec134de3c40167a490f33c74c12581
patch link: https://lore.kernel.org/r/20260514-limit-dentries-cache-v1-1-431b9eb0c530%40ddn.com
patch subject: [PATCH] dcache: add fs.dentry-limit sysctl with negative-first reaper
config: openrisc-randconfig-r073-20260515 (https://download.01.org/0day-ci/archive/20260515/202605152333.0pOd2zJR-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 10.5.0
smatch: v0.5.0-9185-gbcc58b9c
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260515/202605152333.0pOd2zJR-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/202605152333.0pOd2zJR-lkp@intel.com/
All errors (new ones prefixed by >>):
fs/dcache.c: In function 'dentry_limit_worker_fn':
>> fs/dcache.c:1474:7: error: implicit declaration of function 'get_nr_dentry'; did you mean 'retain_dentry'? [-Werror=implicit-function-declaration]
1474 | nr = get_nr_dentry();
| ^~~~~~~~~~~~~
| retain_dentry
cc1: some warnings being treated as errors
vim +1474 fs/dcache.c
1463
1464 static void dentry_limit_worker_fn(struct work_struct *work)
1465 {
1466 struct dentry_limit_ctx ctx;
1467 unsigned long limit = READ_ONCE(sysctl_dentry_limit);
1468 unsigned int ms;
1469 long nr;
1470
1471 if (!limit)
1472 return;
1473
> 1474 nr = get_nr_dentry();
1475 if (nr <= (long)limit)
1476 return;
1477
1478 ctx.over = nr - (long)limit;
1479
1480 /* Phase 1: drain negative dentries across every superblock. */
1481 ctx.isolate = dentry_lru_isolate_negative;
1482 iterate_supers(dentry_limit_prune_sb, &ctx);
1483
1484 /* Phase 2: still over? Apply the ordinary LRU policy. */
1485 if (ctx.over > 0) {
1486 ctx.isolate = dentry_lru_isolate;
1487 iterate_supers(dentry_limit_prune_sb, &ctx);
1488 }
1489
1490 /*
1491 * Re-arm while still above the limit. Re-read the sysctls in
1492 * case the admin raised the cap or disabled the feature during
1493 * the walk.
1494 */
1495 limit = READ_ONCE(sysctl_dentry_limit);
1496 if (!limit || get_nr_dentry() <= (long)limit)
1497 return;
1498
1499 ms = READ_ONCE(sysctl_dentry_limit_interval_ms);
1500 queue_delayed_work(system_unbound_wq, &dentry_limit_work,
1501 msecs_to_jiffies(ms));
1502 }
1503
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 0/4] docs: admin-guide: improve workload tracing guide
From: Jonathan Corbet @ 2026-05-15 14:49 UTC (permalink / raw)
To: Cheng-Han Wu, Shuah Khan
Cc: Randy Dunlap, linux-doc, linux-kernel, Cheng-Han Wu
In-Reply-To: <20260503101429.254394-1-hank20010209@gmail.com>
Cheng-Han Wu <hank20010209@gmail.com> writes:
> This series updates Documentation/admin-guide/workload-tracing.rst
>
> - Patch 1 fixes several typos.
> - Patch 2 fixes stress-ng and perf record command examples.
> - Patch 3 replaces a stale fixed "perf bench all" benchmark list with a
> description of the command behavior and how to query available benchmarks.
> - Patch 4 mentions the kernel build system's cscope target and shows how
> to exclude directories with IGNORE_DIRS.
>
> Built test with:
> make SPHINXDIRS=admin-guide htmldocs
>
> Cheng-Han Wu (4):
> docs: admin-guide: fix typos in workload tracing guide
> docs: admin-guide: fix stress-ng command examples
> docs: admin-guide: clarify perf bench all behavior
> docs: admin-guide: add IGNORE_DIRS example for cscope
>
> .../admin-guide/workload-tracing.rst | 41 +++++++++++++------
> 1 file changed, 29 insertions(+), 12 deletions(-)
Series applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] Documentation: core-api/cpu_hotplug: Remove stale cpu0_hotplug docs
From: Jonathan Corbet @ 2026-05-15 14:44 UTC (permalink / raw)
To: Chao Gao, linux-doc, linux-kernel; +Cc: Chao Gao, Dave Hansen, Shuah Khan
In-Reply-To: <20260507134732.254617-1-chao.gao@intel.com>
Chao Gao <chao.gao@intel.com> writes:
> Commit e59e74dc48a3 ("x86/topology: Remove CPU0 hotplug option")
> removed the 'cpu0_hotplug' option, but its documentation remained in
> cpu_hotplug.rst. Remove the stale entry.
>
> Reported-by: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> ---
> Documentation/core-api/cpu_hotplug.rst | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst
> index 9b4afca9fd09..6de26d1c6a9a 100644
> --- a/Documentation/core-api/cpu_hotplug.rst
> +++ b/Documentation/core-api/cpu_hotplug.rst
> @@ -45,11 +45,6 @@ Command Line Switches
>
> This option is limited to the X86 and S390 architecture.
>
> -``cpu0_hotplug``
> - Allow to shutdown CPU0.
> -
> - This option is limited to the X86 architecture.
> -
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v4] scripts/kernel-doc: Detect mismatched inline member documentation tags
From: Jonathan Corbet @ 2026-05-15 14:42 UTC (permalink / raw)
To: Shuicheng Lin, linux-doc
Cc: Shuicheng Lin, Randy Dunlap, Jani Nikula, linux-kernel, intel-xe
In-Reply-To: <20260507023232.4108680-1-shuicheng.lin@intel.com>
Shuicheng Lin <shuicheng.lin@intel.com> writes:
> 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)
Sigh ... naturally this adds a number of docs-build warnings, but they
do seem to be legit. So I've applied it, thanks.
In the future, please copy the maintainer(s) on your patches;
scripts/get_maintainer.pl should have told you to do that. I almost
missed this one entirely.
jon
^ permalink raw reply
* Re: kernel-doc no longer warns about leftover argument doc?
From: Jonathan Corbet @ 2026-05-15 14:36 UTC (permalink / raw)
To: Randy Dunlap, Jakub Kicinski, Mauro Carvalho Chehab; +Cc: linux-doc
In-Reply-To: <1ff1d237-fd32-4373-aaef-d19743bb2ea4@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> On 5/14/26 6:49 PM, Jakub Kicinski wrote:
>> Hi!
>>
>> Looks like the new python kernel-doc does not warn when there are
>> stray arguments in function kdoc. Eg
>>
>> /**
>> * ksz_wol_pre_shutdown - Prepares the switch device for shutdown while
>> * considering Wake-on-LAN (WoL) settings.
>> * @dev: The switch device structure.
>> * @wol_enabled: Pointer to a boolean which will be set to true if WoL is
>> * enabled on any port.
>> *
>> * This function prepares the switch device for a safe shutdown while taking
>> * into account the Wake-on-LAN (WoL) settings on the user ports. It updates
>> * the wol_enabled flag accordingly to reflect whether WoL is active on any
>> * port.
>> */
>> static void ksz_wol_pre_shutdown(struct ksz_device *dev)
>>
>>
>> AIs seem to catch it but that's not ideal..
>>
>
> Yes, hopefully we can have this patch merged soon:
> https://lore.kernel.org/all/20260507023232.4108680-1-shuicheng.lin@intel.com/
The odds of such things increase significantly when the patch is
actually sent to the maintainer; in the midst of travel such I missed
this one. Looking at it now.
jon
^ permalink raw reply
* Re: [PATCH] docs: Update nosmt support for arm64
From: Jonathan Corbet @ 2026-05-15 14:26 UTC (permalink / raw)
To: Jinjie Ruan, skhan, akpm, bp, rdunlap, pmladek, pawan.kumar.gupta,
feng.tang, dapeng1.mi, kees, elver, paulmck, lirongqing,
safinaskar, bhelgaas, linux-doc, linux-kernel, skelley
Cc: ruanjinjie
In-Reply-To: <20260417032540.3720627-1-ruanjinjie@huawei.com>
Jinjie Ruan <ruanjinjie@huawei.com> writes:
> commit eed4583bcf9a6 ("arm64: Kconfig: Enable HOTPLUG_SMT") enable
> HOTPLUG_SMT for SMT control for arm64, but the documentation was
> not updated accordingly to reflect that ARM64 now supports control SMT
> via boot parameter and sysfs knobs:
>
> 1. Boot parameters:
>
> nosmt: Disable SMT, can be enabled via sysfs knobs.
> nosmt=force: Disable SMT, cannot be enabled via sysfs knobs.
>
> 2. Runtime sysfs controls:
>
> Write "on", "off", "forceoff" or the number of SMT threads (1, 2, ...)
> to /sys/devices/system/cpu/smt/control.
>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index cb850e5290c2..6a73eb5abae9 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4661,7 +4661,7 @@ Kernel parameters
> nosmt [KNL,MIPS,PPC,EARLY] Disable symmetric multithreading (SMT).
> Equivalent to smt=1.
>
> - [KNL,LOONGARCH,X86,PPC,S390] Disable symmetric multithreading (SMT).
> + [KNL,LOONGARCH,X86,ARM64,PPC,S390] Disable symmetric multithreading (SMT).
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v1] docs: housekeeping: Fix struct member access in code example
From: Jonathan Corbet @ 2026-05-15 14:25 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Costa Shulyupin, Shuah Khan, Ryan Cheevers, Waiman Long,
linux-doc, linux-kernel
In-Reply-To: <agMseHkMBF04ecS3@localhost.localdomain>
Frederic Weisbecker <frederic@kernel.org> writes:
> Le Sun, May 03, 2026 at 08:47:01AM -0600, Jonathan Corbet a écrit :
>> Costa Shulyupin <costa.shul@redhat.com> writes:
>>
>> > No such array housekeeping_cpumasks
>> >
>> > Fix to housekeeping.cpumasks.
>> >
>> > Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
>> > ---
>> > Documentation/core-api/housekeeping.rst | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/Documentation/core-api/housekeeping.rst b/Documentation/core-api/housekeeping.rst
>> > index 92c6e53cea75..ccb0a88b9cb3 100644
>> > --- a/Documentation/core-api/housekeeping.rst
>> > +++ b/Documentation/core-api/housekeeping.rst
>> > @@ -99,7 +99,7 @@ the same RCU read side critical section.
>> > A typical layout example would look like this on the update side
>> > (``housekeeping_update()``)::
>> >
>> > - rcu_assign_pointer(housekeeping_cpumasks[type], trial);
>> > + rcu_assign_pointer(housekeeping.cpumasks[type], trial);
>> > synchronize_rcu();
>>
>> This looks actively wrong to me. I think it should be:
>>
>> housekeeping_cpumask(type)
>>
>> ... Frederic ... ?
>
> No, Costa is right, housekeeping.cpumasks[type] is where we store
> the pointer. housekeeping_cpumask(type) is only an accessor.
>
> So:
>
> Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
OK, then, applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v13 0/4] kunit: Add support for suppressing warning backtraces
From: Albert Esteve @ 2026-05-15 14:25 UTC (permalink / raw)
To: Guenter Roeck
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Alessandro Carminati,
Kees Cook, Linux Kernel Functional Testing, Maíra Canal,
Dan Carpenter, Simona Vetter
In-Reply-To: <7bcead90-7d96-4101-bd13-dde2c5ded1aa@roeck-us.net>
On Fri, May 15, 2026 at 3:51 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Hi Albert,
>
> On 5/15/26 05:29, Albert Esteve wrote:
> ...
>
> > Guenter Roeck (3):
> > kunit: Add backtrace suppression self-tests
> > drm: Suppress intentional warning backtraces in scaling unit tests
> > kunit: Add documentation for warning backtrace suppression API
> >
>
>
> How much of that is from me at this point ? Wouldn't it make sense to drop me
> as "author" of those patches ?
Hi Guenter,
I do not mind authorship either. Signed-off-by lines already attest to
everyone's contribution.
In principle I am done with Sashiko's reviews. I addressed all
comments in their respective patches. Some lead to the rabbit holes I
put myself into for previous versions.
I do not plan to send a new version unless a human review requires a change.
If that happens, I may update the authorship. Otherwise, I'd keep it
as is, since you said you do not mind :)
Thanks!
BR,
Albert.
>
> I would not mind. I had the idea, but others like you are doing the hard work
> of pushing it through.
>
> Thanks,
> Guenter
>
^ permalink raw reply
* Re: [PATCH v1] docs: locking: Fix stale dquot.c path
From: Jonathan Corbet @ 2026-05-15 14:24 UTC (permalink / raw)
To: Costa Shulyupin, Matthew Wilcox (Oracle), Jan Kara, Shuah Khan,
Randy Dunlap, linux-fsdevel, linux-mm, linux-doc, linux-kernel
Cc: Costa Shulyupin
In-Reply-To: <20260503160221.1594319-2-costa.shul@redhat.com>
Costa Shulyupin <costa.shul@redhat.com> writes:
> The quota code was moved from fs/dquot.c to fs/quota/dquot.c
> in commit 884d179dff3a ("quota: Move quota files into separate
> directory"). Update the reference.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/filesystems/locking.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
> index 8421ea21bd35..277e49314d32 100644
> --- a/Documentation/filesystems/locking.rst
> +++ b/Documentation/filesystems/locking.rst
> @@ -584,7 +584,7 @@ write_info: yes dqonoff_sem
> FS recursion means calling ->quota_read() and ->quota_write() from superblock
> operations.
>
> -More details about quota locking can be found in fs/dquot.c.
> +More details about quota locking can be found in fs/quota/dquot.c.
>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2] docs: pt_BR: translate process/license-rules.rst
From: Jonathan Corbet @ 2026-05-15 14:24 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260503160352.160135-1-danielmaraboo@gmail.com>
Daniel Pereira <danielmaraboo@gmail.com> writes:
> Translate the license-rules.rst document into Brazilian Portuguese.
> This document provides guidelines on how licenses should be identified
> and handled within the kernel source code.
>
> Additionally, update the pt_BR/process/index.rst to include the new
> translation in the documentation tree.
>
> Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
>
> ---
> v2:
> - Fixed docutils warning: "Line block ends without a blank line" on line 72.
> - Removed stray '|' character from the translation file to fix the build.
> ---
> Documentation/translations/pt_BR/index.rst | 1 +
> .../pt_BR/process/license-rules.rst | 483 ++++++++++++++++++
> 2 files changed, 484 insertions(+)
> create mode 100644 Documentation/translations/pt_BR/process/license-rules.rst
Applied, thanks.
jon
^ 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