From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48FE5C282DD for ; Wed, 8 Jan 2020 18:03:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2AA412067D for ; Wed, 8 Jan 2020 18:03:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730039AbgAHSDG (ORCPT ); Wed, 8 Jan 2020 13:03:06 -0500 Received: from verein.lst.de ([213.95.11.211]:50572 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727090AbgAHSDG (ORCPT ); Wed, 8 Jan 2020 13:03:06 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 6FC9F68BFE; Wed, 8 Jan 2020 19:03:04 +0100 (CET) Date: Wed, 8 Jan 2020 19:03:04 +0100 From: Christoph Hellwig To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Namjae Jeon , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, gregkh@linuxfoundation.org, valdis.kletnieks@vt.edu, hch@lst.de, sj1557.seo@samsung.com, linkinjeon@gmail.com, Arnd Bergmann Subject: Re: [PATCH v9 09/13] exfat: add misc operations Message-ID: <20200108180304.GE14650@lst.de> References: <20200102082036.29643-1-namjae.jeon@samsung.com> <20200102082036.29643-10-namjae.jeon@samsung.com> <20200102091902.tk374bxohvj33prz@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200102091902.tk374bxohvj33prz@pali> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Arnd, can you review the exfat time handling, especially vs y2038 related issues? On Thu, Jan 02, 2020 at 10:19:02AM +0100, Pali Rohár wrote: > On Thursday 02 January 2020 16:20:32 Namjae Jeon wrote: > > This adds the implementation of misc operations for exfat. > > > > Signed-off-by: Namjae Jeon > > Signed-off-by: Sungjong Seo > > --- > > fs/exfat/misc.c | 253 ++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 253 insertions(+) > > create mode 100644 fs/exfat/misc.c > > > > diff --git a/fs/exfat/misc.c b/fs/exfat/misc.c > > new file mode 100644 > > index 000000000000..7f533bcb3b3f > > --- /dev/null > > +++ b/fs/exfat/misc.c > > ... > > > +/* externs sys_tz > > + * extern struct timezone sys_tz; > > + */ > > +#define UNIX_SECS_1980 315532800L > > + > > +#if BITS_PER_LONG == 64 > > +#define UNIX_SECS_2108 4354819200L > > +#endif > > ... > > > +#define TIMEZONE_CUR_OFFSET() ((sys_tz.tz_minuteswest / (-15)) & 0x7F) > > +/* Convert linear UNIX date to a FAT time/date pair. */ > > +void exfat_time_unix2fat(struct exfat_sb_info *sbi, struct timespec64 *ts, > > + struct exfat_date_time *tp) > > +{ > > + time_t second = ts->tv_sec; > > + time_t day, month, year; > > + time_t ld; /* leap day */ > > Question for other maintainers: Has kernel code already time_t defined > as 64bit? Or it is still just 32bit and 32bit systems and some time64_t > needs to be used? I remember that there was discussion about these > problems, but do not know if it was changed/fixed or not... Just a > pointer for possible Y2038 problem. As "ts" is of type timespec64, but > "second" of type time_t. > > > + > > + /* Treats as local time with proper time */ > > + second -= sys_tz.tz_minuteswest * SECS_PER_MIN; > > + tp->timezone.valid = 1; > > + tp->timezone.off = TIMEZONE_CUR_OFFSET(); > > + > > + /* Jan 1 GMT 00:00:00 1980. But what about another time zone? */ > > + if (second < UNIX_SECS_1980) { > > + tp->second = 0; > > + tp->minute = 0; > > + tp->hour = 0; > > + tp->day = 1; > > + tp->month = 1; > > + tp->year = 0; > > + return; > > + } > > + > > + if (second >= UNIX_SECS_2108) { > > Hello, this code cause compile errors on 32bit systems as UNIX_SECS_2108 > macro is not defined when BITS_PER_LONG == 32. > > Value 4354819200 really cannot fit into 32bit signed integer, so you > should use 64bit signed integer. I would suggest to define this macro > value via LL not just L suffix (and it would work on both 32 and 64bit) > > #define UNIX_SECS_2108 4354819200LL > > > + tp->second = 59; > > + tp->minute = 59; > > + tp->hour = 23; > > + tp->day = 31; > > + tp->month = 12; > > + tp->year = 127; > > + return; > > + } > > -- > Pali Rohár > pali.rohar@gmail.com ---end quoted text---