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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ