linux-kernel - Re: [PATCH] docs: Add more message type documentations for checkpatch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k0ntnoyq.fsf@meer.lwn.net>
Date:   Thu, 20 May 2021 14:13:17 -0600
From:   Jonathan Corbet <corbet@....net>
To:     Dwaipayan Ray <dwaipayanray1@...il.com>, mchehab@...nel.org
Cc:     linux-kernel@...r.kernel.org, lukas.bulwahn@...il.com,
        linux-doc@...r.kernel.org, Dwaipayan Ray <dwaipayanray1@...il.com>
Subject: Re: [PATCH] docs: Add more message type documentations for checkpatch

Dwaipayan Ray <dwaipayanray1@...il.com> writes:

> - Document a couple of more checkpatch message types.
> - Add a blank line before all `See:` lines to improve the
>   rst output.
> - Create a new subsection `Permissions` and move a few types
>   to it.
>
> Signed-off-by: Dwaipayan Ray <dwaipayanray1@...il.com>
> ---
>  Documentation/dev-tools/checkpatch.rst | 170 ++++++++++++++++++++++++-
>  1 file changed, 163 insertions(+), 7 deletions(-)

So this seems good, but I just notice something that has evidently
escaped me until now...

> diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
> index 51fed1bd72ec..e409f27f48b6 100644
> --- a/Documentation/dev-tools/checkpatch.rst
> +++ b/Documentation/dev-tools/checkpatch.rst
> @@ -246,6 +246,7 @@ Allocation style
>      The first argument for kcalloc or kmalloc_array should be the
>      number of elements.  sizeof() as the first argument is generally
>      wrong.
> +
>      See: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html
>  
>    **ALLOC_SIZEOF_STRUCT**
> @@ -264,6 +265,7 @@ Allocation style
>    **ALLOC_WITH_MULTIPLY**
>      Prefer kmalloc_array/kcalloc over kmalloc/kzalloc with a
>      sizeof multiply.
> +
>      See: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html
>  
>  
> @@ -284,6 +286,7 @@ API usage
>      BUG() or BUG_ON() should be avoided totally.
>      Use WARN() and WARN_ON() instead, and handle the "impossible"
>      error condition as gracefully as possible.
> +
>      See: https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on
>  
>    **CONSIDER_KSTRTO**
> @@ -292,12 +295,23 @@ API usage
>      may lead to unexpected results in callers.  The respective kstrtol(),
>      kstrtoll(), kstrtoul(), and kstrtoull() functions tend to be the
>      correct replacements.
> +
>      See: https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull
>  
> +  **IN_ATOMIC**
> +    in_atomic() is not for driver use so any such use is reported as an ERROR.
> +    Also in_atomic() is often used to determine if we may sleep, but it is not
> +    reliable in this use model therefore its use is strongly discouraged.
> +
> +    However, in_atomic() is ok for core kernel use.
> +
> +    See: https://lore.kernel.org/lkml/20080320201723.b87b3732.akpm@linux-foundation.org/
> +
>    **LOCKDEP**
>      The lockdep_no_validate class was added as a temporary measure to
>      prevent warnings on conversion of device->sem to device->mutex.
>      It should not be used for any other purpose.
> +
>      See: https://lore.kernel.org/lkml/1268959062.9440.467.camel@laptop/
>  
>    **MALFORMED_INCLUDE**
> @@ -308,11 +322,18 @@ API usage
>    **USE_LOCKDEP**
>      lockdep_assert_held() annotations should be preferred over
>      assertions based on spin_is_locked()
> +
>      See: https://www.kernel.org/doc/html/latest/locking/lockdep-design.html#annotations
>  
>    **UAPI_INCLUDE**
>      No #include statements in include/uapi should use a uapi/ path.
>  
> +  **USLEEP_RANGE**
> +    usleep_range() should be preferred over udelay(). The proper way of
> +    using usleep_range() is mentioned in the kernel docs.
> +
> +    See: https://www.kernel.org/doc/html/latest/timers/timers-howto.html#delays-information-on-the-various-kernel-delay-sleep-mechanisms

We really shouldn't be linking to outside sites - even kernel.org - when
referring to the kernel docs themselves.  Just say
"Documentation/timers/timers-howto" and let the build system handle the
links.

There's a lot of these in this file, alas...

I've applied this patch since it makes things better overall, but I
would really like to see all those URLs go away if possible.

Thanks,

jon