linux-kernel - Re: [PATCH 4/4] CPER: Remove unnecessary use of user-space types

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:   Mon, 25 Mar 2019 12:13:15 -0700
From:   Joe Perches <joe@...ches.com>
To:     Bjorn Helgaas <helgaas@...nel.org>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 4/4] CPER: Remove unnecessary use of user-space types

On Mon, 2019-03-25 at 13:26 -0500, Bjorn Helgaas wrote:
> On Mon, Mar 25, 2019 at 01:14:25PM -0500, helgaas@...nel.org wrote:
> > From: Bjorn Helgaas <bhelgaas@...gle.com>
> > 
> > "__u32" and similar types are intended for things exported to user-space,
> > including structs used in ioctls; see include/uapi/asm-generic/int-l64.h.
> > 
> > They are not needed for the CPER struct definitions, which not exported to
> > user-space and not used in ioctls.  Replace them with the typical "u32" and
> > similar types.  No functional change intended.
[]
> I *think* the conclusion there was that this sort of change makes
> sense, but I want to make sure.  If it does make sense, I'm surprised
> at how much stuff in include/linux/ still uses __u32 when it doesn't
> appear to need it.

It is a fairly large number.

$ git grep -w -P '__[us](?:8|16|32|64)' include/linux/ | wc -l
2318

It's a rather large number of patches though to make all the
actual function definitions match the declarations that are
spread around the kernel sources as well.

Whatever struct member uses of possible temporary assignments
could also be changed to match.

Perhaps it's a lot of churn for relatively little benefit
though I do find __ prefixes unsightly when unnecessary.

A gradual conversion would eventually help isolate uapi uses
in the kernel sources.