Accelerating Y2038 glibc fixes

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Accelerating Y2038 glibc fixes

Wolfgang Denk
Hi all,

this is a somewhat desperate call for help...

We have been trying for some time to help some of our customers to
get patches into glibc to fix the remaining Y2038 issues.

But progress is way too slow...

The problems we are facing are not on a technical level - we believe
we could deal with such.

See for example [1] - there are just 7 lines of "code".  But Joseph
does not accept our patches.  The arguments he gives are not on a
technical level; instead he says that only a native English speaker
who has a with deep understanding of glibc internals and the
previous development process will be capable to provide such a patch
in an acceptable way.

To be honest - I think only himself would fulfill this requirement
good enough.

But Joseph has not enough resources available, and he cannot
allocate more resources even if such efforts would be paid for by
DENX.  And he does not know of anyone to help.

In short, we are stuck, and not even proper funding can accelerate
the process - not to mention, that it's impossible to give any
deadlines at all.


Obviously, this is just my personal and external view - I guess I
must be missing something, because I cannot imagine that the progress
of a project that plays such a central role to the whole FOSS
community suffers from such bottlenecks, and that these cannot be
helped.

Is there anything we can do to accelerate this process?  As
mentioned, we are willing to dedicate both man-power and/or money,
if this helps.

Thanks in advance!

[1] https://patchwork.ozlabs.org/patch/1114061/



Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [hidden email]
An age is called Dark not because  the  light  fails  to  shine,  but
because people refuse to see it.           -- James Michener, "Space"
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Wolfgang Denk
Hi all,

In message <[hidden email]> I wrote:

>
> this is a somewhat desperate call for help...
>
> We have been trying for some time to help some of our customers to
> get patches into glibc to fix the remaining Y2038 issues.
>
> But progress is way too slow...
>
> The problems we are facing are not on a technical level - we believe
> we could deal with such.
>
> See for example [1] - there are just 7 lines of "code".  But Joseph
> does not accept our patches.  The arguments he gives are not on a
> technical level; instead he says that only a native English speaker
> who has a with deep understanding of glibc internals and the
> previous development process will be capable to provide such a patch
> in an acceptable way.
>
> To be honest - I think only himself would fulfill this requirement
> good enough.
>
> But Joseph has not enough resources available, and he cannot
> allocate more resources even if such efforts would be paid for by
> DENX.  And he does not know of anyone to help.
>
> In short, we are stuck, and not even proper funding can accelerate
> the process - not to mention, that it's impossible to give any
> deadlines at all.
>
>
> Obviously, this is just my personal and external view - I guess I
> must be missing something, because I cannot imagine that the progress
> of a project that plays such a central role to the whole FOSS
> community suffers from such bottlenecks, and that these cannot be
> helped.
>
> Is there anything we can do to accelerate this process?  As
> mentioned, we are willing to dedicate both man-power and/or money,
> if this helps.
>
> Thanks in advance!
>
> [1] https://patchwork.ozlabs.org/patch/1114061/

Is there nobody here who has any idea what could be done?

No comments at all?


Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [hidden email]
The only perfect science is hind-sight.
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Siddhesh Poyarekar-8
In reply to this post by Wolfgang Denk
Hello Wolfgang,

I haven't been involved in the Y2038 issue so I cannot comment on the
content or quality of the patches or the way forward in that context.
However I want to assure you that we're collectively trying our best to
review patches that come on the list, just that there aren't enough
hands to help.  glibc is a central project in the Linux ecosystem but
unfortunately it's not as well staffed as other projects such as the
kernel or gcc.  Things have gotten much better in the last few years,
but we're still short of people as many of us are doing other things
alongside glibc.

Hopefully someone with more context and will respond soon and help
unblock things but until then, please don't lose hope, we will get there
eventually!

Siddhesh


On 12/07/19 12:51 PM, Wolfgang Denk wrote:

> See for example [1] - there are just 7 lines of "code".  But Joseph
> does not accept our patches.  The arguments he gives are not on a
> technical level; instead he says that only a native English speaker
> who has a with deep understanding of glibc internals and the
> previous development process will be capable to provide such a patch
> in an acceptable way.
>
> To be honest - I think only himself would fulfill this requirement
> good enough.
>
> But Joseph has not enough resources available, and he cannot
> allocate more resources even if such efforts would be paid for by
> DENX.  And he does not know of anyone to help.
>
> In short, we are stuck, and not even proper funding can accelerate
> the process - not to mention, that it's impossible to give any
> deadlines at all.
>
>
> Obviously, this is just my personal and external view - I guess I
> must be missing something, because I cannot imagine that the progress
> of a project that plays such a central role to the whole FOSS
> community suffers from such bottlenecks, and that these cannot be
> helped.
>
> Is there anything we can do to accelerate this process?  As
> mentioned, we are willing to dedicate both man-power and/or money,
> if this helps.
>
> Thanks in advance!
>
> [1] https://patchwork.ozlabs.org/patch/1114061/
>
>
>
> Best regards,
>
> Wolfgang Denk
>

Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Wolfgang Denk
Dear Siddhesh,

In message <[hidden email]> you wrote:
>
> I haven't been involved in the Y2038 issue so I cannot comment on the
> content or quality of the patches or the way forward in that context.
> However I want to assure you that we're collectively trying our best to
> review patches that come on the list, just that there aren't enough
> hands to help.

Thanks for taking time to read and respond.

I never meant to suggest that you folks are not all trying to do
your best - belive me, I know such a situation very well.  I've been
long enough maintainer of a bigger FOSS project myself (U-Boot)...

> glibc is a central project in the Linux ecosystem but
> unfortunately it's not as well staffed as other projects such as the
> kernel or gcc.  Things have gotten much better in the last few years,
> but we're still short of people as many of us are doing other things
> alongside glibc.

This is something I can understand and accept.  And we're trying to
offer help - both with man-power and with funding.  only nobody
seems to be interested :-(

> Hopefully someone with more context and will respond soon and help
> unblock things but until then, please don't lose hope, we will get there
> eventually!

Thanks!

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [hidden email]
I program, therefore I am.
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Florian Weimer-5
In reply to this post by Wolfgang Denk
* Wolfgang Denk:

> We have been trying for some time to help some of our customers to
> get patches into glibc to fix the remaining Y2038 issues.

> Is there anything we can do to accelerate this process?  As
> mentioned, we are willing to dedicate both man-power and/or money,
> if this helps.

One difficult trade-off is that for you, this is just one-time
enablement work, but the regular contributors will be stuck with the
code you add forever.  Especially since it touches 64-bit architectures
as well.

For me personally, the whole project is quite baffling.  I'm interested
in 32-bit changes only to support legacy binaries, and this is new work
targeting new binaries.  Particularly for i386, it *will* lead to ABI
fragmentation.  We can add dual ABI support for glibc, but for the rest
of the system, distributions will have to pick a default (probably with
their build flags selection), and they will make different choices.
Some distributions will focus on backwards compatibility with legacy
binaries, but others want to keep the i386 architecture alive for many
more years.  I really do not want to deal with the resulting confusion,
but it seems that I do not have any choice there.

Since I'm opposed to this entire project, I have largely refrained from
reviews, except for things that looked obviously wrong to me (e.g.,
things that definitely break compatibility with older kernels or
existing ABIs), but even for those cases, my feedback probably wasn't
very helpful.

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Wolfgang Denk
Dear Florian,

In message <[hidden email]> you wrote:
>
> One difficult trade-off is that for you, this is just one-time
> enablement work, but the regular contributors will be stuck with the
> code you add forever.  Especially since it touches 64-bit architectures
> as well.

I am aware of this, and I'm willing to go all necessary procedures
to get things right.  If someone points out a problem, we can
address it, and move on.  But we haven't seen any progress for a
long time...

> For me personally, the whole project is quite baffling.  I'm interested
> in 32-bit changes only to support legacy binaries, and this is new work
> targeting new binaries.

Indeed it is easy for all the big distros who dropped (at least
commercial) support for 32 bit systems years ago.  But this is only
a fraction of the systems that are affected, and it's not only x86.
There is a zillion of 32 bit ARM, Power architecture and MIPS
devices out there, with more of them being sold for many more years
to come, and many of these are used in products a) with product
lifetimes exceeding Y2038 and b) where being Y2038 clean is a
critical feature.

I think this is part of the problem - the big distros are not really
interested in this work, they see it only as a nuisance to their
business cases.  I cannot stop myself from stating that such an
approach is egotistic at best, if not ignorant, or both.

> Particularly for i386, it *will* lead to ABI
> fragmentation.  We can add dual ABI support for glibc, but for the rest
> of the system, distributions will have to pick a default (probably with
> their build flags selection), and they will make different choices.
> Some distributions will focus on backwards compatibility with legacy
> binaries, but others want to keep the i386 architecture alive for many
> more years.  I really do not want to deal with the resulting confusion,
> but it seems that I do not have any choice there.

As mentioned, it is not only about i386.  There are countless
Embedded Systems running 32 bit ARM, PPC and MIPS systems.

> Since I'm opposed to this entire project, I have largely refrained from
> reviews, except for things that looked obviously wrong to me (e.g.,
> things that definitely break compatibility with older kernels or
> existing ABIs), but even for those cases, my feedback probably wasn't
> very helpful.

I can understand your point of view, but indeed this is not helpful
here.  glibc is a central resource for the whole FOSS system, and we
are not pushing these changes for a fancy, but because a solution
is needed for a large number of affected projects and products.


We need to find a constructive way to proceed with this matter.  It
will not go away if we try to ignore it.

Thanks.


Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [hidden email]
"Text processing has made it possible to right-justify any idea, even
one which cannot be justified on any other grounds."
                                                 -- J. Finnegan, USC.
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Florian Weimer-5
* Wolfgang Denk:

> In message <[hidden email]> you wrote:
>>
>> One difficult trade-off is that for you, this is just one-time
>> enablement work, but the regular contributors will be stuck with the
>> code you add forever.  Especially since it touches 64-bit architectures
>> as well.
>
> I am aware of this, and I'm willing to go all necessary procedures
> to get things right.  If someone points out a problem, we can
> address it, and move on.  But we haven't seen any progress for a
> long time...

This is not what I meant, or maybe I'm misunderstanding you.  Are you
offering a long-term collaboration on a varied range of topics?  Or just
this one contribution of a single feature?

>> For me personally, the whole project is quite baffling.  I'm interested
>> in 32-bit changes only to support legacy binaries, and this is new work
>> targeting new binaries.
>
> Indeed it is easy for all the big distros who dropped (at least
> commercial) support for 32 bit systems years ago.

Red Hat still supports 32-bit legacy applications.  I'm sure SUSE does
as well.

Newer operating system releases do not come with a 32-bit kernel
anymore, but we have a 32-bit userspace (mostly consisting of libraries
to support existing legacy application), so we still need glibc.

> I think this is part of the problem - the big distros are not really
> interested in this work, they see it only as a nuisance to their
> business cases.  I cannot stop myself from stating that such an
> approach is egotistic at best, if not ignorant, or both.

I would even go one step further: For i386, the upcoming ABI
fragmentation impacts our users even if they are never going to use the
new capabilities.

There also appears to be an expectation that all applications which
invoke the futex system call directly need to be changed at the source
code level.  This will affect many upstream projects, even if they
primarily target 64-bit architectures.

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Andrew Pinski-3
On Tue, Jul 16, 2019 at 8:09 AM Florian Weimer <[hidden email]> wrote:

>
> * Wolfgang Denk:
>
> > In message <[hidden email]> you wrote:
> >>
> >> One difficult trade-off is that for you, this is just one-time
> >> enablement work, but the regular contributors will be stuck with the
> >> code you add forever.  Especially since it touches 64-bit architectures
> >> as well.
> >
> > I am aware of this, and I'm willing to go all necessary procedures
> > to get things right.  If someone points out a problem, we can
> > address it, and move on.  But we haven't seen any progress for a
> > long time...
>
> This is not what I meant, or maybe I'm misunderstanding you.  Are you
> offering a long-term collaboration on a varied range of topics?  Or just
> this one contribution of a single feature?
>
> >> For me personally, the whole project is quite baffling.  I'm interested
> >> in 32-bit changes only to support legacy binaries, and this is new work
> >> targeting new binaries.
> >
> > Indeed it is easy for all the big distros who dropped (at least
> > commercial) support for 32 bit systems years ago.
>
> Red Hat still supports 32-bit legacy applications.  I'm sure SUSE does
> as well.
>
> Newer operating system releases do not come with a 32-bit kernel
> anymore, but we have a 32-bit userspace (mostly consisting of libraries
> to support existing legacy application), so we still need glibc.

I should point out a recent case where Ubuntu mentioned they would be
removing the 32bit userspace and some closed source commerical
software (Steam) said they would be pulling support for Ubuntu.  This
forced Ubuntu to change their mind.
This happened within the last few weeks.  I don't know if this is
something we as glibc project as to worry about but it does give
second thoughts to the bigger distros at removing 32bit userland
support or even supporting a new framented ABI.

Thanks,
Andrew Pinski

>
> > I think this is part of the problem - the big distros are not really
> > interested in this work, they see it only as a nuisance to their
> > business cases.  I cannot stop myself from stating that such an
> > approach is egotistic at best, if not ignorant, or both.
>
> I would even go one step further: For i386, the upcoming ABI
> fragmentation impacts our users even if they are never going to use the
> new capabilities.
>
> There also appears to be an expectation that all applications which
> invoke the futex system call directly need to be changed at the source
> code level.  This will affect many upstream projects, even if they
> primarily target 64-bit architectures.
>
> Thanks,
> Florian
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Arnd Bergmann
In reply to this post by Wolfgang Denk
On Tue, Jul 16, 2019 at 4:52 PM Wolfgang Denk <[hidden email]> wrote:

> In message <[hidden email]> you wrote:
>
> > Since I'm opposed to this entire project, I have largely refrained from
> > reviews, except for things that looked obviously wrong to me (e.g.,
> > things that definitely break compatibility with older kernels or
> > existing ABIs), but even for those cases, my feedback probably wasn't
> > very helpful.
>
> I can understand your point of view, but indeed this is not helpful
> here.  glibc is a central resource for the whole FOSS system, and we
> are not pushing these changes for a fancy, but because a solution
> is needed for a large number of affected projects and products.
>
> We need to find a constructive way to proceed with this matter.  It
> will not go away if we try to ignore it.

My impression is that we have two mostly separate groups
of users for 32-bit user space:

a) Those that absolutely require 100% ABI compatibility to run
    legacy code but will eventually migrate to 64-bit user space,
    almost certainly within the coming ten years before we really
    need to worry (too much) about things like key expiration dates
    beyond 2038.

b) Those that already need support for 64-bit time_t because
    they are deploying new 32-bit binaries that are expected to run
    beyond 2038, while not caring at all about compatibility
    with existing binaries that are already known to be broken
    for this purpose.

If we just work to satisfy both these groups but ignore the intersection
(those that have existing 32-bit binaries and want those to run
after 2038?), things could become noticeably easier.

The price for that is a mid-2030s EOL time on any existing 32-bit
glibc ports, any binaries linked to them, and any distros built upon
that, and replacing them with something else that is binary
incompatible but can coexist within e.g. a container.

There are several options what such a replacement might look
like, some that come to mind would include:

- A patchset against glibc that replaces all the time32 interfaces
  with time64 ones and that is maintained outside of the glibc
  code base by whoever is interested in this working.

- A set of glibc architecture ports that can coexist with the
  existing ports but have new target triples and/or soname.
  These could be implemented and merged one architecture
  at a time and share most of the code with the existing
  ports.

- Leave glibc unchanged and require users/distros to migrate to
  musl or something else if they need the time64 support.

Any of the above approaches (including the current plan of
supporting time32 and time64 in a single glibc binary) can of
coexist, but the more incompatible approaches get implemented,
the more fragmentation of ABIs we get.

Note that we have never had such a forced transition on x86, but
there are several examples on other architectures:
- arm oabi/gnueabi/gnueabihf
- ppc64/ppc64le
- mips o32/n32/64
The migration is not much fun for users to say the least, but it's
quite possible that the alternative is even worse.

       Arnd
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Florian Weimer-5
* Arnd Bergmann:

> b) Those that already need support for 64-bit time_t because
>     they are deploying new 32-bit binaries that are expected to run
>     beyond 2038, while not caring at all about compatibility
>     with existing binaries that are already known to be broken
>     for this purpose.

There is also c), new 32-bit architectures which need 64-bit time_t
support today due to kernel limitations.  Whether those binaries need to
run for two years or twenty does not matter to them.

I have reviewed patches for the c) case, but that doesn't seem to be
work that interests Wolfgang.

> Any of the above approaches (including the current plan of
> supporting time32 and time64 in a single glibc binary) can of
> coexist, but the more incompatible approaches get implemented,
> the more fragmentation of ABIs we get.
>
> Note that we have never had such a forced transition on x86,

We did change the stack alignment requirements on x86.  Without any ABI
markup.  For the non-executable stack, we used proper markup, but hat
approach will not work for time_t.

Several of the transitions you mentioned have ELF markup for the
transition, and at least in the case of ELF v2 for POWER, it is really
clear and consistent (it's also an easy scenarion admittedly, and very
different from the time_t situation).

Part of my reservations about the update to legacy ABIs is there hasn't
been any discussion about markup.  I'm not saying that we absolutely
need to have it.  It's just something that contributes to my general
unease.

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Wolfgang Denk
Dear Florian,

In message <[hidden email]> you wrote:

> * Arnd Bergmann:
>
> > b) Those that already need support for 64-bit time_t because
> >     they are deploying new 32-bit binaries that are expected to run
> >     beyond 2038, while not caring at all about compatibility
> >     with existing binaries that are already known to be broken
> >     for this purpose.
>
> There is also c), new 32-bit architectures which need 64-bit time_t
> support today due to kernel limitations.  Whether those binaries need to
> run for two years or twenty does not matter to them.
>
> I have reviewed patches for the c) case, but that doesn't seem to be
> work that interests Wolfgang.

Correct - our situation is Arnd's case b).

But my understanding is that for c) glibc has to modify the generic
syscalls wrapper (like clock_gettime/nanosleep/settime, etc.), and
for b) we also need to do that first.  But currently we are stuck at
the point where the __ASSUME_TIME64_SYSCALLS flag is not accepted /
pulled.

So b) and c) align in development...

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [hidden email]
An Elephant is a mouse with an Operating System.              - Knuth
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Florian Weimer-5
* Wolfgang Denk:

> Dear Florian,
>
> In message <[hidden email]> you wrote:
>> * Arnd Bergmann:
>>
>> > b) Those that already need support for 64-bit time_t because
>> >     they are deploying new 32-bit binaries that are expected to run
>> >     beyond 2038, while not caring at all about compatibility
>> >     with existing binaries that are already known to be broken
>> >     for this purpose.
>>
>> There is also c), new 32-bit architectures which need 64-bit time_t
>> support today due to kernel limitations.  Whether those binaries need to
>> run for two years or twenty does not matter to them.
>>
>> I have reviewed patches for the c) case, but that doesn't seem to be
>> work that interests Wolfgang.
>
> Correct - our situation is Arnd's case b).
>
> But my understanding is that for c) glibc has to modify the generic
> syscalls wrapper (like clock_gettime/nanosleep/settime, etc.), and
> for b) we also need to do that first.  But currently we are stuck at
> the point where the __ASSUME_TIME64_SYSCALLS flag is not accepted /
> pulled.
>
> So b) and c) align in development...

Can you do without __ASSUME_TIME64_SYSCALLS?  Most other __ASSUME_*
macros are an optimization, and if your interest is b),
__ASSUME_TIME64_SYSCALLS will not be the default for glibc distribution
builds anyway because defining it would negatively impact host kernel
compatibility.  It's not just about containers in the fashionable sense,
but simple build chroots are problematic as well in this context.

Or have you received different guidance that __ASSUME_TIME64_SYSCALLS
markup is absolutely required for the initial contribution?

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Lukasz Majewski
Hi Florian,

> * Wolfgang Denk:
>
> > Dear Florian,
> >
> > In message <[hidden email]> you wrote:  
> >> * Arnd Bergmann:
> >>  
> >> > b) Those that already need support for 64-bit time_t because
> >> >     they are deploying new 32-bit binaries that are expected to
> >> > run beyond 2038, while not caring at all about compatibility
> >> >     with existing binaries that are already known to be broken
> >> >     for this purpose.  
> >>
> >> There is also c), new 32-bit architectures which need 64-bit time_t
> >> support today due to kernel limitations.  Whether those binaries
> >> need to run for two years or twenty does not matter to them.
> >>
> >> I have reviewed patches for the c) case, but that doesn't seem to
> >> be work that interests Wolfgang.  
> >
> > Correct - our situation is Arnd's case b).
> >
> > But my understanding is that for c) glibc has to modify the generic
> > syscalls wrapper (like clock_gettime/nanosleep/settime, etc.), and
> > for b) we also need to do that first.  But currently we are stuck at
> > the point where the __ASSUME_TIME64_SYSCALLS flag is not accepted /
> > pulled.
> >
> > So b) and c) align in development...  
>
> Can you do without __ASSUME_TIME64_SYSCALLS?  Most other __ASSUME_*
> macros are an optimization, and if your interest is b),
> __ASSUME_TIME64_SYSCALLS will not be the default for glibc
> distribution builds anyway because defining it would negatively
> impact host kernel compatibility.  It's not just about containers in
> the fashionable sense, but simple build chroots are problematic as
> well in this context.
>
> Or have you received different guidance that __ASSUME_TIME64_SYSCALLS
> markup is absolutely required for the initial contribution?
The __ASSUME_TIME64_SYSCALLS was discussed with Joseph and Stepan (both
CC'ed) for a long time on the libc-alpha mailing list. The discussion
can be found here [1] (last link is the newest one).



As fair as I understood from the previous discussion, adding
__ASSUME_TIME64_SYSCALLS is a first step to add Y2038 support (or 64 bit
time support to 32 bit archs in general).

The latest patch (v8) with semantics explanation of
__ASSUME_TIME64_SYSCALLS: [2]



Note:

[1] Evolution of __ASSUME_TIME64_SYSCALLS up till v7:

https://patchwork.ozlabs.org/patch/1092579/
https://patchwork.ozlabs.org/patch/1096343/
https://patchwork.ozlabs.org/patch/1096349/
https://patchwork.ozlabs.org/patch/1097132/
https://patchwork.ozlabs.org/patch/1100097/
https://patchwork.ozlabs.org/patch/1107125/
https://patchwork.ozlabs.org/patch/1114061/
https://patchwork.ozlabs.org/patch/1117100/

[2] - https://patchwork.ozlabs.org/patch/1117100/

>
> Thanks,
> Florian




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: [hidden email]

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Rich Felker-2
In reply to this post by Arnd Bergmann
On Wed, Jul 17, 2019 at 04:15:25PM +0200, Arnd Bergmann wrote:

> On Tue, Jul 16, 2019 at 4:52 PM Wolfgang Denk <[hidden email]> wrote:
> > In message <[hidden email]> you wrote:
> >
> > > Since I'm opposed to this entire project, I have largely refrained from
> > > reviews, except for things that looked obviously wrong to me (e.g.,
> > > things that definitely break compatibility with older kernels or
> > > existing ABIs), but even for those cases, my feedback probably wasn't
> > > very helpful.
> >
> > I can understand your point of view, but indeed this is not helpful
> > here.  glibc is a central resource for the whole FOSS system, and we
> > are not pushing these changes for a fancy, but because a solution
> > is needed for a large number of affected projects and products.
> >
> > We need to find a constructive way to proceed with this matter.  It
> > will not go away if we try to ignore it.
>
> My impression is that we have two mostly separate groups
> of users for 32-bit user space:
>
> a) Those that absolutely require 100% ABI compatibility to run
>     legacy code but will eventually migrate to 64-bit user space,
>     almost certainly within the coming ten years before we really
>     need to worry (too much) about things like key expiration dates
>     beyond 2038.
>
> b) Those that already need support for 64-bit time_t because
>     they are deploying new 32-bit binaries that are expected to run
>     beyond 2038, while not caring at all about compatibility
>     with existing binaries that are already known to be broken
>     for this purpose.
>
> If we just work to satisfy both these groups but ignore the intersection
> (those that have existing 32-bit binaries and want those to run
> after 2038?), things could become noticeably easier.

Well it replaces one sticky problem with two separate, individually
easier problems. But I'm not sure it reduces the overall amount of
work needed; it might increase it.

The above roughly corresponds to what my original idea for musl and
the ".2 ABI" was, and I'm now fairly skeptical of it. Binary distros
are probably not going to want to expend extra effort to satisfy the
needs of both groups, so they'll either EOL the 32-bit ports they have
now (effectively leaving group (a) screwed, not because glibc dropped
them, but because their distro did) to produce something that will
continue to be relevant into the future, or they'll stick with the old
ABI and EOL 32-bit entirely in the near-ish future.

The segment of group (b) that's building everything themselves
probably doesn't care in the latter case, but then do they even care
about using glibc (vs something else) anyway?

From this analysis it seems like, if you attack the problems
separately, "no action" is the right choice for distros, but that also
leads to EOL for distro support of all existing 32-bit targets.

As a result, I'm leaning strongly towards a conclusion that a solution
that doesn't split the two cases is better, and it's probably what
we'll do for musl.

> The price for that is a mid-2030s EOL time on any existing 32-bit

That's really wishful thinking. I suspect we'll hit critical failures
much sooner due to need to represent dates in the future.

> glibc ports, any binaries linked to them, and any distros built upon
> that, and replacing them with something else that is binary
> incompatible but can coexist within e.g. a container.

I'm not sure how "coexist within a container" is helpful; that might
as well just be a separate system. Multi-arch type approaches might
work a little bit better, but in order for these to be useful to end
users, there need to be automated ways of setting them up. That's a
big burden for distros to spend on archs that many of them would
rather just EOL/drop...

> There are several options what such a replacement might look
> like, some that come to mind would include:
>
> - A patchset against glibc that replaces all the time32 interfaces
>   with time64 ones and that is maintained outside of the glibc
>   code base by whoever is interested in this working.

If you're trying to use incompatible old and new ABI alongside each
other, I would think you only want to do that as long as you still
have old stuff around. But if you're using patches with ad-hoc ABI
that have bypassed the process of upstream review to ensure that
they're making good decisions compatible with the long term, it's
likely that it's going to keep breaking ABI, and you're going to need
to do multiple painful replacements or keep N ABIs alongside each
other rather than 2 (possibly using something like nix to make it
practical).

So I don't think "use out-of-tree patches for time64 support" is a
good approach.

> - A set of glibc architecture ports that can coexist with the
>   existing ports but have new target triples and/or soname.
>   These could be implemented and merged one architecture
>   at a time and share most of the code with the existing
>   ports.

This is basically the same proposal as the musl ".2 ABI", and it's one
of the least-bad, but as explained above I no longer really favor it.

> - Leave glibc unchanged and require users/distros to migrate to
>   musl or something else if they need the time64 support.

As much as I'd like this, I don't think distros that have stability
contracts with their users for how things work can replace the libc
with one which has significantly different behaviors in application-
and user-facing ways. It's a viable solution for users to run new
32-bit stuff alongside a 32-bit glibc target that's being phased-out
and nearing EOL, but if this is the only option I think it would just
lead to distros dropping the targets.

> Any of the above approaches (including the current plan of
> supporting time32 and time64 in a single glibc binary) can of
> coexist, but the more incompatible approaches get implemented,
> the more fragmentation of ABIs we get.

I'm moderately in favor of supporting both in a single binary. As
noted elsewhere, this fundamentally does not break ABI between libc
consumers (main apps or 3rd party libs) and libc, only between pairs
of libc consumers that have used the affected types as part of their
public interfaces.

To answer Wolfgang Denk's original question, in my opinion, the single
most valuable thing for accelerating the time64 process that third
parties could contribute is detailed analysis of the interfaces that
will break. This (1) will give us an idea of the extent of breakage
that could happen in the worst case, and (2) can be translated
directly into a graph of "requires/conflicts-with" relationships
between library packages that a distro can use to ensure consistency
when updating packages.

Are others willing to start a discussion of exactly what form this
analysis should take, how results should be reported, and how to use
them to make such a transition go smoothly?

> Note that we have never had such a forced transition on x86, but
> there are several examples on other architectures:
> - arm oabi/gnueabi/gnueabihf
> - ppc64/ppc64le
> - mips o32/n32/64
> The migration is not much fun for users to say the least, but it's
> quite possible that the alternative is even worse.

I wouldn't characterize all of those as transitions, more as different
options. As far as I know glibc still supports them all except ARM
OABI, which was dropped long before there was serious interest in
end-user-facing Linux on ARM.

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Lukasz Majewski
Hi Rich,

Thanks for sharing your view.

> On Wed, Jul 17, 2019 at 04:15:25PM +0200, Arnd Bergmann wrote:
> > On Tue, Jul 16, 2019 at 4:52 PM Wolfgang Denk <[hidden email]> wrote:  
> > > In message <[hidden email]> you wrote:
> > >  
> > > > Since I'm opposed to this entire project, I have largely
> > > > refrained from reviews, except for things that looked obviously
> > > > wrong to me (e.g., things that definitely break compatibility
> > > > with older kernels or existing ABIs), but even for those cases,
> > > > my feedback probably wasn't very helpful.  
> > >
> > > I can understand your point of view, but indeed this is not
> > > helpful here.  glibc is a central resource for the whole FOSS
> > > system, and we are not pushing these changes for a fancy, but
> > > because a solution is needed for a large number of affected
> > > projects and products.
> > >
> > > We need to find a constructive way to proceed with this matter.
> > > It will not go away if we try to ignore it.  
> >
> > My impression is that we have two mostly separate groups
> > of users for 32-bit user space:
> >
> > a) Those that absolutely require 100% ABI compatibility to run
> >     legacy code but will eventually migrate to 64-bit user space,
> >     almost certainly within the coming ten years before we really
> >     need to worry (too much) about things like key expiration dates
> >     beyond 2038.
> >
> > b) Those that already need support for 64-bit time_t because
> >     they are deploying new 32-bit binaries that are expected to run
> >     beyond 2038, while not caring at all about compatibility
> >     with existing binaries that are already known to be broken
> >     for this purpose.
> >
> > If we just work to satisfy both these groups but ignore the
> > intersection (those that have existing 32-bit binaries and want
> > those to run after 2038?), things could become noticeably easier.  
>
> Well it replaces one sticky problem with two separate, individually
> easier problems. But I'm not sure it reduces the overall amount of
> work needed; it might increase it.
>
> The above roughly corresponds to what my original idea for musl and
> the ".2 ABI" was, and I'm now fairly skeptical of it. Binary distros
> are probably not going to want to expend extra effort to satisfy the
> needs of both groups, so they'll either EOL the 32-bit ports they have
> now (effectively leaving group (a) screwed, not because glibc dropped
> them, but because their distro did) to produce something that will
> continue to be relevant into the future, or they'll stick with the old
> ABI and EOL 32-bit entirely in the near-ish future.
>
> The segment of group (b) that's building everything themselves
> probably doesn't care in the latter case, but then do they even care
> about using glibc (vs something else) anyway?
If I may add my 2$ - I think they care. Otherwise there wouldn't be the
effort to adapt "upstream first" policy with Y2038 support.

>
> From this analysis it seems like, if you attack the problems
> separately, "no action" is the right choice for distros, but that also
> leads to EOL for distro support of all existing 32-bit targets.

But as it was mentioned in the other mail. There are _real_ users of 32
bit targets, so distros may re-consider dropping them.

>
> As a result, I'm leaning strongly towards a conclusion that a solution
> that doesn't split the two cases is better, and it's probably what
> we'll do for musl.

The approach would be very similar to what was done with
_FILE_OFFSET_BITS==64. The end user would need to add -D_TIME_BITS==64
when compiling programs against glibc on 32 bit architecture.

>
> > The price for that is a mid-2030s EOL time on any existing 32-bit  
>
> That's really wishful thinking. I suspect we'll hit critical failures
> much sooner due to need to represent dates in the future.
>
> > glibc ports, any binaries linked to them, and any distros built upon
> > that, and replacing them with something else that is binary
> > incompatible but can coexist within e.g. a container.  
>
> I'm not sure how "coexist within a container" is helpful; that might
> as well just be a separate system.
> 1 Multi-arch type approaches might
> work a little bit better, but in order for these to be useful to end
> users, there need to be automated ways of setting them up. That's a
> big burden for distros to spend on archs that many of them would
> rather just EOL/drop...
>
> > There are several options what such a replacement might look
> > like, some that come to mind would include:
> >
> > - A patchset against glibc that replaces all the time32 interfaces
> >   with time64 ones and that is maintained outside of the glibc
> >   code base by whoever is interested in this working.  
>
> If you're trying to use incompatible old and new ABI alongside each
> other, I would think you only want to do that as long as you still
> have old stuff around. But if you're using patches with ad-hoc ABI
> that have bypassed the process of upstream review to ensure that
> they're making good decisions compatible with the long term, it's
> likely that it's going to keep breaking ABI, and you're going to need
> to do multiple painful replacements or keep N ABIs alongside each
> other rather than 2 (possibly using something like nix to make it
> practical).
>
> So I don't think "use out-of-tree patches for time64 support" is a
> good approach.
I do agree here - the "out-of-tree" is not a good approach. Basically
one would need to rebase those "hacks" on top of each glibc release.

If you are wondering how such set of "out-of-tree" patches ("hacks" is
a better word I think) look like - please check following link [1].

They provide support for Y2038 on 32 bit arch (and even passes some
tests) [2].

>
> > - A set of glibc architecture ports that can coexist with the
> >   existing ports but have new target triples and/or soname.
> >   These could be implemented and merged one architecture
> >   at a time and share most of the code with the existing
> >   ports.  
>
> This is basically the same proposal as the musl ".2 ABI", and it's one
> of the least-bad, but as explained above I no longer really favor it.
>
> > - Leave glibc unchanged and require users/distros to migrate to
> >   musl or something else if they need the time64 support.  
>
> As much as I'd like this, I don't think distros that have stability
> contracts with their users for how things work can replace the libc
> with one which has significantly different behaviors in application-
> and user-facing ways.
+1

> It's a viable solution for users to run new
> 32-bit stuff alongside a 32-bit glibc target that's being phased-out
> and nearing EOL, but if this is the only option I think it would just
> lead to distros dropping the targets.
>
> > Any of the above approaches (including the current plan of
> > supporting time32 and time64 in a single glibc binary) can of
> > coexist, but the more incompatible approaches get implemented,
> > the more fragmentation of ABIs we get.  
>
> I'm moderately in favor of supporting both in a single binary. As
> noted elsewhere, this fundamentally does not break ABI between libc
> consumers (main apps or 3rd party libs) and libc, only between pairs
> of libc consumers that have used the affected types as part of their
> public interfaces.
As I've written above. For the end user it shall be enough to add
-D_TIME_BITS==64 during compilation.

>
> To answer Wolfgang Denk's original question, in my opinion, the single
> most valuable thing for accelerating the time64 process that third
> parties could contribute is detailed analysis of the interfaces that
> will break.

Such analysis is already done and available on glib'c wiki page [3].

> This (1) will give us an idea of the extent of breakage
> that could happen in the worst case, and (2) can be translated
> directly into a graph of "requires/conflicts-with" relationships
> between library packages that a distro can use to ensure consistency
> when updating packages.

As stated above - please visit [3].

>
> Are others willing to start a discussion of exactly what form this
> analysis should take, how results should be reported, and how to use
> them to make such a transition go smoothly?

There is even the OE/Yocto's meta-y2038 layer (thud YPRR) [4] , which
allows building glibc for testing with:

1. Kernel 5.1+ (with 64 bit time syscalls support on 32 bit archs).

2. Kernel < 5.1 (to check if it works with older syscalls)

3. A set of tests for syscalls mentioned in [3][2] (with and without
Y2038 support in glibc)

4. Several different architectures for testing (qemu):
        - ARM 32 bit - vexpress-a9
        - i386 / x86_64
        - x32 - the "special" one
        - All the OE/Yocto supported qemu* targets (mips, ppc)


5. One can run the glibc xtest with mentioned above qemu running system
with test-wrapper='/opt/Y2038/glibc/src/scripts/cross-test-ssh.sh
(detailed instruction in [4]).

6. It is also possible to run plain glibc tests for archs mentioned in
point 4 above.

>
> > Note that we have never had such a forced transition on x86, but
> > there are several examples on other architectures:
> > - arm oabi/gnueabi/gnueabihf
> > - ppc64/ppc64le
> > - mips o32/n32/64
> > The migration is not much fun for users to say the least, but it's
> > quite possible that the alternative is even worse.  
>
> I wouldn't characterize all of those as transitions, more as different
> options. As far as I know glibc still supports them all except ARM
> OABI, which was dropped long before there was serious interest in
> end-user-facing Linux on ARM.
>
> Rich

Note:

[1] -
https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-11-03-2019

[2] - https://github.com/lmajewski/y2038-tests

[3] -
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?highlight=%28y2038%29

[4] - https://github.com/lmajewski/meta-y2038/tree/master


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: [hidden email]

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Rich Felker-2
On Wed, Jul 17, 2019 at 11:57:48PM +0200, Lukasz Majewski wrote:
> > As a result, I'm leaning strongly towards a conclusion that a solution
> > that doesn't split the two cases is better, and it's probably what
> > we'll do for musl.
>
> The approach would be very similar to what was done with
> _FILE_OFFSET_BITS==64. The end user would need to add -D_TIME_BITS==64
> when compiling programs against glibc on 32 bit architecture.

Yes, except that I'd switch the default from the beginning. glibc made
the mistake of not doing this with _FILE_OFFSET_BITS, and it's still
the wrong default 20 years later, with every application's build
system containing workarounds...

> > It's a viable solution for users to run new
> > 32-bit stuff alongside a 32-bit glibc target that's being phased-out
> > and nearing EOL, but if this is the only option I think it would just
> > lead to distros dropping the targets.
> >
> > > Any of the above approaches (including the current plan of
> > > supporting time32 and time64 in a single glibc binary) can of
> > > coexist, but the more incompatible approaches get implemented,
> > > the more fragmentation of ABIs we get.  
> >
> > I'm moderately in favor of supporting both in a single binary. As
> > noted elsewhere, this fundamentally does not break ABI between libc
> > consumers (main apps or 3rd party libs) and libc, only between pairs
> > of libc consumers that have used the affected types as part of their
> > public interfaces.
>
> As I've written above. For the end user it shall be enough to add
> -D_TIME_BITS==64 during compilation.

I think you missed the whole thing about ABI between pairs of libc
consumers...

> > To answer Wolfgang Denk's original question, in my opinion, the single
> > most valuable thing for accelerating the time64 process that third
> > parties could contribute is detailed analysis of the interfaces that
> > will break.
>
> Such analysis is already done and available on glib'c wiki page [3].

...because there's no such analysis here. Such analysis is basically a
grep -r of /usr/include on a Debian system with *-dev installed,
combined with some automated analysis of what packages depend on each
matching package's library, then manual analysis to determine impact
(and in many cases, whether the lib is even a real lib that's used by
multiple programs rather than just by the program it ships with).

Arnd sent me a really preliminary grep like this a couple weeks ago,
but doing it right is going to take a lot more time.

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Lukasz Majewski
Hi Rich,

> On Wed, Jul 17, 2019 at 11:57:48PM +0200, Lukasz Majewski wrote:
> > > As a result, I'm leaning strongly towards a conclusion that a
> > > solution that doesn't split the two cases is better, and it's
> > > probably what we'll do for musl.  
> >
> > The approach would be very similar to what was done with
> > _FILE_OFFSET_BITS==64. The end user would need to add
> > -D_TIME_BITS==64 when compiling programs against glibc on 32 bit
> > architecture.  
>
> Yes, except that I'd switch the default from the beginning. glibc made
> the mistake of not doing this with _FILE_OFFSET_BITS, and it's still
> the wrong default 20 years later, with every application's build
> system containing workarounds...
>
> > > It's a viable solution for users to run new
> > > 32-bit stuff alongside a 32-bit glibc target that's being
> > > phased-out and nearing EOL, but if this is the only option I
> > > think it would just lead to distros dropping the targets.
> > >  
> > > > Any of the above approaches (including the current plan of
> > > > supporting time32 and time64 in a single glibc binary) can of
> > > > coexist, but the more incompatible approaches get implemented,
> > > > the more fragmentation of ABIs we get.    
> > >
> > > I'm moderately in favor of supporting both in a single binary. As
> > > noted elsewhere, this fundamentally does not break ABI between
> > > libc consumers (main apps or 3rd party libs) and libc, only
> > > between pairs of libc consumers that have used the affected types
> > > as part of their public interfaces.  
> >
> > As I've written above. For the end user it shall be enough to add
> > -D_TIME_BITS==64 during compilation.  
>
> I think you missed the whole thing about ABI between pairs of libc
> consumers...
You are probably right, as I'm now biased to the systems where the
Y2038 safe BSP is build with OE/Yocto and deployed (the "self containing
release").

Thanks for extra explanation.

>
> > > To answer Wolfgang Denk's original question, in my opinion, the
> > > single most valuable thing for accelerating the time64 process
> > > that third parties could contribute is detailed analysis of the
> > > interfaces that will break.  
> >
> > Such analysis is already done and available on glib'c wiki page
> > [3].  
>
> ...because there's no such analysis here. Such analysis is basically a
> grep -r of /usr/include on a Debian system with *-dev installed,
> combined with some automated analysis of what packages depend on each
> matching package's library, then manual analysis to determine impact
> (and in many cases, whether the lib is even a real lib that's used by
> multiple programs rather than just by the program it ships with).
>
> Arnd sent me a really preliminary grep like this a couple weeks ago,
> but doing it right is going to take a lot more time.
Is this script available somewhere? I'm wondering if I could adapt it
(and run) to meta-y2038?

>
> Rich




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: [hidden email]

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Rich Felker-2
On Thu, Jul 18, 2019 at 09:20:48AM +0200, Lukasz Majewski wrote:

> > > > To answer Wolfgang Denk's original question, in my opinion, the
> > > > single most valuable thing for accelerating the time64 process
> > > > that third parties could contribute is detailed analysis of the
> > > > interfaces that will break.  
> > >
> > > Such analysis is already done and available on glib'c wiki page
> > > [3].  
> >
> > ...because there's no such analysis here. Such analysis is basically a
> > grep -r of /usr/include on a Debian system with *-dev installed,
> > combined with some automated analysis of what packages depend on each
> > matching package's library, then manual analysis to determine impact
> > (and in many cases, whether the lib is even a real lib that's used by
> > multiple programs rather than just by the program it ships with).
> >
> > Arnd sent me a really preliminary grep like this a couple weeks ago,
> > but doing it right is going to take a lot more time.
>
> Is this script available somewhere? I'm wondering if I could adapt it
> (and run) to meta-y2038?

See this thread: https://www.openwall.com/lists/musl/2019/07/02/2

Again, the point here is identifying libraries that have
time_t-derived structures as part of their public APIs, since that
means their *ABIs* are functions of how time_t is defined. There are
fairly many, but there's also good reason to believe that lots of them
aren't actually "public" in any meaningful sense.

Assuming the list is produced correctly and is complete, updating
these in sync with the apps (or other libs) that consume them avoids
any breakage, and is a much smaller task than replacing the whole
binary ecosystem all at once.

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Rich Felker-2
In reply to this post by Lukasz Majewski
On Wed, Jul 17, 2019 at 11:57:48PM +0200, Lukasz Majewski wrote:
Some findings here that need correction:

[1] is completely missing the sysvipc interfaces affected, and [3]
fails to document them as affected because the structs are variadic
arguments not declared ones. Fortunately, this means we can get away
without actually replacing the functions, and instead define new
command numbers to perform the translation. When doing this, glibc
should follow musl and correct other bugs in these structs: for
example, struct ipc_perm's mode field has the wrong type on some archs
(short instead of mode_t; only makes a difference on big endian).

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating Y2038 glibc fixes

Florian Weimer-5
* Rich Felker:

> On Wed, Jul 17, 2019 at 11:57:48PM +0200, Lukasz Majewski wrote:
>> Note:
>>
>> [1] -
>> https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-11-03-2019
>>
>> [2] - https://github.com/lmajewski/y2038-tests
>>
>> [3] -
>> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?highlight=%28y2038%29
>>
>> [4] - https://github.com/lmajewski/meta-y2038/tree/master
>
> Some findings here that need correction:
>
> [1] is completely missing the sysvipc interfaces affected, and [3]
> fails to document them as affected because the structs are variadic
> arguments not declared ones. Fortunately, this means we can get away
> without actually replacing the functions, and instead define new
> command numbers to perform the translation. When doing this, glibc
> should follow musl and correct other bugs in these structs: for
> example, struct ipc_perm's mode field has the wrong type on some archs
> (short instead of mode_t; only makes a difference on big endian).

Do the musl types match the kernel types?

Thanks,
Florian
123