Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3272844iog; Mon, 27 Jun 2022 12:41:45 -0700 (PDT) X-Google-Smtp-Source: AGRyM1u+FZgA1xYtM7G0IjGf3BfoTwmXH5N0pdt4BMA5dfm4L3lvNc5M2J8nUlt5ChC0c6LRHanj X-Received: by 2002:a05:6402:238c:b0:435:8eb8:48dd with SMTP id j12-20020a056402238c00b004358eb848ddmr18519377eda.301.1656358905353; Mon, 27 Jun 2022 12:41:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656358905; cv=none; d=google.com; s=arc-20160816; b=aF1o5Vi6q3ppaDHxurgxFX1q5nSKCFTpDAJ8bA9uKiTIJX2zMjjj5rOjJbEsh2aRNX REwGtd52+NK3RI2C4aOFenPWVssbYGi4kTfuLMx1mGqCxwExlY+fSuxNG+IBGFWMuWaM bQYbMx4rxk/kCiv8UF10Y/gItQSd/MCKMkpHcJ3xhySlhD1QUUcGCT+QAoXO9lPs6MTO iIcSGpMDOisDQdGSBMJ5Re5ri9yK3bdwrP/3kbHbSXao1toekfD/KQwkOCsQtoNhquH2 jWLLO90gT6QdWKPEE9CnJwWn5okbfsTtVorjK9d5JZxtkVWXuTK5JTwjFZ3jRP20v4oc dFYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=fEFrep1j3Uu5nF0cbVefR8+inlpQOoCUDjH9kHDkIPc=; b=Dj7iYxUlY6B5UGPq0E0uHjbrgx7rMpG4I5eelc1czBJ0qlcYZ1qAKpE1gf0oKH8oZv 1U3bCOWFhCcXqlHx+l4tXiCtkCzeB4ux19QmKfcaNiE94/aRjW0OwX0IzbnlKzEg1/cn Wao0GLGpcGjA6vBu6+8dXn0MuTGhiDl8X3DQbjLKFM/qdCjE8eZzh5C0jiZtGGN/ltwa +/nKjP4Mta61RdH61A4kiFiSCyl3WB4jltgJykggRsHxNkGhDnIKs6OB2jgm8yruzBhZ evA/X5FlOJ8F6nsbq13iZpvQNJua5c5Lg/0DvvMAytiNvA6JPC0+jdVqIEcqVlm6iGJY SpLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=ZikMXjup; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gt30-20020a1709072d9e00b0071200c979b1si5346229ejc.644.2022.06.27.12.41.19; Mon, 27 Jun 2022 12:41:45 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=ZikMXjup; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238395AbiF0Spa (ORCPT + 99 others); Mon, 27 Jun 2022 14:45:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236776AbiF0Sp3 (ORCPT ); Mon, 27 Jun 2022 14:45:29 -0400 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97738CFB for ; Mon, 27 Jun 2022 11:45:28 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id fd6so14346992edb.5 for ; Mon, 27 Jun 2022 11:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fEFrep1j3Uu5nF0cbVefR8+inlpQOoCUDjH9kHDkIPc=; b=ZikMXjupiG7Bsmscz0RDOlUHVSF6PLfqJ6Bcji/5l4g8u5nSeOiVY8S0WMpp9R7Zqh ZgkgXWUTga3UlSEGWIslHjNJUvALPgYkCdupZmdCAVCHH2Fg7tdyok2RC9xwsteTQnLi mzhZ4h6QbZZrIIyhzU+LwwGlaaS0o8v7I5Dsw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fEFrep1j3Uu5nF0cbVefR8+inlpQOoCUDjH9kHDkIPc=; b=cPxW73N4QEiCJx5FxZKoIiOC1xq91KYxZKzJwPS19uvAfBeZvokVfCqW2R286W8kUw rsSJFSMfZAWhAwvmF9Tl3t3OPnHZLmfFtbzB/7+kHJ5yLo6A+rFufZa0r2A/Uy9CQWlV CEYCdRBrijqaqS5JsbaAarxZtWaZIFcNu5NbMIeDj9G/+qoHyCyvv+V1UHSSGc3oTgMo bLeKUusfqDmrQ0wCl1xdU883nZ1/NNDXYY3aFBTCXqSj9kqhhUqDmDGcQ2Dsr8KXOqjY 8HRhHBVnU9taWfwEgVfBbwgBD8olFIGE/Nw7XPTbQalP1Q3m+fl7l2d4tS0Nt9QIxI/4 pNbQ== X-Gm-Message-State: AJIora8ZEEbM5UjJ6KthaxdLHlFoul064aSfftI2YZYqhVzMh8cxy82W t1Io1NG7aXC0F+ObPG2lTmON7lasJdOu5bBE X-Received: by 2002:aa7:c2cf:0:b0:435:6576:b7c0 with SMTP id m15-20020aa7c2cf000000b004356576b7c0mr18708632edp.18.1656355525893; Mon, 27 Jun 2022 11:45:25 -0700 (PDT) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com. [209.85.221.54]) by smtp.gmail.com with ESMTPSA id jw14-20020a170906e94e00b007263481a43fsm5003407ejb.81.2022.06.27.11.45.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jun 2022 11:45:23 -0700 (PDT) Received: by mail-wr1-f54.google.com with SMTP id i25so8798449wrc.13 for ; Mon, 27 Jun 2022 11:45:22 -0700 (PDT) X-Received: by 2002:a05:6000:1f8d:b0:21b:aaec:ebae with SMTP id bw13-20020a0560001f8d00b0021baaecebaemr14401547wrb.274.1656355521955; Mon, 27 Jun 2022 11:45:21 -0700 (PDT) MIME-Version: 1.0 References: <874k0863x8.fsf@email.froward.int.ebiederm.org> <87pmiw1fy6.fsf@email.froward.int.ebiederm.org> <87y1xkwa28.fsf@email.froward.int.ebiederm.org> In-Reply-To: From: Linus Torvalds Date: Mon, 27 Jun 2022 11:45:05 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: re. Spurious wakeup on a newly created kthread To: Wedson Almeida Filho Cc: Peter Zijlstra , "Eric W. Biederman" , Christian Brauner , Tejun Heo , Petr Mladek , Lai Jiangshan , Michal Hocko , Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , Andrew Morton , Oleg Nesterov Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 27, 2022 at 11:23 AM Wedson Almeida Filho 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