On Fri, Jul 26, 2024 at 02:25:26PM -0700, Song Liu wrote: > On Fri, Jul 26, 2024 at 1:56 AM Matt Bobrowski <mattbobrowski@xxxxxxxxxx> wrote: > > > [...] > > + len = buf + buf__sz - ret; > > + memmove(buf, ret, len); > > + return len; > > +} > > +__bpf_kfunc_end_defs(); > > + > > +BTF_KFUNCS_START(bpf_fs_kfunc_set_ids) > > +BTF_ID_FLAGS(func, bpf_get_task_exe_file, > > + KF_ACQUIRE | KF_TRUSTED_ARGS | KF_SLEEPABLE | KF_RET_NULL) > > +BTF_ID_FLAGS(func, bpf_put_file, KF_RELEASE | KF_SLEEPABLE) > > Do we really need KF_SLEEPABLE for bpf_put_file? Well, the guts of fput() is annotated w/ might_sleep(), so the calling thread may presumably be involuntarily put to sleep? You can also see the guts of fput() invoking various indirect function calls i.e. ->release(), and depending on the implementation of those, they could be initiating resource release related actions which consequently could result in waiting for some I/O to be done? fput() also calls dput() and mntput() and these too can also do a bunch of teardown. Please correct me if I've misunderstood something. /M
