From: "arnd@arndb.de" <arnd@arndb.de>
To: Rich Felker <dalias@libc.org>
Cc: "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
"pinskia@gmail.com" <pinskia@gmail.com>,
Marcus Shawcroft <Marcus.Shawcroft@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Szabolcs Nagy <nsz@port70.net>,
Andrew Pinski <apinski@cavium.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
musl@lists.openwall.com
Subject: Re: Re: [PATCHv3 00/24] ILP32 support in ARM64
Date: Wed, 11 Feb 2015 22:09:32 +0100 (CET) [thread overview]
Message-ID: <2013411126.512657.1423688972986.JavaMail.open-xchange@oxbaltgw09.schlund.de> (raw)
In-Reply-To: <1383502854.512344.1423688575473.JavaMail.open-xchange@oxbaltgw09.schlund.de>
Sorry about the HTML mail, I'm currently travelling without access to my regular
mail client.
> "arnd@arndb.de" <arnd@arndb.de> hat am 11. Februar 2015 um 22:02 geschrieben:
>
> Rich Felker <dalias@libc.org> hat am 11. Februar 2015 um 21:12 geschrieben:
> > On Wed, Feb 11, 2015 at 08:50:06PM +0100, arnd@arndb.de wrote:
> > > > > At least for AArch64 ILP32 we are still free to change the
> > > > > user/kernel
> > > > > ABI, so we could add wrappers for the affected syscalls to fix this
> > > > > up.
> > > > yes, afaik on x32 the 64bit kernel expects 64bit layout,
> > > > arm64 can fix this
> > >
> > > We have to fix it on all 32-bit architectures when we move to 64-bit
> > > time_t.
> > >
> > > I think ideally you'd want a user space definition like
> > >
> > > typedef long long time_t;
> > > struct timespec {
> > > time_t tv_sec;
> > > long long tv_nsec;
> > > };
> > >
> > > which is the only way to avoid passing uninitialized tv_nsec into the
> > > kernel
> > > from arbitrary user space doing ioctl. This is of course against POSIX
> > > and
> > > C99. Changing POSIX to allow it is probably easier than the C standard,
> > > but we have a couple of years before we need to make this the default.
> >
> > I don't see why you want it to be long long. There is no harm in
> > passing uninitialized padding to the kernel; the kernel just needs to
> > do the right thing and ignore it (or avoid reading it to begin with).
>
> This would however mean having three different implementations
> in the kernel rather than just two: Every driver that can pass a timespec
> with this model needs to handle the native 64-bit case (64/64), the legacy
> 32-bit case (32/32) and the y2038-safe case (64/32). Most code can
> already handle the first two, and none today handles the third. If you
> want to make the handling explicitly incompatible with native 64-bit
> mode, you get a lot of untested code in obscure places that are never
> tested properly, while using the normal behavior in the kernel at least
> gives us the same bugs that we already have on native 64-bit systems.
>
> In some cases, there may also be a measurable performance penalty
> in interpreting a user space data structure manually over copying
> it (including the timespec values) in one chunk.
>
> An alternative would be to change the native 64-bit case to ignore the upper
> half of tv_nsec and always just copy the low bits. This should work
> fine almost all of the time, but I fear that there might be corner cases
> where existing 64-bit user space depends on passing large or negative
> tv_nsec values into the kernel.
>
> > The other direction, passing uninitialized data from the kernel to
> > userspace, would be dangerous. But it doesn't happen as long as the
> > userspace padding is positioned (in an endian-dependent manner) where
> > the high bits of the kernel type would lie. It could happen if you
> > used a separate conversion wrapper that ony wrote 32 bits, but if you
> > wanted to take that approach you'd just need the wrapper to also write
> > the padding field manually.
>
> Going from kernel to user space should not be an issue as long as we
> always just write two 64-bit words, and this will zero-fill the upper half.
>
> > > In the kernel headers, the current plan is to provide interfaces taking
> > > structures
> > >
> > > typedef long long __kernel_time64_t;
> > > struct __kernel_timespec64_t {
> > > __kernel_time64_t tv_sec;
> > > long long tv_nsec;
> > > };
> > >
> > > at least for ioctls, to avoid the ambiguity with libc headers specifying
> > > something else.
> >
> > This seems hideous from an application standpoint. Application
> > programmers don't want to know, and shouldn't need to know, these
> > silly implementation details that make no sense except as historical
> > baggage. They should just be able to use "struct timespec" everywhere
> > and have it work.
> The kernel does not even know how timespec is defined by libc, and we have
> to at least be able to handle the common cases of timespec being 32/32
> and 64/64 (or 64/32 plus explicit padding). For system calls, we can rely
> on libc calling the syscalls that match the definition (or convert the
> structure as necessary), while for ioctl the command number is chosen
> by the application and has to match the structure definition provided in
> the same header.
>
> In a lot of cases, the ioctl command number is defined (correctly) using the
> _IOR/_IOW macros that take the size of the structure into account, but then
> you also have cases where you get indirect pointers and the size of data
> structure
> passed by the ioctl command is independent of the size of timespec or time_t.
>
> This is not just limited to time_t, we have a lot of data types for which we
> define
> __kernel_*_t types for this purpose, to deal with ioctls that need a specific
> layout independent of what libc uses.
>
> Arnd
>
next prev parent reply other threads:[~2015-02-11 21:09 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20141002155217.GH32147@e104818-lin.cambridge.arm.com>
2015-02-10 18:13 ` Rich Felker
2015-02-11 17:39 ` Catalin Marinas
2015-02-11 19:05 ` Szabolcs Nagy
2015-02-11 19:22 ` [musl] " H.J. Lu
2015-02-11 19:50 ` arnd
2015-02-11 20:12 ` Rich Felker
2015-02-11 20:47 ` Jens Gustedt
2015-02-11 21:02 ` arnd
2015-02-11 21:09 ` arnd [this message]
2015-02-11 21:37 ` [musl] " Rich Felker
2015-02-16 17:20 ` Arnd Bergmann
2015-02-16 17:51 ` [musl] " Rich Felker
2015-02-16 19:38 ` Arnd Bergmann
2015-02-12 8:12 ` Szabolcs Nagy
2015-02-12 17:07 ` Catalin Marinas
2015-02-11 19:21 ` Rich Felker
2015-02-12 18:17 ` Catalin Marinas
2015-02-12 18:59 ` arnd
2015-02-13 13:33 ` Catalin Marinas
2015-02-13 16:30 ` Rich Felker
2015-02-13 17:33 ` Catalin Marinas
2015-02-13 18:37 ` Rich Felker
2015-02-16 14:40 ` Arnd Bergmann
2015-02-16 15:38 ` Rich Felker
2015-02-16 16:54 ` Arnd Bergmann
2015-02-11 18:33 ` H.J. Lu
2015-02-11 19:02 ` Rich Felker
2015-02-11 19:16 ` H.J. Lu
2015-02-11 19:25 ` Rich Felker
2015-02-11 19:34 ` H.J. Lu
2015-02-11 19:47 ` Rich Felker
2015-02-11 19:57 ` H.J. Lu
2015-02-11 20:15 ` Andy Lutomirski
2015-02-12 15:50 ` Catalin Marinas
2015-02-12 16:13 ` Rich Felker
2015-02-12 16:30 ` H.J. Lu
2015-02-12 17:00 ` Rich Felker
2015-02-11 21:41 ` Joseph Myers
2015-02-11 19:04 ` Josiah Worcester
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=2013411126.512657.1423688972986.JavaMail.open-xchange@oxbaltgw09.schlund.de \
--to=arnd@arndb.de \
--cc=Marcus.Shawcroft@arm.com \
--cc=apinski@cavium.com \
--cc=dalias@libc.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=musl@lists.openwall.com \
--cc=nsz@port70.net \
--cc=pinskia@gmail.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).