lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 4 Jan 2022 16:52:25 +0200 From: Andy Shevchenko <andy.shevchenko@...il.com> To: Petr Mladek <pmladek@...e.com>, Ingo Molnar <mingo@...nel.org> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Steven Rostedt <rostedt@...dmis.org>, Sergey Senozhatsky <senozhatsky@...omium.org>, John Ogness <john.ogness@...utronix.de> Subject: Re: header circular dependencies On Tue, Jan 4, 2022 at 4:46 PM Petr Mladek <pmladek@...e.com> wrote: > > On Wed 2021-12-22 21:08:39, Andy Shevchenko wrote: > > `make headerdep` is full of printk.h circular dependencies, like > > > > include/kvm/arm_vgic.h:18: warning: recursive header inclusion > > In file included from linux/printk.h, > > from linux/dynamic_debug.h:188 > > from linux/printk.h:555 <-- here > > This one looks like false positive: > > + printk.h includes dynamic_debug.h when CONFIG_DYNAMIC_DEBUG_CORE > + dynamic_debug.h includes printk.h when !CONFIG_DYNAMIC_DEBUG_CORE > > But there seem to be other cycles, for example: > > + printk.h > + dynamic_debug.h > + jump_label.h > + bug.h > + asm/bug.h > + printk.h > > I guess that it somehow works _only_ because printk.h includes > dynamic_debug.h late. It probably defines everything that is needed > by bug.h early enough. > > > I'm wondering if it's a false positive? > > In either case, can we teach the headerdep not to complain by fixing > > the culprit? > > I am scratching my head how to clean this up. All the dependencies > make sense. The main problem is that all headers provide a lot of > inlined functionality. The inlining is often important either because > of speed or because every caller needs to have its own data structure > (struct _ddebug, struct static_key). > > I can't find any good solution at the moment. But I am still slowed > down after the holidays. Thanks for looking into this. Meanwhile (I haven't looked at that myself) Ingo announced some of his long work on the topic: https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/ Perhaps he has a solution there. -- With Best Regards, Andy Shevchenko
Powered by blists - more mailing lists