Re: [PATCH net-next 1/3] bpf: introduce current->pid, tgid, uid, gid, comm accessors

On 6/12/15 3:08 PM, Andy Lutomirski wrote:

On Fri, Jun 12, 2015 at 2:40 PM, Alexei Starovoitov [off-list ref] wrote:

quoted

eBPF programs attached to kprobes need to filter based on
current->pid, uid and other fields, so introduce helper functions:

u64 bpf_get_current_pid_tgid(void)
Return: current->tgid << 32 | current->pid

u64 bpf_get_current_uid_gid(void)
Return: current_gid << 32 | current_uid

How does this work wrt namespaces,

from_kuid(current_user_ns(), uid)

 > and why the weird packing?

to minimize number of calls.

We've considered several alternatives.
1. 5 different helpers
   Cons: every call adds performance overhead

2a: single helper that populates 'struct bpf_task_info'
   and uses 'flags' with bit per field.
+struct bpf_task_info {
+       __u32 pid;
+       __u32 tgid;
+       __u32 uid;
+       __u32 gid;
+       char comm[16];
+};
bpf_get_current_task_info(task_info, size, flags)
bit 0 - fill in pid
bit 1 - fill in tgid
   Pros: single helper
   Cons: ugly to use and a lot of compares in the helper
   itself (two compares for each field)

2b. single helper that populates 'struct bpf_task_info'
   and uses 'size' to tell how many fields to fill in.
bpf_get_current_task_info(task_info, size);
+       if (size >= offsetof(struct bpf_task_info, pid) + sizeof(info->pid))
+               info->pid = task->pid;
+       if (size >= offsetof(struct bpf_task_info, tgid) + 
sizeof(info->tgid))
+               info->tgid = task->tgid;

   Pros: single call (with single compare per field).
   Cons: still hard to use when only uid is needed.

These three helpers looked as the best balance between
performance and usability.