On Fri, Sep 04, 2026 at 02:49:02PM -0400, Steven Rostedt wrote: > From: Steven Rostedt <[email protected]> > > 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/[email protected]/ > Fixes: TBD > Signed-off-by: Steven Rostedt <[email protected]> > --- > 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 <[email protected]> -- Vincent
