Hi Linus and Alexei, At first, sorry about this issue. I missed to Cc'ed to arch maintainers. On Mon, 21 Mar 2022 17:31:28 -0700 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Mon, Mar 21, 2022 at 4:59 PM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Mon, Mar 21, 2022 at 4:11 PM Alexei Starovoitov > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > Did you look at the code? > > > In particular: > > > https://lore.kernel.org/bpf/164735286243.1084943.7477055110527046644.stgit@devnote2/ > > > > > > it's a copy paste of arch/x86/kernel/kprobes/core.c > > > > > > How is it "bad architecture code" ? > > > > It's "bad architecture code" because the architecture maintainers have > > made changes to check ENDBR in the meantime. > > > > So it used to be perfectly fine. It's not any longer - and the > > architecture maintainers were clearly never actually cc'd on the > > changes, so they didn't find out until much too late. Let me retry porting fprobe on top of ENDBR things and confirm with arch maintainers. > > Not denying that missing cc was an issue. > > We can drop just arch patches: > rethook: x86: Add rethook x86 implementation > arm64: rethook: Add arm64 rethook implementation > powerpc: Add rethook support > ARM: rethook: Add rethook arm implementation > > or everything including Jiri's work on top of it. > Which would be a massive 27 patches. > > We'd prefer the former, of course. > Later during the merge window we can add a single > 'rethook: x86' patch that takes endbr into account, > so that multi-kprobe feature will work on x86. > For the next merge window we can add other archs. > Would that work? BTW, As far as I can see the ENDBR things, the major issue on fprobe is that the ftrace'ed ip address will be different from the symbol address (even) on x86. That must be ensured to work before merge. Let me check it on Linus's tree at first. Thank you, -- Masami Hiramatsu <mhiramat@xxxxxxxxxx>
