linux-kernel - Re: [PATCH] tracing: fix warnings when building htmldocs

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] [day] [month] [year] [list]

Message-ID: <20230623104656.7039aa05@gandalf.local.home>
Date:   Fri, 23 Jun 2023 10:46:56 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Donglin Peng <pengdonglin@...gfor.com.cn>
Cc:     mhiramat@...nel.org, sfr@...b.auug.org.au,
        linux-kernel@...r.kernel.org, linux-next@...r.kernel.org
Subject: Re: [PATCH] tracing: fix warnings when building htmldocs


Remember to also Cc linux-trace-kernel@...r.kernel.org

(I pulled it in regardless)

And I also updated the subject to be:

  tracing: Fix warnings when building htmldocs for function graph retval

As it should start with a capital letter, and be more specific than just
general htmldoc fix.

-- Steve


On Fri, 23 Jun 2023 15:17:28 +0800
Donglin Peng <pengdonglin@...gfor.com.cn> wrote:

> When building htmldocs, the following warnings appear:
> 
> Documentation/trace/ftrace.rst:2797: WARNING: Literal block expected; none found.
> Documentation/trace/ftrace.rst:2816: WARNING: Literal block expected; none found.
> 
> So fix it.
> 
> Signed-off-by: Donglin Peng <pengdonglin@...gfor.com.cn>
> ---
>  Documentation/trace/ftrace.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> index df2d3e57a83f..172f35c7308f 100644
> --- a/Documentation/trace/ftrace.rst
> +++ b/Documentation/trace/ftrace.rst
> @@ -2786,7 +2786,7 @@ option, and these limitations will be eliminated in the future:
>    especially when larger types are truncated, whether explicitly or implicitly.
>    Here are some specific cases to illustrate this point:
>  
> -  **Case One**::
> +  **Case One**:
>  
>    The function narrow_to_u8 is defined as follows::
>  
> @@ -2805,7 +2805,7 @@ option, and these limitations will be eliminated in the future:
>    If you pass 0x123456789abcdef to this function and want to narrow it,
>    it may be recorded as 0x123456789abcdef instead of 0xef.
>  
> -  **Case Two**::
> +  **Case Two**:
>  
>    The function error_if_not_4g_aligned is defined as follows::
>