Messages in this thread | | | Date | Sun, 8 Feb 2015 19:12:08 +0100 | From | Oleg Nesterov <> | Subject | Re: [RFC PATCH 3/8] kmod - teach call_usermodehelper() to use a namespace |
| |
On 02/08, Ian Kent wrote: > > On Fri, 2015-02-06 at 07:08 -0500, Jeff Layton wrote: > > On Thu, 05 Feb 2015 10:34:11 +0800 > > Ian Kent <ikent@redhat.com> wrote: > > > > > +{ > > > + struct task_struct *tsk; > > > + > > > + rcu_read_lock(); > > > + tsk = find_task_by_vpid(1); > > > + if (tsk) > > > + get_task_struct(tsk); > > > + rcu_read_unlock(); > > > > I'm not terribly familiar with the task_struct lifetime rules... > > > > I assume that you can be assured that tsk won't go away while you hold > > the rcu_read_lock, but is doing a get_task_struct while holding it > > sufficient to pin it after you drop the lock? > > > > IOW, could the refcount on the task_struct do a 0->1 transition here and > > end up being freed anyway after you've grabbed a reference? > > Good point, I thought getting a reference under he read lock would be > enough but maybe I need more checks as I do with dentrys. I'll check > that.
This is fine. If find_task_by_vpid() succeeds then delayed_put_task_struct() can't be called until rcu_read_unlock() at least, so this task_struct has a reference.
But I can't understand why do you need this helper... I guess I need to read the whole series first. find_task_by_vpid(1) can never fail, but it can be zombie... At seems we only need this task_struct for task_pid_nr(tsk) in umh_enter_ns(tsk) ? Confused, but please ignore.
Oleg.
| |