linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Petr Mladek <pmladek@suse.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	"Steven Rostedt (VMware)" <rostedt@goodmis.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: [PATCH] lockdep: Move list.h inclusion into lockdep.h
Date: Wed, 24 Jun 2020 22:42:12 +1000	[thread overview]
Message-ID: <20200624124212.GA17350@gondor.apana.org.au> (raw)
In-Reply-To: <20200623142858.GB8444@alley>

On Tue, Jun 23, 2020 at 04:28:58PM +0200, Petr Mladek wrote:
>
> My "allmodconfig" build has successfully finished with the following extra
>  fix on top of the two patches:
> 
> diff --git a/include/linux/list.h b/include/linux/list.h
> index aff44d34f4e4..6d606c4036ce 100644
> --- a/include/linux/list.h
> +++ b/include/linux/list.h
> @@ -6,7 +6,7 @@
>  #include <linux/stddef.h>
>  #include <linux/poison.h>
>  #include <linux/const.h>
> -#include <linux/kernel.h>
> +#include <linux/compiler.h>

Unfortunately this doesn't work because list.h actually does need
kernel.h for container_of.

However, we can easily fix the loop another way by removing list.h
from lockdep.h as it doesn't actually use any list macros/functions
but only the list type which is now in linux/types.h.

We could either fold this into the lockdep_types patch, or fold it
into the printk patch, or just leave it as a standalone patch.
What do you guys think?

---8<---
Currently lockdep_types.h includes list.h without actually using any
of its macros or functions.  All it needs are the type definitions
which were moved into types.h long ago.  This potentially causes
inclusion loops because both are included by many core header
files.

This patch moves the list.h inclusion into lockdep.h.  Note that
we could probably remove it completely but that could potentially
result in compile failures should any end users not include list.h
directly and also be unlucky enough to not get list.h via some other
header file.

Reported-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 3b73cf84f77d..b1ad5c045353 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -21,6 +21,7 @@ extern int lock_stat;
 #ifdef CONFIG_LOCKDEP
 
 #include <linux/linkage.h>
+#include <linux/list.h>
 #include <linux/debug_locks.h>
 #include <linux/stacktrace.h>
 
diff --git a/include/linux/lockdep_types.h b/include/linux/lockdep_types.h
index 7b9350624577..bb35b449f533 100644
--- a/include/linux/lockdep_types.h
+++ b/include/linux/lockdep_types.h
@@ -32,8 +32,6 @@ enum lockdep_wait_type {
 
 #ifdef CONFIG_LOCKDEP
 
-#include <linux/list.h>
-
 /*
  * We'd rather not expose kernel/lockdep_states.h this wide, but we do need
  * the total number of states... :-(
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  parent reply	other threads:[~2020-06-24 12:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-21  3:15 linux-next: build failure after merge of the printk tree Stephen Rothwell
2020-06-21  3:26 ` Herbert Xu
2020-06-23  0:26 ` Stephen Rothwell
2020-06-23 12:16   ` Petr Mladek
2020-06-23 12:19     ` Herbert Xu
2020-06-23 14:28       ` Petr Mladek
2020-06-23 15:17         ` Peter Zijlstra
2020-06-24  8:22           ` Petr Mladek
2020-06-24  0:20         ` Herbert Xu
2020-06-24  8:19           ` Petr Mladek
2020-06-24  8:21             ` Herbert Xu
2020-06-24 12:42         ` Herbert Xu [this message]
2020-06-24 12:49           ` [PATCH] lockdep: Move list.h inclusion into lockdep.h Andy Shevchenko
2020-06-24 12:50             ` Herbert Xu
2020-06-25 10:11           ` Petr Mladek
2020-06-29  7:32             ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200624124212.GA17350@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=andy.shevchenko@gmail.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).