Re: [Y2038] [PATCH v2 10/12] nfsd: use boottime for lease expiry alculation

2019-12-19 Thread J. Bruce Fields
On Fri, Dec 13, 2019 at 03:10:44PM +0100, Arnd Bergmann wrote: > @@ -5212,8 +5211,8 @@ nfs4_laundromat(struct nfsd_net *nn) > struct nfs4_ol_stateid *stp; > struct nfsd4_blocked_lock *nbl; > struct list_head *pos, *next, reaplist; > - time_t cutoff = get_seconds() -

Re: [Y2038] [PATCH v5 6/8] media: v4l2-core: fix v4l2_buffer handling for time64 ABI

2019-12-19 Thread Zach van Rijn
On Sat, 2019-12-14 at 22:44 +0100, Arnd Bergmann wrote: > On Sat, Dec 14, 2019 at 12:27 PM Hans Verkuil .nl> wrote: > > > > On 12/13/19 4:32 PM, Hans Verkuil wrote: > > > > > ... > > > > > > > > I've heard good things about the prebuilt toolchains > > > > from http://musl.cc/. > > > > These

Re: [Y2038] [PATCH v2 27/27] Documentation: document ioctl interfaces better

2019-12-19 Thread Arnd Bergmann
On Wed, Dec 18, 2019 at 11:45 PM Ben Hutchings wrote: > On Tue, 2019-12-17 at 23:17 +0100, Arnd Bergmann wrote: > > --- /dev/null > > +++ b/Documentation/core-api/ioctl.rst > > +``include/uapi/asm-generic/ioctl.h`` provides four macros for defining > > +ioctl commands that follow modern

Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits

2019-12-19 Thread Ben Hutchings
[+cc cip-dev] On Thu, 2019-12-19 at 12:29 +0100, Arnd Bergmann wrote: [...] > - Users of CIP SLTS kernels with extreme service life that may involve > not upgrading until after y2038 (this is obviously not recommended if > you connect to a public network, but I'm sure some people do this

Re: [Y2038] [PATCH v2 21/27] compat_ioctl: move cdrom commands into cdrom.c

2019-12-19 Thread Arnd Bergmann
On Wed, Dec 18, 2019 at 9:11 PM Ben Hutchings wrote: > > On Tue, 2019-12-17 at 23:17 +0100, Arnd Bergmann wrote: > [...] > > @@ -1710,6 +1711,38 @@ static int idecd_ioctl(struct block_device *bdev, > > fmode_t mode, > > return ret; > > } > > > > +#ifdef CONFIG_COMPAT > > +static int

Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits

2019-12-19 Thread Amir Goldstein
On Thu, Dec 19, 2019 at 10:28 AM Arnd Bergmann wrote: > > On Wed, Dec 18, 2019 at 9:46 PM Amir Goldstein wrote: > > > > I don't think there is a clear policy about being friendly to testing > > less that master kernels in xfstest (Eryu?), but IMO we should try to > > accommodate > > this use

Re: [Y2038] [PATCH v2 18/27] compat_ioctl: scsi: move ioctl handling into drivers

2019-12-19 Thread Arnd Bergmann
On Wed, Dec 18, 2019 at 8:57 PM Ben Hutchings wrote: > > On Tue, 2019-12-17 at 23:16 +0100, Arnd Bergmann wrote: > > + > > + /* > > + * CDROM ioctls are handled in the block layer, but > > + * do the scsi blk ioctls here. > > + */ > > + ret = scsi_cmd_blk_ioctl(bdev, mode,

Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits

2019-12-19 Thread Greg KH
On Thu, Dec 19, 2019 at 12:29:39PM +0100, Arnd Bergmann wrote: > On Thu, Dec 19, 2019 at 9:40 AM Greg KH wrote: > > On Thu, Dec 19, 2019 at 09:28:23AM +0100, Arnd Bergmann wrote: > > > On Wed, Dec 18, 2019 at 9:46 PM Amir Goldstein wrote: > > > > > > [1] > > >

Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits

2019-12-19 Thread Arnd Bergmann
On Thu, Dec 19, 2019 at 9:40 AM Greg KH wrote: > On Thu, Dec 19, 2019 at 09:28:23AM +0100, Arnd Bergmann wrote: > > On Wed, Dec 18, 2019 at 9:46 PM Amir Goldstein wrote: > > > > [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/futimens.html > > Ugh, that's a mess. Why not just use

Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits

2019-12-19 Thread Greg KH
On Thu, Dec 19, 2019 at 09:28:23AM +0100, Arnd Bergmann wrote: > On Wed, Dec 18, 2019 at 9:46 PM Amir Goldstein wrote: > > > > I don't think there is a clear policy about being friendly to testing > > less that master kernels in xfstest (Eryu?), but IMO we should try to > > accommodate > > this

Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits

2019-12-19 Thread Arnd Bergmann
On Wed, Dec 18, 2019 at 9:46 PM Amir Goldstein wrote: > > I don't think there is a clear policy about being friendly to testing > less that master kernels in xfstest (Eryu?), but IMO we should try to > accommodate > this use case, because it is in the best interest of everyone that stable >