> > But I also wanted to point out that this helper is logically in the > > same family as bpf_probe_read_kernel/user and bpf_copy_from_user, etc, > > where we have consistent pattern that first two arguments specify > > destination buffer (so buf + len) and the remaining ones specify > > source (in probe_read it's just an address, here it's tsk_addr). So I > > wonder if it would be less surprising and more consistent to reorder > > and have: > > > > buf, len, tsk, addr, flags > > > > ? > > > > I would personally find it more intuitive to have process information > passed as either the first argument (like process_vm_readv does), or > as "last", just before the flags (as extra information required w.r.t. > to local versions, e.g. bpf_copy_from_user). I think that makes sense. I'll combine both Andrii's and Gabriele's suggestions and keep the signature as close to the existing helpers (e.g., bpf_probe_read_user) and add the additional arguments at the end. I'll proceed with this signature: bpf_access_process_vm(void *dst, u32 size, const void *unsafe_ptr, struct task_struct *tsk, unsigned int flags); Thanks for all the suggestions! Kenny
