On Wed, 25 Jan 2023 12:39:36 +0530 "Naveen N. Rao" <naveen.n.rao@xxxxxxxxxxxxxxxxxx> wrote: > Hi Masami, > > Masami Hiramatsu wrote: > >> > > >> > Yes, please make it separate, this test case is for checking whether > >> > the ftrace can define/enable/disable multiple kprobe events. Not for > >> > checking kprobe with different types, nor checking interactions among > >> > different types of kprobes. > >> > > >> > (BTW, if you want to test optprobe on x86, you can not put the probes > >> > within the jump instruction (+5 bytes). It will unoptimize existing > >> > optimized kprobe in that case) > >> > >> Ok, I can see why we won't be able to optimize any of the probes on x86 > >> with this approach. But, we should be able to do so on powerpc and arm, > >> the only other architectures supporting OPTPROBES at this time. For x86, > >> we may have to extend the test to check kprobes/list. > > > > Are there any instruction type specific limitation on those arch for > > using optprobe? I guess the 'call' (branch with link register) will not > > able to be optimized because it leaves the trampoline address on the > > stack. > > Yes, at least on powerpc, we only optimize ALU instructions and do not > optimize load/store instructions, among many others. This is the reason > we try to put a probe uptil 256 offset into a function in the proposed > test, which will almost certainly catch an instruction that can be > optimized. > > > > >> > >> Crucially, I think trying to place a probe at each byte can still > >> exercize interactions across KPROBES_ON_FTRACE and normal kprobes, so > >> this test is still a good start. In addition, we get to ensure that > >> kprobes infrastructure is rejecting placing probes at non-instruction > >> boundaries. > > > > The interfere between probes can be happen between kprobes and optprobe > > (*only on x86*), but not with KPORBES_ON_FTRACE. The ftrace replaced NOP > > will be handled as one instruction. > > Yes. > > > > >> > And do you really need to run "multiple" kprobes at once? > >> > I think what you need is 'kprobe_opt_types.tc'. > >> > >> Yes, enabling those probes is a good stress test to ensure we are only > >> accepting valid probe locations. > >> > >> multiple_kprobe_types.tc ? :) > > > > Please don't mixed it with the concept of 'multiple' probe test. > > It is different that > > - kprobes can put probes on each instruction boundary. > > - kprobes can allocate and enable multiple probes at the same time. > > > > What the multiple_kprobes.tc tests is the latter one. > > (This is the reason why it chooses different functions so as not to > > interfere with each other.) > > Ok, I was coming from the point of view that both tests end up > installing "multiple" kprobes, but I do see your point. > > How about adding two new tests: > 1. The same test as has been proposed in this thread: trying to add a > kprobe at every byte within $FUNCTION_FORK upto an offset of 256 bytes. > We can probably call it kprobe_insn_boundary.tc OK. > 2. A new test to ensure we can add different kprobe types > (kprobe_opt_types.tc). This test will need to enable and check if each > probe has been optimized or not and needs arch-specific knowledge so > that we can take care of x86. OK, this should be only for x86. > > Would that be ok? Yes, this sounds good to me. Thank you! > > > Thanks, > Naveen > -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
