Re: [RFC PATCH 1/2] tracing: fixes of ftrace_enable_fops

[Gabriele Paoloni]

On Tue, Jul 1, 2025 at 11:58 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Fri, 20 Jun 2025 15:26:27 +0200
> Gabriele Paoloni <gpaoloni@xxxxxxxxxx> wrote:
>
> > I think that from my side I do not have comprehensive answers to all your
> > questions (I need to read the code more in depth).
> > So to be pragmatic I can split this effort into two parts (documentation and
> > redesign); I will propose documentation first with the TIPs that you mentioned
> > above and later, if we find a better re-design solution, we can also amend
> > the documentation as needed.
>
> Just to confirm, I agree with Masami. The enable file is quite special,
> and I don't see the use of user space playing tricks with it, which
> even includes lseek. Maybe to keep rewinding a read to get a new status
> change?

Well the proposed patchset was aiming to prevent the user from doing
stupid things (e.g. reading 1byte at a time or reading after a write has
increased ppos). However documenting the correct AoUs would still work

>
> But it usually contains a single character (sometimes two) and a new
> line. It's not something that's ever been reported as an issue. I
> rather not touch it if it hasn't been reported as broken because
> there's some hypothetical use case that can see it as broken.
>
> Documenting its current behavior is perfectly fine with me.

Yep "[RFC PATCH v3] tracing: add testable specifications for
event_enable_write/read" is already out.

Thanks
Gab

>
> -- Steve
>