All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: FW: BPF_PSEUDO_CALL question
       [not found] ` <2601191342CEEE43887BDE71AB9772580148A97E27@irsmsx105.ger.corp.intel.com>
@ 2019-04-16  1:01   ` Alexei Starovoitov
  2019-04-16 14:34     ` Ananyev, Konstantin
  0 siblings, 1 reply; 5+ messages in thread
From: Alexei Starovoitov @ 2019-04-16  1:01 UTC (permalink / raw)
  To: Ananyev, Konstantin, bpf

On Mon, Apr 15, 2019 at 5:13 AM Ananyev, Konstantin
<konstantin.ananyev@intel.com> wrote:
>
> 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@lists.llvm.org] On Behalf Of Ananyev, Konstantin via llvm-dev
> Sent: Wednesday, April 10, 2019 7:37 PM
> To: llvm-dev@lists.llvm.org
> 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
- call pseudo +-off -> call another bpf function
there is no arbitrary call support yet.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: FW: BPF_PSEUDO_CALL question
  2019-04-16  1:01   ` FW: BPF_PSEUDO_CALL question Alexei Starovoitov
@ 2019-04-16 14:34     ` Ananyev, Konstantin
  2019-04-16 16:12       ` Alexei Starovoitov
  0 siblings, 1 reply; 5+ messages in thread
From: Ananyev, Konstantin @ 2019-04-16 14:34 UTC (permalink / raw)
  To: Alexei Starovoitov, bpf



> -----Original Message-----
> From: Alexei Starovoitov [mailto:alexei.starovoitov@gmail.com]
> Sent: Tuesday, April 16, 2019 2:01 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; bpf <bpf@vger.kernel.org>
> Subject: Re: FW: BPF_PSEUDO_CALL question
> 
> On Mon, Apr 15, 2019 at 5:13 AM Ananyev, Konstantin
> <konstantin.ananyev@intel.com> wrote:
> >
> > 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@lists.llvm.org] On Behalf Of Ananyev, Konstantin via llvm-dev
> > Sent: Wednesday, April 10, 2019 7:37 PM
> > To: llvm-dev@lists.llvm.org
> > 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?

> - call pseudo +-off -> call another bpf function
> there is no arbitrary call support yet.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: FW: BPF_PSEUDO_CALL question
  2019-04-16 14:34     ` Ananyev, Konstantin
@ 2019-04-16 16:12       ` Alexei Starovoitov
  2019-04-19 11:16         ` Ananyev, Konstantin
  0 siblings, 1 reply; 5+ messages in thread
From: Alexei Starovoitov @ 2019-04-16 16:12 UTC (permalink / raw)
  To: Ananyev, Konstantin; +Cc: bpf

On Tue, Apr 16, 2019 at 7:34 AM Ananyev, Konstantin
<konstantin.ananyev@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Alexei Starovoitov [mailto:alexei.starovoitov@gmail.com]
> > Sent: Tuesday, April 16, 2019 2:01 AM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; bpf <bpf@vger.kernel.org>
> > Subject: Re: FW: BPF_PSEUDO_CALL question
> >
> > On Mon, Apr 15, 2019 at 5:13 AM Ananyev, Konstantin
> > <konstantin.ananyev@intel.com> wrote:
> > >
> > > 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@lists.llvm.org] On Behalf Of Ananyev, Konstantin via llvm-dev
> > > Sent: Wednesday, April 10, 2019 7:37 PM
> > > To: llvm-dev@lists.llvm.org
> > > 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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: FW: BPF_PSEUDO_CALL question
  2019-04-16 16:12       ` Alexei Starovoitov
@ 2019-04-19 11:16         ` Ananyev, Konstantin
  2019-04-20  0:30           ` Alexei Starovoitov
  0 siblings, 1 reply; 5+ messages in thread
From: Ananyev, Konstantin @ 2019-04-19 11:16 UTC (permalink / raw)
  To: Alexei Starovoitov; +Cc: bpf



> > > >
> > > > 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@lists.llvm.org] On Behalf Of Ananyev, Konstantin via llvm-dev
> > > > Sent: Wednesday, April 10, 2019 7:37 PM
> > > > To: llvm-dev@lists.llvm.org
> > > > 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  


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: FW: BPF_PSEUDO_CALL question
  2019-04-19 11:16         ` Ananyev, Konstantin
@ 2019-04-20  0:30           ` Alexei Starovoitov
  0 siblings, 0 replies; 5+ messages in thread
From: Alexei Starovoitov @ 2019-04-20  0:30 UTC (permalink / raw)
  To: Ananyev, Konstantin; +Cc: bpf

On Fri, Apr 19, 2019 at 11:16:31AM +0000, Ananyev, Konstantin wrote:
> 
> 
> > > > >
> > > > > 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@lists.llvm.org] On Behalf Of Ananyev, Konstantin via llvm-dev
> > > > > Sent: Wednesday, April 10, 2019 7:37 PM
> > > > > To: llvm-dev@lists.llvm.org
> > > > > 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'm not sure what exactly you're proposing.
For local functions llvm will generate relative offset with pseudo_call mark.
That is api and cannot be changed.
Support for calling external functions is currently half way done,
since relocations are there, but could be buggy, since
there is no kernel/libbpf support for it yet.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-04-20  0:30 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <2601191342CEEE43887BDE71AB9772580148A95A96@irsmsx105.ger.corp.intel.com>
     [not found] ` <2601191342CEEE43887BDE71AB9772580148A97E27@irsmsx105.ger.corp.intel.com>
2019-04-16  1:01   ` FW: BPF_PSEUDO_CALL question Alexei Starovoitov
2019-04-16 14:34     ` Ananyev, Konstantin
2019-04-16 16:12       ` Alexei Starovoitov
2019-04-19 11:16         ` Ananyev, Konstantin
2019-04-20  0:30           ` Alexei Starovoitov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.