All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	tanzirh@google.com, Kees Cook <keescook@chromium.org>,
	Andy Shevchenko <andy@kernel.org>,
	linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
	Nick DeSaulniers <nnn@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	llvm@lists.linux.dev
Subject: Re: [PATCH] lib/string: shrink lib/string.i via IWYU
Date: Wed, 6 Dec 2023 08:46:50 +0900	[thread overview]
Message-ID: <2023120657-henna-spongy-9ef6@gregkh> (raw)
In-Reply-To: <CAKwvOdmFJ=ZGN8ZScS5oQpXnAL0wwtTDCeNNGpBKZXzQ4kRAVA@mail.gmail.com>

On Tue, Dec 05, 2023 at 02:14:55PM -0800, Nick Desaulniers wrote:
> On Tue, Dec 5, 2023 at 1:59 PM Greg KH <greg@kroah.com> wrote:
> >
> > On Tue, Dec 05, 2023 at 01:51:10PM -0800, Nick Desaulniers wrote:
> > > On Tue, Dec 5, 2023 at 1:38 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > > >
> > > > It also breeds includes of asm/*.h, by the look of the output, which is
> > > > not a good thing in general ;-/  E.g. #include <asm/uaccess.h> *anywhere*
> > > > outside of linux/uaccess.h is a bad idea.
> > >
> > > It's not clear to me when it's ok to #include <asm/*.h>.  Is there a
> > > convention here that I'm missing?
> >
> > General rule, NEVER include asm/*.h, there should be a include/*.h
> > instead that works.  So much so that checkpatch.pl should catch this,
> > right?
> 
> ah, shoot, I was showing Tanzir how to use `b4` for patch development,
> and forgot to check this.  Indeed it does.
> 
> I can see how the check works (scripts/checkpatch.pl L5881).  Decoding
> that will probably help us improve the tooling.
> 
> >
> > 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.

Good luck!

greg k-h

  reply	other threads:[~2023-12-05 23:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05 20:58 [PATCH] lib/string: shrink lib/string.i via IWYU tanzirh
2023-12-05 21:04 ` Andrew Morton
2023-12-05 21:14   ` Nick Desaulniers
2023-12-05 21:24     ` Andrew Morton
2023-12-05 21:39       ` Nick Desaulniers
2023-12-05 21:43         ` Al Viro
2023-12-05 21:57           ` Nick Desaulniers
2023-12-11 20:47           ` Nick Desaulniers
2023-12-11 20:50             ` Andy Shevchenko
2023-12-05 21:53         ` Andy Shevchenko
2023-12-05 22:05           ` Nick Desaulniers
2023-12-07  6:25         ` Christoph Hellwig
2023-12-05 21:38 ` Al Viro
2023-12-05 21:51   ` Nick Desaulniers
2023-12-05 21:59     ` Greg KH
2023-12-05 22:14       ` Nick Desaulniers
2023-12-05 23:46         ` Greg KH [this message]
2023-12-06  0:55           ` Al Viro
2023-12-06  3:00             ` Al Viro
2023-12-06  3:09               ` Greg KH
2023-12-14 21:04                 ` Al Viro
2023-12-15 21:03                   ` Al Viro
2023-12-07 12:50         ` Andy Shevchenko
2023-12-05 22:01     ` Andy Shevchenko
2023-12-05 22:10       ` Randy Dunlap
2023-12-05 22:25         ` Nick Desaulniers
2023-12-05 22:15       ` Al Viro
2023-12-05 22:20         ` Nick Desaulniers
2023-12-05 22:32         ` Al Viro
2023-12-07 12:52         ` Andy Shevchenko
2023-12-05 21:57   ` Al Viro
2023-12-05 21:50 ` Andy Shevchenko
2023-12-05 22:05 ` Andy Shevchenko
2023-12-06  7:10 ` kernel test robot
2023-12-07 12:55   ` Andy Shevchenko

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=2023120657-henna-spongy-9ef6@gregkh \
    --to=greg@kroah.com \
    --cc=akpm@linux-foundation.org \
    --cc=andy@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=ndesaulniers@google.com \
    --cc=nnn@google.com \
    --cc=tanzirh@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.