[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjHto1Uvb7HY7J003-=7BuJ-8AhEuLco30S8tdqLQTDUw@mail.gmail.com>
Date: Mon, 27 Jun 2022 11:45:05 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Wedson Almeida Filho <wedsonaf@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Christian Brauner <brauner@...nel.org>,
Tejun Heo <tj@...nel.org>, Petr Mladek <pmladek@...e.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Michal Hocko <mhocko@...e.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: re. Spurious wakeup on a newly created kthread
On Mon, Jun 27, 2022 at 11:23 AM Wedson Almeida Filho
<wedsonaf@...gle.com> wrote:
>
> Yes, I wonder how many more instances of this kind of bug we have
> lurking around given that this one in core kernel code appears to have
> been around for at least 17 years.
The good news is that this "explicit wait loop" pattern is actually
starting to be pretty rare.
New code seldom uses it, because "wait_event()" and friends are just
*so* much easier to use, and will magically expand to that kind of
loop properly.
So the explicit loop with add_wait_queue and friends is very
traditional and our original wait model (well, I think I did have
"sleep_on()" *very* early, but I fixed that broken model quickly since
it fundamentally doesn't work for multiple events), but it's not
actually very common any more.
And the "just call schedule, wait for wakeup" should be very rare
indeed. It has never been a valid pattern, so that kthread code is
just plain strange, and I wouldn't expect to see it commonly
elsewhere. It's simply not how things have ever been supposed to be
done.
Linus
Powered by blists - more mailing lists