From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753407AbdCPO6L (ORCPT <rfc822;w@1wt.eu>);
        Thu, 16 Mar 2017 10:58:11 -0400
Received: from mx1.redhat.com ([209.132.183.28]:38342 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753165AbdCPO5x (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 16 Mar 2017 10:57:53 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 48E713D962
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=oleg@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 48E713D962
Date: Thu, 16 Mar 2017 15:54:36 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>, Chris Mason <clm@fb.com>,
        linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 1/2] kthread: add barriers to set_kthread_struct() and
        to_kthread()
Message-ID: <20170316145436.GA24478@redhat.com>
References: <20170315231827.GA13656@htj.duckdns.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170315231827.GA13656@htj.duckdns.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 16 Mar 2017 14:56:34 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Tejun,

On 03/15, Tejun Heo wrote:
>
> Until now, all to_kthread() users are interlocked with kthread
> creation and there's no need to have explicit barriers when setting
> the kthread pointer or dereferencing it.
>
> However, There is a race condition where userland can interfere with a
> kthread while it's being initialized.  To close it, to_kthread() needs
> to be used from an unsynchronized context.

So this is preparation for 2/2... IIUC, the current code is not buggy,
just you need to add kthread_initialized() which can't work without
this change.

>  static inline void set_kthread_struct(void *kthread)
>  {
> +	/* paired with smp_read_data_barrier_depends() in to_kthread() */
> +	smp_wmb();
> +
>  	/*
>  	 * We abuse ->set_child_tid to avoid the new member and because it
>  	 * can't be wrongly copied by copy_process(). We also rely on fact
> @@ -67,8 +70,19 @@ static inline void set_kthread_struct(vo
>
>  static inline struct kthread *to_kthread(struct task_struct *k)
>  {
> +	void *ptr;
> +
>  	WARN_ON(!(k->flags & PF_KTHREAD));
> -	return (__force void *)k->set_child_tid;
> +
> +	ptr = (__force void *)k->set_child_tid;
> +
> +	/*
> +	 * Paired with smp_wmb() in set_kthread_struct() and ensures that
> +	 * the caller sees initialized content of the returned kthread.
> +	 */
> +	smp_read_barrier_depends();
> +
> +	return ptr;

This is almost off-topic, but I think lockless_dereference() will look
better in to_kthread().

And perhaps we should add another helper, say,

	#define lockless_assign_pointer(ptr, val)	\
		smp_store_release(&ptr, val)

for set_kthread_struct() ? it can have more users.

Not that I think you should change your patch, I am just asking.

Oleg.