From: Cyril Hrubis <chrubis@suse.cz>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
LTP List <ltp@lists.linux.it>,
GNU C Library <libc-alpha@sourceware.org>,
linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace
Date: Tue, 23 Nov 2021 10:14:15 +0100 [thread overview]
Message-ID: <YZyw56flmdQnBIuh@yuki> (raw)
In-Reply-To: <CAK8P3a0x5Bw7=0ng-s+KsUywqJYa0tk9cSWmZhx+cZRBOR87ZA@mail.gmail.com>
Hi!
> > +#include <asm/bitsperlong.h>
> > +
> > /*
> > - * int-ll64 is used everywhere now.
> > + * int-ll64 is used everywhere in kernel now.
> > */
> > -#include <asm-generic/int-ll64.h>
> > +#if __BITS_PER_LONG == 64 && !defined(__KERNEL__)
> > +# include <asm-generic/int-l64.h>
> > +#else
> > +# include <asm-generic/int-ll64.h>
> > +#endif
>
> I don't think this is correct on all 64-bit architectures, as far as I
> remember the
> definition can use either 'long' or 'long long' depending on the user space
> toolchain.
As far as I can tell the userspace bits/types.h does exactly the same
check in order to define uint64_t and int64_t, i.e.:
#if __WORDSIZE == 64
typedef signed long int __int64_t;
typedef unsigned long int __uint64_t;
#else
__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;
#endif
The macro __WORDSIZE is defined per architecture, and it looks like the
defintions in glibc sources in bits/wordsize.h match the uapi
asm/bitsperlong.h. But I may have missed something, the code in glibc is
not exactly easy to read.
> Out of the ten supported 64-bit architectures, there are four that already
> use asm-generic/int-l64.h conditionally, and six that don't, and I
> think at least
> some of those are intentional.
>
> I think it would be safer to do this one architecture at a time to make
> sure this doesn't regress on those that require the int-ll64.h version.
I'm still trying to understand what exactly can go wrong here. As long
as __BITS_PER_LONG is correctly defined the __u64 and __s64 will be
correctly sized as well. The only visible change is that one 'long' is
dropped from the type when it's not needed.
> There should also be a check for __SANE_USERSPACE_TYPES__
> to let userspace ask for the ll64 version everywhere.
That one is easy to fix at least.
--
Cyril Hrubis
chrubis@suse.cz
WARNING: multiple messages have this Message-ID (diff)
From: Cyril Hrubis <chrubis@suse.cz>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
GNU C Library <libc-alpha@sourceware.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t in userspace
Date: Tue, 23 Nov 2021 10:14:15 +0100 [thread overview]
Message-ID: <YZyw56flmdQnBIuh@yuki> (raw)
In-Reply-To: <CAK8P3a0x5Bw7=0ng-s+KsUywqJYa0tk9cSWmZhx+cZRBOR87ZA@mail.gmail.com>
Hi!
> > +#include <asm/bitsperlong.h>
> > +
> > /*
> > - * int-ll64 is used everywhere now.
> > + * int-ll64 is used everywhere in kernel now.
> > */
> > -#include <asm-generic/int-ll64.h>
> > +#if __BITS_PER_LONG == 64 && !defined(__KERNEL__)
> > +# include <asm-generic/int-l64.h>
> > +#else
> > +# include <asm-generic/int-ll64.h>
> > +#endif
>
> I don't think this is correct on all 64-bit architectures, as far as I
> remember the
> definition can use either 'long' or 'long long' depending on the user space
> toolchain.
As far as I can tell the userspace bits/types.h does exactly the same
check in order to define uint64_t and int64_t, i.e.:
#if __WORDSIZE == 64
typedef signed long int __int64_t;
typedef unsigned long int __uint64_t;
#else
__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;
#endif
The macro __WORDSIZE is defined per architecture, and it looks like the
defintions in glibc sources in bits/wordsize.h match the uapi
asm/bitsperlong.h. But I may have missed something, the code in glibc is
not exactly easy to read.
> Out of the ten supported 64-bit architectures, there are four that already
> use asm-generic/int-l64.h conditionally, and six that don't, and I
> think at least
> some of those are intentional.
>
> I think it would be safer to do this one architecture at a time to make
> sure this doesn't regress on those that require the int-ll64.h version.
I'm still trying to understand what exactly can go wrong here. As long
as __BITS_PER_LONG is correctly defined the __u64 and __s64 will be
correctly sized as well. The only visible change is that one 'long' is
dropped from the type when it's not needed.
> There should also be a check for __SANE_USERSPACE_TYPES__
> to let userspace ask for the ll64 version everywhere.
That one is easy to fix at least.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2021-11-23 9:13 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 16:43 [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace Cyril Hrubis
2021-11-22 16:43 ` [LTP] " Cyril Hrubis
2021-11-22 16:51 ` Alejandro Colomar (mailing lists)
2021-11-22 16:51 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Alejandro Colomar (mailing lists)
2021-11-22 20:48 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Arnd Bergmann
2021-11-22 20:48 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Arnd Bergmann
2021-11-23 9:14 ` Cyril Hrubis [this message]
2021-11-23 9:14 ` Cyril Hrubis
2021-11-23 14:18 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Arnd Bergmann
2021-11-23 14:18 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Arnd Bergmann
2021-11-23 19:50 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Florian Weimer
2021-11-23 19:50 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Florian Weimer
2021-11-24 10:17 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Alejandro Colomar (man-pages)
2021-11-24 10:17 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Alejandro Colomar (man-pages)
2021-11-22 22:19 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Zack Weinberg
2021-11-22 22:19 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Zack Weinberg
2021-11-23 9:15 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Cyril Hrubis
2021-11-23 9:15 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Cyril Hrubis
2021-12-02 15:34 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Rich Felker
2021-12-02 15:34 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Rich Felker
2021-12-02 23:29 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Rich Felker
2021-12-02 23:29 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Rich Felker
2021-12-02 23:43 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Adhemerval Zanella
2021-12-02 23:43 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Adhemerval Zanella
2021-12-03 0:10 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Zack Weinberg
2021-12-03 0:10 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Zack Weinberg
2021-12-03 12:32 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Adhemerval Zanella
2021-12-03 12:32 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Adhemerval Zanella
2021-12-03 12:54 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Alejandro Colomar (man-pages)
2021-12-03 12:54 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Alejandro Colomar (man-pages)
2021-11-23 16:47 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " David Howells
2021-11-23 16:47 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " David Howells
2021-11-23 16:58 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " David Laight
2021-11-23 16:58 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " David Laight
2021-11-29 11:58 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Cyril Hrubis
2021-11-29 11:58 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Cyril Hrubis
2021-11-29 14:34 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Arnd Bergmann
2021-11-29 14:34 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Arnd Bergmann
2021-12-02 14:55 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Zack Weinberg
2021-12-02 14:55 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Zack Weinberg
2021-12-02 15:01 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " David Howells
2021-12-02 15:01 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " David Howells
2021-12-02 20:48 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Zack Weinberg
2021-12-02 20:48 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Zack Weinberg
2021-12-08 15:33 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Cyril Hrubis
2021-12-08 15:33 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Cyril Hrubis
2022-06-17 12:13 ` Ping: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Alejandro Colomar
2022-06-17 12:13 ` [LTP] Ping: [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Alejandro Colomar
2022-06-17 15:04 ` Ping: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Cyril Hrubis
2022-06-17 15:04 ` [LTP] Ping: [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Cyril Hrubis
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=YZyw56flmdQnBIuh@yuki \
--to=chrubis@suse.cz \
--cc=arnd@arndb.de \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltp@lists.linux.it \
/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.