Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder

Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

On Tue, 2014-08-12 at 17:01 -0700, John Stultz wrote:
[...]
> The downsides here are many. The distros will probably hate this idea,

I certainly hate the idea of adding another 32-bit port to Debian.
I think that it's OK for traditional distros to say 'just upgrade to
64bit' while you solve the problem for 32-bit embedded systems where
there's probably little demand for supporting multiple ABIs at once.

>  as it requires rebuilding the world, and maintaining another legacy
> architecture support. I’m also not completely sure how robust
> multi-arch packaging is in the face of having to handle 3-4
> architectures on one system.

dpkg multiarch covers this just fine, while I believe RPM is limited to
biarch.

> On the kernel side, it also adds more complexity, where we have to add
> even more complex compat support for 64bit systems to handle all the
> various 32bit applications possible.
[...]

Didn't we need to do this already to support x32?  Have compat ioctls
involving time been botched?

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder

[John Stultz]

On 08/12/2014 07:06 PM, Ben Hutchings wrote:
> On Tue, 2014-08-12 at 17:01 -0700, John Stultz wrote:
> [...]
>> The downsides here are many. The distros will probably hate this idea,
> I certainly hate the idea of adding another 32-bit port to Debian.
> I think that it's OK for traditional distros to say 'just upgrade to
> 64bit' while you solve the problem for 32-bit embedded systems where
> there's probably little demand for supporting multiple ABIs at once.

So I don't necessarily disagree, but if the rule really is "we don't
break userspace" we will need a solution that at least allows for
multiple ABIs from the kernel side, and we can then let distros chose if
they want to handle both or not.  Even in the embedded world, as usage
grows with things like Android, we're starting to see more strict needs
for ABI/platform stability (see the ARMv8 SWP discussion from last
month).  Fancy android based dashboard infotainment systems probably
want to both be 2038 safe and run today's unsafe applications (hoping
that they get upgraded eventually).


>
>>  as it requires rebuilding the world, and maintaining another legacy
>> architecture support. I’m also not completely sure how robust
>> multi-arch packaging is in the face of having to handle 3-4
>> architectures on one system.
> dpkg multiarch covers this just fine, while I believe RPM is limited to
> biarch.
>
>> On the kernel side, it also adds more complexity, where we have to add
>> even more complex compat support for 64bit systems to handle all the
>> various 32bit applications possible.
> [...]
>
> Didn't we need to do this already to support x32?  Have compat ioctls
> involving time been botched?
I'm not sure exactly what you mean here, but yea, its very much like
supporting something like x32, but its one more to the list and has to
be supported on both 32 and 64 architectures.

thanks
-john

Re: 2038 Kernel Summit Discussion Fodder

[Joseph S. Myers]

Please include linux-api on such discussions relating to the kernel / 
userspace interface.  I'm likely to pay more attention to them if I 
receive them through linux-api than anything only received through direct 
email.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: 2038 Kernel Summit Discussion Fodder

[Joseph S. Myers]

On Wed, 13 Aug 2014, John Stultz wrote:

> 2) Userspace ABI modifications: This includes how we expose the new 
> 64bit time_t and related structures to userland via syscalls and ioctls, 

Note the point from previous discussions that whenever the kernel takes a 
64-bit timespec value from 32-bit userspace (which should include x32), 
the upper 32 bits of the nanoseconds value should be ignored for POSIX 
compatibility (but maximum compatibility with existing x32 userspace means 
you should still write those bits as 0 when writing such a value out to 
userspace).

> Basically this is the same as the above, where the kernel provides both
> legacy and new time_t related interfaces. However, the libc would make a
> version break, migrating to using 64bit time_t types and syscalls. Legacy
> applications would still work using the old glibc version, but this would
> provide a stronger line in the sand between 2038 safe and unsafe
> applications and libraries, making it easier to avoid mixing the two.
> NetBSD developers discussed this same approach back in 2008 here:
> https://mail-index.netbsd.org/tech-userlevel/2008/03/22/msg000231.html

Given discussions lately of how it's no longer feasible to change the 
libstdc++ soname for C++11 issues 
<https://gcc.gnu.org/ml/gcc/2014-08/msg00107.html> - libstdc++ needs to 
include both old and new ABI versions of all relevant interfaces - I think 
we can assume the same is true to a much greater extent for the libc 
soname (at least on i386).  Much the same conclusion was also reached 
regarding the libc soname on S/390 in discussions of jmp_buf issues.

Technically of course you can have a port variant which does have a 
different soname - and a different GNU triplet - like the transition from 
arm-*-linux-gnu old-ABI to arm-*-linux-gnueabi EABI.  (And in principle 
distributions can allow in-place upgrades - after all, it was done for the 
move from libc5 to libc6.)  But I don't see any likelihood that's what the 
community of users and distributors on i386 would actually want.

Properly done, moving to _TIME_BITS=64 in a distribution would involve 
changing the sonames of lots of affected other libraries (while keeping 
compatibility versions under the old sonames to support existing binaries 
users may have), and it's an open question whether distributors would wish 
to do that either - or whether you get server / desktop distributions 
phasing out 32-bit support by 2038, while only embedded users, with 
control over everything being built for the device and less likelihood of 
having to deal with old binaries from ISVs, build the whole system with a 
_TIME_BITS=64 default.

> 32bit applications on 64bit kernels. In this case, we wouldn't introduce
> new 64 bit syscalls in the kernel, as the existing interfaces would just be
> typed correctly for our new virtual architecture, but we would have

The installed uapi headers would of course need conditionals in them 
(based on whatever preprocessor macro is defined in userspace for the new 
virtual architecture) to export the right ABI for each case.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder

[Arnd Bergmann]

On Wednesday 13 August 2014 03:06:53 Ben Hutchings wrote:
> > On the kernel side, it also adds more complexity, where we have to add
> > even more complex compat support for 64bit systems to handle all the
> > various 32bit applications possible.
> [...]
> 
> Didn't we need to do this already to support x32?  Have compat ioctls
> involving time been botched?

AFAICT, every ioctl that involves passing a __kernel_ulong_t or
__kernel_ulong_t is potentially broken on x32, and this includes
everything passing a time_t or timespec.

The problem is that the libc ioctl() function ends up in the kernel's
compat_ioctl handler, which expects the 32-bit ABI, not the 64-bit ABI.
Most other syscalls in x32 however use the 64-bit ABI.

It works only for drivers that use the same function for .ioctl and
.compat_ioctl, and that encode the size of the data structure correctly
in the ioctl command code. I assume this is how we will do it for all
32-bit architectures with 64-bit time_t, but on x32 it also concerns
other types that use __kernel_long_t.

	Arnd

Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder

[H. Peter Anvin]

On 08/13/2014 01:06 PM, Arnd Bergmann wrote:
> On Wednesday 13 August 2014 03:06:53 Ben Hutchings wrote:
>>> On the kernel side, it also adds more complexity, where we have to add
>>> even more complex compat support for 64bit systems to handle all the
>>> various 32bit applications possible.
>> [...]
>>
>> Didn't we need to do this already to support x32?  Have compat ioctls
>> involving time been botched?
> 
> AFAICT, every ioctl that involves passing a __kernel_ulong_t or
> __kernel_ulong_t is potentially broken on x32, and this includes
> everything passing a time_t or timespec.
> 
> The problem is that the libc ioctl() function ends up in the kernel's
> compat_ioctl handler, which expects the 32-bit ABI, not the 64-bit ABI.
> Most other syscalls in x32 however use the 64-bit ABI.
> 
> It works only for drivers that use the same function for .ioctl and
> .compat_ioctl, and that encode the size of the data structure correctly
> in the ioctl command code. I assume this is how we will do it for all
> 32-bit architectures with 64-bit time_t, but on x32 it also concerns
> other types that use __kernel_long_t.
> 

OK, super-late reply.

Actually we have by and large dealt with that.  Sadly this meant an
increase in the number of paths with conditional ABI.

	-hpa