On Tue, 5 Nov 2019 08:28:02 -0800 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Tue, Nov 05, 2019 at 11:00:28AM -0500, Steven Rostedt wrote: > > On Tue, 5 Nov 2019 07:47:11 -0800 > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > If you have to wait you may need to wait. The Linux kernel isn't > > > > something that is suppose to put in temporary hacks, just to satisfy > > > > someone's deadline. > > > > > > Ok. I will switch to text_poke and will make it hack free. > > > ftrace mechanisms are being replaced by text_poke anyway. > > > > I see that Facebook now owns Linux. > > huh? Sorry, I'm a bit grumpy. I've been non stop for over a week (7 days of conferences), and I'm still not done traveling yet. :-p > > > Peter's text poke patches most likely not be ready for the next > > merge window either. Don't you require them? > > nope. > But I strongly support them. ftrace->text_poke + static_call + nop2 > are all great improvements. > I'd really like to see them landing in this merge window. > > > The database of function nops are part of the ftrace mechanisms which > > are not part of text poke, and there's strong accounting associated to > > them which allows the user to see how their kernel is modified. > > I guess the part that wasn't obvious from commit log of bpf trampoline patches > is that they don't care about nops and ftrace recording of nops. bpf trampoline > will work even if there are no nops in front of the function. It will work when > CONFIG_HAVE_FENTRY is off. I'm guessing it will use kprobes (or optimized probes). I haven't had a chance to look at your patches. I still think using the register_ftrace_direct() will be cleaner (as it is built on top of code that's been in the kernel for a decade). Perhaps we can make it work even without the full ftrace code. -- Steve
