> On Dec 16, 2020, at 10:18 AM, Yonghong Song <yhs@xxxxxx> wrote: > [...] >> + >> + err = bpf_iter_task_vma__load(skel); >> + if (CHECK(err, "bpf_iter_task_vma__load", "skeleton load failed\n")) >> + goto out; >> + >> + do_dummy_read(skel->progs.proc_maps); > > This do_dummy_read() is not needed, right? do_dummy_read() helped me got bug in earlier version. I am planning to change the following to do smaller reads, then do_dummy_read() is no longer needed. [...] > >> + >> +SEC("iter.s/task_vma") int proc_maps(struct bpf_iter__task_vma *ctx) >> +{ >> + struct __vm_area_struct *vma = ctx->vma; >> + struct seq_file *seq = ctx->meta->seq; >> + struct task_struct *task = ctx->task; >> + struct file *file = ctx->file; >> + char perm_str[] = "----"; >> + >> + if (task == (void *)0 || vma == (void *)0 || task->pid != pid) > > I suppose kernel already filtered all non-group-leader tasks, so here > we can have task->tgid != pid? Yeah, that works. > >> + return 0; > > Using /proc system, user typically do cat /proc/pid/maps. How can we > have a similar user experience with vma_iter here? One way to do this > is: > - We still have this bpf program, filtering based on user pid, > - normal bpftool iter pin command pid the program to say /sys/fs/bpf/task_vma > - since "pid" is in a map, user can use bpftool to update "pid" > with the target pid. > - "cat /sys/fs/bpf/task_vma" will work. > > One thing here is pid and d_path_buf are global (map) variables, so > if two users are trying to do "cat /sys/fs/bpf/task_vma" at the same > time, there will be interferences and it will not work. > > One possible way is during BPF_ITER_CREATE, we duplicate all program > maps. But this is unnecessary as in most cases, the bpf_iter is not > pinned and private to applications. > > Any other ideas? Maybe we can use task local storage for pid and d_path_buf? To make it more practical, we probably want in kernel filtering based on pid. IOW, let user specify which task to iterate. Thanks, Song