RE: FW: BPF_PSEUDO_CALL question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> > > >
> > > > Hi Alexei,
> > > > I posted the question below on llvm-dev mailing list, but there is no answer so far.
> > > > As you seems the author of BPF_PSEUDO_CALL in LLVM (and linux kernel) thought might
> > > > be you know the answer?
> > > > I looked through the patches, but didn't spot anything myself.
> > > > Thanks
> > > > Konstantin
> > > >
> > > > -----Original Message-----
> > > > From: llvm-dev [mailto:llvm-dev-bounces@xxxxxxxxxxxxxx] On Behalf Of Ananyev, Konstantin via llvm-dev
> > > > Sent: Wednesday, April 10, 2019 7:37 PM
> > > > To: llvm-dev@xxxxxxxxxxxxxx
> > > > Subject: [llvm-dev] BPF_PSEUDO_CALL question
> > > >
> > > >
> > > > Hi everyone,
> > > > with clang 6.0 and onwards, for the following code:
> > > > $ cat t6.c
> > > >
> > > > #include <stdint.h>
> > > >
> > > > extern int ffx1(const void *p);
> > > >
> > > > uint64_t entry(const void *p)
> > > > {
> > > >         return ffx1(p);
> > > > }
> > > >
> > > > clang -O2  -target bpfel -c t6.c
> > > > generates for the call BPF_PSEUDO_CALL instruction:
> > > > entry:
> > > >        0:       85 10 00 00 ff ff ff ff         call -1
> > > >        1:       67 00 00 00 20 00 00 00         r0 <<= 32
> > > >        2:       c7 00 00 00 20 00 00 00         r0 s>>= 32
> > > >        3:       95 00 00 00 00 00 00 00         exit
> > > >
> > > > Is there any way to force clang to generate proper BPF_CALL instruction,
> > > > i.e: 85 00 00 00 ff ff ff ff (as it did in older versions)?
> > >
> > > older version of llvm generated broken code.
> > > there are only two call flavors:
> > > - call imm -> calling particular kernel helper where imm==helper_id
> >
> > Ok but in the example above, is it possible tell to the llvm that
> > ffx1() is actually a kernel helper with id==X?
> 
> here is how it works for helpers:
> static void *(*bpf_map_lookup_elem)(void *map, const void *key) =
>         (void *) BPF_FUNC_map_lookup_elem;
> 
> User space can hack similar thing for any integer and any name.

Thanks a lot.
Yes, such approach would work.
Though it means that user will need to define exact id for the each  helper function
and keep it always in sync between bpf programs and bpf execution environment. 
Probably not a big deal for kernel when all helpers are well defined and restricted,
but might become messy for user-space where each app might want to have it's
own set of helpers.
My thought was - might be it is possible to say to llvm that it is a helper function
but with unknown id that will be resolved dynamically at bpf load time.
I presume the answer is 'no', but wanted to double-check that I am not missing
something obvious here.
Konstantin  





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux