linux-kernel - Re: [PATCH v6 0/8] Fix year 2038 issue for sound subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5hzhgzn304.wl-tiwai@suse.de>
Date:   Wed, 13 Nov 2019 17:40:43 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     ALSA Development Mailing List <alsa-devel@...a-project.org>,
        Takashi Iwai <tiwai@...e.com>,
        Baolin Wang <baolin.wang7@...il.com>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH v6 0/8] Fix year 2038 issue for sound subsystem

On Wed, 13 Nov 2019 15:32:44 +0100,
Arnd Bergmann wrote:
> 
> On Tue, Nov 12, 2019 at 9:37 PM Takashi Iwai <tiwai@...e.de> wrote:
> > On Tue, 12 Nov 2019 16:16:34 +0100, Arnd Bergmann wrote:
> > > I would like to propose merging this into the alsa tree after
> > > the v5.5 merge window for inclusion into v5.6, to allow a good
> > > amount of testing, in particular for the header changes that
> > > may cause problems for user space applications.
> >
> > Agreed, it's still no urgent problem.
> 
> I actually do think it's getting urgent, anything that touches
> the ABI must be done carefully and not rushed.
> 
> The urgency at the moment is that developers are starting to
> deploy systems with 64-bit time_t with musl-libc making this
> the default now, and 32-bit risc-v not offering 32-bit time_t at all.
> 
> At the moment, this means that audio support is broken for
> them, and that needs to be fixed.
> 
> The other reason why lots of people care about moving all user
> space to 64-bit time_t is that 32-bit hardware is slowly starting
> to become less common. We know there will still be many
> 32-bit ARM systems operational in 2038, but most of them will
> be on (then) 10+ year old hardware, running even older software
> that already being worked on today. The longer it takes us to
> stop using 32-bit time_t in user space, the more systems will
> end up having to be thrown away rather than fixed.

Don't worry, I planned merging the whole changes for 5.6.

> > So now taking a quick look through the series, I find this approach is
> > the way to go.  Although one might get a bit more optimization after
> > squeeze, it's already a good compromise between the readability and
> > the efficiency.
> 
> Thanks!
> 
> > A slight uncertain implementation is the timer tread stuff, especially
> > the conditional definition of SNDRV_TIMER_IOCTL_TREAD (IIRC, I already
> > complained it in the past, too).  But I have no other idea as well, so
> > unless someone else gives a better option, we can live with that.
> 
> We had discussed alternatives for this one last time, and decided
> to go with the solution I posted here. The main alternative would
> be to change the 'timespec' in snd_timer_tread to a fixed-length
> structure based on two 'long' members. This would avoid the
> need to match the command with the time_t type, but the cost would
> be requiring CLOCK_MONOTONIC timestamps to avoid the
> overflow, and changing all application source code that requires
> the type to be compatible with 'timespec'.

Fair enough.

One thing I forgot to mention: when we add/modify the ioctl or ABI, we
need to increment the protocol version, e.g. SNDRV_PCM_VERSION to
indicate user-space the supported ABI.  Please change these in your
next patches, too.


thanks,

Takashi