On Wed, Sep 30, 2020 at 5:01 PM Jann Horn <ja...@google.com> wrote: > Hmm, this won't work, because the task could be exiting, and seccomp > filters are detached in release_task() (using > seccomp_filter_release()). And at the moment, seccomp_filter_release() > just locklessly NULLs out the tsk->seccomp.filter pointer and drops > the reference. > > The locking here is kind of gross, but basically I think you can > change this code to use lock_task_sighand() / unlock_task_sighand() > (see the other examples in fs/proc/base.c), and bail out if > lock_task_sighand() returns NULL. And in seccomp_filter_release(), add > something like this: > > /* We are effectively holding the siglock by not having any sighand. */ > WARN_ON(tsk->sighand != NULL);
Ah thanks. I was thinking about how tasks exit and get freed and that sort of stuff, and how this would race against them. The last time I worked with procfs there was some magic going on that I could not figure out, so I was thinking if some magic will stop the task_struct from being released, considering it's an argument here. I just looked at release_task and related functions; looks like it will, at the end, decrease the reference count of the task_struct. Does procfs increase the refcount while calling the procfs functions? Hence, in procfs functions one can rely on the task_struct still being a task_struct, but any direct effects of release_task may happen while the procfs functions are running? YiFei Zhu
