[PATCH] selftests/ftrace: update kprobe syntax error test for ppc64le

Steven Rostedt rostedt at goodmis.org
Tue Nov 5 02:27:04 AEDT 2024


On Mon, 4 Nov 2024 04:36:15 -0600
Segher Boessenkool <segher at kernel.crashing.org> wrote:

> > >>Querying for function arguments is supported on kprobes only at function
> > >>entry. This is a negative test case where the offset is intentionally
> > >>set beyond function entry while querying for function arguments.
> > >>I guess, simply setting the offset to 20 (vfs_read is anyway
> > >>going to be beyond 5 instructions) instead of 8 for powerpc would
> > >>make all platforms and ABI variants happy?  
> > >
> > >I have no idea.  What is this "offset" anyway?  
> > 
> > offset (in bytes) from function start address..  
> 
> But what is there?

Function start address is what kallsyms returns. That is:

  grep function /proc/kallsyms

> 
> > >This is just the ELFv2 ABI.  No platform can make up its own thing at
> > >all (well, none decided to be gratuitously incompatible, so far).  And
> > >there are no "ABI variants"!  
> > 
> > The test case applies for ABIv1 & ABIv2. All ppc32 & ppc64 platforms..  
> 
> Hrm.  So you allow essentially random entry points on other ABIs to
> work?
> 
> > >You're just making assumptions here that are based on nothing else but
> > >observations of what is done most of the time.  That might work for a
> > >while -- maybe a long while even! -- but it can easily break down.  
> > 
> > Hmmm.. I understand that you want the test case to read st_other field
> > but would you rather suggest an offset of 64?  
> 
> I have no idea what "offset" means here.

The offset is the number of bytes from the address that is returned by
kallsyms.


> 
> > Is a GEP of 8/16 instructions going to be true anytime soon or is it
> > true already for some cases? The reason I ask that is some kprobe/ftrace
> > code in the kernel might need a bit of re-look if that is the case.  
> 
> An entry point has no instructions at all.  Oh, you mean the code at
> the GEP.
> 
> The LEP can already be all the allowed distances after the GEP.  And
> the .localentry GAS directive already supports all those distances
> always.  Not a lot of code written in assembler does use that, and
> certainly GCC does not use a lot of the freedom it has here, but it
> could (and so could assembler programmers).  Typically people will want
> to make the code here as short as possible, and there are restrictions
> on what is *allowed* to be done here anyway (ld, the link editor, can
> change this code after all!), so it is not too likely you will ever see
> big code at the GEP often, but times change, etc.


This is all determined by the kernel. It's considered a function entry by
the function:

   arch_kprobe_on_func_entry()

Which on PowerPC has:

static bool arch_kprobe_on_func_entry(unsigned long offset)
{
#ifdef CONFIG_PPC64_ELF_ABI_V2
#ifdef CONFIG_KPROBES_ON_FTRACE
        return offset <= 16;
#else
        return offset <= 8;
#endif
#else
        return !offset;
#endif  
}

So, being greater than 16 on powerpc with config CONFIG_PPC64_ELF_ABI_V2
set, would work. If that function changes, then the test needs to change.

-- Steve


More information about the Linuxppc-dev mailing list