From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14468 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Final (?) time64 proposal Date: Mon, 29 Jul 2019 17:26:28 -0400 Message-ID: <20190729212628.GW1506@brightrain.aerifal.cx> References: <20190724053142.GB1506@brightrain.aerifal.cx> <20190729211154.GV1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="239044"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14484-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 29 23:26:43 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hsDAJ-00105P-2C for gllmg-musl@m.gmane.org; Mon, 29 Jul 2019 23:26:43 +0200 Original-Received: (qmail 19503 invoked by uid 550); 29 Jul 2019 21:26:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 19483 invoked from network); 29 Jul 2019 21:26:40 -0000 Content-Disposition: inline In-Reply-To: <20190729211154.GV1506@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14468 Archived-At: On Mon, Jul 29, 2019 at 05:11:54PM -0400, Rich Felker wrote: > On Wed, Jul 24, 2019 at 01:31:42AM -0400, Rich Felker wrote: > > My plan to go ahead looks like: > > > > [...] > > - struct shmid_ds, msqid_ds, semid_ds layout kept, extended with > > 64-bit time_t's on the ends > > This looks like the unnecessarily painful course of action. I worked > out a grid of all the existing archs' quirks, and except for mips and > mipsn32, all archs admit a solution that's just endian-swapping the > time_t members in-place. > > The mips awfulness is isolated to shmid_ds and semid_ds (not affecting > msqid_ds). It's only shmid_ds where 64-bit time_t actually _doesn't > fit_ in the existing structure (the kernel limits high bits to 16-bit > so it can pack them in the limited available unused space). For > semid_ds, the space is there but it just requires moving one of the > two time_t's. > > My leaning is to just do the endian-swap as needed (whether it's > needed varies by arch, so syscall_arch.h will need to define it) and > make some mechanism whereby mips can provide its own hideous thing to > do instead. For semid_ds, that's probably going to be: > > otime = sem_otime & 0xffffffff | (sem_ctime & 0xfffffff)<<32; > ctime = sem_otime>>32 | sem_ctime & 0xffffffff00000000; > sem_otime = otime; > sem_ctime = ctime; > > and for shmid_ds, it will probably just be adding 3 new time_t's to > the end. > > Note that there's some tradeoff here between ugliness of the internal > code in libc to do the transformations, and ugliness of the public > interface (the structure definitions). I'd really like the public > interface to be what's clean and simple. If I do it this way, it can > be, everywhere but mips, and in fact almost all of the arch-specific > sem.h and shm.h variants for 32-bit archs collapse down to being > identical to the variant common to 64-bit archs. > > > - new definitions of IPC_STAT, SHM_STAT, SHM_STAT_ANY, SEM_STAT, > > SEM_STAT_ANY, MSG_STAT, and MSG_STAT_ANY to expand the shmid_ds, > > semid_ds, and msqid_ds upper and lower time bits from their > > locations in the kernel struct to the new fields at the end. > > I'm still undecided on whether this is better than just wrapping them. > If I go with the above approach for struct layouts, then the generic > compat shims just have to endian-swap the hi/lo 32-bit words of the > time_t fields back -- and copy through a temp object, then memcpy, > since the caller's object may not be aligned suitably for accessing > 64-bit types in-place. Then mips and mipsn32 would have to provide a > custom arch-specific version of the wrappers that, for semctl, invert > the above transformation, and for shmctl, just memcpy a truncated > structure (leaving the undersized fields from the kernel in-place). > > If I go with the new definitions of IPC_STAT, etc., no compat shims or > symbols redirection are needed for ipc *ctl functions (but note: > semtimedop already has a redirection needed, so sys/sem.h will be > aware of them anyway), and it's easy to do the conversions for 64-bit > time_t only if the new cmd numbers are used; it doesn't even need to > be aware of specific commands, just a special bit for "do conversion". > But it does consume a bit of the command number. Lucky find! There's already a bit we can use for this. On 32-bit archs, there's an "IPC_64" bit that has to be set in cmd when making the *ctl syscalls (without it you get some ancient broken form of the result structure), but the bit is not set in the public definitions for IPC_STAT, etc. Rather both musl and glibc or it into the cmd at the time of the syscall. So, we can just redefine IPC_STAT to 0x102, and likewise for the other affected commands, on 32-bit archs using 64-bit time_t. Then the libc code can perform the conversion after the syscall returns with success if and only if the 0x100 bit is set in the caller-passed cmd (which will be the case whenever caller is using 64-bit time_t headers). This solution is really clean, and probably eliminates the need to consider the other with redirects/compat-shims. Rich