linux-kernel - Re: [PATCH bpf-next v2 3/3] bpf: Use BPF_KFUNC macro at all kfunc definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ebff2166-8a70-af62-b859-6b5c6b008b36@iogearbox.net>
Date:   Mon, 23 Jan 2023 20:04:57 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        David Vernet <void@...ifault.com>
Cc:     bpf@...r.kernel.org, ast@...nel.org, andrii@...nel.org,
        martin.lau@...ux.dev, song@...nel.org, yhs@...a.com,
        john.fastabend@...il.com, kpsingh@...nel.org, sdf@...gle.com,
        haoluo@...gle.com, jolsa@...nel.org, linux-kernel@...r.kernel.org,
        kernel-team@...a.com, memxor@...il.com
Subject: Re: [PATCH bpf-next v2 3/3] bpf: Use BPF_KFUNC macro at all kfunc
 definitions

On 1/23/23 7:54 PM, Alexei Starovoitov wrote:
> On Mon, Jan 23, 2023 at 12:48:27PM -0600, David Vernet wrote:
>> On Mon, Jan 23, 2023 at 10:33:05AM -0800, Alexei Starovoitov wrote:
>>> On Mon, Jan 23, 2023 at 11:15:06AM -0600, David Vernet wrote:
>>>> -void *bpf_obj_new_impl(u64 local_type_id__k, void *meta__ign)
>>>> +BPF_KFUNC(void *bpf_obj_new_impl(u64 local_type_id__k, void *meta__ign))
>>>>   {
>>>>   	struct btf_struct_meta *meta = meta__ign;
>>>>   	u64 size = local_type_id__k;
>>>> @@ -1790,7 +1786,7 @@ void *bpf_obj_new_impl(u64 local_type_id__k, void *meta__ign)
>>>>   	return p;
>>>>   }
>>>>   
>>>> -void bpf_obj_drop_impl(void *p__alloc, void *meta__ign)
>>>> +BPF_KFUNC(void bpf_obj_drop_impl(void *p__alloc, void *meta__ign))
>>>>   {
>>>
>>> The following also works:
>>> -BPF_KFUNC(void *bpf_obj_new_impl(u64 local_type_id__k, void *meta__ign))
>>> +BPF_KFUNC(
>>> +void *bpf_obj_new_impl(u64 local_type_id__k, void *meta__ign)
>>> +)
>>>
>>> and it looks little bit cleaner to me.
>>>
>>> git grep -A1 BPF_KFUNC
>>> can still find all instances of kfuncs.
>>>
>>> wdyt?
>>
>> I'm fine with putting it on its own line if that's your preference.
>> Agreed that it might be a bit cleaner, especially for functions with the
>> return type on its own line, so we'd have e.g.:
>>
>> BPF_KFUNC(
>> struct nf_conn *
>> bpf_skb_ct_lookup(struct __sk_buff *skb_ctx, struct bpf_sock_tuple *bpf_tuple,
>> 		  u32 tuple__sz, struct bpf_ct_opts *opts, u32 opts__sz)
> 
> Yeah. Especially for those.
> 
>> ) {
>>
>> // ...
>>
>> }
>>
>> Note the presence of the { on the closing paren. Are you ok with that?
>> Otherwise I think it will look a bit odd:
> 
> Yep. Good idea. Either ){ or ) { look good to me.
> 
>> BPF_KFUNC(
>> struct nf_conn *
>> bpf_skb_ct_lookup(struct __sk_buff *skb_ctx, struct bpf_sock_tuple *bpf_tuple,
>> 		  u32 tuple__sz, struct bpf_ct_opts *opts, u32 opts__sz)
>> )
>> {
>>
>> }

Did you look into making this similar to the EXPORT_SYMBOL() infra? If possible
that would look much more natural to developers, e.g. :

struct nf_conn *
bpf_skb_ct_lookup(struct __sk_buff *skb_ctx, struct bpf_sock_tuple *bpf_tuple,
  		  u32 tuple__sz, struct bpf_ct_opts *opts, u32 opts__sz)
{
	[...]
}

EXPORT_BPF_KFUNC(bpf_skb_ct_lookup);