linux-kernel - Re: [PATCH] tracing: document buffer_size

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: <a1ae1bc0-0677-8284-9f18-1171e1dcb175@huawei.com>
Date:   Mon, 25 Sep 2023 19:44:22 +0800
From:   Zheng Yejian <zhengyejian1@...wei.com>
To:     Christian Loehle <christian.loehle@....com>, <rostedt@...dmis.org>,
        <mhiramat@...nel.org>, <linux-kernel@...r.kernel.org>,
        <linux-trace-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>
Subject: Re: [PATCH] tracing: document buffer_size_kb more precisely

On 2023/9/25 18:02, Christian Loehle wrote:
> buffer_size_kb no longer shows the requested amount, but the one that
> is actually used internally for the ring buffer.
> 
> commit 6d98a0f2ac3c ("tracing: Set actual size after ring buffer resize")
> changed the sysfs behavior such that value read will always show the
> actual size, while previously it showed the size that was requested
> through the sysfs interface, even if it was rounded up to fulfill
> the request.
> So the documentation can state that more precisely now.
> 
> Signed-off-by: Christian Loehle <christian.loehle@....com>
> ---
>   Documentation/trace/ftrace.rst | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> index 23572f6697c0..2e066b3b6edc 100644
> --- a/Documentation/trace/ftrace.rst
> +++ b/Documentation/trace/ftrace.rst
> @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files:
>   	A few extra pages may be allocated to accommodate buffer management
>   	meta-data. If the last page allocated has room for more bytes
>   	than requested, the rest of the page will be used,
> -	making the actual allocation bigger than requested or shown.
> +	making the actual allocation bigger than requested.

Hi, the actual allocation should still be bigger than shown due to the
loss of accuracy when doing unit conversion from bytes to kilobytes (see
tracing_entries_read()).

--

Thanks,
Zheng Yejian

>   	( Note, the size may not be a multiple of the page size
>   	due to buffer management meta-data. )
>