Message-ID: <4254860.84WuxPQ4j9@wuerfel>
Date:	Mon, 19 May 2014 10:08:18 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Joseph S. Myers" <joseph@...esourcery.com>
Cc:	Chung-Lin Tang <cltang@...esourcery.com>,
	John Stultz <john.stultz@...aro.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Christoph Hellwig <hch@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ley Foon Tan <lftan@...era.com>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	LeyFoon Tan <lftan.linux@...il.com>
Subject: Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

On Thursday 15 May 2014 21:05:03 Joseph S. Myers wrote:
> On Thu, 15 May 2014, Arnd Bergmann wrote:
> 
> > > The distribution side of the change for _FILE_OFFSET_BITS (i.e., moving to 
> > > building libraries that way so a glibc change to the default wouldn't 
> > > cause issues for other libraries' ABIs) has gradually been done.  The 
> > > discussion in March on libc-alpha about changing the default tailed off.  
> > > This is something that needs someone to take the lead with a *careful and 
> > > detailed analysis of the information from the previous discussion* in 
> > > order to present a properly reasoned proposal for a change to the default 
> > > - not scattergun patches, not patches with brief or no analysis of the 
> > > environment in which glibc is used, not dismissing concerns, but a 
> > > properly reasoned argument for why the change should be made, along with 
> > > details of how distributions can determine whether ABI issues would arise 
> > > from rebuilding a particular library against newer glibc.
> > 
> > Ok, I see. I wasn't aware that distributions actually set _FILE_OFFSET_BITS
> > globally for building packages. I guess the effect (from the distro point
> > of view) of that is similar to having a configure option when building glibc
> > as I expected to be the normal way to do it.
> 
> I'm not sure they set it globally (modulo the suggestion in that recent 
> thread that Gentoo might try changing the default and seeing what breaks) 
> - but it at least seems to be set for most libraries for which it affects 
> the ABI (whether upstream or by the distributions), based on the sample 
> Paul Eggert looked at 
> <https://sourceware.org/ml/libc-alpha/2014-03/msg00351.html> (which is an 
> important piece of evidence that a change to the default in glibc wouldn't 
> be dumping a large problem on distributors regarding the ABIs of many 
> widely-used libraries).

I'm mostly worried about the embedded use case, which at least for time_t
would have to build everything the new way as soon as possible. For
desktop and server systems, doing a slow migration to catch the bugs
and never introduce regressions in the field makes a lot of sense,
but when someone today wants to build an embedded system, they already
build everything from source, and it's more important to find all
the bugs now (ideally at compile time) than to have a chance of hitting
a subtle issue 24 years ago on today's build.

For that, it would be nice to even build a glibc that has no backwards
compatibility interfaces for 32-bit time_t at all.

> > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > problematic.
> 
> Yes, we have a glibc bug 
> <https://sourceware.org/bugzilla/show_bug.cgi?id=16437> about the glibc 
> definition (64-bit tv_nsec in x32 userspace to match the kernel's 64-bit 
> "long") being nonconforming, but without the kernel treating upper bits as 
> padding, fixing glibc requires wrappers that copy the value and clear the 
> upper bits.

Ok. There is also work going on to have an x32-like ABI for ARM64, and
that will likely have to support big-endian as well, so then it's not
just about clearing the padding bits, but also having them in the right
place.

I don't know what happens with powerpc64le, but I assume they will also
at some point want to support 32-bit user space if they don't already.

> > For timeval, I think we don't care about the padding, because we wouldn't
> > use it on new interfaces when the kernel uses nanosecond resolution
> > internally.
> 
> Indeed - I haven't checked, but hopefully none of the asm-generic 
> interfaces use timeval (and I was suggesting that only the interfaces 
> present in asm-generic should be duplicated for 64-bit time_t).
> 
> (You also mentioned ioctls.  All affected ioctls would need new variants 
> unless you have a new variant of the ioctl syscall itself.  Logically I 
> suppose _TIME_BITS=64 should then map the generic version of an ioctl to 
> the 64-bit time_t version so applications don't need to change beyond 
> defining _TIME_BITS=64, though I don't know if there's any precedent for 
> doing that sort of thing for definitions in kernel headers rather than 
> glibc's headers.)

For ioctls, it's not that uncommon to change the definition in the kernel
headers to fix bugs, implying we break compatibility between a user space
tool built against new kernel headers but running on older kernels. That
is already the case for any user space relying on newly introduced ioctls,
so we can e.g. introduce a new ioctl command using a
struct __kernel_timespec64 in one of its structs.

Unfortunately, not every driver installs the header files into the user
visible location, some of them have a copy in their (only) user space
tool. This is still fine if we can catch it and if the driver uses
the correct macro to create the ioctl number, which changes the command
code because of the new argument size. The same would be true if we get
a glibc with 64-bit time_t and old kernel headers that use a 'struct
timespec' or 'time_t' in an ioctl data structure and expect that to
use  a 32-bit type. There are probably a small number of those that
also use a malformed command code definition (one that does not take
the structure size into account), and those will cause us problems no
matter what we do.

Another incompatibility is clearly things like include/sound/asound.h
if we decide to change all the structs to use u64 nanosecond timestamps
instead of timespec as we discussed earlier. This means we don't just
have to introduced new command codes but also change all user space
code working with the structs.

The worst case I've found so far is include/linux/if_packet.h, which
uses a memory mapped data structure with 'unsigned int ts_sec'
embedded. It's not possible to translate this at all, and it's also
broken on all 64-bit architectures today. There are already three
versions of that ABI defined though, and I guess there will have to
be another one.

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

Powered by blists - more mailing lists