* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 21:24 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <e5ca4be6-6919-4855-bb7f-bd36761eab0f@infradead.org>
On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
...
> > -The header file include/linux/kernel.h contains a number of macros that
> > +There many header files in include/linux/ that contain a number of macros that
>
> There are many
>
> > you should use, rather than explicitly coding some variant of them yourself.
> > For example, if you need to calculate the length of an array, take advantage
> > of the macro
>
> Otherwise LGTM. Thanks.
>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks!
Can you also test it? I hope it will be not so broken (as some of the files
seems never were before in the generated docs).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-26 21:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <aSdwIN6qA-66hYhm@smile.fi.intel.com>
On 11/26/25 1:24 PM, Andy Shevchenko wrote:
> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
>
> ...
>
>>> -The header file include/linux/kernel.h contains a number of macros that
>>> +There many header files in include/linux/ that contain a number of macros that
>>
>> There are many
>>
>>> you should use, rather than explicitly coding some variant of them yourself.
>>> For example, if you need to calculate the length of an array, take advantage
>>> of the macro
>>
>> Otherwise LGTM. Thanks.
>>
>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>
> Thanks!
>
> Can you also test it? I hope it will be not so broken (as some of the files
> seems never were before in the generated docs).
It's not completely happy:
linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
--
~Randy
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-26 21:36 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <8d68b0b7-ee9e-4121-aa85-19fbf8470fdc@infradead.org>
On 11/26/25 1:33 PM, Randy Dunlap wrote:
>
>
> On 11/26/25 1:24 PM, Andy Shevchenko wrote:
>> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
>>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
>>
>> ...
>>
>>>> -The header file include/linux/kernel.h contains a number of macros that
>>>> +There many header files in include/linux/ that contain a number of macros that
>>>
>>> There are many
>>>
>>>> you should use, rather than explicitly coding some variant of them yourself.
>>>> For example, if you need to calculate the length of an array, take advantage
>>>> of the macro
>>>
>>> Otherwise LGTM. Thanks.
>>>
>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>>
>> Thanks!
>>
>> Can you also test it? I hope it will be not so broken (as some of the files
>> seems never were before in the generated docs).
>
> It's not completely happy:
>
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
>
>
This little change fixes it for me. Just include it in your patch, please.
---
include/linux/util_macros.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20251126.orig/include/linux/util_macros.h
+++ linux-next-20251126/include/linux/util_macros.h
@@ -119,7 +119,7 @@
* a fuss about it. This makes the programmer responsible for tagging
* the functions that can be garbage-collected.
*
- * With the macro it is possible to write the following:
+ * With the macro it is possible to write the following::
*
* static int foo_suspend(struct device *dev)
* {
--
~Randy
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 21:37 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <8d68b0b7-ee9e-4121-aa85-19fbf8470fdc@infradead.org>
On Wed, Nov 26, 2025 at 01:33:13PM -0800, Randy Dunlap wrote:
> On 11/26/25 1:24 PM, Andy Shevchenko wrote:
> > On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
> >> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
...
> >>> -The header file include/linux/kernel.h contains a number of macros that
> >>> +There many header files in include/linux/ that contain a number of macros that
> >>
> >> There are many
> >>
> >>> you should use, rather than explicitly coding some variant of them yourself.
> >>> For example, if you need to calculate the length of an array, take advantage
> >>> of the macro
> >>
> >> Otherwise LGTM. Thanks.
> >>
> >> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> >
> > Thanks!
> >
> > Can you also test it? I hope it will be not so broken (as some of the files
> > seems never were before in the generated docs).
>
> It's not completely happy:
A-ha, thanks for trying!
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
I will look at it tomorrow, but can you remove this (or even fix) and check the
rest meanwhile?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-26 21:39 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <aSdzHqxI-iDsksao@smile.fi.intel.com>
On 11/26/25 1:37 PM, Andy Shevchenko wrote:
> On Wed, Nov 26, 2025 at 01:33:13PM -0800, Randy Dunlap wrote:
>> On 11/26/25 1:24 PM, Andy Shevchenko wrote:
>>> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
>>>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
>
> ...
>
>>>>> -The header file include/linux/kernel.h contains a number of macros that
>>>>> +There many header files in include/linux/ that contain a number of macros that
>>>>
>>>> There are many
>>>>
>>>>> you should use, rather than explicitly coding some variant of them yourself.
>>>>> For example, if you need to calculate the length of an array, take advantage
>>>>> of the macro
>>>>
>>>> Otherwise LGTM. Thanks.
>>>>
>>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>>>
>>> Thanks!
>>>
>>> Can you also test it? I hope it will be not so broken (as some of the files
>>> seems never were before in the generated docs).
>>
>> It's not completely happy:
>
> A-ha, thanks for trying!
>
>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
>
>
> I will look at it tomorrow, but can you remove this (or even fix) and check the
> rest meanwhile?
That was the only docs warnings caused by your patch (at least in my testing).
and now easily fixed.
--
~Randy
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 21:39 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <aSdzHqxI-iDsksao@smile.fi.intel.com>
On Wed, Nov 26, 2025 at 11:37:40PM +0200, Andy Shevchenko wrote:
> On Wed, Nov 26, 2025 at 01:33:13PM -0800, Randy Dunlap wrote:
> > On 11/26/25 1:24 PM, Andy Shevchenko wrote:
> > > On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
> > >> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
...
> > >>> -The header file include/linux/kernel.h contains a number of macros that
> > >>> +There many header files in include/linux/ that contain a number of macros that
> > >>
> > >> There are many
> > >>
> > >>> you should use, rather than explicitly coding some variant of them yourself.
> > >>> For example, if you need to calculate the length of an array, take advantage
> > >>> of the macro
> > >>
> > >> Otherwise LGTM. Thanks.
> > >>
> > >> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> > >
> > > Thanks!
> > >
> > > Can you also test it? I hope it will be not so broken (as some of the files
> > > seems never were before in the generated docs).
> >
> > It's not completely happy:
>
> A-ha, thanks for trying!
>
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
>
>
> I will look at it tomorrow, but can you remove this (or even fix) and check the
> rest meanwhile?
At glance seems like colon is missing, should be :: instead of : in near lines.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-26 21:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <aSdzo8aOns_3oPQA@smile.fi.intel.com>
On 11/26/25 1:39 PM, Andy Shevchenko wrote:
> On Wed, Nov 26, 2025 at 11:37:40PM +0200, Andy Shevchenko wrote:
>> On Wed, Nov 26, 2025 at 01:33:13PM -0800, Randy Dunlap wrote:
>>> On 11/26/25 1:24 PM, Andy Shevchenko wrote:
>>>> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
>>>>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
>
> ...
>
>>>>>> -The header file include/linux/kernel.h contains a number of macros that
>>>>>> +There many header files in include/linux/ that contain a number of macros that
>>>>>
>>>>> There are many
>>>>>
>>>>>> you should use, rather than explicitly coding some variant of them yourself.
>>>>>> For example, if you need to calculate the length of an array, take advantage
>>>>>> of the macro
>>>>>
>>>>> Otherwise LGTM. Thanks.
>>>>>
>>>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>>>>
>>>> Thanks!
>>>>
>>>> Can you also test it? I hope it will be not so broken (as some of the files
>>>> seems never were before in the generated docs).
>>>
>>> It's not completely happy:
>>
>> A-ha, thanks for trying!
>>
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
>>
>>
>> I will look at it tomorrow, but can you remove this (or even fix) and check the
>> rest meanwhile?
>
> At glance seems like colon is missing, should be :: instead of : in near lines.
>
Yes, that's what I sent earlier :)
--
~Randy
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 21:42 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <9e0b0711-b558-4f58-9f6a-3463cbc50669@infradead.org>
On Wed, Nov 26, 2025 at 01:36:44PM -0800, Randy Dunlap wrote:
> On 11/26/25 1:33 PM, Randy Dunlap wrote:
> > On 11/26/25 1:24 PM, Andy Shevchenko wrote:
> >> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
> >>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
...
> >>>> -The header file include/linux/kernel.h contains a number of macros that
> >>>> +There many header files in include/linux/ that contain a number of macros that
> >>>
> >>> There are many
> >>>
> >>>> you should use, rather than explicitly coding some variant of them yourself.
> >>>> For example, if you need to calculate the length of an array, take advantage
> >>>> of the macro
> >>>
> >>> Otherwise LGTM. Thanks.
> >>>
> >>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> >>
> >> Thanks!
> >>
> >> Can you also test it? I hope it will be not so broken (as some of the files
> >> seems never were before in the generated docs).
> >
> > It's not completely happy:
> >
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
> >
>
> This little change fixes it for me. Just include it in your patch, please.
Thanks, just 15 sec before your message I guessed the same fix.
> ---
> include/linux/util_macros.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20251126.orig/include/linux/util_macros.h
> +++ linux-next-20251126/include/linux/util_macros.h
> @@ -119,7 +119,7 @@
> * a fuss about it. This makes the programmer responsible for tagging
> * the functions that can be garbage-collected.
> *
> - * With the macro it is possible to write the following:
> + * With the macro it is possible to write the following::
> *
> * static int foo_suspend(struct device *dev)
> * {
Since it's like this, I just fix both places you pointed out and issue a v2.
May I have ypour Tested-by ten?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-26 21:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <aSd0SvaYlIX1HElt@smile.fi.intel.com>
On 11/26/25 1:42 PM, Andy Shevchenko wrote:
> On Wed, Nov 26, 2025 at 01:36:44PM -0800, Randy Dunlap wrote:
>> On 11/26/25 1:33 PM, Randy Dunlap wrote:
>>> On 11/26/25 1:24 PM, Andy Shevchenko wrote:
>>>> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
>>>>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
>
> ...
>
>>>>>> -The header file include/linux/kernel.h contains a number of macros that
>>>>>> +There many header files in include/linux/ that contain a number of macros that
>>>>>
>>>>> There are many
>>>>>
>>>>>> you should use, rather than explicitly coding some variant of them yourself.
>>>>>> For example, if you need to calculate the length of an array, take advantage
>>>>>> of the macro
>>>>>
>>>>> Otherwise LGTM. Thanks.
>>>>>
>>>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>>>>
>>>> Thanks!
>>>>
>>>> Can you also test it? I hope it will be not so broken (as some of the files
>>>> seems never were before in the generated docs).
>>>
>>> It's not completely happy:
>>>
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
>>>
>>
>> This little change fixes it for me. Just include it in your patch, please.
>
> Thanks, just 15 sec before your message I guessed the same fix.
>
>> ---
>> include/linux/util_macros.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --- linux-next-20251126.orig/include/linux/util_macros.h
>> +++ linux-next-20251126/include/linux/util_macros.h
>> @@ -119,7 +119,7 @@
>> * a fuss about it. This makes the programmer responsible for tagging
>> * the functions that can be garbage-collected.
>> *
>> - * With the macro it is possible to write the following:
>> + * With the macro it is possible to write the following::
>> *
>> * static int foo_suspend(struct device *dev)
>> * {
>
> Since it's like this, I just fix both places you pointed out and issue a v2.
> May I have ypour Tested-by ten?
Yes.
Tested-by: Randy Dunlap <rdunlap@infradead.org>
--
~Randy
^ permalink raw reply
* [PATCH v2 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 21:46 UTC (permalink / raw)
To: Randy Dunlap, Andy Shevchenko, Dr. David Alan Gilbert, linux-doc,
linux-kernel, workflows, linux-remoteproc
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Bjorn Andersson, Mathieu Poirier
For several years, and still ongoing, the kernel.h is being split
to smaller and narrow headers to avoid "including everything" approach
which is bad in many ways. Since that, documentation missed a few
required updates to align with that work. Do it here.
Note, language translations are left untouched and if anybody willing
to help, please provide path(es) based on the updated English variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
---
v2: collected tag (Randy), fixed util_macros k-doc (Randy, me), fixed spelling (Randy)
Documentation/core-api/kobject.rst | 2 +-
Documentation/dev-tools/checkpatch.rst | 2 +-
Documentation/driver-api/basics.rst | 17 ++++++++++++++++-
.../driver-api/driver-model/design-patterns.rst | 2 +-
Documentation/process/coding-style.rst | 10 +++++++---
Documentation/staging/rpmsg.rst | 7 +++++--
include/linux/util_macros.h | 2 +-
7 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/Documentation/core-api/kobject.rst b/Documentation/core-api/kobject.rst
index 7310247310a0..5f6c61bc03bf 100644
--- a/Documentation/core-api/kobject.rst
+++ b/Documentation/core-api/kobject.rst
@@ -78,7 +78,7 @@ just a matter of using the kobj member. Code that works with kobjects will
often have the opposite problem, however: given a struct kobject pointer,
what is the pointer to the containing structure? You must avoid tricks
(such as assuming that the kobject is at the beginning of the structure)
-and, instead, use the container_of() macro, found in ``<linux/kernel.h>``::
+and, instead, use the container_of() macro, found in ``<linux/container_of.h>``::
container_of(ptr, type, member)
diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index fa2988dd4657..c1dff8e6bccb 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -753,7 +753,7 @@ Macros, Attributes and Symbols
sizeof(foo)/sizeof(foo[0]) for finding number of elements in an
array.
- The macro is defined in include/linux/kernel.h::
+ The macro is defined in include/linux/array_size.h::
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst
index 5e9f7aee71a7..8b6a5888cb11 100644
--- a/Documentation/driver-api/basics.rst
+++ b/Documentation/driver-api/basics.rst
@@ -114,10 +114,25 @@ Kernel objects manipulation
Kernel utility functions
------------------------
-.. kernel-doc:: include/linux/kernel.h
+.. kernel-doc:: include/linux/array_size.h
+ :internal:
+
+.. kernel-doc:: include/linux/container_of.h
+ :internal:
+
+.. kernel-doc:: include/linux/kstrtox.h
:internal:
:no-identifiers: kstrtol kstrtoul
+.. kernel-doc:: include/linux/stddef.h
+ :internal:
+
+.. kernel-doc:: include/linux/util_macros.h
+ :internal:
+
+.. kernel-doc:: include/linux/wordpart.h
+ :internal:
+
.. kernel-doc:: kernel/printk/printk.c
:export:
:no-identifiers: printk
diff --git a/Documentation/driver-api/driver-model/design-patterns.rst b/Documentation/driver-api/driver-model/design-patterns.rst
index 41eb8f41f7dd..965b2b93be6f 100644
--- a/Documentation/driver-api/driver-model/design-patterns.rst
+++ b/Documentation/driver-api/driver-model/design-patterns.rst
@@ -103,7 +103,7 @@ The design pattern is the same for an hrtimer or something similar that will
return a single argument which is a pointer to a struct member in the
callback.
-container_of() is a macro defined in <linux/kernel.h>
+container_of() is a macro defined in <linux/container_of.h>
What container_of() does is to obtain a pointer to the containing struct from
a pointer to a member by a simple subtraction using the offsetof() macro from
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 2969ca378dbb..258158637f65 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -1070,7 +1070,7 @@ readability.
18) Don't re-invent the kernel macros
-------------------------------------
-The header file include/linux/kernel.h contains a number of macros that
+There are many header files in include/linux/ that contain a number of macros that
you should use, rather than explicitly coding some variant of them yourself.
For example, if you need to calculate the length of an array, take advantage
of the macro
@@ -1079,14 +1079,18 @@ of the macro
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+which is defined in array_size.h.
+
Similarly, if you need to calculate the size of some structure member, use
.. code-block:: c
#define sizeof_field(t, f) (sizeof(((t*)0)->f))
-There are also min() and max() macros that do strict type checking if you
-need them. Feel free to peruse that header file to see what else is already
+which is defined in stddef.h.
+
+There are also min() and max() macros defined in minmax.h that do strict type checking
+if you need them. Feel free to peruse the header files to see what else is already
defined that you shouldn't reproduce in your code.
diff --git a/Documentation/staging/rpmsg.rst b/Documentation/staging/rpmsg.rst
index 40282cca86ca..42bac1149d9d 100644
--- a/Documentation/staging/rpmsg.rst
+++ b/Documentation/staging/rpmsg.rst
@@ -224,9 +224,12 @@ content to the console.
::
- #include <linux/kernel.h>
+ #include <linux/dev_printk.h>
+ #include <linux/mod_devicetable.h>
#include <linux/module.h>
+ #include <linux/printk.h>
#include <linux/rpmsg.h>
+ #include <linux/types.h>
static void rpmsg_sample_cb(struct rpmsg_channel *rpdev, void *data, int len,
void *priv, u32 src)
@@ -244,7 +247,7 @@ content to the console.
/* send a message on our channel */
err = rpmsg_send(rpdev->ept, "hello!", 6);
if (err) {
- pr_err("rpmsg_send failed: %d\n", err);
+ dev_err(&rpdev->dev, "rpmsg_send failed: %d\n", err);
return err;
}
diff --git a/include/linux/util_macros.h b/include/linux/util_macros.h
index 2eb528058d0d..71564868b8f6 100644
--- a/include/linux/util_macros.h
+++ b/include/linux/util_macros.h
@@ -119,7 +119,7 @@
* a fuss about it. This makes the programmer responsible for tagging
* the functions that can be garbage-collected.
*
- * With the macro it is possible to write the following:
+ * With the macro it is possible to write the following::
*
* static int foo_suspend(struct device *dev)
* {
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 21:49 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <cf6fa77c-3fe3-4262-96e4-f2cc79d6abb5@infradead.org>
On Wed, Nov 26, 2025 at 01:46:05PM -0800, Randy Dunlap wrote:
> On 11/26/25 1:42 PM, Andy Shevchenko wrote:
...
> > Since it's like this, I just fix both places you pointed out and issue a v2.
> > May I have ypour Tested-by ten?
>
> Yes.
> Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks, but I have just sent it out, please reply there.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-27 0:26 UTC (permalink / raw)
To: Andy Shevchenko, Dr. David Alan Gilbert, linux-doc, linux-kernel,
workflows, linux-remoteproc
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Bjorn Andersson, Mathieu Poirier
In-Reply-To: <20251126214709.2322314-1-andriy.shevchenko@linux.intel.com>
On 11/26/25 1:46 PM, Andy Shevchenko wrote:
> For several years, and still ongoing, the kernel.h is being split
> to smaller and narrow headers to avoid "including everything" approach
> which is bad in many ways. Since that, documentation missed a few
> required updates to align with that work. Do it here.
>
> Note, language translations are left untouched and if anybody willing
> to help, please provide path(es) based on the updated English variant.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
> ---
>
> v2: collected tag (Randy), fixed util_macros k-doc (Randy, me), fixed spelling (Randy)
>
> Documentation/core-api/kobject.rst | 2 +-
> Documentation/dev-tools/checkpatch.rst | 2 +-
> Documentation/driver-api/basics.rst | 17 ++++++++++++++++-
> .../driver-api/driver-model/design-patterns.rst | 2 +-
> Documentation/process/coding-style.rst | 10 +++++++---
> Documentation/staging/rpmsg.rst | 7 +++++--
> include/linux/util_macros.h | 2 +-
> 7 files changed, 32 insertions(+), 10 deletions(-)
>
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Joe Perches @ 2025-11-27 17:34 UTC (permalink / raw)
To: Andy Shevchenko, Randy Dunlap, Dr. David Alan Gilbert, linux-doc,
linux-kernel, workflows, linux-remoteproc
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn, Bjorn Andersson,
Mathieu Poirier
In-Reply-To: <20251126214709.2322314-1-andriy.shevchenko@linux.intel.com>
On Wed, 2025-11-26 at 22:46 +0100, Andy Shevchenko wrote:
> For several years, and still ongoing, the kernel.h is being split
> to smaller and narrow headers to avoid "including everything" approach
> which is bad in many ways.
And I still think precompiled headers can be beneficial to
standardize using kernel.h to reduce overall compilation time.
^ permalink raw reply
* Re: [PATCH v2 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-27 18:19 UTC (permalink / raw)
To: Joe Perches
Cc: Randy Dunlap, Dr. David Alan Gilbert, linux-doc, linux-kernel,
workflows, linux-remoteproc, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Jonathan Corbet,
Dwaipayan Ray, Lukas Bulwahn, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <0fe4a563da5316ef702d7c324d0820c8c2c224e7.camel@perches.com>
On Thu, Nov 27, 2025 at 09:34:51AM -0800, Joe Perches wrote:
> On Wed, 2025-11-26 at 22:46 +0100, Andy Shevchenko wrote:
> > For several years, and still ongoing, the kernel.h is being split
> > to smaller and narrow headers to avoid "including everything" approach
> > which is bad in many ways.
>
> And I still think precompiled headers can be beneficial to
> standardize using kernel.h to reduce overall compilation time.
Same Q, why don't we have just a single header? Why do we have a concept of
(modular) headers to begin with? And Ingo's approach shows that the problem
can be solved properly by dividing headers to be more logical smaller pieces.
So, I have a strong disagreement for using kernel.h. At least not in this form,
It needs to be cleaned up and some sanity given to that train wreck. When it's
done, we can think of precompiled headers.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-29 15:24 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <a731c794-1b4c-4ea7-9cf1-0210b95eaa4d@infradead.org>
On Wed, Nov 26, 2025 at 04:26:04PM -0800, Randy Dunlap wrote:
> On 11/26/25 1:46 PM, Andy Shevchenko wrote:
> > For several years, and still ongoing, the kernel.h is being split
> > to smaller and narrow headers to avoid "including everything" approach
> > which is bad in many ways. Since that, documentation missed a few
> > required updates to align with that work. Do it here.
> >
> > Note, language translations are left untouched and if anybody willing
> > to help, please provide path(es) based on the updated English variant.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>
> Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks, Randy!
Jonathan, please apply this change. Independently on the opinions about
kernel.h the documentation has to be updated as it's currently misleading.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] docs: submitting-patches: Clarify that removal of Acks needs explanation too
From: Jonathan Corbet @ 2025-11-29 15:31 UTC (permalink / raw)
To: Krzysztof Kozlowski, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20251126081905.7684-2-krzysztof.kozlowski@oss.qualcomm.com>
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> writes:
> The paragraph mentions only removal of Tested-by and Reviewed-by tags as
> action needing mentioning in patch changelog, so some developers treat
> it too literally. Acks, as a weaker form of review/approval, should
> rarely be removed, but if that happens it should be explained as well.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> Documentation/process/submitting-patches.rst | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 910e8fc9e3c8..9a509f1a6873 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -592,8 +592,9 @@ Both Tested-by and Reviewed-by tags, once received on mailing list from tester
> or reviewer, should be added by author to the applicable patches when sending
> next versions. However if the patch has changed substantially in following
> version, these tags might not be applicable anymore and thus should be removed.
> -Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned
> -in the patch changelog (after the '---' separator).
> +Usually removal of someone's Acked-by, Tested-by or Reviewed-by tags should be
> +mentioned in the patch changelog with an explanation (after the '---'
> +separator).
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v5] README: restructure with role-based documentation and guidelines
From: Jonathan Corbet @ 2025-11-29 15:42 UTC (permalink / raw)
To: Sasha Levin, linux-doc
Cc: josh, kees, konstantin, linux-kernel, rostedt, workflows, joe,
rdunlap, Sasha Levin, Mauro Carvalho Chehab
In-Reply-To: <20251121180009.2634393-1-sashal@kernel.org>
Sasha Levin <sashal@kernel.org> writes:
> Reorganize README to provide targeted documentation paths for different user
> roles including developers, researchers, security experts, and maintainers.
>
> Add quick start section and essential docs links.
>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
> ---
>
> Changes since v4:
>
> - Remove explicit reference to GPLv2
> - Fix up the commit message to drop AI blurb
>
> README | 160 +++++++++++++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 149 insertions(+), 11 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Jonathan Corbet @ 2025-11-29 15:54 UTC (permalink / raw)
To: Andy Shevchenko, Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Bjorn Andersson, Mathieu Poirier
In-Reply-To: <aSsQFjv5DK_7GS6P@smile.fi.intel.com>
Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> On Wed, Nov 26, 2025 at 04:26:04PM -0800, Randy Dunlap wrote:
>> On 11/26/25 1:46 PM, Andy Shevchenko wrote:
>> > For several years, and still ongoing, the kernel.h is being split
>> > to smaller and narrow headers to avoid "including everything" approach
>> > which is bad in many ways. Since that, documentation missed a few
>> > required updates to align with that work. Do it here.
>> >
>> > Note, language translations are left untouched and if anybody willing
>> > to help, please provide path(es) based on the updated English variant.
>> >
>> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> > Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>>
>> Tested-by: Randy Dunlap <rdunlap@infradead.org>
>
> Thanks, Randy!
>
> Jonathan, please apply this change. Independently on the opinions about
> kernel.h the documentation has to be updated as it's currently misleading.
I will but not right away...I'm really trying to stabilize things,
already too late, for the merge window.
jon
^ permalink raw reply
* Re: [PATCH v2 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-29 17:46 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Randy Dunlap, Dr. David Alan Gilbert, linux-doc, linux-kernel,
workflows, linux-remoteproc, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <87wm38vnp3.fsf@trenco.lwn.net>
On Sat, Nov 29, 2025 at 08:54:48AM -0700, Jonathan Corbet wrote:
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> > On Wed, Nov 26, 2025 at 04:26:04PM -0800, Randy Dunlap wrote:
> >> On 11/26/25 1:46 PM, Andy Shevchenko wrote:
> >> > For several years, and still ongoing, the kernel.h is being split
> >> > to smaller and narrow headers to avoid "including everything" approach
> >> > which is bad in many ways. Since that, documentation missed a few
> >> > required updates to align with that work. Do it here.
> >> >
> >> > Note, language translations are left untouched and if anybody willing
> >> > to help, please provide path(es) based on the updated English variant.
> >> >
> >> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >> > Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> >>
> >> Tested-by: Randy Dunlap <rdunlap@infradead.org>
> >
> > Thanks, Randy!
> >
> > Jonathan, please apply this change. Independently on the opinions about
> > kernel.h the documentation has to be updated as it's currently misleading.
>
> I will but not right away...I'm really trying to stabilize things,
> already too late, for the merge window.
Noted, thanks for explanation!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] Documentation: Improve wording on requirements for a free Nitrokey
From: Uwe Kleine-König @ 2025-12-03 7:43 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Konstantin Ryabitsev, workflows, linux-doc
"listed in MAINTAINERS" is not enough to qualify for the free Nitrokey
Start. You have to be listed in an M: entry. Mention that to reduce
confusion for reviewers who wonder why their application fails.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
Documentation/process/maintainer-pgp-guide.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
index b6919bf606c3..2e4da3de25d4 100644
--- a/Documentation/process/maintainer-pgp-guide.rst
+++ b/Documentation/process/maintainer-pgp-guide.rst
@@ -405,8 +405,8 @@ geographical region, and open/proprietary hardware considerations.
.. note::
- If you are listed in MAINTAINERS or have an account at kernel.org,
- you `qualify for a free Nitrokey Start`_ courtesy of The Linux
+ If you are listed in an `M:` entry in MAINTAINERS or have an account at
+ kernel.org, you `qualify for a free Nitrokey Start`_ courtesy of The Linux
Foundation.
.. _`Nitrokey Start`: https://www.nitrokey.com/products/nitrokeys
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
--
2.47.3
^ permalink raw reply related
* [PATCH v7] checkpatch: add uninitialized pointer with __free attribute check
From: Ally Heev @ 2025-12-03 15:28 UTC (permalink / raw)
To: Dwaipayan Ray, Lukas Bulwahn, Joe Perches, Jonathan Corbet,
Andy Whitcroft
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven, James Bottomley,
Krzysztof Kozlowski, Ally Heev
uninitialized pointers with __free attribute can cause undefined
behavior as the memory randomly assigned to the pointer is freed
automatically when the pointer goes out of scope.
add check in checkpatch to detect such issues.
Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
Acked-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Ally Heev <allyheev@gmail.com>
---
Testing:
ran checkpatch.pl before and after the change on
crypto/asymmetric_keys/x509_public_key.c, which has
both initialized with NULL and uninitialized pointers
---
Changes in v7:
- RESEND. Also, added Reviewed-by trailer
- Link to v6: https://lore.kernel.org/r/20251125-aheev-checkpatch-uninitialized-free-v6-1-2f3a1d78f678@gmail.com
Changes in v6:
- added declaration at the place of use suggestion
- Link to v5: https://lore.kernel.org/r/20251124-aheev-checkpatch-uninitialized-free-v5-1-0c523b1a3f5a@gmail.com
Changes in v5:
- fixed checkpatch doc
- Link to v4: https://lore.kernel.org/r/20251107-aheev-checkpatch-uninitialized-free-v4-1-4822a6ac728f@gmail.com
Changes in v4:
- fixed UNINITIALIZED_PTR_WITH_FREE description
- Link to v3: https://lore.kernel.org/r/20251025-aheev-checkpatch-uninitialized-free-v3-1-a67f72b1c2bd@gmail.com
Changes in v3:
- remove $FreeAttribute
- Link to v2: https://lore.kernel.org/r/20251024-aheev-checkpatch-uninitialized-free-v2-0-16c0900e8130@gmail.com
Changes in v2:
- change cover letter and title to reflect new changes
- fix regex to handle multiple declarations in a single line case
- convert WARN to ERROR for uninitialized pointers
- add a new WARN for pointers initialized with NULL
- NOTE: tried handling multiple declarations on a single line by splitting
them and matching the parts with regex, but, it turned out to be
complex and overkill. Moreover, multi-line declarations pose a threat
- Link to v1: https://lore.kernel.org/r/20251021-aheev-checkpatch-uninitialized-free-v1-1-18fb01bc6a7a@gmail.com
---
Documentation/dev-tools/checkpatch.rst | 23 +++++++++++++++++++++++
scripts/checkpatch.pl | 6 ++++++
2 files changed, 29 insertions(+)
diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index d5c47e560324fb2399a5b1bc99c891ed1de10535..b6e02fb91e85710fecfc0a5e5c83a8e7f32d1d3c 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -1009,6 +1009,29 @@ Functions and Variables
return bar;
+ **UNINITIALIZED_PTR_WITH_FREE**
+ Pointers with __free attribute should be declared at the place of use
+ and initialized (see include/linux/cleanup.h). In this case
+ declarations at the top of the function rule can be relaxed. Not doing
+ so may lead to undefined behavior as the memory assigned (garbage,
+ in case not initialized) to the pointer is freed automatically when
+ the pointer goes out of scope.
+
+ Also see: https://lore.kernel.org/lkml/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
+
+ Example::
+
+ type var __free(free_func);
+ ... // var not used, but, in future someone might add a return here
+ var = malloc(var_size);
+ ...
+
+ should be initialized as::
+
+ ...
+ type var __free(free_func) = malloc(var_size);
+ ...
+
Permissions
-----------
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 92669904eecc7a8d2afd3f2625528e02b6d17cd6..e697d81d71c0b3628f7b59807e8bc40d582621bb 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7721,6 +7721,12 @@ sub process {
ERROR("MISSING_SENTINEL", "missing sentinel in ID array\n" . "$here\n$stat\n");
}
}
+
+# check for uninitialized pointers with __free attribute
+ while ($line =~ /\*\s*($Ident)\s+__free\s*\(\s*$Ident\s*\)\s*[,;]/g) {
+ ERROR("UNINITIALIZED_PTR_WITH_FREE",
+ "pointer '$1' with __free attribute should be initialized\n" . $herecurr);
+ }
}
# If we have no input at all, then there is nothing to report on
---
base-commit: 6548d364a3e850326831799d7e3ea2d7bb97ba08
change-id: 20251021-aheev-checkpatch-uninitialized-free-5c39f75e10a1
Best regards,
--
Ally Heev <allyheev@gmail.com>
^ permalink raw reply related
* Re: [PATCH v7] checkpatch: add uninitialized pointer with __free attribute check
From: Joe Perches @ 2025-12-03 16:53 UTC (permalink / raw)
To: Ally Heev, Dwaipayan Ray, Lukas Bulwahn, Jonathan Corbet,
Andy Whitcroft, Andrew Morton
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven, James Bottomley,
Krzysztof Kozlowski
In-Reply-To: <20251203-aheev-checkpatch-uninitialized-free-v7-1-841e3b31d8f3@gmail.com>
On Wed, 2025-12-03 at 20:58 +0530, Ally Heev wrote:
> uninitialized pointers with __free attribute can cause undefined
> behavior as the memory randomly assigned to the pointer is freed
> automatically when the pointer goes out of scope.
> add check in checkpatch to detect such issues.
>
> Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
> Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
> Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
> Acked-by: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Ally Heev <allyheev@gmail.com>
Acked-by: Joe Perches <joe@perches.com>
> ---
> Testing:
> ran checkpatch.pl before and after the change on
> crypto/asymmetric_keys/x509_public_key.c, which has
> both initialized with NULL and uninitialized pointers
> ---
> Changes in v7:
> - RESEND. Also, added Reviewed-by trailer
> - Link to v6: https://lore.kernel.org/r/20251125-aheev-checkpatch-uninitialized-free-v6-1-2f3a1d78f678@gmail.com
>
> Changes in v6:
> - added declaration at the place of use suggestion
> - Link to v5: https://lore.kernel.org/r/20251124-aheev-checkpatch-uninitialized-free-v5-1-0c523b1a3f5a@gmail.com
>
> Changes in v5:
> - fixed checkpatch doc
> - Link to v4: https://lore.kernel.org/r/20251107-aheev-checkpatch-uninitialized-free-v4-1-4822a6ac728f@gmail.com
>
> Changes in v4:
> - fixed UNINITIALIZED_PTR_WITH_FREE description
> - Link to v3: https://lore.kernel.org/r/20251025-aheev-checkpatch-uninitialized-free-v3-1-a67f72b1c2bd@gmail.com
>
> Changes in v3:
> - remove $FreeAttribute
> - Link to v2: https://lore.kernel.org/r/20251024-aheev-checkpatch-uninitialized-free-v2-0-16c0900e8130@gmail.com
>
> Changes in v2:
> - change cover letter and title to reflect new changes
> - fix regex to handle multiple declarations in a single line case
> - convert WARN to ERROR for uninitialized pointers
> - add a new WARN for pointers initialized with NULL
> - NOTE: tried handling multiple declarations on a single line by splitting
> them and matching the parts with regex, but, it turned out to be
> complex and overkill. Moreover, multi-line declarations pose a threat
> - Link to v1: https://lore.kernel.org/r/20251021-aheev-checkpatch-uninitialized-free-v1-1-18fb01bc6a7a@gmail.com
> ---
> Documentation/dev-tools/checkpatch.rst | 23 +++++++++++++++++++++++
> scripts/checkpatch.pl | 6 ++++++
> 2 files changed, 29 insertions(+)
>
> diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
> index d5c47e560324fb2399a5b1bc99c891ed1de10535..b6e02fb91e85710fecfc0a5e5c83a8e7f32d1d3c 100644
> --- a/Documentation/dev-tools/checkpatch.rst
> +++ b/Documentation/dev-tools/checkpatch.rst
> @@ -1009,6 +1009,29 @@ Functions and Variables
>
> return bar;
>
> + **UNINITIALIZED_PTR_WITH_FREE**
> + Pointers with __free attribute should be declared at the place of use
> + and initialized (see include/linux/cleanup.h). In this case
> + declarations at the top of the function rule can be relaxed. Not doing
> + so may lead to undefined behavior as the memory assigned (garbage,
> + in case not initialized) to the pointer is freed automatically when
> + the pointer goes out of scope.
> +
> + Also see: https://lore.kernel.org/lkml/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
> +
> + Example::
> +
> + type var __free(free_func);
> + ... // var not used, but, in future someone might add a return here
> + var = malloc(var_size);
> + ...
> +
> + should be initialized as::
> +
> + ...
> + type var __free(free_func) = malloc(var_size);
> + ...
> +
>
> Permissions
> -----------
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 92669904eecc7a8d2afd3f2625528e02b6d17cd6..e697d81d71c0b3628f7b59807e8bc40d582621bb 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -7721,6 +7721,12 @@ sub process {
> ERROR("MISSING_SENTINEL", "missing sentinel in ID array\n" . "$here\n$stat\n");
> }
> }
> +
> +# check for uninitialized pointers with __free attribute
> + while ($line =~ /\*\s*($Ident)\s+__free\s*\(\s*$Ident\s*\)\s*[,;]/g) {
> + ERROR("UNINITIALIZED_PTR_WITH_FREE",
> + "pointer '$1' with __free attribute should be initialized\n" . $herecurr);
> + }
> }
>
> # If we have no input at all, then there is nothing to report on
>
> ---
> base-commit: 6548d364a3e850326831799d7e3ea2d7bb97ba08
> change-id: 20251021-aheev-checkpatch-uninitialized-free-5c39f75e10a1
>
> Best regards,
^ permalink raw reply
* [PATCH v6 4/5] slab: Introduce kmalloc_flex() and family
From: Kees Cook @ 2025-12-03 23:30 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Kees Cook, Jonathan Corbet, Andrew Morton, Christoph Lameter,
David Rientjes, Roman Gushchin, Harry Yoo, Gustavo A. R. Silva,
workflows, linux-doc, linux-mm, linux-hardening, Linus Torvalds,
Randy Dunlap, Miguel Ojeda, Przemek Kitszel, Matthew Wilcox,
John Hubbard, Joe Perches, Christoph Lameter, Marco Elver,
Vegard Nossum, Pekka Enberg, Joonsoo Kim, Bill Wendling,
Justin Stitt, Jann Horn, Greg Kroah-Hartman, Sasha Levin,
Nathan Chancellor, Peter Zijlstra, Nick Desaulniers,
Jakub Kicinski, Yafang Shao, Tony Ambardar, Alexander Lobakin,
Jan Hendrik Farr, Alexander Potapenko, linux-kernel, llvm
In-Reply-To: <20251203233029.it.641-kees@kernel.org>
As done for kmalloc_obj*(), introduce a type-aware allocator for flexible
arrays, which may also have "counted_by" annotations:
ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
becomes:
ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
The internal use of __flex_counter() allows for automatically setting
the counter member of a struct's flexible array member when it has
been annotated with __counted_by(), avoiding any missed early size
initializations while __counted_by() annotations are added to the
kernel. Additionally, this also checks for "too large" allocations based
on the type size of the counter variable. For example:
if (count > type_max(ptr->flex_counter))
fail...;
size = struct_size(ptr, flex_member, count);
ptr = kmalloc(size, gfp);
ptr->flex_counter = count;
becomes (n.b. unchanged from earlier example):
ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
ptr->flex_count = count;
Note that manual initialization of the flexible array counter is still
required (at some point) after allocation as not all compiler versions
support the __counted_by annotation yet. But doing it internally makes
sure they cannot be missed when __counted_by _is_ available, meaning
that the bounds checker will not trip due to the lack of "early enough"
initializations that used to work before enabling the stricter bounds
checking. For example:
ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
fill(ptr->flex, count);
ptr->flex_count = count;
This works correctly before adding a __counted_by annotation (since
nothing is checking ptr->flex accesses against ptr->flex_count). After
adding the annotation, the bounds sanitizer would trip during fill()
because ptr->flex_count wasn't set yet. But with kmalloc_flex() setting
ptr->flex_count internally at allocation time, the existing code works
without needing to move the ptr->flex_count assignment before the call
to fill(). (This has been a stumbling block for __counted_by adoption.)
Signed-off-by: Kees Cook <kees@kernel.org>
---
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <cl@gentwo.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Harry Yoo <harry.yoo@oracle.com>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: <workflows@vger.kernel.org>
Cc: <linux-doc@vger.kernel.org>
Cc: <linux-mm@kvack.org>
Cc: <linux-hardening@vger.kernel.org>
---
Documentation/process/deprecated.rst | 7 ++++
include/linux/slab.h | 48 ++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index 91c628fa2d59..fed56864d036 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -387,6 +387,7 @@ allocations. For example, these open coded assignments::
ptr = kzalloc(sizeof(*ptr), gfp);
ptr = kmalloc_array(count, sizeof(*ptr), gfp);
ptr = kcalloc(count, sizeof(*ptr), gfp);
+ ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
ptr = kmalloc(sizeof(struct foo, gfp);
become, respectively::
@@ -395,4 +396,10 @@ become, respectively::
ptr = kzalloc_obj(*ptr, gfp);
ptr = kmalloc_objs(*ptr, count, gfp);
ptr = kzalloc_objs(*ptr, count, gfp);
+ ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
__auto_type ptr = kmalloc_obj(struct foo, gfp);
+
+If `ptr->flex_member` is annotated with __counted_by(), the allocation
+will automatically fail if `count` is larger than the maximum
+representable value that can be stored in the counter member associated
+with `flex_member`.
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 726457daedbd..2656ea610b68 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -982,6 +982,33 @@ void *kmalloc_nolock_noprof(size_t size, gfp_t gfp_flags, int node);
(TYPE *)KMALLOC(__obj_size, GFP); \
})
+/**
+ * __alloc_flex - Allocate an object that has a trailing flexible array
+ * @KMALLOC: kmalloc wrapper function to use for allocation.
+ * @GFP: GFP flags for the allocation.
+ * @TYPE: type of structure to allocate space for.
+ * @FAM: The name of the flexible array member of @TYPE structure.
+ * @COUNT: how many @FAM elements to allocate space for.
+ *
+ * Returns: Newly allocated pointer to @TYPE with @COUNT-many trailing
+ * @FAM elements, or NULL on failure or if @COUNT cannot be represented
+ * by the member of @TYPE that counts the @FAM elements (annotated via
+ * __counted_by()).
+ */
+#define __alloc_flex(KMALLOC, GFP, TYPE, FAM, COUNT) \
+({ \
+ const size_t __count = (COUNT); \
+ const size_t __obj_size = struct_size_t(TYPE, FAM, __count); \
+ TYPE *__obj_ptr; \
+ if (WARN_ON_ONCE(overflows_flex_counter_type(TYPE, FAM, __count))) \
+ __obj_ptr = NULL; \
+ else \
+ __obj_ptr = KMALLOC(__obj_size, GFP); \
+ if (__obj_ptr) \
+ __set_flex_counter(__obj_ptr->FAM, __count); \
+ __obj_ptr; \
+})
+
/**
* kmalloc_obj - Allocate a single instance of the given type
* @VAR_OR_TYPE: Variable or type to allocate.
@@ -1005,23 +1032,44 @@ void *kmalloc_nolock_noprof(size_t size, gfp_t gfp_flags, int node);
#define kmalloc_objs(VAR_OR_TYPE, COUNT, GFP) \
__alloc_objs(kmalloc, GFP, typeof(VAR_OR_TYPE), COUNT)
+/**
+ * kmalloc_flex - Allocate a single instance of the given flexible structure
+ * @VAR_OR_TYPE: Variable or type to allocate (with its flex array).
+ * @FAM: The name of the flexible array member of the structure.
+ * @COUNT: How many flexible array member elements are desired.
+ * @GFP: GFP flags for the allocation.
+ *
+ * Returns: newly allocated pointer to @VAR_OR_TYPE on success, NULL on
+ * failure. If @FAM has been annotated with __counted_by(), the allocation
+ * will immediately fail if @COUNT is larger than what the type of the
+ * struct's counter variable can represent.
+ */
+#define kmalloc_flex(VAR_OR_TYPE, FAM, COUNT, GFP) \
+ __alloc_flex(kmalloc, GFP, typeof(VAR_OR_TYPE), FAM, COUNT)
+
/* All kzalloc aliases for kmalloc_(obj|objs|flex). */
#define kzalloc_obj(P, GFP) \
__alloc_objs(kzalloc, GFP, typeof(P), 1)
#define kzalloc_objs(P, COUNT, GFP) \
__alloc_objs(kzalloc, GFP, typeof(P), COUNT)
+#define kzalloc_flex(P, FAM, COUNT, GFP) \
+ __alloc_flex(kzalloc, GFP, typeof(P), FAM, COUNT)
/* All kvmalloc aliases for kmalloc_(obj|objs|flex). */
#define kvmalloc_obj(P, GFP) \
__alloc_objs(kvmalloc, GFP, typeof(P), 1)
#define kvmalloc_objs(P, COUNT, GFP) \
__alloc_objs(kvmalloc, GFP, typeof(P), COUNT)
+#define kvmalloc_flex(P, FAM, COUNT, GFP) \
+ __alloc_flex(kvmalloc, GFP, typeof(P), FAM, COUNT)
/* All kvzalloc aliases for kmalloc_(obj|objs|flex). */
#define kvzalloc_obj(P, GFP) \
__alloc_objs(kvzalloc, GFP, typeof(P), 1)
#define kvzalloc_objs(P, COUNT, GFP) \
__alloc_objs(kvzalloc, GFP, typeof(P), COUNT)
+#define kvzalloc_flex(P, FAM, COUNT, GFP) \
+ __alloc_flex(kvzalloc, GFP, typeof(P), FAM, COUNT)
#define kmem_buckets_alloc(_b, _size, _flags) \
alloc_hooks(__kmalloc_node_noprof(PASS_BUCKET_PARAMS(_size, _b), _flags, NUMA_NO_NODE))
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] Documentation: Improve wording on requirements for a free Nitrokey
From: Konstantin Ryabitsev @ 2025-12-04 20:42 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Jonathan Corbet, workflows, linux-doc
In-Reply-To: <20251203074349.1826233-2-u.kleine-koenig@baylibre.com>
On Wed, Dec 03, 2025 at 08:43:47AM +0100, Uwe Kleine-König wrote:
> - If you are listed in MAINTAINERS or have an account at kernel.org,
> - you `qualify for a free Nitrokey Start`_ courtesy of The Linux
> + If you are listed in an `M:` entry in MAINTAINERS or have an account at
> + kernel.org, you `qualify for a free Nitrokey Start`_ courtesy of The Linux
> Foundation.
Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
-K
^ permalink raw reply
* Re: [PATCH] Documentation: Improve wording on requirements for a free Nitrokey
From: Bagas Sanjaya @ 2025-12-04 22:48 UTC (permalink / raw)
To: Uwe Kleine-König, Jonathan Corbet
Cc: Konstantin Ryabitsev, workflows, linux-doc
In-Reply-To: <20251203074349.1826233-2-u.kleine-koenig@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
On Wed, Dec 03, 2025 at 08:43:47AM +0100, Uwe Kleine-König wrote:
> diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
> index b6919bf606c3..2e4da3de25d4 100644
> --- a/Documentation/process/maintainer-pgp-guide.rst
> +++ b/Documentation/process/maintainer-pgp-guide.rst
> @@ -405,8 +405,8 @@ geographical region, and open/proprietary hardware considerations.
>
> .. note::
>
> - If you are listed in MAINTAINERS or have an account at kernel.org,
> - you `qualify for a free Nitrokey Start`_ courtesy of The Linux
> + If you are listed in an `M:` entry in MAINTAINERS or have an account at
i.e. being listed as a maintainer?
> + kernel.org, you `qualify for a free Nitrokey Start`_ courtesy of The Linux
> Foundation.
>
> .. _`Nitrokey Start`: https://www.nitrokey.com/products/nitrokeys
>
The text looks good.
Acked-by: Bagas Sanjaya <bagasdotme@gmail.com>
Thanks.
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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