On Fri, Mar 17, 2023 at 09:33:17AM -0700, Andrii Nakryiko wrote: > > But build IDs are _generally_ available. The only problem (AIUI) > > is when you're trying to examine the contents of one container from > > another container. And to solve that problem, you're imposing a cost > > on everybody else with (so far) pretty vague justifications. I really > > don't like to see you growing struct file for this (nor struct inode, > > nor struct vm_area_struct). It's all quite unsatisfactory and I don't > > have a good suggestion. > > There is a lot of profiling, observability and debugging tooling built > using BPF. And when capturing stack traces from BPF programs, if the > build ID note is not physically present in memory, fetching it from > the BPF program might fail in NMI (and other non-faultable contexts). > This patch set is about making sure we always can fetch build ID, even > from most restrictive environments. It's guarded by Kconfig to avoid > adding 8 bytes of overhead to struct file for environment where this > might be unacceptable, giving users and distros a choice. Lovely. As an exercise you might want to collect the stats on the number of struct file instances on the system vs. the number of files that happen to be ELF objects and are currently mmapped anywhere. That does depend upon the load, obviously, but it's not hard to collect - you already have more than enough hooks inserted in the relevant places. That might give a better appreciation of the reactions...
