Re: [PATCH 3/3] introduce task_rcu_dereference()

2016-05-26 Thread Peter Zijlstra
On Wed, May 18, 2016 at 09:57:33PM +0200, Oleg Nesterov wrote: > Do we really want try_get_task_struct() here? How about the change below? > > To me it would be more clean to do get_task_struct() in task_numa_assign(), > it clearly pairs with put_task_struct(best_task) and task_numa_compare() > lo

Re: [PATCH 3/3] introduce task_rcu_dereference()

2016-05-18 Thread Oleg Nesterov
On 05/18, Peter Zijlstra wrote: > > OK, something like so then? Yes thanks! Just one note, > +struct task_struct *task_rcu_dereference(struct task_struct **ptask) > +{ > + struct sighand_struct *sighand; > + struct task_struct *task; > + > + /* > + * We need to verify that relea

Re: [PATCH 3/3] introduce task_rcu_dereference()

2016-05-18 Thread Peter Zijlstra
On Wed, May 18, 2016 at 08:23:18PM +0200, Oleg Nesterov wrote: > IOW. We can never know if we have a garbage in "sighand" or the real value, > this task_struct can be freed/reallocated when we do probe_slab_address(). > > And this is fine. We re-check that "task == *ptask" after that. Now we have

Re: [PATCH 3/3] introduce task_rcu_dereference()

2016-05-18 Thread Oleg Nesterov
On 05/18, Peter Zijlstra wrote: > > So I keep coming back to this, and every time I look at it my brain > explodes. Heh ;) I forgot about this completely. > On Mon, Oct 27, 2014 at 08:54:46PM +0100, Oleg Nesterov wrote: > > +struct task_struct *task_rcu_dereference(struct task_struct **ptask) > >

Re: [PATCH 3/3] introduce task_rcu_dereference()

2016-05-18 Thread Peter Zijlstra
So I keep coming back to this, and every time I look at it my brain explodes. On Mon, Oct 27, 2014 at 08:54:46PM +0100, Oleg Nesterov wrote: > +struct task_struct *task_rcu_dereference(struct task_struct **ptask) > +{ > + struct task_struct *task; > + struct sighand_struct *sighand; I th

Re: [PATCH 3/3] introduce task_rcu_dereference()

2014-10-27 Thread Kirill Tkhai
В Пн, 27/10/2014 в 20:54 +0100, Oleg Nesterov пишет: > task_struct is only protected by RCU if it was found on a RCU protected > list (say, for_each_process() or find_task_by_vpid()). > > And as Kirill pointed out rq->curr isn't protected by RCU, the scheduler > drops the (potentially) last refere