Re: [PATCH] tracing: Fix comment in tracing_buffers_splice_read()
From: Vincent Donnefort
Date: Sat Sep 05 2026 - 09:05:01 EST
On Fri, Sep 04, 2026 at 02:49:02PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@xxxxxxxxxxx>
>
> The comment about returning an error if the read fails on the first
> iteration is slightly incorrect. It makes it sound like the only reason it
> could fail on a later iteration is if the subbuf order changed. That is
> incorrect, it could also fail if the length passed in was not a multiple
> of the subbuf size. Fix the comment.
>
> Link: https://lore.kernel.org/all/20260904143527.40e73d36@xxxxxxxxxxxxxxxxxx/
> Fixes: TBD
> Signed-off-by: Steven Rostedt <rostedt@xxxxxxxxxxx>
> ---
> kernel/trace/trace.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index b26c4c277ce5..8658cad53cb5 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -7296,11 +7296,13 @@ ssize_t tracing_buffers_splice_read(struct file *file, loff_t *ppos,
> r = ring_buffer_read_page(ref->buffer, ref->rpage, len, iter->cpu_file, 1);
> } else if (!i) {
> /*
> - * We failed to read because the length is too small
> - * or unaligned. If this is the first iteration, it's
> - * an invalid userspace input. Otherwise, this is due
> - * to a subbuf order change. Do not report an error
> - * and just finish the read.
> + * If this fails to read on the first iteration, it
> + * means the length was too small and an error should
> + * be returned to user space. Otherwise, at least
> + * one sub-buffer was successfully read but this failed
> + * due to either the length was unaligned or the
> + * subbuf order changed. Either case, do not report
> + * an error.
> */
> ret = -EINVAL;
> }
> --
> 2.53.0
>
Ha yes, I see the missing case you were refering to now.
Reviewed-by: Vincent Donnefort <vdonnefort@xxxxxxxxxx>
--
Vincent