From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753623AbdJaQ7X (ORCPT ); Tue, 31 Oct 2017 12:59:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:47118 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751318AbdJaQ7W (ORCPT ); Tue, 31 Oct 2017 12:59:22 -0400 Date: Tue, 31 Oct 2017 17:59:13 +0100 From: Jan Kara To: Arnd Bergmann Cc: Jan Kara , y2038 Mailman List , Al Viro , Deepa Dinamani , Linux FS-devel Mailing List , Anders Larsen , "# 3.4.x" , David Howells , Linux Kernel Mailing List Subject: Re: [PATCH v2 1/2] isofs: fix timestamps beyond 2027 Message-ID: <20171031165913.GH26128@quack2.suse.cz> References: <20171019144811.2144678-1-arnd@arndb.de> <20171019151737.GC17891@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 19-10-17 17:29:12, Arnd Bergmann wrote: > On Thu, Oct 19, 2017 at 5:17 PM, Jan Kara wrote: > > On Thu 19-10-17 16:47:48, Arnd Bergmann wrote: > >> isofs uses a 'char' variable to load the number of years since > >> 1900 for an inode timestamp. On architectures that use a signed > >> char type by default, this results in an invalid date for > >> anything beyond 2027. > >> > >> This changes the function argument to a 'u8' array, which > >> is defined the same way on all architectures, and unambiguously > >> lets us use years until 2155. > >> > >> This should be backported to all kernels that might still be > >> in use by that date. > >> > >> Cc: stable@vger.kernel.org > >> Signed-off-by: Arnd Bergmann > > ... > >> -int iso_date(char * p, int flag) > >> +int iso_date(u8 *p, int flag) > >> { > >> int year, month, day, hour, minute, second, tz; > >> int crtime; > >> > >> - year = p[0]; > >> + year = (int)(u8)p[0]; > > > > The cast seems unnecessary now? > > > > Sorry, I must have rebased the patch incorrectly, this was intended to > be removed > of course. OK, I've picked up this patch to my tree with this correction. Honza -- Jan Kara SUSE Labs, CR