linux-kernel - Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64

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: <20120519143519.GA11775@ZenIV.linux.org.uk>
Date:	Sat, 19 May 2012 15:35:19 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Daney <ddaney.cavm@...il.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	"H.J. Lu" <hjl.tools@...il.com>, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, mingo@...nel.org, tglx@...utronix.de
Subject: Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

On Sat, May 19, 2012 at 07:56:30AM +0000, Arnd Bergmann wrote:

> * __kernel_time_t is not the only type that differs between 32 and 64
>   bit platforms: the structures also include a __kernel_mode_t, which
>   is different between 32/64 bit on at least s390, x86, arm and sparc.

... and said __kernel_mode_t needs to die.  Along with all remaining
instances of mode_t kernel-side.

BTW, ncp_mount_data (i.e. ncp mount with version less than 4) needs to be
added to feature-removal-schedule.txt.  That'll bury one of the few places
where we have that crap in public headers.

And no, assorted struct stat do not need that thing at all.  They should
use explicit types, TYVM.

BTW, why do we have __kernel_uid32_t?  As an invitation for some architecture
to come up with 64bit "32bit UID" type?  What's wrong with __u32, or
at least moving the default (== only, fortunately) definitions to
linux/posix_types.h and making them unconditional?  Same for gid32_t
stuff, of course...

__kernel_nlink_t is also a bad idea (and an invitation to bugs in the kernel,
while we are at it).  BTW, now that I look at it...  ulong_t as default is
also wrong; there's no point making the internal nlink_t different on different
platforms.  Fortunately, that one is really easy to kill; mips/parisc/ppc
stat.h instances switch to corresponding explictly-sized types, at which point
nothing in userland needs to see it and we can simply switch nlink_t
kernel-side to __u32 and be done with that...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/