| Message ID | 20220809195429.1043220-2-kuifeng@fb.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | Parameterize task iterators. | expand |
On Tue, Aug 9, 2022 at 12:54 PM Kui-Feng Lee <kuifeng@fb.com> wrote: > > Allow creating an iterator that loops through resources of one task/thread. > > People could only create iterators to loop through all resources of > files, vma, and tasks in the system, even though they were interested > in only the resources of a specific task or process. Passing the > additional parameters, people can now create an iterator to go > through all resources or only the resources of a task. > > Signed-off-by: Kui-Feng Lee <kuifeng@fb.com> > --- > include/linux/bpf.h | 8 ++ > include/uapi/linux/bpf.h | 36 +++++++++ > kernel/bpf/task_iter.c | 134 +++++++++++++++++++++++++++------ > tools/include/uapi/linux/bpf.h | 36 +++++++++ > 4 files changed, 190 insertions(+), 24 deletions(-) > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > index 11950029284f..bef81324e5f1 100644 > --- a/include/linux/bpf.h > +++ b/include/linux/bpf.h > @@ -1718,6 +1718,14 @@ int bpf_obj_get_user(const char __user *pathname, int flags); > > struct bpf_iter_aux_info { > struct bpf_map *map; > + struct { > + enum bpf_iter_task_type type; > + union { > + u32 tid; > + u32 tgid; > + u32 pid_fd; > + }; > + } task; > }; > > typedef int (*bpf_iter_attach_target_t)(struct bpf_prog *prog, > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > index ffcbf79a556b..3d0b9e34089f 100644 > --- a/include/uapi/linux/bpf.h > +++ b/include/uapi/linux/bpf.h > @@ -87,10 +87,46 @@ struct bpf_cgroup_storage_key { > __u32 attach_type; /* program attach type (enum bpf_attach_type) */ > }; > > +/* > + * The task type of iterators. > + * > + * For BPF task iterators, they can be parameterized with various > + * parameters to visit only some of tasks. > + * > + * BPF_TASK_ITER_ALL (default) > + * Iterate over resources of every task. > + * > + * BPF_TASK_ITER_TID > + * Iterate over resources of a task/tid. > + * > + * BPF_TASK_ITER_TGID > + * Iterate over reosurces of evevry task of a process / task group. > + * > + * BPF_TASK_ITER_PIDFD > + * Iterate over resources of every task of a process /task group specified by a pidfd. > + */ > +enum bpf_iter_task_type { > + BPF_TASK_ITER_ALL = 0, > + BPF_TASK_ITER_TID, > + BPF_TASK_ITER_TGID, > + BPF_TASK_ITER_PIDFD, > +}; > + > union bpf_iter_link_info { > struct { > __u32 map_fd; > } map; > + /* > + * Parameters of task iterators. > + */ > + struct { > + enum bpf_iter_task_type type; > + union { > + __u32 tid; > + __u32 tgid; > + __u32 pid_fd; > + }; Sorry I'm late to this discussion, but with enum and with union we kinda tell the kernel the same information twice. Here is how the selftest looks: + linfo.task.tid = getpid(); + linfo.task.type = BPF_TASK_ITER_TID; first line -> use tid. second line -> yeah. I really meant the tid. Instead of union and type can we do: > + __u32 tid; > + __u32 tgid; > + __u32 pid_fd; as 3 separate fields? The kernel would have to check that only one of them is set. I could have missed an earlier discussion on this subj.
On Tue, 2022-08-09 at 15:12 -0700, Alexei Starovoitov wrote: > On Tue, Aug 9, 2022 at 12:54 PM Kui-Feng Lee <kuifeng@fb.com> wrote: > > > > Allow creating an iterator that loops through resources of one > > task/thread. > > > > People could only create iterators to loop through all resources of > > files, vma, and tasks in the system, even though they were > > interested > > in only the resources of a specific task or process. Passing the > > additional parameters, people can now create an iterator to go > > through all resources or only the resources of a task. > > > > Signed-off-by: Kui-Feng Lee <kuifeng@fb.com> > > --- > > include/linux/bpf.h | 8 ++ > > include/uapi/linux/bpf.h | 36 +++++++++ > > kernel/bpf/task_iter.c | 134 +++++++++++++++++++++++++++-- > > ---- > > tools/include/uapi/linux/bpf.h | 36 +++++++++ > > 4 files changed, 190 insertions(+), 24 deletions(-) > > > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > > index 11950029284f..bef81324e5f1 100644 > > --- a/include/linux/bpf.h > > +++ b/include/linux/bpf.h > > @@ -1718,6 +1718,14 @@ int bpf_obj_get_user(const char __user > > *pathname, int flags); > > > > struct bpf_iter_aux_info { > > struct bpf_map *map; > > + struct { > > + enum bpf_iter_task_type type; > > + union { > > + u32 tid; > > + u32 tgid; > > + u32 pid_fd; > > + }; > > + } task; > > }; > > > > typedef int (*bpf_iter_attach_target_t)(struct bpf_prog *prog, > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > index ffcbf79a556b..3d0b9e34089f 100644 > > --- a/include/uapi/linux/bpf.h > > +++ b/include/uapi/linux/bpf.h > > @@ -87,10 +87,46 @@ struct bpf_cgroup_storage_key { > > __u32 attach_type; /* program attach type > > (enum bpf_attach_type) */ > > }; > > > > +/* > > + * The task type of iterators. > > + * > > + * For BPF task iterators, they can be parameterized with various > > + * parameters to visit only some of tasks. > > + * > > + * BPF_TASK_ITER_ALL (default) > > + * Iterate over resources of every task. > > + * > > + * BPF_TASK_ITER_TID > > + * Iterate over resources of a task/tid. > > + * > > + * BPF_TASK_ITER_TGID > > + * Iterate over reosurces of evevry task of a process / task > > group. > > + * > > + * BPF_TASK_ITER_PIDFD > > + * Iterate over resources of every task of a process /task > > group specified by a pidfd. > > + */ > > +enum bpf_iter_task_type { > > + BPF_TASK_ITER_ALL = 0, > > + BPF_TASK_ITER_TID, > > + BPF_TASK_ITER_TGID, > > + BPF_TASK_ITER_PIDFD, > > +}; > > + > > union bpf_iter_link_info { > > struct { > > __u32 map_fd; > > } map; > > + /* > > + * Parameters of task iterators. > > + */ > > + struct { > > + enum bpf_iter_task_type type; > > + union { > > + __u32 tid; > > + __u32 tgid; > > + __u32 pid_fd; > > + }; > > Sorry I'm late to this discussion, but > with enum and with union we kinda tell > the kernel the same information twice. > Here is how the selftest looks: > + linfo.task.tid = getpid(); > + linfo.task.type = BPF_TASK_ITER_TID; > > first line -> use tid. > second line -> yeah. I really meant the tid. > > Instead of union and type can we do: > > + __u32 tid; > > + __u32 tgid; > > + __u32 pid_fd; > > as 3 separate fields? > The kernel would have to check that only one > of them is set. > > I could have missed an earlier discussion on this subj. We may have other parameter types later, for example, cgroups. Unfortunately, we don't have tagged enum or tagged union, like what Rust or Haskell has, in C. A separated 'type' field would be easier and clear to distinguish them. With 3 separated fields, people may wonder if they can be set them all, or just one of them, in my opinion. With an union, people should know only one of them should be set.
On Tue, Aug 9, 2022 at 3:35 PM Kui-Feng Lee <kuifeng@fb.com> wrote: > > On Tue, 2022-08-09 at 15:12 -0700, Alexei Starovoitov wrote: > > On Tue, Aug 9, 2022 at 12:54 PM Kui-Feng Lee <kuifeng@fb.com> wrote: > > > > > > Allow creating an iterator that loops through resources of one > > > task/thread. > > > > > > People could only create iterators to loop through all resources of > > > files, vma, and tasks in the system, even though they were > > > interested > > > in only the resources of a specific task or process. Passing the > > > additional parameters, people can now create an iterator to go > > > through all resources or only the resources of a task. > > > > > > Signed-off-by: Kui-Feng Lee <kuifeng@fb.com> > > > --- > > > include/linux/bpf.h | 8 ++ > > > include/uapi/linux/bpf.h | 36 +++++++++ > > > kernel/bpf/task_iter.c | 134 +++++++++++++++++++++++++++-- > > > ---- > > > tools/include/uapi/linux/bpf.h | 36 +++++++++ > > > 4 files changed, 190 insertions(+), 24 deletions(-) > > > > > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > > > index 11950029284f..bef81324e5f1 100644 > > > --- a/include/linux/bpf.h > > > +++ b/include/linux/bpf.h > > > @@ -1718,6 +1718,14 @@ int bpf_obj_get_user(const char __user > > > *pathname, int flags); > > > > > > struct bpf_iter_aux_info { > > > struct bpf_map *map; > > > + struct { > > > + enum bpf_iter_task_type type; > > > + union { > > > + u32 tid; > > > + u32 tgid; > > > + u32 pid_fd; > > > + }; > > > + } task; > > > }; > > > > > > typedef int (*bpf_iter_attach_target_t)(struct bpf_prog *prog, > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > > index ffcbf79a556b..3d0b9e34089f 100644 > > > --- a/include/uapi/linux/bpf.h > > > +++ b/include/uapi/linux/bpf.h > > > @@ -87,10 +87,46 @@ struct bpf_cgroup_storage_key { > > > __u32 attach_type; /* program attach type > > > (enum bpf_attach_type) */ > > > }; > > > > > > +/* > > > + * The task type of iterators. > > > + * > > > + * For BPF task iterators, they can be parameterized with various > > > + * parameters to visit only some of tasks. > > > + * > > > + * BPF_TASK_ITER_ALL (default) > > > + * Iterate over resources of every task. > > > + * > > > + * BPF_TASK_ITER_TID > > > + * Iterate over resources of a task/tid. > > > + * > > > + * BPF_TASK_ITER_TGID > > > + * Iterate over reosurces of evevry task of a process / task > > > group. > > > + * > > > + * BPF_TASK_ITER_PIDFD > > > + * Iterate over resources of every task of a process /task > > > group specified by a pidfd. > > > + */ > > > +enum bpf_iter_task_type { > > > + BPF_TASK_ITER_ALL = 0, > > > + BPF_TASK_ITER_TID, > > > + BPF_TASK_ITER_TGID, > > > + BPF_TASK_ITER_PIDFD, > > > +}; > > > + > > > union bpf_iter_link_info { > > > struct { > > > __u32 map_fd; > > > } map; > > > + /* > > > + * Parameters of task iterators. > > > + */ > > > + struct { > > > + enum bpf_iter_task_type type; > > > + union { > > > + __u32 tid; > > > + __u32 tgid; > > > + __u32 pid_fd; > > > + }; > > > > Sorry I'm late to this discussion, but > > with enum and with union we kinda tell > > the kernel the same information twice. > > Here is how the selftest looks: > > + linfo.task.tid = getpid(); > > + linfo.task.type = BPF_TASK_ITER_TID; > > > > first line -> use tid. > > second line -> yeah. I really meant the tid. > > > > Instead of union and type can we do: > > > + __u32 tid; > > > + __u32 tgid; > > > + __u32 pid_fd; > > > > as 3 separate fields? > > The kernel would have to check that only one > > of them is set. > > > > I could have missed an earlier discussion on this subj. > > We may have other parameter types later, for example, cgroups. > Unfortunately, we don't have tagged enum or tagged union, like what > Rust or Haskell has, in C. A separated 'type' field would be easier > and clear to distinguish them. With 3 separated fields, people may > wonder if they can be set them all, or just one of them, in my opinion. > With an union, people should know only one of them should be set. What stops us adding new fields to the end in such a case? Some combinations will not be meaningful and the kernel would have to check and error regardless. Imagine extending union: struct { enum bpf_iter_task_type type; union { struct { __u32 tid; __u64 something_else; }; __u32 tgid; __u32 pid_fd; }; }; and now we're suddenly hitting the same issue we discussed with struct bpf_link_info in the other thread due to alignment increasing from 4 to 8 bytes. We might even need bpf_iter_link_info _v2. If 'something_else' is u32 the kernel still needs to check that it's zero in the tgid and pid_fd cases. If we're extending fields we can add a comment: struct { __u32 tid; __u32 tgid; __u32 pid_fd; __u32 something_else; /* useful in combination with tid */ }; and it's obvious what is used with what. It still feels that 3 different fields are easier to use.
On Tue, 2022-08-09 at 18:08 -0700, Alexei Starovoitov wrote: > On Tue, Aug 9, 2022 at 3:35 PM Kui-Feng Lee <kuifeng@fb.com> wrote: > > > > On Tue, 2022-08-09 at 15:12 -0700, Alexei Starovoitov wrote: > > > On Tue, Aug 9, 2022 at 12:54 PM Kui-Feng Lee <kuifeng@fb.com> > > > wrote: > > > > > > > > Allow creating an iterator that loops through resources of one > > > > task/thread. > > > > > > > > People could only create iterators to loop through all > > > > resources of > > > > files, vma, and tasks in the system, even though they were > > > > interested > > > > in only the resources of a specific task or process. Passing > > > > the > > > > additional parameters, people can now create an iterator to go > > > > through all resources or only the resources of a task. > > > > > > > > Signed-off-by: Kui-Feng Lee <kuifeng@fb.com> > > > > --- > > > > include/linux/bpf.h | 8 ++ > > > > include/uapi/linux/bpf.h | 36 +++++++++ > > > > kernel/bpf/task_iter.c | 134 > > > > +++++++++++++++++++++++++++-- > > > > ---- > > > > tools/include/uapi/linux/bpf.h | 36 +++++++++ > > > > 4 files changed, 190 insertions(+), 24 deletions(-) > > > > > > > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > > > > index 11950029284f..bef81324e5f1 100644 > > > > --- a/include/linux/bpf.h > > > > +++ b/include/linux/bpf.h > > > > @@ -1718,6 +1718,14 @@ int bpf_obj_get_user(const char __user > > > > *pathname, int flags); > > > > > > > > struct bpf_iter_aux_info { > > > > struct bpf_map *map; > > > > + struct { > > > > + enum bpf_iter_task_type type; > > > > + union { > > > > + u32 tid; > > > > + u32 tgid; > > > > + u32 pid_fd; > > > > + }; > > > > + } task; > > > > }; > > > > > > > > typedef int (*bpf_iter_attach_target_t)(struct bpf_prog *prog, > > > > diff --git a/include/uapi/linux/bpf.h > > > > b/include/uapi/linux/bpf.h > > > > index ffcbf79a556b..3d0b9e34089f 100644 > > > > --- a/include/uapi/linux/bpf.h > > > > +++ b/include/uapi/linux/bpf.h > > > > @@ -87,10 +87,46 @@ struct bpf_cgroup_storage_key { > > > > __u32 attach_type; /* program attach type > > > > (enum bpf_attach_type) */ > > > > }; > > > > > > > > +/* > > > > + * The task type of iterators. > > > > + * > > > > + * For BPF task iterators, they can be parameterized with > > > > various > > > > + * parameters to visit only some of tasks. > > > > + * > > > > + * BPF_TASK_ITER_ALL (default) > > > > + * Iterate over resources of every task. > > > > + * > > > > + * BPF_TASK_ITER_TID > > > > + * Iterate over resources of a task/tid. > > > > + * > > > > + * BPF_TASK_ITER_TGID > > > > + * Iterate over reosurces of evevry task of a process / > > > > task > > > > group. > > > > + * > > > > + * BPF_TASK_ITER_PIDFD > > > > + * Iterate over resources of every task of a process /task > > > > group specified by a pidfd. > > > > + */ > > > > +enum bpf_iter_task_type { > > > > + BPF_TASK_ITER_ALL = 0, > > > > + BPF_TASK_ITER_TID, > > > > + BPF_TASK_ITER_TGID, > > > > + BPF_TASK_ITER_PIDFD, > > > > +}; > > > > + > > > > union bpf_iter_link_info { > > > > struct { > > > > __u32 map_fd; > > > > } map; > > > > + /* > > > > + * Parameters of task iterators. > > > > + */ > > > > + struct { > > > > + enum bpf_iter_task_type type; > > > > + union { > > > > + __u32 tid; > > > > + __u32 tgid; > > > > + __u32 pid_fd; > > > > + }; > > > > > > Sorry I'm late to this discussion, but > > > with enum and with union we kinda tell > > > the kernel the same information twice. > > > Here is how the selftest looks: > > > + linfo.task.tid = getpid(); > > > + linfo.task.type = BPF_TASK_ITER_TID; > > > > > > first line -> use tid. > > > second line -> yeah. I really meant the tid. > > > > > > Instead of union and type can we do: > > > > + __u32 tid; > > > > + __u32 tgid; > > > > + __u32 pid_fd; > > > > > > as 3 separate fields? > > > The kernel would have to check that only one > > > of them is set. > > > > > > I could have missed an earlier discussion on this subj. > > > > We may have other parameter types later, for example, cgroups. > > Unfortunately, we don't have tagged enum or tagged union, like what > > Rust or Haskell has, in C. A separated 'type' field would be > > easier > > and clear to distinguish them. With 3 separated fields, people may > > wonder if they can be set them all, or just one of them, in my > > opinion. > > With an union, people should know only one of them should be set. > > What stops us adding new fields to the end in such a case? > Some combinations will not be meaningful and the kernel > would have to check and error regardless. > Imagine extending union: > struct { > enum bpf_iter_task_type type; > union { > struct { > __u32 tid; > __u64 something_else; > }; > __u32 tgid; > __u32 pid_fd; > }; > }; > > and now we're suddenly hitting the same issue we discussed > with struct bpf_link_info in the other thread due to alignment > increasing from 4 to 8 bytes. > We might even need bpf_iter_link_info _v2. It is a good point. In that case, we probably need task_v2 instead of bpf_iter_link_info_v2. The other solution is to make whole 'task' as an union instead of a struct. union bpf_iter_link_info { ...... union { enum bpf_iter_task_type type; struct { enum bpf_iter_task_type tid__type; __u32 tid; }; struct { enum bpf_iter_task_type tgid__type; __u32 tgid; }; ...... } task; } Even adding something new, it doesn't affect the offsets of old fields. > > If 'something_else' is u32 the kernel still needs to check > that it's zero in the tgid and pid_fd cases. > If we're extending fields we can add a comment: > struct { > __u32 tid; > __u32 tgid; > __u32 pid_fd; > __u32 something_else; /* useful in combination with tid */ > }; > and it's obvious what is used with what. > > It still feels that 3 different fields are easier to use. Agree! Having 3 separated fields is easier to use for assigning only one value.
diff --git a/include/linux/bpf.h b/include/linux/bpf.h index 11950029284f..bef81324e5f1 100644 --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -1718,6 +1718,14 @@ int bpf_obj_get_user(const char __user *pathname, int flags); struct bpf_iter_aux_info { struct bpf_map *map; + struct { + enum bpf_iter_task_type type; + union { + u32 tid; + u32 tgid; + u32 pid_fd; + }; + } task; }; typedef int (*bpf_iter_attach_target_t)(struct bpf_prog *prog, diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index ffcbf79a556b..3d0b9e34089f 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -87,10 +87,46 @@ struct bpf_cgroup_storage_key { __u32 attach_type; /* program attach type (enum bpf_attach_type) */ }; +/* + * The task type of iterators. + * + * For BPF task iterators, they can be parameterized with various + * parameters to visit only some of tasks. + * + * BPF_TASK_ITER_ALL (default) + * Iterate over resources of every task. + * + * BPF_TASK_ITER_TID + * Iterate over resources of a task/tid. + * + * BPF_TASK_ITER_TGID + * Iterate over reosurces of evevry task of a process / task group. + * + * BPF_TASK_ITER_PIDFD + * Iterate over resources of every task of a process /task group specified by a pidfd. + */ +enum bpf_iter_task_type { + BPF_TASK_ITER_ALL = 0, + BPF_TASK_ITER_TID, + BPF_TASK_ITER_TGID, + BPF_TASK_ITER_PIDFD, +}; + union bpf_iter_link_info { struct { __u32 map_fd; } map; + /* + * Parameters of task iterators. + */ + struct { + enum bpf_iter_task_type type; + union { + __u32 tid; + __u32 tgid; + __u32 pid_fd; + }; + } task; }; /* BPF syscall commands, see bpf(2) man-page for more details. */ diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c index 8c921799def4..047d94493117 100644 --- a/kernel/bpf/task_iter.c +++ b/kernel/bpf/task_iter.c @@ -12,6 +12,12 @@ struct bpf_iter_seq_task_common { struct pid_namespace *ns; + enum bpf_iter_task_type type; + union { + u32 tid; + u32 tgid; + u32 pid_fd; + }; }; struct bpf_iter_seq_task_info { @@ -22,24 +28,41 @@ struct bpf_iter_seq_task_info { u32 tid; }; -static struct task_struct *task_seq_get_next(struct pid_namespace *ns, +static struct task_struct *task_seq_get_next(struct bpf_iter_seq_task_common *common, u32 *tid, bool skip_if_dup_files) { struct task_struct *task = NULL; struct pid *pid; + if (common->type == BPF_TASK_ITER_TID) { + if (*tid && *tid != common->tid) + return NULL; + rcu_read_lock(); + pid = find_pid_ns(common->tid, common->ns); + if (pid) { + task = get_pid_task(pid, PIDTYPE_PID); + *tid = common->tid; + } + rcu_read_unlock(); + return task; + } + rcu_read_lock(); retry: - pid = find_ge_pid(*tid, ns); + pid = find_ge_pid(*tid, common->ns); if (pid) { - *tid = pid_nr_ns(pid, ns); + *tid = pid_nr_ns(pid, common->ns); task = get_pid_task(pid, PIDTYPE_PID); + + if (!task) { ++*tid; goto retry; - } else if (skip_if_dup_files && !thread_group_leader(task) && - task->files == task->group_leader->files) { + } else if ((skip_if_dup_files && !thread_group_leader(task) && + task->files == task->group_leader->files) || + (common->type == BPF_TASK_ITER_TGID && + __task_pid_nr_ns(task, PIDTYPE_TGID, common->ns) != common->tgid)) { put_task_struct(task); task = NULL; ++*tid; @@ -56,7 +79,8 @@ static void *task_seq_start(struct seq_file *seq, loff_t *pos) struct bpf_iter_seq_task_info *info = seq->private; struct task_struct *task; - task = task_seq_get_next(info->common.ns, &info->tid, false); + task = task_seq_get_next(&info->common, &info->tid, false); + if (!task) return NULL; @@ -73,7 +97,8 @@ static void *task_seq_next(struct seq_file *seq, void *v, loff_t *pos) ++*pos; ++info->tid; put_task_struct((struct task_struct *)v); - task = task_seq_get_next(info->common.ns, &info->tid, false); + + task = task_seq_get_next(&info->common, &info->tid, false); if (!task) return NULL; @@ -117,6 +142,50 @@ static void task_seq_stop(struct seq_file *seq, void *v) put_task_struct((struct task_struct *)v); } +static int bpf_iter_attach_task(struct bpf_prog *prog, + union bpf_iter_link_info *linfo, + struct bpf_iter_aux_info *aux) +{ + unsigned int flags; + struct pid_namespace *ns; + struct pid *pid; + pid_t tgid; + + if (linfo->task.type == BPF_TASK_ITER_ALL && linfo->task.pid_fd != 0) + return -EINVAL; + + aux->task.type = linfo->task.type; + + switch (linfo->task.type) { + case BPF_TASK_ITER_TID: + aux->task.tid = linfo->task.tid; + break; + case BPF_TASK_ITER_TGID: + aux->task.tgid = linfo->task.tgid; + break; + case BPF_TASK_ITER_PIDFD: + pid = pidfd_get_pid(linfo->task.pid_fd, &flags); + if (IS_ERR(pid)) + return PTR_ERR(pid); + + ns = task_active_pid_ns(current); + if (IS_ERR(ns)) + return PTR_ERR(ns); + + tgid = pid_nr_ns(pid, ns); + if (tgid <= 0) + return -EINVAL; + + aux->task.tgid = tgid; + aux->task.type = BPF_TASK_ITER_TGID; + break; + default: + break; + } + + return 0; +} + static const struct seq_operations task_seq_ops = { .start = task_seq_start, .next = task_seq_next, @@ -137,8 +206,7 @@ struct bpf_iter_seq_task_file_info { static struct file * task_file_seq_get_next(struct bpf_iter_seq_task_file_info *info) { - struct pid_namespace *ns = info->common.ns; - u32 curr_tid = info->tid; + u32 saved_tid = info->tid; struct task_struct *curr_task; unsigned int curr_fd = info->fd; @@ -151,21 +219,18 @@ task_file_seq_get_next(struct bpf_iter_seq_task_file_info *info) curr_task = info->task; curr_fd = info->fd; } else { - curr_task = task_seq_get_next(ns, &curr_tid, true); + curr_task = task_seq_get_next(&info->common, &info->tid, true); if (!curr_task) { info->task = NULL; - info->tid = curr_tid; return NULL; } - /* set info->task and info->tid */ + /* set info->task */ info->task = curr_task; - if (curr_tid == info->tid) { + if (saved_tid == info->tid) curr_fd = info->fd; - } else { - info->tid = curr_tid; + else curr_fd = 0; - } } rcu_read_lock(); @@ -186,9 +251,15 @@ task_file_seq_get_next(struct bpf_iter_seq_task_file_info *info) /* the current task is done, go to the next task */ rcu_read_unlock(); put_task_struct(curr_task); + + if (info->common.type == BPF_TASK_ITER_TID) { + info->task = NULL; + return NULL; + } + info->task = NULL; info->fd = 0; - curr_tid = ++(info->tid); + saved_tid = ++(info->tid); goto again; } @@ -269,6 +340,17 @@ static int init_seq_pidns(void *priv_data, struct bpf_iter_aux_info *aux) struct bpf_iter_seq_task_common *common = priv_data; common->ns = get_pid_ns(task_active_pid_ns(current)); + common->type = aux->task.type; + switch (common->type) { + case BPF_TASK_ITER_TID: + common->tid = aux->task.tid; + break; + case BPF_TASK_ITER_TGID: + common->tgid = aux->task.tgid; + break; + default: + break; + } return 0; } @@ -307,11 +389,10 @@ enum bpf_task_vma_iter_find_op { static struct vm_area_struct * task_vma_seq_get_next(struct bpf_iter_seq_task_vma_info *info) { - struct pid_namespace *ns = info->common.ns; enum bpf_task_vma_iter_find_op op; struct vm_area_struct *curr_vma; struct task_struct *curr_task; - u32 curr_tid = info->tid; + u32 saved_tid = info->tid; /* If this function returns a non-NULL vma, it holds a reference to * the task_struct, and holds read lock on vma->mm->mmap_lock. @@ -371,14 +452,13 @@ task_vma_seq_get_next(struct bpf_iter_seq_task_vma_info *info) } } else { again: - curr_task = task_seq_get_next(ns, &curr_tid, true); + curr_task = task_seq_get_next(&info->common, &info->tid, true); if (!curr_task) { - info->tid = curr_tid + 1; + info->tid++; goto finish; } - if (curr_tid != info->tid) { - info->tid = curr_tid; + if (saved_tid != info->tid) { /* new task, process the first vma */ op = task_vma_iter_first_vma; } else { @@ -430,9 +510,12 @@ task_vma_seq_get_next(struct bpf_iter_seq_task_vma_info *info) return curr_vma; next_task: + if (info->common.type == BPF_TASK_ITER_TID) + goto finish; + put_task_struct(curr_task); info->task = NULL; - curr_tid++; + info->tid++; goto again; finish: @@ -533,6 +616,7 @@ static const struct bpf_iter_seq_info task_seq_info = { static struct bpf_iter_reg task_reg_info = { .target = "task", + .attach_target = bpf_iter_attach_task, .feature = BPF_ITER_RESCHED, .ctx_arg_info_size = 1, .ctx_arg_info = { @@ -551,6 +635,7 @@ static const struct bpf_iter_seq_info task_file_seq_info = { static struct bpf_iter_reg task_file_reg_info = { .target = "task_file", + .attach_target = bpf_iter_attach_task, .feature = BPF_ITER_RESCHED, .ctx_arg_info_size = 2, .ctx_arg_info = { @@ -571,6 +656,7 @@ static const struct bpf_iter_seq_info task_vma_seq_info = { static struct bpf_iter_reg task_vma_reg_info = { .target = "task_vma", + .attach_target = bpf_iter_attach_task, .feature = BPF_ITER_RESCHED, .ctx_arg_info_size = 2, .ctx_arg_info = { diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index ffcbf79a556b..3d0b9e34089f 100644 --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -87,10 +87,46 @@ struct bpf_cgroup_storage_key { __u32 attach_type; /* program attach type (enum bpf_attach_type) */ }; +/* + * The task type of iterators. + * + * For BPF task iterators, they can be parameterized with various + * parameters to visit only some of tasks. + * + * BPF_TASK_ITER_ALL (default) + * Iterate over resources of every task. + * + * BPF_TASK_ITER_TID + * Iterate over resources of a task/tid. + * + * BPF_TASK_ITER_TGID + * Iterate over reosurces of evevry task of a process / task group. + * + * BPF_TASK_ITER_PIDFD + * Iterate over resources of every task of a process /task group specified by a pidfd. + */ +enum bpf_iter_task_type { + BPF_TASK_ITER_ALL = 0, + BPF_TASK_ITER_TID, + BPF_TASK_ITER_TGID, + BPF_TASK_ITER_PIDFD, +}; + union bpf_iter_link_info { struct { __u32 map_fd; } map; + /* + * Parameters of task iterators. + */ + struct { + enum bpf_iter_task_type type; + union { + __u32 tid; + __u32 tgid; + __u32 pid_fd; + }; + } task; }; /* BPF syscall commands, see bpf(2) man-page for more details. */
Allow creating an iterator that loops through resources of one task/thread. People could only create iterators to loop through all resources of files, vma, and tasks in the system, even though they were interested in only the resources of a specific task or process. Passing the additional parameters, people can now create an iterator to go through all resources or only the resources of a task. Signed-off-by: Kui-Feng Lee <kuifeng@fb.com> --- include/linux/bpf.h | 8 ++ include/uapi/linux/bpf.h | 36 +++++++++ kernel/bpf/task_iter.c | 134 +++++++++++++++++++++++++++------ tools/include/uapi/linux/bpf.h | 36 +++++++++ 4 files changed, 190 insertions(+), 24 deletions(-)