From: Waiman Long <waiman.long@hpe.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>, "Theodore Ts'o" <tytso@mit.edu>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Scott J Norton <scott.norton@hpe.com>,
Douglas Hatch <doug.hatch@hpe.com>
Subject: Re: [PATCH] random: Fix kernel panic due to system_wq use before init
Date: Wed, 14 Sep 2016 15:24:48 -0400 [thread overview]
Message-ID: <57D9A400.2010501@hpe.com> (raw)
In-Reply-To: <CA+55aFx0vPuMuxn00rBSM192n-Du5uxy+4AvKa0SBSOVJeuCGg@mail.gmail.com>
On 09/14/2016 03:14 PM, Linus Torvalds wrote:
> Ugh, I detest this patch.
>
> My gut feeling is that a driver (even a fairly core one like the
> random code) should not have to know these kinds of details like
> "schedule_work() needs system_wq to have been initialized".
>
> I'm wondering if we couldn't just initialize "system_wq" earlier.
> Right now init_workqueues() is an "early_initcall()", so it's at the
> same priority as a number of other random early initcalls. My gut
> feeling is that it should be initialized even earlier, with the
> scheduler.
>
> Because dammit, we use "schedule_work()" as if it was a pretty core
> scheduler thing, and having to have some odd knowledge of system_wq
> initialization details in the rest of the kernel sounds really really
> wrong.
>
> I don't think the random code is at all special in maybe wanting to
> schedule some work despite being an "early" initcall.
>
> Adding Tejun to the cc, and quoting the whole email.
>
> Tejun, comments?
>
> Linus
>
>
My patch does not really fix the boot problem as detailed in my
follow-up email. It serves mostly to jump start the discussion on the
problem that I saw. The schedule_work() call was issued as part of
interrupt handling that seems to be started pretty early in the boot
process before the early_initcall. I guess it is possible to move the
initialization earlier, but I am not sure where will be a good place.
Cheers,
Longman
next prev parent reply other threads:[~2016-09-14 19:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 19:03 [PATCH] random: Fix kernel panic due to system_wq use before init Waiman Long
2016-09-14 19:14 ` Linus Torvalds
2016-09-14 19:24 ` Waiman Long [this message]
2016-09-14 19:55 ` Tejun Heo
2016-09-14 22:26 ` Tejun Heo
2016-09-14 19:14 ` Waiman Long
2016-09-14 19:19 ` Linus Torvalds
2016-09-14 19:34 ` Waiman Long
2016-09-14 21:06 ` Linus Torvalds
2016-09-14 22:15 ` Waiman Long
2016-09-19 3:09 ` Waiman Long
2016-09-19 9:25 ` Matt Fleming
2016-09-19 12:43 ` Matt Fleming
2016-09-19 14:48 ` Waiman Long
2016-09-19 14:51 ` Matt Fleming
2016-09-19 17:09 ` Waiman Long
2016-09-20 14:04 ` Matt Fleming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57D9A400.2010501@hpe.com \
--to=waiman.long@hpe.com \
--cc=arnd@arndb.de \
--cc=doug.hatch@hpe.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=scott.norton@hpe.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.