From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755810AbcAITZ3 (ORCPT ); Sat, 9 Jan 2016 14:25:29 -0500 Received: from mx2.suse.de ([195.135.220.15]:42124 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754236AbcAITZ1 (ORCPT ); Sat, 9 Jan 2016 14:25:27 -0500 Date: Sat, 9 Jan 2016 11:25:17 -0800 From: Davidlohr Bueso To: Thomas Gleixner Cc: bigeasy@linutronix.de, peterz@infradead.org, linux-kernel@vger.kernel.org, dbueso@suse.de, rostedt@goodmis.org, mingo@kernel.org, hpa@zytor.com, torvalds@linux-foundation.org, linux-tip-commits@vger.kernel.org, stable@vger.kernel.org Subject: Re: [tip:sched/core] sched/core: Reset task' s lockless wake-queues on fork() Message-ID: <20160109192517.GA6139@linux-uzut.site> References: <20151221171710.GA5499@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 08 Jan 2016, Thomas Gleixner wrote: >On Wed, 6 Jan 2016, tip-bot for Sebastian Andrzej Siewior wrote: > >> Commit-ID: 093e5840ae76f1082633503964d035f40ed0216d >> Gitweb: http://git.kernel.org/tip/093e5840ae76f1082633503964d035f40ed0216d >> Author: Sebastian Andrzej Siewior >> AuthorDate: Mon, 21 Dec 2015 18:17:10 +0100 >> Committer: Ingo Molnar >> CommitDate: Wed, 6 Jan 2016 11:01:07 +0100 >> >> sched/core: Reset task's lockless wake-queues on fork() >> >> In the following commit: >> >> 7675104990ed ("sched: Implement lockless wake-queues") >> >> we gained lockless wake-queues. >> >> The -RT kernel managed to lockup itself with those. There could be multiple >> attempts for task X to enqueue it for a wakeup _even_ if task X is already >> running. >> >> The reason is that task X could be runnable but not yet on CPU. The the >> task performing the wakeup did not leave the CPU it could performe >> multiple wakeups. >> >> With the proper timming task X could be running and enqueued for a >> wakeup. If this happens while X is performing a fork() then its its >> child will have a !NULL `wake_q` member copied. >> >> This is not a problem as long as the child task does not participate in >> lockless wakeups :) It also makes sense in that a new task has no business inherinting whatever pending wakeups the parent is involved in. It should get a fresh wake_q. >> >> Signed-off-by: Sebastian Andrzej Siewior >> Signed-off-by: Peter Zijlstra (Intel) >> Cc: Davidlohr Bueso >> Cc: Linus Torvalds >> Cc: Peter Zijlstra >> Cc: Steven Rostedt >> Cc: Thomas Gleixner >> Fixes: 7675104990ed ("sched: Implement lockless wake-queues") > >Shouldn't that go into stable? Yes, as of v4.2 afaict. Ccing. Thanks, Davidlohr