On 2023-06-05 15:47:23 [-0700], Andrii Nakryiko wrote: > I understand it's safe today, but I'm more worried for future places > that will do bpf_link_put(). Given it's only close() and BPF FS > unlink() that require synchronous semantics, I think it's fine to make > bpf_link_put() to be async, and have bpf_link_put_sync() (or direct, > or whatever suffix) as a conscious special case. Okay, let me do that then. > > This is invoked from the RCU callback (which is usually softirq): > > destroy_inode() > > -> call_rcu(&inode->i_rcu, i_callback); > > > > Freeing memory is fine but there is a mutex that is held in the process. > > I think it should be fine for BPF link destruction then? bpf_any_put() needs that "may sleep" exception for BPF_TYPE_LINK if it comes from RCU. I will swap that patch to be async by default and make sync for bpf_any_put() if called from close (except for the RCU case). Sebastian
