linux-kernel - Re: [PATCH] tracing: Fix to avoid wakeup loop in splice read of per-cpu buffer

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: <20230821112703.23b1964b@gandalf.local.home>
Date:   Mon, 21 Aug 2023 11:27:03 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Masami Hiramatsu (Google)" <mhiramat@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH] tracing: Fix to avoid wakeup loop in splice read of
 per-cpu buffer

On Tue, 22 Aug 2023 00:16:39 +0900
Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:

> BTW, even with this fix, blocking splice still causes a strange behavior.
> If I set '400' to buffer_size_kb (so 100 pages) and '1' to buffer_percent,
> splice always returns 8192 (2 pages) to read. But I expected that should
> return 4096 (1 page). This means splice() waits longer than I thought.
> 
> I think the fullfilled percentage calculation will be a bit wrong.

Note, the percentage is when to wake up the task. If between the wakeup and
the read/splice, another ring buffer page gets filled more, then it will
give that as well. The buffer_percent is just how long to wait, not for how
much to read.

Now if you test this with just adding enough to fill one page, and it
doesn't wake up the reader, then that would be a bug.

-- Steve