On Thu, Jun 09, 2022 at 11:32:59AM -0700, Andrii Nakryiko wrote: > On Wed, Jun 8, 2022 at 9:08 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > On Wed, 8 Jun 2022 08:59:50 -0700 > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > Would it be possible to preprocess ftrace_pages to remove such invalid > > > records (so that by the time we have to report > > > available_filter_functions there are no invalid records)? Or that data > > > is read-only when kernel is running? > > > > It's possible, but will be time consuming (slow down boot up) and racy. In > > other words, I didn't feel it was worth it. > > > > We can add it. How much of an issue is it to have these place holders for > > you? Currently, I only see it causes issues with tests. Is it really an > > issue for use cases? > > I have the tool (retsnoop) that uses available_filter_functions, I'll > have to update it to ignore such entries. It's a small inconvenience, > once you know about this change, but multiply that for multiple users > that use available_filter_functions for some sort of generic tooling > doing kprobes/tracing, and it adds up. So while it's not horrible, > ideally user-visible data shouldn't have non-usable placeholders. > > How much slowdown would you expect on start up? Not clear what would > be racy about this start up preprocessing, but I believe you. > > So in summary, it's not the end of the world, but as a user I'd prefer > not to know about this quirk, of course :) ok, I'l resend with the test workaround jirka
