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

[Alexei Starovoitov]

On 6/12/15 3:08 PM, Andy Lutomirski wrote:
> On Fri, Jun 12, 2015 at 2:40 PM, Alexei Starovoitov <ast@xxxxxxxxxxxx> wrote:
> > 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/