[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141022222330.GA28423@redhat.com>
Date: Thu, 23 Oct 2014 00:23:30 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Kirill Tkhai <ktkhai@...allels.com>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Vladimir Davydov <vdavydov@...allels.com>,
Kirill Tkhai <tkhai@...dex.ru>
Subject: Re: introduce task_rcu_dereference?
Damn.
On 10/22, Oleg Nesterov wrote:
>
> +struct task_struct *task_rcu_dereference(struct task_struct **ptask)
> +{
> + struct task_struct *task;
> + struct sighand_struct *sighand;
> +
> + task = rcu_dereference(*ptask);
> + if (!task)
> + return NULL;
> +
> + /* If it fails the check below must fail too */
> + probe_slab_address(&task->sighand, sighand);
> + /*
> + * Pairs with atomic_dec_and_test() in put_task_struct(task).
> + * If we have read the freed/reused memory, we must see that
> + * the pointer was updated. The caller might want to retry in
> + * this case.
> + */
> + smp_rmb();
> + if (unlikely(task != ACCESS_ONCE(*ptask)))
> + return ERR_PTR(-EAGAIN);
This is not exactly right. task == *ptask can be false positive.
It can be freed, then resused (so that sighand != NULL can be false
positive), then freed again, and then reused again as task_struct.
This is not that bad, we still can safely use this task_struct, but
the comment should be updated. Plus -EINVAL below can be wrong in
this case although this minor.
Yeees, SLAB_DESTTROY_BY_RCU closes this race. Not sure why I'd like
to avoid it, but I do ;)
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists