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

Message-Id: <20230623173753.83e69284d2752f57c91abf4e@kernel.org>
Date:   Fri, 23 Jun 2023 17:37:53 +0900
From:   Masami Hiramatsu (Google) <mhiramat@...nel.org>
To:     Donglin Peng <pengdonglin@...gfor.com.cn>
Cc:     rostedt@...dmis.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

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>

Looks good to me.

Acked-by: Masami Hiramatsu (Google) <mhiramat@...nel.org>

Also,

Reported-by: Stephen Rothwell <sfr@...b.auug.org.au>
Link: https://lore.kernel.org/all/20230623143517.19ffc6c0@canb.auug.org.au/
Fixes: 21c094d3f8a6 ("tracing: Add documentation for funcgraph-retval and funcgraph-retval-hex")

Thank you,

> ---
>  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::
>  
> -- 
> 2.40.1
> 


-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>