Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1642262

Re: [patch 17/18] sched: Enable might_sleep() checks early

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [patch 17/18] sched: Enable might_sleep() checks early
Date 2017-05-16 09:20 +0200
Message-ID <tHEVX-2xx-9@gated-at.bofh.it> (permalink)
References <tH6AV-56V-3@gated-at.bofh.it> <tH6AW-56V-11@gated-at.bofh.it> <tHpWV-1pB-3@gated-at.bofh.it> <tHtHc-3KQ-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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 <tglx@linutronix.de> 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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[patch 17/18] sched: Enable might_sleep() checks early Thomas Gleixner <tglx@linutronix.de> - 2017-05-14 20:40 +0200
  Re: [patch 17/18] sched: Enable might_sleep() checks early Steven Rostedt <rostedt@goodmis.org> - 2017-05-15 17:20 +0200
    Re: [patch 17/18] sched: Enable might_sleep() checks early Thomas Gleixner <tglx@linutronix.de> - 2017-05-15 21:20 +0200
      Re: [patch 17/18] sched: Enable might_sleep() checks early Peter Zijlstra <peterz@infradead.org> - 2017-05-16 09:20 +0200
        Re: [patch 17/18] sched: Enable might_sleep() checks early Thomas Gleixner <tglx@linutronix.de> - 2017-05-16 09:40 +0200
          Re: [patch 17/18] sched: Enable might_sleep() checks early Steven Rostedt <rostedt@goodmis.org> - 2017-05-16 15:20 +0200

csiph-web