linux-kernel - Re: header circular dependencies

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75Vd0-__zV72YGpNqjdV6kOEQYcPkHeyEHPCQ0iL6K8oidQ@mail.gmail.com>
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