[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190729212628.GW1506@brightrain.aerifal.cx>
Date: Mon, 29 Jul 2019 17:26:28 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Final (?) time64 proposal
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
