All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: "Arnaud Panaïotis" <arnaud.panaiotis@gmx.fr>
Cc: linux-kernel@vger.kernel.org, y2038@lists.linaro.org,
	alpha@sourceware.org
Subject: Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel
Date: Tue, 31 May 2022 10:24:15 +0200	[thread overview]
Message-ID: <CAK8P3a0bmE03wJ_iELrAMyFvamwd_r5aLsFBH=6=5YaueO=-kg@mail.gmail.com> (raw)

On 17/05/2022 09:51, Arnaud Panaïotis wrote:
> Hello,
>
> I'm working for a client to generate embedded 32-bits Linux Kernel working after y2038 issue.
>
> I generated a 5.15 Kernel thought Buildroot with Coreutils 9.0, GCC 11.2.0, Binutils 2.37, Glibc 2.34-9 and CFLAGS  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -D_TIME_BITS=64.
>
> I encounter an issue while working with OpenSSH (I initially contacted them before).

To clarify: did you build just openssh with  -D_TIME_BITS=64, or did
you build the user space
this way?

> After 2038, /usr/sbin/sshd does not create an error but it child does generate this one:
> daemon() failed: Value too large for defined data type
>
> This happend here in sshd.c:
>
> 2019         /*
> 2020          * If not in debugging mode, not started from inetd and not already
> 2021          * daemonized (eg re-exec via SIGHUP), disconnect from the controlling
> 2022          * terminal, and fork.  The original process exits.
> 2023          */
> 2024         already_daemon = daemonized();
> 2025         if (!(debug_flag || inetd_flag || no_daemon_flag || already_daemon)) {
> 2026
> 2027                 if (daemon(0, 0) == -1)
> 2028                         fatal("daemon() failed: %.200s", strerror(errno));

My guess is that there are parts of glibc that are not fully
y2038-safe at the moment, but
merely provide the interfaces for time64 applications.


In the glibc code, I see

int
daemon (int nochdir, int noclose)
{
...
                if ((fd = __open_nocancel(_PATH_DEVNULL, O_RDWR, 0)) != -1
                    && (__builtin_expect (__fstat64 (fd, &st), 0)
                        == 0)) {
...
                             } else {
                        __close_nocancel_nostatus (fd);
                        return -1;
                }
     return (0);
}

__fstatat64 (int fd, const char *file, struct stat64 *buf, int flags)
{
  struct __stat64_t64 st_t64;
  return __fstatat64_time64 (fd, file, &st_t64, flags)
         ?: __cp_stat64_t64_stat64 (&st_t64, buf);
}

If I'm reading this correctly, daemon() internally uses the time32
version of 'stat', which
fails for files with out-of-range timestamps. Are you able to rebuild
the ssh binary
(or your entire distro, if that's easier) against musl-1.2.x instead
of glibc to see if the
same thing happens there?

       Arnd

> To reproduce:
>
> # date -s "2040-05-12"
> # hwclock --systohc
> # reboot
> # /usr/sbin/sshd
>
> Note this error occurs only after the reboot, and setting a date before 2038 also require a reboot to remove the error.
>
> strace and gdb trace linked.
>
> Let me know if you need additional information.

             reply	other threads:[~2022-05-31  8:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-31  8:24 Arnd Bergmann [this message]
2022-05-31  8:33 ` PROBLEM: with daemon.c after y2038 on 32-bits Kernel Arnd Bergmann
2022-05-31 10:54   ` Adhemerval Zanella
2022-05-31 12:16     ` Arnaud Panaïotis
2022-05-31 13:02       ` Szabolcs Nagy
2022-05-31 13:24         ` Arnaud Panaïotis
  -- strict thread matches above, loose matches on Subject: below --
2022-05-17  7:51 Arnaud Panaïotis
2022-05-30  7:03 ` Arnaud Panaïotis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK8P3a0bmE03wJ_iELrAMyFvamwd_r5aLsFBH=6=5YaueO=-kg@mail.gmail.com' \
    --to=arnd@kernel.org \
    --cc=alpha@sourceware.org \
    --cc=arnaud.panaiotis@gmx.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.