[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YrrPKU2y4liY91u9@alley>
Date: Tue, 28 Jun 2022 11:51:37 +0200
From: Petr Mladek <pmladek@...e.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>,
Michal Hocko <mhocko@...e.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: re. Spurious wakeup on a newly created kthread
On Sat 2022-06-25 10:01:35, Linus Torvalds wrote:
> On Fri, Jun 24, 2022 at 10:00 PM Tejun Heo <tj@...nel.org> wrote:
> For example, the reason that quoted patch cannot be right is that this
> code pattern:
>
> while (wait_for_completion_interruptible(&worker->ready_to_start))
> ;
>
> is not valid kernel code. EVER. There is absolutely no way that can be correct.
>
> Either that code can take a signal, or it cannot. If it can take a
> signal, it had better react to said signal. If it cannot, it must not
> use an interruptble sleep - since now that loop turned into a
> kernel-side busy-loop.
I agree that the code is ugly and does not make sense.
JFYI, I did it this way because I wanted to calm down the hung task
detector. kthreads ignore signals so that I did not think about
this aspect. I though that I saw this trick somewhere.
Do not ask me why I wanted to calm down the hung task detector.
I quess that I felt overloaded and wished a calm day
or something like this. I agree that it does not make
much sense.
Best Regards,
Petr
Powered by blists - more mailing lists