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: <CA+55aFx4sEQT=U4DBULeo9=3piOx_pQUws92ovKV5bKsu3hQQQ@mail.gmail.com>
Date:	Thu, 17 May 2012 17:41:42 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	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 Thu, May 17, 2012 at 5:22 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> That's why I think it's unfixable. It started out broken, and I
> presume that 32-bit user land on a 64-bit MIPS/PPC thing either do not
> work, or there's some compat crap (like special user-land headers)
> fixing things up. Or they just don't use that buggered msqid64_ds
> thing at all.

Btw, even if it's unfixable, that doesn't necessarily mean that we
can't make it *prettier*.

For example, instead of this horrible crap:

          __kernel_time_t msg_stime;      /* last msgsnd time */
  #if __BITS_PER_LONG != 64
          unsigned long   __unused1;
  #endif

which is just nasty, we *could* have something much cleaner like this:

  #define align_64_entry(type,name) \
              union { type name; __u64 __align_##name; }

and then just use

           align_64_entry(__kernel_time_t msg_stime);

without any preprocessor #if/#ifdef crap anywhere.

It would keep the current state for the (apparently broken) case of
64-bit kernel and 32-bit user space with big-endian architectures, but
it would *also* just magically work if __kernel_time_t is 64-bit
despite "long" being 32-bit.

So it would fix the x32 case, as far as I can tell.

Note: totally untested. Maybe there's some reason why my anonymous
union trick wouldn't work.

                    Linus
--
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/