Date: Thu, 17 Feb 2022 20:25:01 -0500 From: Satadru Pramanik <satadru@...il.com> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: Fwd: Re: musl getaddr info breakage on older kernels I have attached the working patch I have ended up using, which has added only a definition for ENOSYS. Thanks again. It's nice to be offering software for these machines with working, current libc. :) Satadru On Thu, Feb 17, 2022 at 5:48 PM Rich Felker <dalias@...c.org> wrote: > On Thu, Feb 17, 2022 at 04:43:51PM -0500, Satadru Pramanik wrote: > > > issues in userspace to maintain some functionality for any users who > may > > > > still be using the device. > > > > > > > > The simplest workaround possible would be ideal. > > > > > > If you're shipping binaries specifically for these devices, the > > > simplest fix is just to emulate the failure that should happen in the > > > kernel in userspace, using the attached patch. DO NOT deploy this > > > patch in binaries meant to be used on modern systems, since they will > > > break when Y2038 rolls around. (Your old Chromebooks will break then > > > too.) > > > > > I'll let the next generation of preservationists worry about the Y2038 > > issues. Thanks for the patch. I'll build that now with the > > > https://git.musl-libc.org/cgit/musl/patch/?id=c2feda4e2ea61f4da73f2f38b2be5e327a7d1a91 > > reversal patch for the i686 machines, and see if that fixes the issue. If > > That reversal should no longer be needed with the other patch, which > is a much bigger hammer. Reversing that just got rid of using the new > socket-related syscalls; the new hack patch gets rid of using all new > syscalls. > > > so, we can consider the matter closed, unless you want to suggest a > > modification of the syscall patch to handle older working kernels which > > might avoid the need for the patch when used with older systems. > > The patch is fine for older broken or older working systems. It just > suppresses the ability to use any syscall added after Linux 3.8, so > it's a bad idea to use on *newer* systems. > > > > It is interesting though > > > > that the sample program works fine when built against near-stock > glibc > > > > 2.23, no? > > > > > > No. If your kernel has a bug that makes something behave wildly wrong, > > > whether you do or don't see that as visible breakage with a particular > > > piece of software is not particularly interesting. > > > > > > I'm pretty sure, however, that you just haven't tested enough to see > > > any failures. glibc 2.23 is from 2016, so any functionality in it > > > using syscalls added after 2011 (3.8 kernel) is going to blow up > > > badly, thinking the syscall succeeded and returned some positive value > > > when actually the kernel lacks it. > > > > > > In the particular case of clock_gettime, it's just that your glibc > > > 2.23 has a hard Y2038 EOL and does not use/support the missing time64 > > > syscalls. > > > > > > > > Duly noted. > > > > Thanks so much for being patient while I got you enough information to > fix > > this! > > > > On behalf of the entire Chromebrew community, thank you! > > And thanks for reporting, running tests, and following through on > this. It will be useful to know this is an issue others might hit, and > to be able to check other old systems that might have backported the > patch with the bug. > Content of type "text/html" skipped Download attachment "broken_chromeos_kernel_hack_2.diff" of type "application/octet-stream" (2653 bytes)
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.