netdev - Re: [PATCH bpf-next v3 2/7] bpf: introduce bpf subcommand BPF_TASK_FD

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] [day] [month] [year] [list]

Date:   Wed, 23 May 2018 14:27:45 -0700
From:   Yonghong Song <yhs@...com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Martin KaFai Lau <kafai@...com>
CC:     <peterz@...radead.org>, <ast@...com>, <daniel@...earbox.net>,
        <netdev@...r.kernel.org>, <kernel-team@...com>
Subject: Re: [PATCH bpf-next v3 2/7] bpf: introduce bpf subcommand
 BPF_TASK_FD_QUERY



On 5/23/18 2:04 PM, Alexei Starovoitov wrote:
> On Wed, May 23, 2018 at 10:13:22AM -0700, Martin KaFai Lau wrote:
>>> +		__u32		prog_id;	/* output: prod_id */
>>> +		__u32		attach_info;	/* output: BPF_ATTACH_* */
>>> +		__u64		probe_offset;	/* output: probe_offset */
>>> +		__u64		probe_addr;	/* output: probe_addr */
>>> +	} task_fd_query;
>>>   } __attribute__((aligned(8)));
>>>   
>>>   /* The description below is an attempt at providing documentation to eBPF
>>> @@ -2458,4 +2475,14 @@ struct bpf_fib_lookup {
>>>   	__u8	dmac[6];     /* ETH_ALEN */
>>>   };
>>>   
>>> +/* used by <task, fd> based query */
>>> +enum {
>> Nit. Instead of a comment, is it better to give this
>> enum a descriptive name?
>>
>>> +	BPF_ATTACH_RAW_TRACEPOINT,	/* tp name */
>>> +	BPF_ATTACH_TRACEPOINT,		/* tp name */
>>> +	BPF_ATTACH_KPROBE,		/* (symbol + offset) or addr */
>>> +	BPF_ATTACH_KRETPROBE,		/* (symbol + offset) or addr */
>>> +	BPF_ATTACH_UPROBE,		/* filename + offset */
>>> +	BPF_ATTACH_URETPROBE,		/* filename + offset */
>>> +};
> 
> One more nit here.
> Can we come up with better names for the above?
> 'attach' is a verb. I cannot help but read above as it's an action
> for the kernel to attach to something and not the type of event
> where the program was attached to.
> Since we pass task+fd into that BPF_TASK_FD_QUERY command how
> about returning BPF_FD_TYPE_KPROBE, BPF_FD_TYPE_TRACEPOINT, ... ?

Okay will use BPF_FD_TYPE_*... which is indeed better than
BPF_ATTACH_*.