On 10/17/18 2:31 PM, Arnaldo Carvalho de Melo wrote: > > Keep all that info in a file, as I described above. Or keep it for a > while, to give that thread in userspace time to get it and tell the > kernel that it can trow it away.
stashing by kernel into a file is a huge headache, since format of the file becomes kernel abi. Plus why have it in two places (in a file and in normal kernel data structures)? > It may well be that most of the time the 'perf record' thread catching > those events picks that up and saves it in > /var/tmp/bcc/bpf_prog_BUILDID/ even before the program gets unloaded, > no? Whether perf user space stashes that info into perf.data as synthetic records or stashes it somewhere in /var/tmp/ sound about equivalent to me. Both have their pros and cons. This is certainly a good topic to discuss further. But asking kernel to keep JITed images and all relevant bpf data after program has been unloaded sounds really scary to me. I struggling to think through the security implications with that. How long kernel suppose to keep that? Some timeout? As I explained already the time it takes for perf to do _single_ get_fd_by_id syscall when it sees RECORD_MMAP with prog_id is pretty instant. All other syscalls to grab JITed image and everything else can be done later. The prog will not go away because perf will hold an fd. If prog was somehow unloaded before perf could do get_fd_by_id no one cares about such programs, since there is close to zero chance that this program was attached to anything and absolutely no chance that it run.
