Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp957702pxp; Wed, 16 Mar 2022 22:37:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz28H2RQTBqNWyWk3vC6vXVLY/NkxLlcZf6QPUSe3MF31pTOsttMQrTiXIGYz2IZiW79r0e X-Received: by 2002:a63:1065:0:b0:376:30d7:781c with SMTP id 37-20020a631065000000b0037630d7781cmr2427477pgq.35.1647495453240; Wed, 16 Mar 2022 22:37:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647495453; cv=none; d=google.com; s=arc-20160816; b=MYK2p3yioOeherRkjz8FCzAyipzaVygcHUh7M6xtp1Bzj3/XVh037OnLrcoiFvYj+e rOvDMPIIkijjks18zrqWP1ogamCdvlbP61mbjg0rmHqJTWIRViP4EfS2sXJFsC72zfKd 9BCvHxig2j/0CT287UmjH0UP64iCxM+kNyHaycTikvFBbSNAkALiGRxQ4nyzpDwhpk+T ch0XxnJU4HfDyTwajDO1x7x5zwI4TLsOlrUxOYWOl66/s8couqHZmj5b7aou8Dntcw3q VKzpk1+e3X8AHiQJt9VVjcO8BeRsGx/NED/oKr4UWbMMsljoNhb7UdG8iTo7L3xdtFIX VEXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=9bIfkplOutFYaWeLdLUALKRF5qrlW7wQAPZL71jBcPM=; b=fsBca9CJ9XuI7LlRMkyyuTPT3U03TXOP+DUNviioq0CN7P/X803dU9iKv1ya/2eI+/ oT0feRr+xH94N1xOWGzAuOThBGqnK7Vp+4HwvUnQ0nMA6fj0TX4laSs3pixvy4N7/JV/ O2nhqXbdZO2h3cNPGQEdyT1pY0VCEZf1mvGP8O62xyFn0IRM/alVT2knYPleOL3407+t Y9e5JL7Fd6WdoPbXeO0wKMOmV6Y6xEzV/PQdMsXla5BZ0YZulHDxPKQZBdUtj4YSyoyR 48WWtRzEIDo71OfkDtkflxnMT+wLU++zqGozGX2FnzAjhysr1rs0WmyI4BE1aDLRIr16 WQWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=F0c0KaG6; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id x37-20020a056a0018a500b004fa0a7a00a5si4138810pfh.346.2022.03.16.22.37.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 22:37:33 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=F0c0KaG6; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1FE71DAFEF; Wed, 16 Mar 2022 21:41:28 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236399AbiCNOzI (ORCPT + 99 others); Mon, 14 Mar 2022 10:55:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237045AbiCNOzI (ORCPT ); Mon, 14 Mar 2022 10:55:08 -0400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27CA3377F5 for ; Mon, 14 Mar 2022 07:53:49 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id 17so20172261lji.1 for ; Mon, 14 Mar 2022 07:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=9bIfkplOutFYaWeLdLUALKRF5qrlW7wQAPZL71jBcPM=; b=F0c0KaG6f5abypfTP/M0sYlybmoG0dxaeEL3Y1aA8Z7mNuKO9gw/sK9nVcqbjCt6ry a/bTET5mPjHIpN14Y96QHg7kwCn3Ngt2FiswaiCDhXJ/SFDbuxwvzPCY4gMmPQptG9Yi Z2y+nS1WWB8CH0YwImUEEishrw0ImTWmorxmw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=9bIfkplOutFYaWeLdLUALKRF5qrlW7wQAPZL71jBcPM=; b=JXjW7g6Hy5jZSgnbaLHtw3oNThoT1hVpuWqYQrD/FjDMGf3kYbNKehuyZj7uUZuOEb oxmF94MAr11/i9NCR4iAJPbFwZri7PeHZw5p4F7rwTTfdal5noM75Uv4auAmFsuuoBZv coubwqhWPRsfFIjwzXB2I6gDL2B0e+UOIcOYCucDhB9Y+M0yuBT05H0X1SDztlOKkD+W Om+1im7IiQN7isw674ReE/5c44IaGIdBcGpTFEh5wf08GY8vxJsH97Az9MOiAFBZZLt5 jvs3i6wdFIYQH2Q6kiEFubqXTX5zNv99cogRok7KRZ+3fqpIcydVFx/0vIrq7COyBbKO GCJA== X-Gm-Message-State: AOAM530TYxrcKKPN1V7mCcALbvoVmFv2auiSVeEB51D0KQms/m0QPVU8 nn5t6tsvlwCaJJshDnJoi+ppOiqBccwX1vZB X-Received: by 2002:a2e:b617:0:b0:247:e9bb:2228 with SMTP id r23-20020a2eb617000000b00247e9bb2228mr14761338ljn.129.1647269626945; Mon, 14 Mar 2022 07:53:46 -0700 (PDT) Received: from prevas-ravi.prevas.se ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id bg11-20020a05651c0b8b00b00247feb5841bsm4020168ljb.86.2022.03.14.07.53.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Mar 2022 07:53:46 -0700 (PDT) From: Rasmus Villemoes To: "Eric W. Biederman" , Andrew Morton , Petr Mladek , David Hildenbrand , Yafang Shao , Cai Huoqing Cc: Tejun Heo , Rasmus Villemoes , linux-kernel@vger.kernel.org Subject: [PATCH] linux/kthread.h: remove unused macros Date: Mon, 14 Mar 2022 15:53:42 +0100 Message-Id: <20220314145343.494694-1-linux@rasmusvillemoes.dk> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,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 Ever since these macros were introduced in commit b56c0d8937e6 ("kthread: implement kthread_worker"), there has been precisely one user (commit 4d115420707a, "NVMe: Async IO queue deletion"), and that user went away in 2016 with db3cbfff5bcc ("NVMe: IO queue deletion re-write"). Apart from being unused, these macros are also awkward to use (which may contribute to them not being used): Having a way to statically (or on-stack) allocating the storage for the struct kthread_worker itself doesn't help much, since obviously one needs to have some code for actually _spawning_ the worker thread, which must have error checking. And these days we have the kthread_create_worker() interface which both allocates the struct kthread_worker and spawns the kthread. Signed-off-by: Rasmus Villemoes --- include/linux/kthread.h | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/include/linux/kthread.h b/include/linux/kthread.h index 3df4ea04716f..de5d75bafd66 100644 --- a/include/linux/kthread.h +++ b/include/linux/kthread.h @@ -141,12 +141,6 @@ struct kthread_delayed_work { struct timer_list timer; }; -#define KTHREAD_WORKER_INIT(worker) { \ - .lock = __RAW_SPIN_LOCK_UNLOCKED((worker).lock), \ - .work_list = LIST_HEAD_INIT((worker).work_list), \ - .delayed_work_list = LIST_HEAD_INIT((worker).delayed_work_list),\ - } - #define KTHREAD_WORK_INIT(work, fn) { \ .node = LIST_HEAD_INIT((work).node), \ .func = (fn), \ @@ -158,9 +152,6 @@ struct kthread_delayed_work { TIMER_IRQSAFE), \ } -#define DEFINE_KTHREAD_WORKER(worker) \ - struct kthread_worker worker = KTHREAD_WORKER_INIT(worker) - #define DEFINE_KTHREAD_WORK(work, fn) \ struct kthread_work work = KTHREAD_WORK_INIT(work, fn) @@ -168,19 +159,6 @@ struct kthread_delayed_work { struct kthread_delayed_work dwork = \ KTHREAD_DELAYED_WORK_INIT(dwork, fn) -/* - * kthread_worker.lock needs its own lockdep class key when defined on - * stack with lockdep enabled. Use the following macros in such cases. - */ -#ifdef CONFIG_LOCKDEP -# define KTHREAD_WORKER_INIT_ONSTACK(worker) \ - ({ kthread_init_worker(&worker); worker; }) -# define DEFINE_KTHREAD_WORKER_ONSTACK(worker) \ - struct kthread_worker worker = KTHREAD_WORKER_INIT_ONSTACK(worker) -#else -# define DEFINE_KTHREAD_WORKER_ONSTACK(worker) DEFINE_KTHREAD_WORKER(worker) -#endif - extern void __kthread_init_worker(struct kthread_worker *worker, const char *name, struct lock_class_key *key); -- 2.31.1