Received: by 10.192.165.148 with SMTP id m20csp3660687imm; Mon, 30 Apr 2018 04:19:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqDUwNbl8qWYf3x+ghC7IW8b2jQrSwmrg8r43Xu57VICDnqum8hZsc9zam7uG9U+Xf1Fq6Q X-Received: by 10.98.88.65 with SMTP id m62mr3371022pfb.116.1525087169407; Mon, 30 Apr 2018 04:19:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525087169; cv=none; d=google.com; s=arc-20160816; b=EAli/3gUkRwJBaFNioz5I0yMUZMBs/VyabjN27VYk39MUB/Yuzn9Effm7j2FzE4wjU nwCSc8Ss+xOjIqqH3SZ0pBK+ZNaxQ+kQrueoBr9RhlpgnLKdXOyU/AEQ/UY3B5rOUY+7 lDxPV9806e/7P0BzcVuccMwF3jhnXzdw3X1e3khM+/h57o3iAF1gP9NWpCHOIGAIHMAG j8sA+dBJKt2Xh4upxf0hUqXfll4jp4OIdZ642FYy2Hy+/Q/Mwdr52bqb0qRNz27VD2E9 ML25JfPNErocWMdKgMhcFy4ydgM3Kh3Rnf+3v2mCJQEKTZRG4s9p0GDw89fr8iHAiyVA F/cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=uReN/mCP1IwYJHy+ZdhMnm4sBC1aSuDDEQTLgvNDmtQ=; b=SJapqpcxP+WXYHzoIhPMfTkSlH1bDjM286OaDGft4f54nrlPXBTQ3bRx+DFfhDoZTf T8GfBZFWaAOmqoqMzNQTxOteF4rVNGu9mWmMLUYzZlYtcMAw2T7SGsTV2E6AtTQ9nLk0 8mmje6gqTv5pngY1ct3t72L6NmvcJKy3k/p7b7kSAlflUBK62GnlezyEX/ja8oghfJiV YiqOikt8NiPgggtImLWL265ObDazDlOiT2kAFpqlFRsUo0E8ZMgISM6PdMLmC/GpOTQW LvH3Ckq4Huck0WRr9PdF3/6edSR5969p7XuAK80zESFe6OhHD/qvOaC2HUsnG6EBIBR/ OZsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=Q6qWikxy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 92-v6si7069838plw.299.2018.04.30.04.19.15; Mon, 30 Apr 2018 04:19:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=Q6qWikxy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752430AbeD3LRz (ORCPT + 99 others); Mon, 30 Apr 2018 07:17:55 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:33280 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751606AbeD3LRx (ORCPT ); Mon, 30 Apr 2018 07:17:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uReN/mCP1IwYJHy+ZdhMnm4sBC1aSuDDEQTLgvNDmtQ=; b=Q6qWikxyqR3y/PyGhC9mTw9npI XLhMKNvdLYaZMLIcVjicsBZzBQIPm6d8LfFHXF+p4Y1/2fzJ0GTQr4Rem/WlR1A38TZqehPQak9GF YeB2dtuVu5aClEADm4L9y9JKHr/uAde0ofGQDG1Xh61225h0PiqUOAXX7mBC9v3RqX6kdMPw9AuP2 3Cet5ESUYjKmjJ4IZXTCAVBAKt2jqZpmRyQCgpAn9qrwgifLUgAw8D5BywCgXzysMX8cSjMwTt2WW zUQsn2hf2fVsXZLAm7lq57DguN/g+bjB749IgjGEeULiokCiAFgUghHqfUqB60AJVRXHD7KPZk4M3 8fKbXqZg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fD6oV-00053T-Gt; Mon, 30 Apr 2018 11:17:47 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id A5EED2029FD46; Mon, 30 Apr 2018 13:17:44 +0200 (CEST) Date: Mon, 30 Apr 2018 13:17:44 +0200 From: Peter Zijlstra To: "Kohli, Gaurav" Cc: tglx@linutronix.de, mpe@ellerman.id.au, mingo@kernel.org, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Neeraj Upadhyay , Will Deacon , Oleg Nesterov Subject: Re: [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup Message-ID: <20180430111744.GE4082@hirez.programming.kicks-ass.net> References: <1524645199-5596-1-git-send-email-gkohli@codeaurora.org> <20180425200917.GZ4082@hirez.programming.kicks-ass.net> <20180426084131.GV4129@hirez.programming.kicks-ass.net> <20180426085719.GW4129@hirez.programming.kicks-ass.net> <4d3f68f8-e599-6b27-a2e8-9e96b401d57a@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4d3f68f8-e599-6b27-a2e8-9e96b401d57a@codeaurora.org> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 26, 2018 at 09:23:25PM +0530, Kohli, Gaurav wrote: > On 4/26/2018 2:27 PM, Peter Zijlstra wrote: > > > On Thu, Apr 26, 2018 at 10:41:31AM +0200, Peter Zijlstra wrote: > > > diff --git a/kernel/kthread.c b/kernel/kthread.c > > > index cd50e99202b0..4b6503c6a029 100644 > > > --- a/kernel/kthread.c > > > +++ b/kernel/kthread.c > > > @@ -177,12 +177,13 @@ void *kthread_probe_data(struct task_struct *task) > > > static void __kthread_parkme(struct kthread *self) > > > { > > > - __set_current_state(TASK_PARKED); > > > - while (test_bit(KTHREAD_SHOULD_PARK, &self->flags)) { > > > + for (;;) { > > > + __set_task_state(TASK_PARKED); > > set_current_state(TASK_PARKED); > > > > of course.. > > Hi Peter, > > Maybe i am missing something , but still that race can come as we don't put task_parked on special state. > > Controller ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Hotplug > > ???? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? Loop > > ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ?Task_Interruptible > > Set SHOULD_PARK > > wakeup -> Proceeds > > ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ? Set Running > > ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ? kthread_parkme > > ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ? SET TASK_PARKED > > ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ? schedule > > Set TASK_RUNNING > > Can you please correct ME, if I misunderstood this. If that could happen, all wait-loops would be broken. However, AFAICT that cannot happen, because ttwu_remote() and schedule() serialize on rq->lock. See: A B for (;;) { set_current_state(UNINTERRUPTIBLE); cond1 = true; wake_up_process(A) lock(A->pi_lock) smp_mb__after_spinlock() if (A->state & TASK_NORMAL) A->on_rq && ttwu_remote() if (cond1) // true break; schedule(); } __set_current_state(RUNNING); for (;;) { set_current_state(UNINTERRUPTIBLE); if (cond2) break; schedule(); lock(rq->lock) smp_mb__after_spinlock(); deactivate_task(A); unlock(rq->lock); rq = __task_rq_lock(A) if (A->on_rq) // false A->state = TASK_RUNNING; __task_rq_unlock(rq) Either A's schedule() must observe RUNNING (not shown) or B must observe !A->on_rq (shown) and not issue the store.