Message ID | 20231216033552.3553579-3-kent.overstreet@linux.dev |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-2025-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:24d3:b0:fb:cd0c:d3e with SMTP id r19csp17913dyi; Fri, 15 Dec 2023 19:38:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IFByVfnhIwV/9xtgDkAyYlxASd4cmVihYBIoVGyh1LpOEZuDRKkIUjj/Kgs4Qguu+5L7S4L X-Received: by 2002:a05:620a:4950:b0:77f:89e:986d with SMTP id vz16-20020a05620a495000b0077f089e986dmr16345062qkn.78.1702697906487; Fri, 15 Dec 2023 19:38:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702697906; cv=none; d=google.com; s=arc-20160816; b=t4EEes1luKzgt48pPNhLCKRAHN+5wk6nhjEI8xZQ5y8Sg1XsOXzXyaOPtVlQ5mNTjc gyu2LSPn00/5WCDL2S4tc6ztae6CtqxLeHLftSG+QuTAW8tObGZaIRHbzne/Ud5O/nFS AHs7KtWHqapXXsnkoFf+skWFMxakm/mw7fjO1bjTSxWanDwYo6D69qq/azA2LEBE8b+j TuLWOLIcT61fbQ3jgZorOucDKhADicVMftPmN9SD5v0rnL4oWBXKzcKDFztX/69K+9Y/ KFBUBQvCjrnAWe264hqzlp3iQgrnlSxnSnxxgZwxd0yDIwJ3lDLd822i9GX/zLbE5XYN pj6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=OUqwYAx0DDPud63nNEdLEk98WtGqrjOdsdwrtUhwy7M=; fh=vHhjxHftTECn/hRvIWNlq1eDzDsn74Roqz0kmRcPgcE=; b=lpyDWsllEXSOhfmCPTCL8tK76w+Noywr4762EIXTLaEcYMP6kyQRDFdHDT56hhumSZ TSmCOfVUSplQSjU4SfAGZOaixOGwk9wWZlc9vTUogCjy6nef/N7mIab+bMgx8J1KCh5C 5grHefly6Ls0vRdcXAjPaXNRjwP3d7gK6dX1ozptqfPi0xIx2qEzPjjlD52el+HtGEDt lL4tDzgJiTpa8P1B0vOd6njScPhiQaPxAkOVzDiR7UFA03dAaL3VmO+66d6uYihCQ/kk hto7wdHE9jSIpKzY1YMn9RhagIwNd3RogIaJ2PA+IqaD44qItlryR+G/b04tsra0jNIC Q/Hw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b="RK/hF5+q"; spf=pass (google.com: domain of linux-kernel+bounces-2025-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-2025-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id v3-20020a05620a0f0300b0077c0f390186si19827657qkl.368.2023.12.15.19.38.26 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 19:38:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-2025-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b="RK/hF5+q"; spf=pass (google.com: domain of linux-kernel+bounces-2025-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-2025-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 4C96B1C24A26 for <ouuuleilei@gmail.com>; Sat, 16 Dec 2023 03:38:26 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BBBB612B68; Sat, 16 Dec 2023 03:36:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="RK/hF5+q" X-Original-To: linux-kernel@vger.kernel.org Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3EE465670 for <linux-kernel@vger.kernel.org>; Sat, 16 Dec 2023 03:36:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1702697767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OUqwYAx0DDPud63nNEdLEk98WtGqrjOdsdwrtUhwy7M=; b=RK/hF5+qNAuTN//SAOHI3R7Lu9Lf4KKbYrkcT/9G7ZF0d+mCv64pZGUkMRZpfq0PJil7/G 9K/J6HudIs1uYCuuQDHxAZkUyBklxOtXfa5qhuihA7RRVwaGkztuPBEywhIYYfGrmFaPOT 3b5Jx+8IMm2SxDqdLfIJPieW5co+7gU= From: Kent Overstreet <kent.overstreet@linux.dev> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Cc: Kent Overstreet <kent.overstreet@linux.dev>, tglx@linutronix.de, x86@kernel.org, tj@kernel.org, peterz@infradead.org, mathieu.desnoyers@efficios.com, paulmck@kernel.org, keescook@chromium.org, dave.hansen@linux.intel.com, mingo@redhat.com, will@kernel.org, longman@redhat.com, boqun.feng@gmail.com, brauner@kernel.org Subject: [PATCH 46/50] preempt.h: Kill dependency on list.h Date: Fri, 15 Dec 2023 22:35:47 -0500 Message-ID: <20231216033552.3553579-3-kent.overstreet@linux.dev> In-Reply-To: <20231216033552.3553579-1-kent.overstreet@linux.dev> References: <20231216024834.3510073-1-kent.overstreet@linux.dev> <20231216033552.3553579-1-kent.overstreet@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785408159804933358 X-GMAIL-MSGID: 1785408159804933358 |
Series |
big header dependency cleanup targeting sched.h
|
|
Commit Message
Kent Overstreet
Dec. 16, 2023, 3:35 a.m. UTC
We really only need types.h, list.h is big.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
---
include/linux/preempt.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Comments
On Fri, Dec 15, 2023 at 10:35:47PM -0500, Kent Overstreet wrote: > - INIT_HLIST_NODE(¬ifier->link); > + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ > + notifier->link.next = NULL; > + notifier->link.pprev = NULL; Arguably INIT_HLIST_NODE() belongs in types.h -- we already have RCUREF_INIT() and ATOMIC_INIT() in there.
On 12/15/23 22:13, Matthew Wilcox wrote: > On Fri, Dec 15, 2023 at 10:35:47PM -0500, Kent Overstreet wrote: >> - INIT_HLIST_NODE(¬ifier->link); >> + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ >> + notifier->link.next = NULL; >> + notifier->link.pprev = NULL; > > Arguably INIT_HLIST_NODE() belongs in types.h -- we already have > RCUREF_INIT() and ATOMIC_INIT() in there. > That would be far better than open-coding it.
On Sat, Dec 16, 2023 at 06:13:41AM +0000, Matthew Wilcox wrote: > On Fri, Dec 15, 2023 at 10:35:47PM -0500, Kent Overstreet wrote: > > - INIT_HLIST_NODE(¬ifier->link); > > + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ > > + notifier->link.next = NULL; > > + notifier->link.pprev = NULL; > > Arguably INIT_HLIST_NODE() belongs in types.h -- we already have > RCUREF_INIT() and ATOMIC_INIT() in there. I think I'd prefer to keep types.h as minimal as possible - as soon as we start putting non type stuff in there people won't know what the distinction is and it'll grow. preempt.h is a bit unusual too, normally we'd just split out a _types.h header there but it's not so easy to split up usefully.
On 12/16/23 14:35, Kent Overstreet wrote: > On Sat, Dec 16, 2023 at 06:13:41AM +0000, Matthew Wilcox wrote: >> On Fri, Dec 15, 2023 at 10:35:47PM -0500, Kent Overstreet wrote: >>> - INIT_HLIST_NODE(¬ifier->link); >>> + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ >>> + notifier->link.next = NULL; >>> + notifier->link.pprev = NULL; >> >> Arguably INIT_HLIST_NODE() belongs in types.h -- we already have >> RCUREF_INIT() and ATOMIC_INIT() in there. > > I think I'd prefer to keep types.h as minimal as possible - as soon as > we start putting non type stuff in there people won't know what the > distinction is and it'll grow. > > preempt.h is a bit unusual too, normally we'd just split out a _types.h > header there but it's not so easy to split up usefully. > I don't feel like I have NAK power, but if I did, I would NAK open coding of INIT_HLIST_HEAD() or anything like it. I would expect some $maintainer to do likewise, but I could be surprised.
On Sat, Dec 16, 2023 at 04:04:43PM -0800, Randy Dunlap wrote: > > > On 12/16/23 14:35, Kent Overstreet wrote: > > On Sat, Dec 16, 2023 at 06:13:41AM +0000, Matthew Wilcox wrote: > >> On Fri, Dec 15, 2023 at 10:35:47PM -0500, Kent Overstreet wrote: > >>> - INIT_HLIST_NODE(¬ifier->link); > >>> + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ > >>> + notifier->link.next = NULL; > >>> + notifier->link.pprev = NULL; > >> > >> Arguably INIT_HLIST_NODE() belongs in types.h -- we already have > >> RCUREF_INIT() and ATOMIC_INIT() in there. > > > > I think I'd prefer to keep types.h as minimal as possible - as soon as > > we start putting non type stuff in there people won't know what the > > distinction is and it'll grow. > > > > preempt.h is a bit unusual too, normally we'd just split out a _types.h > > header there but it's not so easy to split up usefully. > > > > I don't feel like I have NAK power, but if I did, I would NAK > open coding of INIT_HLIST_HEAD() or anything like it. > I would expect some $maintainer to do likewise, but I could be > surprised. There is another solution here (although I prefer moving INIT_HLIST_HEAD into types.h). The preprocessor allows redefinitions as long as the two definitions match exactly. So you can copy INIT_HLIST_HEAD into preempt.h and if the definition ever changes, we'll notice.
On Sat, Dec 16, 2023 at 04:04:43PM -0800, Randy Dunlap wrote: > > > On 12/16/23 14:35, Kent Overstreet wrote: > > On Sat, Dec 16, 2023 at 06:13:41AM +0000, Matthew Wilcox wrote: > >> On Fri, Dec 15, 2023 at 10:35:47PM -0500, Kent Overstreet wrote: > >>> - INIT_HLIST_NODE(¬ifier->link); > >>> + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ > >>> + notifier->link.next = NULL; > >>> + notifier->link.pprev = NULL; > >> > >> Arguably INIT_HLIST_NODE() belongs in types.h -- we already have > >> RCUREF_INIT() and ATOMIC_INIT() in there. > > > > I think I'd prefer to keep types.h as minimal as possible - as soon as > > we start putting non type stuff in there people won't know what the > > distinction is and it'll grow. > > > > preempt.h is a bit unusual too, normally we'd just split out a _types.h > > header there but it's not so easy to split up usefully. > > > > I don't feel like I have NAK power, but if I did, I would NAK > open coding of INIT_HLIST_HEAD() or anything like it. > I would expect some $maintainer to do likewise, but I could be > surprised. It's INIT_HLIST_HEAD(), there's approximately zero chance of the implementation changing, and there's a comment.
On Sun, Dec 17, 2023 at 12:18:17AM +0000, Matthew Wilcox wrote: > On Sat, Dec 16, 2023 at 04:04:43PM -0800, Randy Dunlap wrote: > > > > > > On 12/16/23 14:35, Kent Overstreet wrote: > > > On Sat, Dec 16, 2023 at 06:13:41AM +0000, Matthew Wilcox wrote: > > >> On Fri, Dec 15, 2023 at 10:35:47PM -0500, Kent Overstreet wrote: > > >>> - INIT_HLIST_NODE(¬ifier->link); > > >>> + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ > > >>> + notifier->link.next = NULL; > > >>> + notifier->link.pprev = NULL; > > >> > > >> Arguably INIT_HLIST_NODE() belongs in types.h -- we already have > > >> RCUREF_INIT() and ATOMIC_INIT() in there. > > > > > > I think I'd prefer to keep types.h as minimal as possible - as soon as > > > we start putting non type stuff in there people won't know what the > > > distinction is and it'll grow. > > > > > > preempt.h is a bit unusual too, normally we'd just split out a _types.h > > > header there but it's not so easy to split up usefully. > > > > > > > I don't feel like I have NAK power, but if I did, I would NAK > > open coding of INIT_HLIST_HEAD() or anything like it. > > I would expect some $maintainer to do likewise, but I could be > > surprised. > > There is another solution here (although I prefer moving INIT_HLIST_HEAD > into types.h). The preprocessor allows redefinitions as long as the two > definitions match exactly. So you can copy INIT_HLIST_HEAD into > preempt.h and if the definition ever changes, we'll notice. I like it.
On 12/16/23 16:18, Kent Overstreet wrote: > On Sat, Dec 16, 2023 at 04:04:43PM -0800, Randy Dunlap wrote: >> >> >> On 12/16/23 14:35, Kent Overstreet wrote: >>> On Sat, Dec 16, 2023 at 06:13:41AM +0000, Matthew Wilcox wrote: >>>> On Fri, Dec 15, 2023 at 10:35:47PM -0500, Kent Overstreet wrote: >>>>> - INIT_HLIST_NODE(¬ifier->link); >>>>> + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ >>>>> + notifier->link.next = NULL; >>>>> + notifier->link.pprev = NULL; >>>> >>>> Arguably INIT_HLIST_NODE() belongs in types.h -- we already have >>>> RCUREF_INIT() and ATOMIC_INIT() in there. >>> >>> I think I'd prefer to keep types.h as minimal as possible - as soon as >>> we start putting non type stuff in there people won't know what the >>> distinction is and it'll grow. >>> >>> preempt.h is a bit unusual too, normally we'd just split out a _types.h >>> header there but it's not so easy to split up usefully. >>> >> >> I don't feel like I have NAK power, but if I did, I would NAK >> open coding of INIT_HLIST_HEAD() or anything like it. >> I would expect some $maintainer to do likewise, but I could be >> surprised. > > It's INIT_HLIST_HEAD(), there's approximately zero chance of the > implementation changing, and there's a comment. s/_HEAD/_NODE/ for both of us. :)
On 12/16/23 16:20, Kent Overstreet wrote: > On Sun, Dec 17, 2023 at 12:18:17AM +0000, Matthew Wilcox wrote: >> On Sat, Dec 16, 2023 at 04:04:43PM -0800, Randy Dunlap wrote: >>> >>> >>> On 12/16/23 14:35, Kent Overstreet wrote: >>>> On Sat, Dec 16, 2023 at 06:13:41AM +0000, Matthew Wilcox wrote: >>>>> On Fri, Dec 15, 2023 at 10:35:47PM -0500, Kent Overstreet wrote: >>>>>> - INIT_HLIST_NODE(¬ifier->link); >>>>>> + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ >>>>>> + notifier->link.next = NULL; >>>>>> + notifier->link.pprev = NULL; >>>>> >>>>> Arguably INIT_HLIST_NODE() belongs in types.h -- we already have >>>>> RCUREF_INIT() and ATOMIC_INIT() in there. >>>> >>>> I think I'd prefer to keep types.h as minimal as possible - as soon as >>>> we start putting non type stuff in there people won't know what the >>>> distinction is and it'll grow. >>>> >>>> preempt.h is a bit unusual too, normally we'd just split out a _types.h >>>> header there but it's not so easy to split up usefully. >>>> >>> >>> I don't feel like I have NAK power, but if I did, I would NAK >>> open coding of INIT_HLIST_HEAD() or anything like it. >>> I would expect some $maintainer to do likewise, but I could be >>> surprised. >> >> There is another solution here (although I prefer moving INIT_HLIST_HEAD >> into types.h). The preprocessor allows redefinitions as long as the two >> definitions match exactly. So you can copy INIT_HLIST_HEAD into >> preempt.h and if the definition ever changes, we'll notice. > > I like it. Possible to revert 490d6ab170c9 ? although with something list this inserted: struct hlist_node *_p = h; and then use _p instead of h (or the old macro's 'ptr') The code looks the same to me, although I could have mucked something up: https://godbolt.org/z/z76nsqGx3 although Andrew prefers inlines for type checking.
On Sat, Dec 16, 2023 at 06:03:36PM -0800, Randy Dunlap wrote: > > > On 12/16/23 16:20, Kent Overstreet wrote: > > On Sun, Dec 17, 2023 at 12:18:17AM +0000, Matthew Wilcox wrote: > >> On Sat, Dec 16, 2023 at 04:04:43PM -0800, Randy Dunlap wrote: > >>> > >>> > >>> On 12/16/23 14:35, Kent Overstreet wrote: > >>>> On Sat, Dec 16, 2023 at 06:13:41AM +0000, Matthew Wilcox wrote: > >>>>> On Fri, Dec 15, 2023 at 10:35:47PM -0500, Kent Overstreet wrote: > >>>>>> - INIT_HLIST_NODE(¬ifier->link); > >>>>>> + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ > >>>>>> + notifier->link.next = NULL; > >>>>>> + notifier->link.pprev = NULL; > >>>>> > >>>>> Arguably INIT_HLIST_NODE() belongs in types.h -- we already have > >>>>> RCUREF_INIT() and ATOMIC_INIT() in there. > >>>> > >>>> I think I'd prefer to keep types.h as minimal as possible - as soon as > >>>> we start putting non type stuff in there people won't know what the > >>>> distinction is and it'll grow. > >>>> > >>>> preempt.h is a bit unusual too, normally we'd just split out a _types.h > >>>> header there but it's not so easy to split up usefully. > >>>> > >>> > >>> I don't feel like I have NAK power, but if I did, I would NAK > >>> open coding of INIT_HLIST_HEAD() or anything like it. > >>> I would expect some $maintainer to do likewise, but I could be > >>> surprised. > >> > >> There is another solution here (although I prefer moving INIT_HLIST_HEAD > >> into types.h). The preprocessor allows redefinitions as long as the two > >> definitions match exactly. So you can copy INIT_HLIST_HEAD into > >> preempt.h and if the definition ever changes, we'll notice. > > > > I like it. > > Possible to revert 490d6ab170c9 ? although with something list > this inserted: > > struct hlist_node *_p = h; > and then use _p instead of h (or the old macro's 'ptr') > > The code looks the same to me, although I could have mucked something > up: https://godbolt.org/z/z76nsqGx3 > > although Andrew prefers inlines for type checking. I prefer inlines whenever possible too, a macro should really be a signal that 'something interesting is going on here'. I'm just going with my original version.
diff --git a/include/linux/preempt.h b/include/linux/preempt.h index 9aa6358a1a16..7233e9cf1bab 100644 --- a/include/linux/preempt.h +++ b/include/linux/preempt.h @@ -9,7 +9,7 @@ #include <linux/linkage.h> #include <linux/cleanup.h> -#include <linux/list.h> +#include <linux/types.h> /* * We put the hardirq and softirq counter into the preemption @@ -360,7 +360,9 @@ void preempt_notifier_unregister(struct preempt_notifier *notifier); static inline void preempt_notifier_init(struct preempt_notifier *notifier, struct preempt_ops *ops) { - INIT_HLIST_NODE(¬ifier->link); + /* INIT_HLIST_NODE() open coded, to avoid dependency on list.h */ + notifier->link.next = NULL; + notifier->link.pprev = NULL; notifier->ops = ops; }