On Thu, Nov 21, 2024 at 1:15 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > I'm personally not *so* hung up about a pointer in struct inode but I can > > see why Christian is and I agree adding a pointer there isn't a win for > > everybody. > > Maybe I'm annoying here but I feel that I have to be. Because it's > trivial to grow structs it's rather cumbersome work to get them to > shrink. I just looked at struct task_struct again and it has four bpf > related structures/pointers in there. Ok, struct task_struct is > everyone's favorite struct to bloat so whatever. > > For the VFS the structures we maintain longterm that need to be so > generic as to be usable by so many different filesystems have a tendency > to grow over time. > > With some we are very strict, i.e., nobody would dare to grow struct > dentry and that's mostly because we have people that really care about > this and have an eye on that and ofc also because it's costly. > > But for some structures we simply have no one caring about them that > much. So what happens is that with the ever growing list of features we > bloat them over time. There need to be some reasonable boundaries on > what we accept or not and the criteria I have been using is how > generically useful to filesystems or our infrastructre this is (roughly) > and this is rather very special-case so I'm weary of wasting 8 bytes in > struct inode that we fought rather hard to get back: Jeff's timespec > conversion and my i_state conversion. > > I'm not saying it's out of the question but I want to exhaust all other > options and I'm not yet sure we have. +1 to all of the above. I hope we don't end up as strict as sk_buff though. I think Song can proceed without this patch. Worst case bpf hash map with key==inode will do.
