On Thu, Dec 10, 2020 at 01:29:01PM -0600, Eric W. Biederman wrote: > Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > > What are the users of that thing and is there any chance to replace it > > with something saner? IOW, what *is* realistically called for each > > struct file by the users of that iterator? > > The bpf guys are no longer Cc'd and they can probably answer better than > I. > > In a previous conversation it was mentioned that task_iter was supposed > to be a high performance interface for getting proc like data out of the > kernel using bpf. > > If so I think that handles the lifetime issues as bpf programs are > supposed to be short-lived and can not pass references anywhere. > > On the flip side it raises the question did the BPF guys just make the > current layout of task_struct and struct file part of the linux kernel > user space ABI? An interesting question, that... For the record: anybody coming to complain about a removed/renamed/replaced with something else field in struct file will be refered to Figure 1. None of the VFS data structures has any layout stability warranties. If BPF folks want access to something in that, they are welcome to come and discuss the set of accessors; so far nothing of that sort has happened. Direct access to any fields of any of those structures is subject to being broken at zero notice. IMO we need some notation for a structure being off-limits for BPF, tracing, etc., along the lines of "don't access any field directly".
