Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200102082036.29643-1-namjae.jeon@samsung.com>
 <CGME20200102082406epcas1p268f260d90213bdaabee25a7518f86625@epcas1p2.samsung.com>
 <20200102082036.29643-10-namjae.jeon@samsung.com> <20200102091902.tk374bxohvj33prz@pali>
 <20200108180304.GE14650@lst.de>
In-Reply-To: <20200108180304.GE14650@lst.de>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Wed, 8 Jan 2020 20:40:53 +0100
Message-ID: <CAK8P3a0S6DBJqDMj4Oy9xeYVhW87HbBX2SqURFPKYT8K1z7fDw@mail.gmail.com>
Subject: Re: [PATCH v9 09/13] exfat: add misc operations
To:     Christoph Hellwig <hch@lst.de>
Cc:     =?UTF-8?Q?Pali_Roh=C3=A1r?= <pali.rohar@gmail.com>,
        Namjae Jeon <namjae.jeon@samsung.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
        gregkh <gregkh@linuxfoundation.org>,
        Valdis Kletnieks <valdis.kletnieks@vt.edu>,
        sj1557.seo@samsung.com, linkinjeon@gmail.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Jan 8, 2020 at 7:03 PM Christoph Hellwig <hch@lst.de> wrote:
>
> Arnd, can you review the exfat time handling, especially vs y2038
> related issues?

Sure, thanks for adding me to the loop

> 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:
> > > +#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.

I am actually very close to sending the patches to remove the time_t
definition from the kernel, at least in yesterday's version there were no
users.

exfat_time_unix2fat() seems to be a copy of the old fat_time_unix2fat()
that we fixed a while ago, please have a look at that implementation
based on time64_to_tm(), which avoids time_t.

      Arnd