linux-kernel - Re: [PATCH] kthreads: Fix startup synchronization boot crash

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090901145526.GA31317@redhat.com>
Date:	Tue, 1 Sep 2009 16:55:26 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	arjan@...radead.org, jeremy@...p.org, mschmidt@...hat.com,
	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	tj@...nel.org, tglx@...utronix.de,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-tip-commits@...r.kernel.org
Subject: Re: [PATCH] kthreads: Fix startup synchronization boot crash

On 09/01, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@...hat.com> wrote:
>
> > On 09/01, Ingo Molnar wrote:
> > >
> > > * Oleg Nesterov <oleg@...hat.com> wrote:
> > >
> > > > Yes, this should work. But I _think_ we can make the better fix...
> > > >
> > > > I'll try to make the patch soon. Afaics we don't need
> > > > kthreadd_task_init_done.
> > >
> > > ok.
> >
> > Just in case, the patch is ready. [...]
>
> yes - that's roughly the cleanup i referred to in the commit log.
>
> way too late for -rc8 though - the minimal fix i did _might_ be
> eligible.
>
> agreed?

Agreed. Then I will sent the patch on top of this change.

But. May be your minimal patch needs a small tweak ?

rest_init()->complete(&kthreadd_task_init_done) assumes that exactly
_one_ caller of kthread_create() can race with kernel_thread(kthreadd).
Perhap we need complete_all() ?


But I must admit, now I don't understand what happens,

	The modification of that variable is protected by the BKL, but
	the _ordering_ of the initial task (which becomes the idle
	thread of CPU0) and the init task (which is spawned by the
	initial task) is not synchronized.

	So we can occasionally end up init running sooner than
	rest_init()

How? rest_init() can't be preempted and it holds BKL. And kernel_init()
takes BKL before anything else. Confused...

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/