search for: time64_t

...ct timespec64 ts) +{ + inode->i_ctime = ts; + return ts; +} + +/** + * inode_ctime_set_sec - set only the tv_sec field in the inode ctime + * @inode: inode in which to set the ctime + * @sec: value to set the tv_sec field + * + * Set the sec field in the ctime. Returns @sec. + */ +static inline time64_t inode_ctime_set_sec(struct inode *inode, time64_t sec) +{ + inode->i_ctime.tv_sec = sec; + return sec; +} + +/** + * inode_ctime_set_nsec - set only the tv_nsec field in the inode ctime + * @inode: inode in which to set the ctime + * @nsec: value to set the tv_nsec field + * + * Set the nsec fi...

I've been working on a patchset to change how the inode->i_ctime is accessed in order to give us conditional, high-res timestamps for the ctime and mtime. struct timespec64 has unused bits in it that we can use to implement this. In order to do that however, we need to wrap all accesses of inode->i_ctime to ensure that bits used as flags are appropriately handled. This patchset first

...ten Glaser wrote: > Arnd Bergmann dixit: > > >In the patch series I posted recently [1], I introduce new system calls to deal > >with modified data structures, but left the question open on how these should > >be best accessed from libc. The patches introduce a new __kernel_time64_t type > > Can we please have ioctls fixed for mixed 32/64-bit systems > such as MIPS (o32/n32/n64) and x86 (i386/x32/amd64) first, > before even more such chance for breakage is introduced? It's hard because we don't even know what ioctls are affected at this point, and I was h...

...64-bit __kernel_long_t in its n32 ABI. I have heard from a MIPS porter that one of the flavours suffers from similar problems as x32, just not to that extent. But I don?t recall my source? >ioctls. My plan at this point is to eliminate all uses of time_t in >the kernel and replace them with time64_t or other safe types. >This way, we will eventually find all code that passes 32-bit time types >to user space and can fix it. This will take care of the time_t >related problems on x32 as well. Ah, interesting approach. And existing userspace, as well as new userspace that does not declar...

...: Deepa and I have discussed the vdso in the past for 2038. I have started a patch that I'll have to redo on top of yours, but that is fine, your cleanup is only going to help here. More generally speaking, Deepa said that she would like to see some generalization on the vdso before adding the time64_t based variants. Your series probably makes x86 diverge more from the others, which makes it harder to consolidate them again, but we might just as well use your new implementation to base the generic one on, and just move the other ones over to that. A couple of architectures (s390, ia64, riscv, p...

In the patch series I posted recently [1], I introduce new system calls to deal with modified data structures, but left the question open on how these should be best accessed from libc. The patches introduce a new __kernel_time64_t type and based on that five new data structured: struct __kernel_timespec, struct __kernel_itimerspec, struct __kernel_stat, struct __kernel_rusage, and struct __kernel_timex. This works fine for the case when all libc implementations provide their own definitions to user space, but not for the sim...

Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing