[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <678F3D1BB717D949B966B68EAEB446ED4827C527@dggemm526-mbx.china.huawei.com>
Date: Thu, 17 Sep 2020 02:43:34 +0000
From: "Zengtao (B)" <prime.zeng@...ilicon.com>
To: Arnd Bergmann <arnd@...db.de>
CC: Thomas Gleixner <tglx@...utronix.de>,
Vincenzo Frascino <vincenzo.frascino@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] time: Avoid undefined behaviour in timespec64_to_ns
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@...db.de]
> Sent: Tuesday, September 15, 2020 8:45 PM
> To: Zengtao (B)
> Cc: Thomas Gleixner; Vincenzo Frascino; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH] time: Avoid undefined behaviour in
> timespec64_to_ns
>
> On Tue, Sep 15, 2020 at 2:20 PM Zengtao (B)
> <prime.zeng@...ilicon.com> wrote:
>
> > > > Fixes: bd40a175769d ("y2038: itimer: change implementation to
> > > timespec64")
> > >
> > > This one caused the regression, but if we add the check here, it
> > > may be best to also add it in prior kernels that may have the same
> > > bug in other callers of the same function. Maybe backport all the
> > > way to stable kernels that first added timespec64?
> > >
> >
> > I think we need to do the backport, but not sure about the start
> point
> > Thanks for your review.
>
> I would suggest
>
> Cc: <stable@...r.kernel.org> # v3.17+
> Fixes: 361a3bf00582 ("time64: Add time64.h header and define
> struct timespec64")
Yes, make sense, commit 361a3bf00582 introduce a potential issue and
commit bd40a175769d trigger the issue.
Regards
Zengtao
>
> Arnd
Powered by blists - more mailing lists