On Wed 2020-06-24 22:42:12, Herbert Xu wrote:

On Tue, Jun 23, 2020 at 04:28:58PM +0200, Petr Mladek wrote:

quoted

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.

Ah, I see.

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?

It logically belongs to the lockdep_types area.

I think that separate patch is the best solution so that Peter does
not need to rebase tip/locking/header.

---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>

It works with allmodconfig here, so feel free to use:

Tested-by: Petr Mladek <pmladek@suse.com>

Of course, it does not have much value. There might still be another
configuration or architecture that does not work but I would leave
this for test bots.

Best Regards,
Petr