linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Arnd Bergmann" <arnd@kernel.org>
Cc: "Alessandro Zummo" <a.zummo@towertech.it>,
	"Reinier Kuipers" <kuipers.reinier@gmail.com>,
	linux-rtc@vger.kernel.org, "Russell King" <linux@armlinux.org.uk>,
	"Yang Yingliang" <yangyingliang@huawei.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [RFC] rtc: y2038: remove broken RTC_HCTOSYS workaround
Date: Wed, 16 Nov 2022 08:01:00 +0100	[thread overview]
Message-ID: <c5e8ab50-aacb-4651-8893-a6dd9edcd155@app.fastmail.com> (raw)
In-Reply-To: <Y3QNzvAYo9y+yyTf@mail.local>

On Tue, Nov 15, 2022, at 23:08, Alexandre Belloni wrote:
> Hello,
>
> I'm fine with the patch and I'll probably take it, 

Ok, thanks!

> I a an observation though:
>
> On 08/09/2022 13:53:20+0200, Arnd Bergmann wrote:
>> +	 *
>> +	 * Since the kernel has no way of knowing what user space it runs,
>> +	 * warn here whenever the kernel is able to run it.
>> +	 * When CONFIG_COMPAT_32BIT_TIME is disabled, we know that the
>> +	 * system is safe, but unfortunately this this is currently not
>> +	 * supported by musl-1.2.x or most glibc based user space.
>
> I was under the impression that musl never had a 32bit time_t nor used
> the 32bit time APIs so it would not be affected by the bug.
> So I guess the only affected userspace is glibc without _TIME_BITS=64

It's actually the opposite: while new versions of musl only allow
building applications against the time64 interfaces, musl itself
uses a mix of the time32 and time64 system calls, and the musl
maintainer considers turning CONFIG_COMPAT_32BIT_TIME off a
misfeature of the kernel that he does not want to support.

      Arnd

      reply	other threads:[~2022-11-16  7:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-08 11:53 [PATCH] [RFC] rtc: y2038: remove broken RTC_HCTOSYS workaround Arnd Bergmann
2022-11-15 22:08 ` Alexandre Belloni
2022-11-16  7:01   ` Arnd Bergmann [this message]

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=c5e8ab50-aacb-4651-8893-a6dd9edcd155@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=arnd@kernel.org \
    --cc=kuipers.reinier@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=yangyingliang@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).