Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2385490iog; Sun, 26 Jun 2022 14:34:26 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uaTLbiZSXImU1GNyYE3dXCsx8VwuHjBLNFs+5gncN7tiIsK339UFNjIdw4SdVnOOudTho/ X-Received: by 2002:a05:6a00:1701:b0:525:9f20:a78a with SMTP id h1-20020a056a00170100b005259f20a78amr6656299pfc.2.1656279266288; Sun, 26 Jun 2022 14:34:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656279266; cv=none; d=google.com; s=arc-20160816; b=RerrpDtQAo2GteZiJJ7LxKLmEnIaCi5wkzSivkeS956CQZRH4D8fkCBlPoQP7BNbiY 6xWxZOiEyf245mVqEySwbu6xviX6tV5vTCoNTUmKwhnAe/EgzGyDjVmYwhJTzLJ03rnL qsX22R4GS+p9OMUhmT0OCCOcBBRfKqyj3ramecHmm5VmsaOAFsd9OAD+p+DNfQzkISsY vXVPmcos1LiEN8R9mpFXBBjjO6x2p442GsApYTGU3YQPqq3Sn2Raj4M5/mn7EpbETzyD tHwoT1CEaR2IDVSPHJ8HB0ZG7uYvjFDdfbzZ+2uLNXabf0yl//QBMCfMkWhNviOlBvrc VUjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=4OJRktS48/0rG6k8YY0xWCcBZOBBbOWsnd9nXtcIDLg=; b=HKWhEAHl8obxyS07COiSAjL6KOkPNaWYZ3qbc3DRot3OE70u8khsJKy4SOFpcjw61m aGC2d/lARuD5swF8rDZ/KIs27XT9bNg08MAerlYQMK4uIlDKZyx2U6qgphcr0K8Gysv0 mf9unFVX/kKNm7OL3a9lrVa6eMS+v/KfkTyPWDYAvN7ISNg87JlPVE/p5r6MebQ1Ng+y lPCShQO4tqE/swo4nHzq9cwgpM7AN4DbZNh0qK9vVyog18VIY6MwiBbYtBVj4RkVC+CI vs5WbKSVwc5GtsJKY0NbFD6JO65K4DahpWuntpiQ4cPFOf2vn7cFd76/YMaDGP2MPJ/e HoFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=dTD3qSwZ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l184-20020a6388c1000000b0040cfc09baa7si11692121pgd.749.2022.06.26.14.34.12; Sun, 26 Jun 2022 14:34:26 -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=@gmail.com header.s=20210112 header.b=dTD3qSwZ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232011AbiFZUXG (ORCPT + 99 others); Sun, 26 Jun 2022 16:23:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229955AbiFZUXF (ORCPT ); Sun, 26 Jun 2022 16:23:05 -0400 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B574C7C for ; Sun, 26 Jun 2022 13:23:04 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id 184so7229242pga.12 for ; Sun, 26 Jun 2022 13:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4OJRktS48/0rG6k8YY0xWCcBZOBBbOWsnd9nXtcIDLg=; b=dTD3qSwZT/PIgwqCXoipscq+hWjyB3oEWYlyXWq9ZELHGY51nxszHF4JK7BKYQFULY nPsx4fHosoN1DsxHVNNu6YUMPl6ozH7lnIrSZKMrxg0Zg6PaZUiyDNVkUz9zIMj6aw7P rXko6rodGjPg2okTLby2WBUR8weA+Lftwt7J54vOC/fSw8ltTGhhw5pDRzKXXJlgp9/S 1IEVMhYQ0XTjj2N9sucryPdqK/9Oss9IcU2I5w5NxZMORUX94R4v/VH51lJIs43y9gry jhplQJOOieSVyMYjyQHS4QHHorZhWa6hISGn4fcfrQq7q6UpHWJ5hjgx9Zz5AEjZEWvm TlWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=4OJRktS48/0rG6k8YY0xWCcBZOBBbOWsnd9nXtcIDLg=; b=dBCEgpdbXbx/FKiV+EMHAyiPhygxU4KUUaa/icDnnFmmTfF2Zeua1ldAoFrkld7Zx8 u87YNiovuEANohfxF4Mr4K8KZlJVQK/nuHKO7th2/hx3V3l0wlgQxuGHlrjTkOtfQ4kp ziI2KtKDyW9gXmvyaDxzJiDpka9yUhUt0uY9kVdtrE1+gLlmYHipShtfR0DkVdH6THDM 8ctCECIn7YN1dq9SSPrgzRMFKICHUmGTqtaXgqPD8j6b2UN3ZzGEjv4UN5l5P4/+N056 GuLraVci0eOKjEOjvaPQr57uxhJgH5rwG/Xoo+ly55Khnm4aPE0IMn7Fqz/fCoq4DFNb RK3A== X-Gm-Message-State: AJIora9E9Wi/OImb7hO5CuvLSbF+AwuDk78jPpuvJ5b5YW39Ux9br2iZ /Cr1BHXYOwmW33ixI1Z+gLg= X-Received: by 2002:a63:2055:0:b0:404:3941:e05e with SMTP id r21-20020a632055000000b004043941e05emr9590553pgm.66.1656274983991; Sun, 26 Jun 2022 13:23:03 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:1820]) by smtp.gmail.com with ESMTPSA id a8-20020a656048000000b003db7de758besm5608676pgp.5.2022.06.26.13.23.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Jun 2022 13:23:03 -0700 (PDT) Sender: Tejun Heo Date: Mon, 27 Jun 2022 05:23:00 +0900 From: Tejun Heo To: Linus Torvalds Cc: "Eric W. Biederman" , Christian Brauner , Petr Mladek , Lai Jiangshan , Michal Hocko , Linux Kernel Mailing List , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Andrew Morton , Oleg Nesterov Subject: Re: [PATCH 3/3] kthread: Stop abusing TASK_UNINTERRUPTIBLE (INCOMPLETE) Message-ID: References: <874k0863x8.fsf@email.froward.int.ebiederm.org> <87pmiw1fy6.fsf@email.froward.int.ebiederm.org> <87ilonuti2.fsf_-_@email.froward.int.ebiederm.org> <871qvbutex.fsf_-_@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 Hello, On Sun, Jun 26, 2022 at 12:59:09PM -0700, Linus Torvalds wrote: > And I think *that* should be the change - add a "setup()" function > pointer to the whole kthread infrastructure. Allow it to return an > error, which will then just kill the new thread again without ever > even starting it up. > > I'd really prefer to avoid having random drivers and subsystems know > about the *very* magical "wake_up_new_task()" thing. Yes, it's a real > thing, but it's a thing that normal code should not ever use. > > The whole "wake_up_process()" model for kthread creation was wrong. > But moving existing users of a bad interface to using the even more > special "wake_up_new_task()" thing is not the solution, I feel. This is a bit of bike-shedding but there are inherent downsides to callback based interface in terms of write/readability. Now you have to move the init code out of line, and if the context that needs to be passing doesn't fit in a single pointer, you gotta define a struct to carry it adding to the boilerplate. Having separate create and run steps makes sense as a pattern and wake_up_new_task() is less error prone in one sense - if the caller doesn't call it, the new kthread actually won't start running making the bug obvious. The fact that the function blindly trusts the caller to be handing in an actual new task is scary and we likely don't wanna proliferate its use across the code base. Would it be a reasonable tradeoff to have a kthread wrapper - kthread_start() or whatever - which ensures that it is actually called once on a new task? That way, we can keep the init code inline and bugs on both sides (not starting and starting incorrectly) are obvious. Thanks. -- tejun