On Mon, 22 Sep 2014 18:44:40 +0200
Oleg Nesterov <o...@redhat.com> wrote:
> __cleanup_sighand() frees sighand without RCU grace period. This is
> correct but this looks "obviously buggy" and constantly confuses the
> readers, add the comments to explain how this works.
Reviewed-by: Steven Rostedt <rost...@goodmis.org>
-- Steve
>
> Signed-off-by: Oleg Nesterov <o...@redhat.com>
> ---
> kernel/fork.c | 5 ++++-
> kernel/signal.c | 12 +++++++++++-
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 1380d8a..2dd9f1d 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1017,11 +1017,14 @@ void __cleanup_sighand(struct sighand_struct *sighand)
> {
> if (atomic_dec_and_test(&sighand->count)) {
> signalfd_cleanup(sighand);
> + /*
> + * sighand_cachep is SLAB_DESTROY_BY_RCU so we can free it
> + * without an RCU grace period, see __lock_task_sighand().
> + */
> kmem_cache_free(sighand_cachep, sighand);
> }
> }
>
> -
> /*
> * Initialize POSIX timer handling for a thread group.
> */
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 61a1f55..9562a4f 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -1272,7 +1272,17 @@ struct sighand_struct *__lock_task_sighand(struct
> task_struct *tsk,
> sighand = rcu_dereference(tsk->sighand);
> if (unlikely(sighand == NULL))
> break;
> -
> + /*
> + * This sighand can be already freed and even reused, but
> + * we rely on SLAB_DESTROY_BY_RCU and sighand_ctor() which
> + * initializes ->siglock: this slab can't go away, it has
> + * the same object type, ->siglock can't be reinitialized.
> + *
> + * We need to ensure that tsk->sighand is still the same
> + * after we take the lock, we can race with de_thread() or
> + * __exit_signal(). In the latter case the next iteration
> + * must see ->sighand == NULL.
> + */
> spin_lock_irqsave(&sighand->siglock, *flags);
> if (likely(sighand == tsk->sighand))
> break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
