linux-kernel - Re: [PATCH] lib/string: shrink lib/string.i via IWYU

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]

Date:   Wed, 6 Dec 2023 00:55:42 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Greg KH <greg@...ah.com>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>, tanzirh@...gle.com,
        Kees Cook <keescook@...omium.org>,
        Andy Shevchenko <andy@...nel.org>,
        linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
        Nick DeSaulniers <nnn@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>, llvm@...ts.linux.dev
Subject: Re: [PATCH] lib/string: shrink lib/string.i via IWYU

On Wed, Dec 06, 2023 at 08:46:50AM +0900, Greg KH wrote:
> > >
> > > But of course, it doesn't always hold true, there are a few minor
> > > exceptions, but they are rare.
> > 
> > $ grep -r \\#include lib | grep asm
> > 
> > shows quite a few exceptions, and just in lib/.
> > 
> > For example, lib/math/int_log.c includes asm/bug.h.  Is that a case
> > where lib/math/int_log.c should be #include 'ing linux/bug.h rather
> > than asm/bug.h?
> 
> Probably yes, but we don't normally go back and take coding style fixes
> for old files like this as it doesn't make much sense to do so.
> 
> But, if you are cleaning up the headers for large portions with the goal
> of faster builds, that's a good reason.

FWIW, the most common (by far - about 13% of such includes, over drivers/, fs/,
mm/, net/ and sound/) is asm/unaligned.h.

The next are asm/io.h (10%), asm/byteorder.h (6%), asm/irq.h (5%), asm/div64.h (3%),
asm/page.h and asm/dma.h (2% each).  The rest is below that (the next is a bit over
1%).

In fs/* unaligned.h is again the top one (37 out of 139), followed by
byteorder.h (30 out of 139), div64.h (12), page.h (10) and then comes random
shite - I do not believe that fs/coda/psdev.c might have a legitimate
reason to pull asm/io.h, for one thing...