From: Al Viro <viro@zeniv.linux.org.uk>
To: Greg KH <greg@kroah.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
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: Thu, 14 Dec 2023 21:04:00 +0000 [thread overview]
Message-ID: <20231214210400.GR1674809@ZenIV> (raw)
In-Reply-To: <2023120650-faucet-palpable-f1a3@gregkh>
On Wed, Dec 06, 2023 at 12:09:17PM +0900, Greg KH wrote:
> > slap #include "unaligned.h" into their traps.c and unaligned.c
> > (callers and definitions resp.) and strip those from asm/unaligned.h?
> > At that point we can remove arch/{arc,parisc}/asm/unaligned.h - everything
> > will pick include/asm-generic/unaligned.h.
> >
> > Then the next cycle we ask Linus to run the following:
> > for i in `git grep -l -w asm/unaligned.h`; do
> > sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
> > done
> > git mv include/asm-generic/unaligned.h include/linux/unaligned.h
> > sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
> > right before releasing -rc1 and asm/unaligned.h is gone...
>
> Please do, it's really annoying and would be great to fix up.
FWIW, turns out that we have several places in drivers/* that pull
asm-generic/unaligned.h. IMO that's completely wrong - not just in this
case (it's a matter of trivially adjusting the script), but I think that
as a matter of policy we should *NOT* have includes of asm-generic/*.h
anywhere in drivers/ fs/ io_uring/ kernel/ mm/ net/ sound/
Current situation (outside of arch, include, scripts and tools,
with asm-generic/unaligned.h cases already taken out):
drivers/android/binderfs.c:32:#include <uapi/asm-generic/errno-base.h>
drivers/clk/microchip/clk-mpfs-ccc.c:7:#include "asm-generic/errno-base.h"
drivers/firmware/arm_scmi/shmem.c:13:#include <asm-generic/bug.h>
drivers/irqchip/irq-ti-sci-inta.c:24:#include <asm-generic/msi.h>
drivers/mtd/nand/raw/ingenic/ingenic_ecc.h:9:#include <uapi/asm-generic/errno-base.h>
drivers/platform/x86/hp/hp-bioscfg/passwdobj-attributes.c:10:#include <asm-generic/posix_types.h>
io_uring/uring_cmd.c:10:#include <uapi/asm-generic/ioctls.h>
lib/trace_readwrite.c:10:#include <asm-generic/io.h>
mm/damon/vaddr.c:10:#include <asm-generic/mman-common.h>
net/sunrpc/xprtrdma/verbs.c:58:#include <asm-generic/barrier.h>
rust/uapi/uapi_helper.h:9:#include <uapi/asm-generic/ioctl.h>
That's it. asm-generic/errno-base.h cases - just use linux/errno.h and
be done with it. Anyone who goes "I've got ENOENT and ENOMEM in my driver,
but those two are covered by errno-base.h and I can be clever and use
just that" is wrong.
asm-generic/mman-common.h - and linux/mman.h would not serve why, exactly?
uapi/linux/linux/mman.h, if one really feels like it...
asm-generic/ioctls.h in io_uring - definitely wrong; SIOCINQ is what
it's brought for, but that's in sockios.h. It expands to FIONREAD, which
*is* in ioctls.h, but...
arch/alpha/include/uapi/asm/ioctls.h:11:#define FIONREAD _IOR('f', 127, int)
arch/mips/include/uapi/asm/ioctls.h:64:#define FIONREAD 0x467f
arch/parisc/include/uapi/asm/ioctls.h:35:#define FIONREAD 0x541B
arch/powerpc/include/uapi/asm/ioctls.h:11:#define FIONREAD _IOR('f', 127, int)
arch/sh/include/uapi/asm/ioctls.h:11:#define FIONREAD _IOR('f', 127, int)
arch/sparc/include/uapi/asm/ioctls.h:101:#define FIONREAD _IOR('f', 127, int)
arch/xtensa/include/uapi/asm/ioctls.h:23:#define FIONREAD _IOR('f', 127, int)
include/uapi/asm-generic/ioctls.h:46:#define FIONREAD 0x541B
See the problem? On mips the value is not 0x541B - it's 0x467F; on
alpha, powerpc and sparc it's 0x4004667F, on sh and xtensa - 0x8004667F
(different expansions of _IOR).
The only thing that has any business including asm-generic/ioctls.h is
arch/*/include/uapi/asm/ioctls.h - if it feels like doing so. Anywhere
else it ought to be asm/ioctls.h.
asm-generic/msi.h - looks bogus; there's an include of linux/msi.h several lines
above, and that pulls asm/msi.h. Which makes it either a no-op or a build bug
(the latter - if that driver can be built on x86 with CONFIG_GENERIC_MSI_IRQ
defined;
typedef struct irq_alloc_info msi_alloc_info_t;
in asm/msi.h vs.
typedef struct msi_alloc_info {
struct msi_desc *desc;
irq_hw_number_t hwirq;
unsigned long flags;
union {
unsigned long ul;
void *ptr;
} scratchpad[NUM_MSI_ALLOC_SCRATCHPAD_REGS];
} msi_alloc_info_t;
in asm-generic/msi.h).
Hell knows about the rest, but they all look very dubious...
next prev parent reply other threads:[~2023-12-14 21:04 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
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 [this message]
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=20231214210400.GR1674809@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=andy@kernel.org \
--cc=greg@kroah.com \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox