* [PATCH v1 2/2] Documentation: dev-tools: add container.rst page
From: Guillaume Tucker @ 2025-12-10 13:58 UTC (permalink / raw)
To: Nathan Chancellor, Miguel Ojeda
Cc: linux-kernel, rust-for-linux, linux-kbuild, automated-testing,
workflows, llvm, Arnd Bergmann, Guillaume Tucker
In-Reply-To: <cover.1765374789.git.gtucker@gtucker.io>
Add a dev-tools/container.rst documentation page for the
scripts/container tool. This covers the basic usage with additional
information about environment variables and user IDs. It also
includes a number of practical examples with a reference to the
experimental kernel.org toolchain images.
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
---
Documentation/dev-tools/container.rst | 175 ++++++++++++++++++++++++++
Documentation/dev-tools/index.rst | 1 +
2 files changed, 176 insertions(+)
create mode 100644 Documentation/dev-tools/container.rst
diff --git a/Documentation/dev-tools/container.rst b/Documentation/dev-tools/container.rst
new file mode 100644
index 000000000000..2a56f256f648
--- /dev/null
+++ b/Documentation/dev-tools/container.rst
@@ -0,0 +1,175 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2025 Guillaume Tucker
+
+====================
+Containerized Builds
+====================
+
+The ``container`` tool can be used to run any command in the kernel source tree
+from within a container. Doing so facilitates reproducing builds across
+various platforms, for example when a test bot has reported an issue which
+requires a specific version of a compiler or an external test suite. While
+this can already be done by users who are familiar with containers, having a
+dedicated tool in the kernel tree lowers the barrier to entry by solving common
+problems once and for all (e.g. user id management). It also makes it easier
+to share an exact command line leading to a particular result. The main use
+case is likely to be kernel builds but virtually anything can be run: KUnit,
+checkpatch etc. provided a suitable image is available.
+
+
+Options
+=======
+
+Command line syntax::
+
+ scripts/container [OPTION]... CMD...
+
+Available options:
+
+``-e, --env-file ENV_FILE``
+
+ Path to an environment file to load in the container.
+
+``-g, --gid GID``
+
+ Group id to use inside the container.
+
+``-i, --image IMAGE``
+
+ Container image, default is ``gcc``.
+
+``-r, --runtime RUNTIME``
+
+ Container runtime, default is ``docker``. Supported runtimes: ``docker``,
+ ``podman``.
+
+``-u, --uid UID``
+
+ User id to use inside the container. If the ``-g`` option is not
+ specified, the user id will also be used for the group id.
+
+``-v, --verbose``
+
+ Enable verbose output.
+
+``-h, --help``
+
+ Show the help message and exit.
+
+
+Usage
+=====
+
+It's entirely up to the user to choose which image to use and the ``CMD``
+arguments are passed directly as an arbitrary command line to run in the
+container. The tool will take care of mounting the source tree as the current
+working directory and adjust the user and group id as needed.
+
+The container images are provided by the user and selected via the ``-i``
+option. They will typically include a compiler toolchain to build the kernel
+and as such, the default image tag is set to ``gcc`` to give a convenient way
+of running builds. Any local image with a GCC compiler toolchain could be
+tagged as ``gcc`` to make it point to it. For example::
+
+ docker tag my-user/gcc:15 gcc
+
+The container runtime can be selected with the ``-r`` option, which can be
+either Docker or Podman. Support for other runtimes may be added later
+depending on their popularity among users.
+
+
+Environment Variables
+=====================
+
+Environment variables are not propagated to the container so they have to be
+either defined in the image itself or via the ``-e`` option using an
+environment file. In some cases it makes more sense to have them defined in
+the Containerfile used to create the image. For example, a Clang-only compiler
+toolchain image would most likely have ``LLVM=1`` defined. The local
+environment file is more useful for user-specific variables during development.
+
+Please note that ``make`` options can still be passed on the command line, so
+while this can't be done as the first argument needs to be the executable::
+
+ scripts/container INSTALL_MOD_STRIP=1 make modules_install
+
+this will work::
+
+ scripts/container make modules_install INSTALL_MOD_STRIP=1
+
+
+User IDs
+========
+
+This is an area where the behaviour will vary slightly depending on the
+container runtime. The goal is to run commands as the user invoking the tool.
+With Podman, a namespace is created to map the current user id to a different
+one in the container (1000 by default). With Docker, while this is also
+possible with recent versions it requires a special feature to be enabled in
+the daemon so it's not used here for simplicity. Instead, the container is run
+with the current user id directly. In both cases, this will provide the same
+file permissions for the kernel source tree mounted as a volume. The only
+difference is that when using Docker without a namespace, the user id may not
+be the same as the default one set in the image.
+
+Say, we're using an image which sets up a default user with id 1000 and the
+current user calling the ``container`` tool has id 1234. The kernel source
+tree was checked out by this same user so the files belong to user 1234. With
+Podman, the container will be running as user id 1000 with a mapping to id 1234
+so that the files from the mounted volume appear to belong to id 1000 inside
+the container. With Docker and no namespace, the container will be running
+with user id 1234 which can access the files in the volume but not in the user
+1000 home directory. This shouldn't be an issue when running commands only in
+the kernel tree but it is worth highlighting here as it might matter for
+special corner cases.
+
+
+Examples
+========
+
+The shortest example is to run a basic kernel build using Docker and the
+default ``gcc`` image::
+
+ scripts/container -- make defconfig
+ scripts/container -- make -j$(nproc)
+
+.. note::
+
+ When running a command with options within the container, it should be
+ separated with a double dash ``--`` to not confuse them with the
+ ``container`` tool options. Simple make targets with no options don't
+ strictly require the double dashes e.g.::
+
+ scripts/container make mrproper
+
+To run ``checkpatch.pl`` in a ``patches`` directory with a generic image::
+
+ scripts/container -i perl:slim-trixie scripts/checkpatch.pl patches/*
+
+To build using the TuxMake Clang image::
+
+ scripts/container -i tuxmake/x86_64_korg-clang -- make LLVM=1 -j$(nproc)
+
+The examples below refer to ``kernel.org`` images which are based on the
+`kernel.org compiler toolchains
+<https://mirrors.edge.kernel.org/pub/tools/>`__. These aren't (yet) available
+in any public registry but users can build their own locally instead using this
+`experimental repository <https://gitlab.com/gtucker/korg-containers>`__ by
+running ``make PREFIX=kernel.org/``.
+
+To build just ``bzImage`` using Clang::
+
+ scripts/container -i kernel.org/clang -- make bzImage -j$(nproc)
+
+To run KUnit::
+
+ scripts/container -i kernel.org/gcc:kunit -- \
+ tools/testing/kunit/kunit.py \
+ run \
+ --arch=x86_64 \
+ --cross_compile=x86_64-linux-
+
+To build the HTML documentation, which requires the ``kdocs`` image built with
+``make PREFIX=kernel.org/ extra`` as it's not a compiler toolchain::
+
+ scripts/container -i kernel.org/kdocs make htmldocs
diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst
index 4b8425e348ab..527a0e4cf2ed 100644
--- a/Documentation/dev-tools/index.rst
+++ b/Documentation/dev-tools/index.rst
@@ -38,6 +38,7 @@ Documentation/process/debugging/index.rst
gpio-sloppy-logic-analyzer
autofdo
propeller
+ container
.. only:: subproject and html
--
2.47.3
^ permalink raw reply related
* [PATCH v1 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2025-12-10 13:58 UTC (permalink / raw)
To: Nathan Chancellor, Miguel Ojeda
Cc: linux-kernel, rust-for-linux, linux-kbuild, automated-testing,
workflows, llvm, Arnd Bergmann, Guillaume Tucker
In-Reply-To: <cover.1765374789.git.gtucker@gtucker.io>
Add a 'scripts/container' tool written in Python to run any command in
the source tree from within a container. This can typically be used
to call 'make' with a compiler toolchain image to run reproducible
builds but any arbitrary command can be run too. Only Docker and
Podman are supported for this initial version.
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Link: https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
---
scripts/container | 112 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 112 insertions(+)
create mode 100755 scripts/container
diff --git a/scripts/container b/scripts/container
new file mode 100755
index 000000000000..74644ac33685
--- /dev/null
+++ b/scripts/container
@@ -0,0 +1,112 @@
+#!/bin/env python3
+# SPDX-License-Identifier: GPL-2.0-only
+# Copyright (C) 2025 Guillaume Tucker
+
+"""Containerized builds"""
+
+import argparse
+import logging
+import os
+import subprocess
+import sys
+
+
+def get_logger(verbose):
+ """Set up a logger with the appropriate level"""
+ logger = logging.getLogger('container')
+ handler = logging.StreamHandler()
+ handler.setFormatter(logging.Formatter(
+ fmt='[container {levelname}] {message}', style='{'
+ ))
+ logger.addHandler(handler)
+ logger.setLevel(logging.DEBUG if verbose is True else logging.INFO)
+ return logger
+
+
+def run_docker(args):
+ """Run a command in a Docker container"""
+ uid = args.uid or os.getuid()
+ gid = args.gid or args.uid or os.getgid()
+ cmd = [
+ 'docker', 'run',
+ '--interactive',
+ '--volume', f'{os.getcwd()}:/src',
+ '--workdir', '/src',
+ '--user', f'{uid}:{gid}'
+ ]
+ if args.env_file:
+ cmd += ['--env-file', args.env_file]
+ cmd.append(args.image)
+ cmd += args.cmd
+ return subprocess.call(cmd)
+
+
+def run_podman(args):
+ """Run a command in a Podman container"""
+ uid = args.uid or 1000
+ gid = args.gid or args.uid or 1000
+ cmd = [
+ 'podman', 'run',
+ '--interactive',
+ '--volume', f'{os.getcwd()}:/src',
+ '--workdir', '/src',
+ '--userns', f'keep-id:uid={uid},gid={gid}',
+ ]
+ if args.env_file:
+ cmd += ['--env-file', args.env_file]
+ cmd.append(args.image)
+ cmd += args.cmd
+ return subprocess.call(cmd)
+
+
+def main(args):
+ """Main entry point for the container tool"""
+ logger = get_logger(args.verbose)
+ logger.debug("runtime=%s, image=%s", args.runtime, args.image)
+ runtimes = {
+ 'docker': run_docker,
+ 'podman': run_podman,
+ }
+ handler = runtimes.get(args.runtime)
+ if not handler:
+ logger.error("Unknown container runtime: %s", args.runtime)
+ return 1
+ try:
+ return handler(args)
+ except KeyboardInterrupt:
+ logger.error("aborted")
+ return 1
+
+
+if __name__ == '__main__':
+ parser = argparse.ArgumentParser("Containerized builds")
+ parser.add_argument(
+ '-e', '--env-file',
+ help="Path to an environment file to load in the container."
+ )
+ parser.add_argument(
+ '-g', '--gid',
+ help="Group ID to use inside the container."
+ )
+ parser.add_argument(
+ '-i', '--image', default='gcc',
+ help="Container image, default is gcc."
+ )
+ parser.add_argument(
+ '-r', '--runtime', choices=['docker', 'podman'], default='docker',
+ help="Container runtime, default is docker."
+ )
+ parser.add_argument(
+ '-u', '--uid',
+ help="User ID to use inside the container. If the -g option is not"
+ "specified, the user ID will also be used for the group ID."
+ )
+ parser.add_argument(
+ '-v', '--verbose', action='store_true',
+ help="Enable verbose output."
+ )
+ parser.add_argument(
+ 'cmd', nargs='+',
+ help="Command to run in the container"
+ )
+ sys.exit(main(parser.parse_args(sys.argv[1:])))
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/2] scripts: introduce containerized builds
From: Guillaume Tucker @ 2025-12-10 13:58 UTC (permalink / raw)
To: Nathan Chancellor, Miguel Ojeda
Cc: linux-kernel, rust-for-linux, linux-kbuild, automated-testing,
workflows, llvm, Arnd Bergmann, Guillaume Tucker
This proposal emerged from an email discussion and a talk at Plumbers
last year:
https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
The aim is to facilitate reproducing builds for CI bots as well as
developers using containers. Here's an illustrative example with a
kernel.org toolchain in a Docker image from tuxmake:
$ scripts/container -i tuxmake/korg-clang-21 make LLVM=1 defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
[...]
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
and a follow-up command to build the kernel with the verbose flag
turned on to show DEBUG log messages from the container tool:
$ scripts/container -i tuxmake/korg-clang-21 -v -- make LLVM=1 -j8
[container DEBUG] runtime=docker, image=tuxmake/korg-clang-21
GEN arch/x86/include/generated/asm/orc_hash.h
HOSTCC scripts/basic/fixdep
SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h
WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/x86/include/generated/uapi/asm/errno.h
[...]
LD arch/x86/boot/setup.elf
OBJCOPY arch/x86/boot/setup.bin
BUILD arch/x86/boot/bzImage
Kernel: arch/x86/boot/bzImage is ready (#1)
While the example above uses a tuxmake image, I've also started
preparing reference container images with kernel.org toolchains and
no third-party dependencies other than the base Debian distro:
https://gitlab.com/gtucker/korg-containers
This patch series include a documentation page with all the relevant
details about how to use the tool and images currently available.
Guillaume Tucker (2):
scripts: add tool to run containerized builds
Documentation: dev-tools: add container.rst page
Documentation/dev-tools/container.rst | 175 ++++++++++++++++++++++++++
Documentation/dev-tools/index.rst | 1 +
scripts/container | 112 +++++++++++++++++
3 files changed, 288 insertions(+)
create mode 100644 Documentation/dev-tools/container.rst
create mode 100755 scripts/container
--
2.47.3
^ permalink raw reply
* Re: [PATCH] Documentation: Improve wording on requirements for a free Nitrokey
From: Bagas Sanjaya @ 2025-12-05 23:25 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jonathan Corbet, Konstantin Ryabitsev, workflows, linux-doc
In-Reply-To: <j6mj6stlk4ojprdpfvoa35ghsfics5wou4nh3khymmb2aiqxbr@73jzs33sbyly>
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
On Fri, Dec 05, 2025 at 04:33:15PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Fri, Dec 05, 2025 at 05:48:57AM +0700, Bagas Sanjaya wrote:
> > 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?
>
> Yes, that seems to be the criteria. This was at least the explanation
> when a coworker with an R: entry wasn't able to apply (and the error
> message gives no hint about the problem then).
OK, 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
* Re: [PATCH] Documentation: Improve wording on requirements for a free Nitrokey
From: Uwe Kleine-König @ 2025-12-05 15:33 UTC (permalink / raw)
To: Bagas Sanjaya; +Cc: Jonathan Corbet, Konstantin Ryabitsev, workflows, linux-doc
In-Reply-To: <aTIP2Wqspl-jfm7M@archie.me>
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
Hello,
On Fri, Dec 05, 2025 at 05:48:57AM +0700, Bagas Sanjaya wrote:
> 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?
Yes, that seems to be the criteria. This was at least the explanation
when a coworker with an R: entry wasn't able to apply (and the error
message gives no hint about the problem then).
> > + kernel.org, you `qualify for a free Nitrokey Start`_ courtesy of The Linux
> > Foundation.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Mathieu Poirier @ 2025-12-05 15:25 UTC (permalink / raw)
To: Andy Shevchenko
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, Joe Perches, Bjorn Andersson
In-Reply-To: <20251126214709.2322314-1-andriy.shevchenko@linux.intel.com>
On Wed, 26 Nov 2025 at 14:47, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> 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>
> ---
>
> 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;
> }
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> 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
* [PATCH] Doc:it_IT: Do not reference kernel.h anymore
From: Andi Shyti @ 2025-12-05 11:15 UTC (permalink / raw)
To: linux-doc, linux-kernel, workflows
Cc: Jonathan Corbet, Andi Shyti, Andy Shevchenko, Federico Vaga
In-Reply-To: <20251126214709.2322314-1-andriy.shevchenko@linux.intel.com>
coding-style.rst still references the kernel.h header, which is
being phased out. Remove that reference and point to the proper
headers for the examples instead: array_size.h, stddef.h and
minmax.h.
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Federico Vaga <federico.vaga@vaga.pv.it>
---
Hi,
Following Andy's suggestion, and as a native Italian speaker,
I am updating the Italian translation of coding-style.rst based
on his original change.
I also took the chance to improve the phrasing in a few places.
Andi
.../it_IT/process/coding-style.rst | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst
index c0dc786b8474..b2fd74528de5 100644
--- a/Documentation/translations/it_IT/process/coding-style.rst
+++ b/Documentation/translations/it_IT/process/coding-style.rst
@@ -1068,15 +1068,17 @@ può migliorare la leggibilità.
18) Non reinventate le macro del kernel
---------------------------------------
-Il file di intestazione include/linux/kernel.h contiene un certo numero
-di macro che dovreste usare piuttosto che implementarne una qualche variante.
-Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
-macro:
+I file header presenti in include/linux mettono a disposizione numerose macro
+che è preferibile utilizzare, evitando di sviluppare implementazioni
+alternative. Per esempio, se dovete calcolare la lunghezza di un vettore,
+sfruttate la macro:
.. code-block:: c
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+definita in array_size.h.
+
Analogamente, se dovete calcolare la dimensione di un qualche campo di una
struttura, usate
@@ -1084,10 +1086,11 @@ struttura, usate
#define sizeof_field(t, f) (sizeof(((t*)0)->f))
-Ci sono anche le macro min() e max() che, se vi serve, effettuano un controllo
-rigido sui tipi. Sentitevi liberi di leggere attentamente questo file
-d'intestazione per scoprire cos'altro è stato definito che non dovreste
-reinventare nel vostro codice.
+definita in stddef.h.
+
+Ci sono anche le macro min() e max() definite in minmax.h che effettuano un
+controllo rigoroso sui tipi. È consigliato consultare i vari file header per
+vedere altre macro già disponibili.
19) Linee di configurazione degli editor e altre schifezze
-----------------------------------------------------------
--
2.51.0
^ permalink raw reply related
* 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
* 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
* [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 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 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
* [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
* 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
* 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 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] 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 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 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: 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: 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 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
* [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: 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
* 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
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