* 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
* Re: [PATCH] docs: pt_BR: update minimal software requirements in changes.rst
From: Jonathan Corbet @ 2026-05-15 14:21 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260505194143.32009-1-danielmaraboo@gmail.com>
Daniel Pereira <danielmaraboo@gmail.com> writes:
> Update the Brazilian Portuguese translation of changes.rst to align with
> the latest English version.
>
> Key changes include:
> - Updated minimum versions for Rust (1.85.0), bindgen (0.71.1), and
> pahole (1.22).
> - Fixed ReST syntax for internal references (:ref:) and external links.
> - Corrected formatting for tool names and config options using inline
> code backticks.
> - Synchronized technical descriptions for udev, kmod, and NFS-utils.
>
> Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
> ---
> .../translations/pt_BR/process/changes.rst | 52 +++++++++----------
> 1 file changed, 26 insertions(+), 26 deletions(-)
This doesn't build...?
> Documentation/translations/pt_BR/process/changes.rst:37:
> ERROR: Malformed table. Text in column margin in table line 7.
>
> ====================== ===============
> ======================================== Programa Versão mínima
> Comando para verificar a versão ======================
> =============== ======================================== GNU C 8.1
> gcc --version Clang/LLVM (optional) 15.0.0 clang --version Rust
> (optional) 1.85.0 rustc --version bindgen (optional) 0.71.1 bindgen
> --version GNU make 4.0 make --version bash 4.2 bash --version
> binutils 2.30 ld -v flex 2.5.35 flex --version gdb 7.2 gdb
> --version bison 2.0 bison --version pahole 1.22 pahole --version
> util-linux 2.10o mount --version kmod 13 kmod -V e2fsprogs 1.41.4
> e2fsck -V jfsutils 1.1.3 fsck.jfs -V xfsprogs 2.6.0 xfs_db -V
> squashfs-tools 4.0 mksquashfs -version btrfs-progs 0.18 btrfs
> --version pcmciautils 004 pccardctl -V quota-tools 3.09 quota -V
> PPP 2.4.0 pppd --version nfs-utils 1.0.5 showmount --version procps
> 3.2.0 ps --version udev 081 udevadm --version grub 0.93 grub
> --version || grub-install --version mcelog 0.6 mcelog --version
> iptables 1.4.2 iptables -V openssl & libcrypto 1.0.0 openssl
> version bc 1.06.95 bc --version Sphinx\ [#f1]_ 3.4.3 sphinx-build
> --version GNU tar 1.28 tar --version gtags (opcional) 6.6.5 gtags
> --version mkimage (opcional) 2017.01 mkimage --version Python 3.9.x
> python3 --version GNU AWK (opcional) 5.1.0 gawk --version
> ====================== ===============
> ======================================== [docutils]
> /stuff/k/git/kernel/Documentation/translations/pt_BR/process/changes.rst:71:
> WARNING: Footnote [#] is not referenced. [ref.footnote]
>
jon
^ permalink raw reply
* Re: [PATCH] kdoc: xforms: move context attrs to function_xforms list
From: Jonathan Corbet @ 2026-05-15 14:20 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Randy Dunlap, Shuah Khan, linux-doc, Mauro Carvalho Chehab
In-Reply-To: <20260505221548.163751-1-rdunlap@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> The context analysis macros are function attributes that should be
> in the function_xforms list. Somewhere along the way they were
> inserted into the struct_xforms list instead. This causes docs build
> warnings to continue to be emitted for context macros.
>
> Move the context analysis macros to the function_xforms list where
> they should be to eliminate these warnings.
>
> Documentation/core-api/kref:328: ../include/linux/kref.h:72: WARNING: Invalid C declaration: Expected end of definition. [error at 96]
> int kref_put_mutex (struct kref *kref, void (*release)(struct kref *kref), struct mutex *mutex) __cond_acquires(true# mutex)
> Documentation/core-api/kref:328: ../include/linux/kref.h:94: WARNING: Invalid C declaration: Expected end of definition. [error at 92]
> int kref_put_lock (struct kref *kref, void (*release)(struct kref *kref), spinlock_t *lock) __cond_acquires(true# lock)
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Shuah Khan <skhan@linuxfoundation.org>
> Cc: linux-doc@vger.kernel.org
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
>
> tools/lib/python/kdoc/xforms_lists.py | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: kernel-doc: python: strip __counted_by_ptr macro
From: Jonathan Corbet @ 2026-05-15 14:15 UTC (permalink / raw)
To: Tudor Ambarus, Mauro Carvalho Chehab, Kees Cook,
Gustavo A. R. Silva
Cc: linux-kernel, linux-doc, linux-hardening, peter.griffin,
andre.draszik, willmcvicker, jyescas, krzk, kernel-team,
Tudor Ambarus
In-Reply-To: <20260506-kdoc-__counted_by_ptr-v1-1-70763486871f@linaro.org>
Tudor Ambarus <tudor.ambarus@linaro.org> writes:
> The `__counted_by_ptr` macro was recently introduced [1] to extend
> bounds checking semantics to standard dynamically allocated pointers.
>
> However, the new Python implementation of kernel-doc does not currently
> recognize it as a compiler attribute. When kernel-doc encounters a
> struct member annotated with this macro, it fails to parse the variable
> name correctly, resulting in false-positive warnings like:
>
> Warning: ... struct member '__counted_by_ptr(cmdcnt' not described
>
> Add `__counted_by_ptr` to the `struct_xforms` regex list so it gets
> safely stripped out during the parsing phase, mirroring the existing
> behavior for `__counted_by`. Update the corresponding unit tests.
>
> Link: https://git.kernel.org/torvalds/c/150a04d817d8 [1]
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> tools/lib/python/kdoc/xforms_lists.py | 1 +
> tools/unittests/test_cmatch.py | 1 +
> 2 files changed, 2 insertions(+)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v13 2/4] kunit: Add backtrace suppression self-tests
From: Albert Esteve @ 2026-05-15 14:14 UTC (permalink / raw)
To: 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
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Alessandro Carminati,
Dan Carpenter, Kees Cook
In-Reply-To: <20260515-kunit_add_support-v13-2-18ee42f96e7b@redhat.com>
On Fri, May 15, 2026 at 2:30 PM Albert Esteve <aesteve@redhat.com> wrote:
>
> From: Guenter Roeck <linux@roeck-us.net>
>
> Add unit tests to verify that warning backtrace suppression works.
>
> Tests cover both API forms:
> - Scoped: kunit_warning_suppress() with in-block count verification
> and post-block inactivity check.
> - Direct functions: kunit_start/end_suppress_warning() with
> sequential independent suppression blocks and per-block counts.
>
> Furthermore, tests verify incremental warning counting, that
> kunit_has_active_suppress_warning() transitions correctly around
> suppression boundaries, and that suppression active in the test
> kthread does not leak to a separate kthread.
>
> If backtrace suppression does _not_ work, the unit tests will likely
> trigger unsuppressed backtraces, which should actually help to get
> the affected architectures / platforms fixed.
>
Another set of sashiko comments for this patch
https://sashiko.dev/#/patchset/20260515-kunit_add_support-v13-0-18ee42f96e7b%40redhat.com?part=2
here:
1. CPU spike from while (!kthread_should_stop()) schedule()
Ha! I expected this one because I saw it in a previous review from the
bot. schedule() from TASK_RUNNING yields the CPU; it does not
spin-wait. The thread is rescheduled only when the scheduler gives it
time, not in a tight loop. But the important thing is that the window
where this loop actually runs is negligible: the parent calls
kthread_stop() immediately after wait_for_completion() returns. Using
set_current_state(TASK_INTERRUPTIBLE) would be slightly more
CPU-friendly, but for a test that probably runs and exits in
microseconds, it makes no practical difference. And it unnecessarily
adds complexity.
2. Orphaned kthread on early abort
This cannot happen in this test. The only KUNIT_ASSERT_* that could
abort early is KUNIT_ASSERT_FALSE(test, IS_ERR(task)). If that
assertion fails, it means kthread_run() itself returned an error,
therefore, the kthread was never started and there is nothing to
orphan. If kthread_run() succeeds, the assertion passes, and execution
continues sequentially to kthread_stop(). No code path allows a live
kthread to exist while bypassing kthread_stop().
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
> Reviewed-by: David Gow <david@davidgow.net>
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
> lib/kunit/Makefile | 1 +
> lib/kunit/backtrace-suppression-test.c | 192 +++++++++++++++++++++++++++++++++
> 2 files changed, 193 insertions(+)
>
> diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
> index 4592f9d0aa8dd..2e8a6b71a2ab0 100644
> --- a/lib/kunit/Makefile
> +++ b/lib/kunit/Makefile
> @@ -22,6 +22,7 @@ obj-$(if $(CONFIG_KUNIT),y) += hooks.o
>
> obj-$(CONFIG_KUNIT_TEST) += kunit-test.o
> obj-$(CONFIG_KUNIT_TEST) += platform-test.o
> +obj-$(CONFIG_KUNIT_TEST) += backtrace-suppression-test.o
>
> # string-stream-test compiles built-in only.
> ifeq ($(CONFIG_KUNIT_TEST),y)
> diff --git a/lib/kunit/backtrace-suppression-test.c b/lib/kunit/backtrace-suppression-test.c
> new file mode 100644
> index 0000000000000..59a038b2739f5
> --- /dev/null
> +++ b/lib/kunit/backtrace-suppression-test.c
> @@ -0,0 +1,192 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit test for suppressing warning tracebacks.
> + *
> + * Copyright (C) 2024, Guenter Roeck
> + * Author: Guenter Roeck <linux@roeck-us.net>
> + */
> +
> +#include <kunit/test.h>
> +#include <linux/bug.h>
> +#include <linux/completion.h>
> +#include <linux/kthread.h>
> +
> +static void backtrace_suppression_test_warn_direct(struct kunit *test)
> +{
> + if (!IS_ENABLED(CONFIG_BUG))
> + kunit_skip(test, "requires CONFIG_BUG");
> +
> + kunit_warning_suppress(test) {
> + WARN(1, "This backtrace should be suppressed");
> + /*
> + * Count must be checked inside the scope; the handle
> + * is not accessible after the block exits.
> + */
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> + }
> + KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
> +}
> +
> +static noinline void trigger_backtrace_warn(void)
> +{
> + WARN(1, "This backtrace should be suppressed");
> +}
> +
> +static void backtrace_suppression_test_warn_indirect(struct kunit *test)
> +{
> + if (!IS_ENABLED(CONFIG_BUG))
> + kunit_skip(test, "requires CONFIG_BUG");
> +
> + kunit_warning_suppress(test) {
> + trigger_backtrace_warn();
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> + }
> +}
> +
> +static void backtrace_suppression_test_warn_multi(struct kunit *test)
> +{
> + if (!IS_ENABLED(CONFIG_BUG))
> + kunit_skip(test, "requires CONFIG_BUG");
> +
> + kunit_warning_suppress(test) {
> + WARN(1, "This backtrace should be suppressed");
> + trigger_backtrace_warn();
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 2);
> + }
> +}
> +
> +static void backtrace_suppression_test_warn_on_direct(struct kunit *test)
> +{
> + if (!IS_ENABLED(CONFIG_BUG))
> + kunit_skip(test, "requires CONFIG_BUG");
> +
> + kunit_warning_suppress(test) {
> + WARN_ON(1);
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> + }
> +}
> +
> +static noinline void trigger_backtrace_warn_on(void)
> +{
> + WARN_ON(1);
> +}
> +
> +static void backtrace_suppression_test_warn_on_indirect(struct kunit *test)
> +{
> + if (!IS_ENABLED(CONFIG_BUG))
> + kunit_skip(test, "requires CONFIG_BUG");
> +
> + kunit_warning_suppress(test) {
> + trigger_backtrace_warn_on();
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> + }
> +}
> +
> +static void backtrace_suppression_test_count(struct kunit *test)
> +{
> + if (!IS_ENABLED(CONFIG_BUG))
> + kunit_skip(test, "requires CONFIG_BUG");
> +
> + kunit_warning_suppress(test) {
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 0);
> +
> + WARN(1, "suppressed");
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> +
> + WARN(1, "suppressed again");
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 2);
> + }
> +}
> +
> +static void backtrace_suppression_test_active_state(struct kunit *test)
> +{
> + KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
> +
> + kunit_warning_suppress(test) {
> + KUNIT_EXPECT_TRUE(test, kunit_has_active_suppress_warning());
> + }
> +
> + KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
> +
> + kunit_warning_suppress(test) {
> + KUNIT_EXPECT_TRUE(test, kunit_has_active_suppress_warning());
> + }
> +
> + KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
> +}
> +
> +static void backtrace_suppression_test_multi_scope(struct kunit *test)
> +{
> + struct kunit_suppressed_warning *sw1, *sw2;
> +
> + if (!IS_ENABLED(CONFIG_BUG))
> + kunit_skip(test, "requires CONFIG_BUG");
> +
> + sw1 = kunit_start_suppress_warning(test);
> + trigger_backtrace_warn_on();
> + WARN(1, "suppressed by sw1");
> + kunit_end_suppress_warning(test, sw1);
> +
> + sw2 = kunit_start_suppress_warning(test);
> + WARN(1, "suppressed by sw2");
> + kunit_end_suppress_warning(test, sw2);
> +
> + KUNIT_EXPECT_EQ(test, kunit_suppressed_warning_count(sw1), 2);
> + KUNIT_EXPECT_EQ(test, kunit_suppressed_warning_count(sw2), 1);
> +}
> +
> +struct cross_kthread_data {
> + bool was_active;
> + struct completion done;
> +};
> +
> +static int cross_kthread_fn(void *data)
> +{
> + struct cross_kthread_data *d = data;
> +
> + d->was_active = kunit_has_active_suppress_warning();
> + complete(&d->done);
> + while (!kthread_should_stop())
> + schedule();
> + return 0;
> +}
> +
> +static void backtrace_suppression_test_cross_kthread(struct kunit *test)
> +{
> + struct cross_kthread_data data;
> + struct task_struct *task;
> +
> + data.was_active = false;
> + init_completion(&data.done);
> +
> + kunit_warning_suppress(test) {
> + task = kthread_run(cross_kthread_fn, &data, "kunit-cross-test");
> + KUNIT_ASSERT_FALSE(test, IS_ERR(task));
> + wait_for_completion(&data.done);
> + kthread_stop(task);
> + }
> +
> + KUNIT_EXPECT_FALSE(test, data.was_active);
> +}
> +
> +static struct kunit_case backtrace_suppression_test_cases[] = {
> + KUNIT_CASE(backtrace_suppression_test_warn_direct),
> + KUNIT_CASE(backtrace_suppression_test_warn_indirect),
> + KUNIT_CASE(backtrace_suppression_test_warn_multi),
> + KUNIT_CASE(backtrace_suppression_test_warn_on_direct),
> + KUNIT_CASE(backtrace_suppression_test_warn_on_indirect),
> + KUNIT_CASE(backtrace_suppression_test_count),
> + KUNIT_CASE(backtrace_suppression_test_active_state),
> + KUNIT_CASE(backtrace_suppression_test_multi_scope),
> + KUNIT_CASE(backtrace_suppression_test_cross_kthread),
> + {}
> +};
> +
> +static struct kunit_suite backtrace_suppression_test_suite = {
> + .name = "backtrace-suppression-test",
> + .test_cases = backtrace_suppression_test_cases,
> +};
> +kunit_test_suites(&backtrace_suppression_test_suite);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("KUnit test to verify warning backtrace suppression");
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v2 5/6] misc: amd-sbi: Add SBTSI ioctl register transfer interface
From: Guenter Roeck @ 2026-05-15 14:11 UTC (permalink / raw)
To: Akshay Gupta, linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, arnd, gregkh, naveenkrishna.chatradhi, Prathima.Lk,
Anand.Umarji, Kevin.Tung
In-Reply-To: <20260515134506.397649-6-Akshay.Gupta@amd.com>
On 5/15/26 06:45, Akshay Gupta wrote:
> From: Prathima <Prathima.Lk@amd.com>
>
> Implement IOCTL interface for SB-TSI driver to enable userspace access
> to TSI register read/write operations through the AMD Advanced Platform
> Management Link (APML) protocol.
> Add an ioctl command (SBTSI_IOCTL_REG_XFER_CMD) that accepts a register
> address, data byte, and direction flag. Serialize access with a mutex
> shared between the hwmon and ioctl paths to prevent concurrent bus
> transactions from corrupting register state.
>
> Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Prathima <Prathima.Lk@amd.com>
> ---
> Changes since v1:
> - Use of devm_mutex_init in place of mutex_init
> - Use of guard_mutex in place of mutex_lock()/mutex_unlock()
> - Use of devm_add_action_or_reset() for clean removal
>
> drivers/hwmon/sbtsi_temp.c | 6 +++
> drivers/misc/amd-sbi/tsi-core.c | 84 ++++++++++++++++++++++++++++++++-
> drivers/misc/amd-sbi/tsi-core.h | 15 ++++++
> drivers/misc/amd-sbi/tsi.c | 20 ++++++--
> include/linux/misc/tsi.h | 8 ++++
> include/uapi/misc/amd-apml.h | 23 +++++++++
> 6 files changed, 151 insertions(+), 5 deletions(-)
> create mode 100644 drivers/misc/amd-sbi/tsi-core.h
>
> diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
> index d7ae986d824c..00e982f4c716 100644
> --- a/drivers/hwmon/sbtsi_temp.c
> +++ b/drivers/hwmon/sbtsi_temp.c
> @@ -64,12 +64,15 @@ static inline void sbtsi_mc_to_reg(s32 temp, u8 *integer, u8 *decimal)
> /*
> * Read integer and decimal parts of an SB-TSI temperature register pair
> * The read order is determined by the ReadOrder bit to ensure atomic latching.
> + * The mutex protects against concurrent access to the shared I2C/I3C bus by
> + * the hwmon sysfs and a userspace ioctl
> */
> static int sbtsi_temp_read(struct sbtsi_data *data, u8 reg1, u8 reg2,
> u8 *val1, u8 *val2)
> {
> int ret;
>
> + guard(mutex)(&data->lock);
I would suggest to hide this behind access functions such as sbtsi_lock(),
sbtsi_unlock(), and the matching guard functions. That can be done in a
separate patch; it should not be necessary to include hwmon in the patch
introducing the ioctl.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] Documentation: fix typo and formattting in security/credentials.rst
From: Jonathan Corbet @ 2026-05-15 14:10 UTC (permalink / raw)
To: Mayank Gite, Paul Moore
Cc: Mayank Gite, Serge Hallyn, Shuah Khan, linux-security-module,
linux-doc, linux-kernel
In-Reply-To: <20260506225925.271163-1-drapl0n.kernel@gmail.com>
Mayank Gite <drapl0n.kernel@gmail.com> writes:
> - Fixes a typo in "Keys and keyrings" section. Replaces "keying" with
> "keyring".
> - Updates formatting of keyring types.
>
> Signed-off-by: Mayank Gite <drapl0n.kernel@gmail.com>
> ---
> Documentation/security/credentials.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
> index d0191c8b8060..4996838491b1 100644
> --- a/Documentation/security/credentials.rst
> +++ b/Documentation/security/credentials.rst
> @@ -189,9 +189,9 @@ The Linux kernel supports the following types of credentials:
> be searched for the desired key. Each process may subscribe to a number
> of keyrings:
>
> - Per-thread keying
> - Per-process keyring
> - Per-session keyring
> + - Per-thread keyring
> + - Per-process keyring
> + - Per-session keyring
>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v3 00/13] Improve process/maintainers output
From: Jonathan Corbet @ 2026-05-15 14:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Miguel Ojeda
Cc: Mauro Carvalho Chehab, linux-doc, linux-kernel, rust-for-linux,
Björn Roy Baron, Alice Ryhl, Andreas Hindborg, Andrew Morton,
Benno Lossin, Boqun Feng, Danilo Krummrich, Gary Guo, Joe Perches,
Matteo Croce, Shuah Khan, Trevor Gross
In-Reply-To: <cover.1778309595.git.mchehab+huawei@kernel.org>
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> Hi Jon,
>
> This series improve the output at process/maintainers: instead of a
> pure enriched text, the maintainer's file content is now converted
> to a table, and has gained a javascript to allow filtering entries.
OK, I've applied it. I've wondered about including the MAINTAINERS
stuff, but I must admit that the search box is kind of cool...
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