Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 27 Jun 2022 18:23:25 +0000
From:   Wedson Almeida Filho <wedsonaf@google.com>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     "Eric W. Biederman" <ebiederm@xmission.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Christian Brauner <brauner@kernel.org>,
        Tejun Heo <tj@kernel.org>, Petr Mladek <pmladek@suse.com>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        Michal Hocko <mhocko@suse.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>
Subject: Re: re. Spurious wakeup on a newly created kthread
Message-ID: <Yrn1nQU3h+vHK1nz@google.com>
References: <CAHk-=wiC7rj1o7vTnYUPfD7YxAu09MZiZbahHqvLm9+Cgg1dFw@mail.gmail.com>
 <874k0863x8.fsf@email.froward.int.ebiederm.org>
 <CAHk-=wgTG2K3erROP19320zBN6BHVf0hRfXGdawkGR4gzrJN6w@mail.gmail.com>
 <CAHk-=whLsaRKaFKS0UffeCYYCVyP0bbiB4BTYTaXtScgu6R9yA@mail.gmail.com>
 <87pmiw1fy6.fsf@email.froward.int.ebiederm.org>
 <CAHk-=wiutNT47oNhyk_WvMj2qp4pehYFptXCUzW=u_2STLQiww@mail.gmail.com>
 <CAHk-=whX_=BNZ4kVEAu2NV3CMnhwsuYTyE65FQXUMx8VPNOAOA@mail.gmail.com>
 <87y1xkwa28.fsf@email.froward.int.ebiederm.org>
 <YrjxcR2M6AD6S9dW@google.com>
 <YrlYDppYKw6HRP1j@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YrlYDppYKw6HRP1j@hirez.programming.kicks-ass.net>
Precedence: bulk

On Mon, Jun 27, 2022 at 09:11:10AM +0200, Peter Zijlstra wrote:
> Current freezer can thaw at random points in time, even before SMP
> bringup if you're unlucky. And yes, I think it can induce 'spurious'
> wakeups as well.

Thanks, Peter, that's good to know!

> But really; like Linus already said upsteam, every wait loop *MUST*
> already be able to deal with spurious wakeups. This is why pretty much
> every wait primitive we have looks like:
> 
> 	for (;;) {
> 		set_current_state(state);
> 		if (cond)
> 			break;
> 		schedule();
> 	}
> 	__set_current_state(RUNNING);
> 
> Which is immune to random wake-ups since it need @cond to make progress.
> *NEVER* rely on just the wakeup itself for progress, that's buggy as
> heck in lots of ways.

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.