From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751253AbdEPHOv (ORCPT ); Tue, 16 May 2017 03:14:51 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:46433 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750765AbdEPHOu (ORCPT ); Tue, 16 May 2017 03:14:50 -0400 Date: Tue, 16 May 2017 09:14:42 +0200 From: Peter Zijlstra To: Thomas Gleixner Cc: Steven Rostedt , LKML , Ingo Molnar , Mark Rutland Subject: Re: [patch 17/18] sched: Enable might_sleep() checks early Message-ID: <20170516071442.h3hapwksk2fwgqkb@hirez.programming.kicks-ass.net> References: <20170514182716.347236777@linutronix.de> <20170514183613.836520655@linutronix.de> <20170515111008.1215e489@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 15, 2017 at 09:12:03PM +0200, Thomas Gleixner wrote: > On Mon, 15 May 2017, Steven Rostedt wrote: > > > On Sun, 14 May 2017 20:27:33 +0200 > > Thomas Gleixner wrote: > > > > > might_sleep() checks are enabled after the boot process is done. That hides > > > bugs in the smp bringup and driver initialization code. > > > > > > Enable it right when the scheduler starts working, i.e. when init task and > > > kthreadd have been created and right before the idle task enables > > > preemption. > > > > Looking at commit b433c3d4549ae749, it appears that on very slow > > machines, there is a possibility that the init task can start running. > > Should system_state be updated before that complete() is called? > > That commit is magic voodoo with exactly no effect at all. > > rest_init() is called with preemption disabled and nothing can schedule > there _before_ schedule_preempt_disabled(). > > Both threads - init task and kthreadd - are only created and woken up. They > cannot get on the CPU simply because preemption is disabled. And this was > the case back then in 2.6.35 as well. > > It does not matter at all whether the machine is slow or not. That > completion is pointless. > > Peter, can you explain what the heck this patch is actually doing? Argh.. what a shit Changelog, who wrote that crap!? So the problem was with PREEMPT_VOLUNTARY (where, as you know, preempt_disable() has no meaning). Supposedly there's a might_sleep()/cond_resched() point somewhere around there (every alloc in the fork path for example), which will happily reschedule us. So if we schedule to the kernel_init() task before we set kthreadd_task we'll try and spawn kthreads and OOPS.