Re: [Y2038] [PATCH v2 09/24] fs: udf: Replace CURRENT_TIME with current_time()
On Wed, Jun 22, 2016 at 6:54 AM, Arnd Bergmann wrote: > On Sunday, June 19, 2016 5:27:08 PM CEST Deepa Dinamani wrote: >> mutex_lock(&sbi->s_alloc_mutex); >> lvidiu->impIdent.identSuffix[0] = UDF_OS_CLASS_UNIX; >> lvidiu->impIdent.identSuffix[1] = UDF_OS_ID_LINUX; >> + ktime_get_real_ts(&ts); >> udf_time_to_disk_stamp(&lvid->recordingDateAndTime, >> - CURRENT_TIME); >> + timespec_trunc(ts, sb->s_time_gran)); >> lvid->integrityType = cpu_to_le32(LVID_INTEGRITY_TYPE_OPEN); >> >> lvid->descTag.descCRC = cpu_to_le16( >> > > I think we don't need the timespec_trunc here, and introducing the > call might complicate matters in the future. This was done so that it could be similar to inode timestamps as both have same format and use same formatting functions. > IMHO timespec_trunc() really only makes sense when assigning into > an inode timestamp, whereas udf_time_to_disk_stamp() already truncates > the resulting nanoseconds to microseconds. I reconsidered our discussion. I think you are correct. I missed that the prints using microseconds format would actually convert seconds also to microseconds and not just nanoseconds. I will remove the timespec_trunc here and post a v3. Thanks, -Deepa ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH v2 19/24] fnic: Use time64_t to represent trace timestamps
On Wed, Jun 22, 2016 at 7:09 AM, Arnd Bergmann wrote: > On Sunday, June 19, 2016 5:27:18 PM CEST Deepa Dinamani wrote: >> trace timestamps use struct timespec and CURRENT_TIME which >> are not y2038 safe. >> These timestamps are only part of the trace log on the machine >> and are not shared with the fnic. >> Replace then with y2038 safe struct timespec64 and >> ktime_get_real_ts64(), respectively. >> >> Note that change to add time64_to_tm() is already part of John's >> kernel tree: https://lkml.org/lkml/2016/6/17/875 . >> > > While the patch looks good, I think it can't be part of this > series now, since it has to go on top of that first patch, > rather than merged in parallel. Oh, I didn't realize we could merge these in parallel. I thought the time64_to_tm() had to go in first. > When you send a pull request, please leave it out and submit > this one separately after 4.8-rc1. Will do. Thanks, Deepa ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] Fourth draft of the Y2038 design document
On Wed, 22 Jun 2016, Arnd Bergmann wrote: > We can avoid most of the problems if building with _TIME_BITS=64 > has no effect unless both glibc and the kernel headers are new > enough to provide the definitions for 64-bit time_t. That way > we can at least ensure that calling an ioctl command or setsockopt > with an incompatible ABI will result in an error code rather than > wrong data. I'd be a lot more comfortable with requiring new kernel headers to build and use glibc than with requiring a new kernel at runtime for _TIME_BITS=64 to work. New kernel headers are one of the easiest things to use when building glibc, since we have the --with-headers option. (In fact right now the headers requirement (3.2) is newer than the runtime requirement (2.6.32) on x86_64 / x86.) (_TIME_BITS=64 should of course be an OS-independent API, supported for all glibc configurations. Obviously exactly what Hurd does is up to the Hurd maintainers, as probably is fixing Hurd to keep it working with _TIME_BITS=64, but _TIME_BITS=64 should clearly enable 64-bit time_t for it even if some underlying Y2038-safety is missing. NaCl already has 64-bit time_t so _TIME_BITS=64 would have no effect there.) -- Joseph S. Myers jos...@codesourcery.com ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH v2] crypto: Jitter RNG - use ktime_get_ns as fallback
On Wednesday, June 22, 2016 7:26:06 PM CEST Stephan Mueller wrote: > As part of the Y2038 development, __getnstimeofday is not supposed to be > used any more. It is now replaced with ktime_get_ns. The Jitter RNG uses > the time stamp to measure the execution time of a given code path and > tries to detect variations in the execution time. Therefore, the only > requirement the Jitter RNG has, is a sufficient high resolution to > detect these variations. > > The change was tested on x86 to show an identical behavior as RDTSC. The > used test code simply measures the execution time of the heart of the > RNG: > > jent_get_nstime(&time); > jent_memaccess(ec, min); > jent_fold_time(NULL, time, &folded, min); > jent_get_nstime(&time2); > return ((time2 - time)); > > Signed-off-by: Stephan Mueller > --- > Acked-by: Arnd Bergmann ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] Fourth draft of the Y2038 design document
On Wednesday, June 22, 2016 2:30:10 PM CEST Joseph Myers wrote: > On Wed, 22 Jun 2016, Arnd Bergmann wrote: > > > Regarding the "Support for non-Y2038-safe kernels" section, I'm not > > sure if that can work at all: A kernel that does not have the appropriate > > system calls will also not have the handlers for a lot of the ioctl > > commands and possibly other interfaces that rely on a specific > > structure layout. If we can instead enforce that __USE_TIME_BITS64 > > Maybe it's hard for ioctls, but I see no reason it shouldn't work for > applications using normal non-ioctl glibc interfaces, with runtime > fallbacks in glibc such as have been used for plenty of previous kernel > features. > > Of course eventually we remove support for the older kernels - when they > are no longer on the list at https://www.kernel.org/category/releases.html > unless something comes up like the issue with people expecting to use new > glibc on old virtualization solutions only supporting 2.6.32 kernels - but > it would be good for people and distributions to be using / testing > _TIME_BITS=64 before they reach the point of ceasing to support any older > kernels. Testing is a good point, we crearly don't want to force people to give up support for older kernels in their glibc binaries in order to be able to build with _TIME_BITS=64. At the same time I'd be worried about users building a binary against a new libc with _TIME_BITS=64 and then running into data corruption because they are accidentally executing the binaries on kernels that interpret the some ABI differently. We can avoid most of the problems if building with _TIME_BITS=64 has no effect unless both glibc and the kernel headers are new enough to provide the definitions for 64-bit time_t. That way we can at least ensure that calling an ioctl command or setsockopt with an incompatible ABI will result in an error code rather than wrong data. Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH v2] crypto: Jitter RNG - use ktime_get_ns as fallback
On Wed, Jun 22, 2016 at 10:26 AM, Stephan Mueller wrote: > Hi John, Herbert, > > Changes v2: use ktime_get_ns instead of ktime_get_raw_ns > > The testing was re-performed and indicate no difference to the previous > testing. Thanks for following through on this. This version addresses my concerns about using specialized time accessors without clear rational. thanks -john ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
[Y2038] [PATCH v2] crypto: Jitter RNG - use ktime_get_ns as fallback
Hi John, Herbert,
Changes v2: use ktime_get_ns instead of ktime_get_raw_ns
The testing was re-performed and indicate no difference to the previous testing.
Ciao
Stephan
---8<---
As part of the Y2038 development, __getnstimeofday is not supposed to be
used any more. It is now replaced with ktime_get_ns. The Jitter RNG uses
the time stamp to measure the execution time of a given code path and
tries to detect variations in the execution time. Therefore, the only
requirement the Jitter RNG has, is a sufficient high resolution to
detect these variations.
The change was tested on x86 to show an identical behavior as RDTSC. The
used test code simply measures the execution time of the heart of the
RNG:
jent_get_nstime(&time);
jent_memaccess(ec, min);
jent_fold_time(NULL, time, &folded, min);
jent_get_nstime(&time2);
return ((time2 - time));
Signed-off-by: Stephan Mueller
---
crypto/jitterentropy-kcapi.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/crypto/jitterentropy-kcapi.c b/crypto/jitterentropy-kcapi.c
index 597cedd..be1577c 100644
--- a/crypto/jitterentropy-kcapi.c
+++ b/crypto/jitterentropy-kcapi.c
@@ -87,24 +87,28 @@ void jent_memcpy(void *dest, const void *src, unsigned int
n)
memcpy(dest, src, n);
}
+/*
+ * Obtain a high-resolution time stamp value. The time stamp is used to measure
+ * the execution time of a given code path and its variations. Hence, the time
+ * stamp must have a sufficiently high resolution.
+ *
+ * Note, if the function returns zero because a given architecture does not
+ * implement a high-resolution time stamp, the RNG code's runtime test
+ * will detect it and will not produce output.
+ */
void jent_get_nstime(__u64 *out)
{
- struct timespec ts;
__u64 tmp = 0;
tmp = random_get_entropy();
/*
-* If random_get_entropy does not return a value (which is possible on,
-* for example, MIPS), invoke __getnstimeofday
+* If random_get_entropy does not return a value, i.e. it is not
+* implemented for a given architecture, use a clock source.
* hoping that there are timers we can work with.
*/
- if ((0 == tmp) &&
- (0 == __getnstimeofday(&ts))) {
- tmp = ts.tv_sec;
- tmp = tmp << 32;
- tmp = tmp | ts.tv_nsec;
- }
+ if (tmp == 0)
+ tmp = ktime_get_ns();
*out = tmp;
}
--
2.5.5
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH v2 23/24] time: Delete CURRENT_TIME_SEC and CURRENT_TIME macro
On Sunday, June 19, 2016 5:27:22 PM CEST Deepa Dinamani wrote: > All uses of these macros have been replaced by other > time functions. > These macros are also not y2038 safe. > And, all its use cases can be fulfilled by y2038 > safe ktime_get_* variants. > > Signed-off-by: Deepa Dinamani > Cc: John Stultz > Cc: Thomas Gleixner > Acked-by: John Stultz > Since we can't merge patch 19 yet due to the dependency on John's tree, this will have to wait as well. Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] Fourth draft of the Y2038 design document
On Wed, 22 Jun 2016, Arnd Bergmann wrote: > Regarding the "Support for non-Y2038-safe kernels" section, I'm not > sure if that can work at all: A kernel that does not have the appropriate > system calls will also not have the handlers for a lot of the ioctl > commands and possibly other interfaces that rely on a specific > structure layout. If we can instead enforce that __USE_TIME_BITS64 Maybe it's hard for ioctls, but I see no reason it shouldn't work for applications using normal non-ioctl glibc interfaces, with runtime fallbacks in glibc such as have been used for plenty of previous kernel features. Of course eventually we remove support for the older kernels - when they are no longer on the list at https://www.kernel.org/category/releases.html unless something comes up like the issue with people expecting to use new glibc on old virtualization solutions only supporting 2.6.32 kernels - but it would be good for people and distributions to be using / testing _TIME_BITS=64 before they reach the point of ceasing to support any older kernels. -- Joseph S. Myers jos...@codesourcery.com ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH v2 19/24] fnic: Use time64_t to represent trace timestamps
On Sunday, June 19, 2016 5:27:18 PM CEST Deepa Dinamani wrote: > trace timestamps use struct timespec and CURRENT_TIME which > are not y2038 safe. > These timestamps are only part of the trace log on the machine > and are not shared with the fnic. > Replace then with y2038 safe struct timespec64 and > ktime_get_real_ts64(), respectively. > > Note that change to add time64_to_tm() is already part of John's > kernel tree: https://lkml.org/lkml/2016/6/17/875 . > While the patch looks good, I think it can't be part of this series now, since it has to go on top of that first patch, rather than merged in parallel. When you send a pull request, please leave it out and submit this one separately after 4.8-rc1. Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH v2 09/24] fs: udf: Replace CURRENT_TIME with current_time()
On Sunday, June 19, 2016 5:27:08 PM CEST Deepa Dinamani wrote: > mutex_lock(&sbi->s_alloc_mutex); > lvidiu->impIdent.identSuffix[0] = UDF_OS_CLASS_UNIX; > lvidiu->impIdent.identSuffix[1] = UDF_OS_ID_LINUX; > + ktime_get_real_ts(&ts); > udf_time_to_disk_stamp(&lvid->recordingDateAndTime, > - CURRENT_TIME); > + timespec_trunc(ts, sb->s_time_gran)); > lvid->integrityType = cpu_to_le32(LVID_INTEGRITY_TYPE_OPEN); > > lvid->descTag.descCRC = cpu_to_le16( > I think we don't need the timespec_trunc here, and introducing the call might complicate matters in the future. IMHO timespec_trunc() really only makes sense when assigning into an inode timestamp, whereas udf_time_to_disk_stamp() already truncates the resulting nanoseconds to microseconds. Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH v2 07/24] fs: ubifs: Replace CURRENT_TIME_SEC with current_time
On Sunday, June 19, 2016 5:27:06 PM CEST Deepa Dinamani wrote: > @@ -84,6 +84,8 @@ static int create_default_filesystem(struct ubifs_info *c) > int min_leb_cnt = UBIFS_MIN_LEB_CNT; > long long tmp64, main_bytes; > __le64 tmp_le64; > + __le32 tmp_le32; > + struct timespec ts; > > /* Some functions called from here depend on the @c->key_len filed */ > c->key_len = UBIFS_SK_LEN; > @@ -297,13 +299,17 @@ static int create_default_filesystem(struct ubifs_info > *c) > ino->ch.node_type = UBIFS_INO_NODE; > ino->creat_sqnum = cpu_to_le64(++c->max_sqnum); > ino->nlink = cpu_to_le32(2); > - tmp_le64 = cpu_to_le64(CURRENT_TIME_SEC.tv_sec); > + > + ktime_get_real_ts(&ts); > + ts = timespec_trunc(ts, DEFAULT_TIME_GRAN); > + tmp_le64 = cpu_to_le64(ts.tv_sec); > ino->atime_sec = tmp_le64; > ino->ctime_sec = tmp_le64; > ino->mtime_sec = tmp_le64; > - ino->atime_nsec = 0; > - ino->ctime_nsec = 0; > - ino->mtime_nsec = 0; > + tmp_le32 = cpu_to_le32(ts.tv_nsec); > + ino->atime_nsec = tmp_le32; > + ino->ctime_nsec = tmp_le32; > + ino->mtime_nsec = tmp_le32; This part of the patch seems independent of the rest, as you don't actually use current_time() here, or assign the timespec to an inode. I'd suggest either leaving this part out of the patch series for now, or making it a separate patch that uses timespec64 directly. Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH v2 06/24] fs: ext4: Use current_time() for inode timestamps
On Sunday, June 19, 2016 5:27:05 PM CEST Deepa Dinamani wrote: > @@ -3727,6 +3727,7 @@ static int ext4_cross_rename(struct inode *old_dir, > struct dentry *old_dentry, > }; > u8 new_file_type; > int retval; > + struct timespec ctime; > > if ((ext4_encrypted_inode(old_dir) || > ext4_encrypted_inode(new_dir)) && > @@ -3829,8 +3830,9 @@ static int ext4_cross_rename(struct inode *old_dir, > struct dentry *old_dentry, > * Like most other Unix systems, set the ctime for inodes on a > * rename. > */ > - old.inode->i_ctime = ext4_current_time(old.inode); > - new.inode->i_ctime = ext4_current_time(new.inode); > + ctime = current_time(old.inode); > + old.inode->i_ctime = ctime; > + new.inode->i_ctime = ctime; > ext4_mark_inode_dirty(handle, old.inode); > ext4_mark_inode_dirty(handle, new.inode); > Adding a local variable here looks like it is going to cause us trouble when we change the return type of current_time() to timespec64. I'd write this as new.inode->i_ctime = old.inode->i_ctime; instead. Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] Fourth draft of the Y2038 design document
On Wednesday, June 22, 2016 12:58:38 AM CEST Albert ARIBAUD wrote: > Hi all, > > I have produced a fourth draft of what will eventually become the Y2038 > design document: > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=83 > > Relative to the previous draft: > > * the scope clarifies that *only* Y2038 is considered, and no other >doomsday such as Y2106 or Y; > > * all types directly or indirectly derived from time_t are now listed; > > * all APIs using these types are now listed; > > * all functions which use time_t internally are now listed; > > * also listed are types and APIs related to time but which are >Y2038-safe (even though they might be unsafe for some other >doomsday, e.g. struct rpc_timeval being Y2106-unsafe). > > As always, comments welcome. I've cross-checked your list of data structures with the one I have for the kernel at https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T_0YiQwis/edit#gid=0 I noticed 'struct sysinfo' as another interface that holds a time, even though this is documented as 'long' and I concluded that we won't need to change it, that should probably be documented. 'struct rusage' is also interesting, as there is no overflow in 2038, but instead it could overflow on large machines (hundreds of CPUs) with very long-running tasks (months), so I'm unsure how to treat that from the kernel side. It's also one of very few kernel interfaces using 'timeval' rather than 'timespec' (we generally replaced the other ones). My current kernel patch series changes rusage by using 64-bit fields for everything, with the intention of having the same binary layout for 32-bit and 64-bit processes, and reusing the 64-bit syscall entry point for compat mode (running 32-bit tasks on a 64-bit kernel). Does that work for you? I think we should expand the ioctl section a bit: I can do most of it in the kernel, but need help from glibc for a few things in which we need to agree on calling conventions. Here is what I'd suggest having in the document, feel free to take that into your document or edit as you wish: == IOCTLs and Y2038 == Some Linux IOCTLs may be Y2038-unsafe, or use types defined by glibc that do not match the kernel internal types. Known important cases are: - An ioctl command number is defined using the _IOR/_IOW/_IORW macros by the kernel with a structure whose size changes based on glibc's time_t. The kernel can handle these transparently by implementing handlers for both command numbers with the correct structure format. - The binary ABI changes based on the glibc time_t type, but the command number does not change. In this case, the kernel header files defining the data structure will check the "__USE_TIME_BITS64" macro [do we need a new macro for the kernel headers?] to provide a different command number for the new data structure layout. glibc will define this macro at an appropriate location [where?] to make it visible before including kernel header files. - An ioctl command passes time information in a structure that is not based on time_t but another integer type that does not get changed. The kernel header files will provide both a new structure layout and command number when "__USE_TIME_BITS64" is set. [I can find examples for ioctl commands in each of those categories if needed.] == Socket options == Like ioctl(), setsockopt()/getsockopt() has a few interfaces that are passing time data: SO_TIMESTAMP/SO_TIMESTAMPNS/SO_TIMESTAMPING: These enable the timestamping infrastructure for a socket, which will consecutively return data to user space using "cmsg" data on the socket. The kernel does not know the layout of 'struct timespec' and 'struct timeval' when filling the cmsg data, so we need to define new binary values for the three flags, which then get used if __USE_TIME_BITS64 is set. SO_RCVTIMEO/SO_SNTTIMEO: These pass a 'struct timeval' and a length. Assuming that the 'optlen' argument of the setsockopt syscall always matches the size of 'struct timeval', the kernel will be able to access the data in the same format that was passed by glibc. [alternatively, we could handle this the same way as SO_TIMESTAMP*, using new numbers for the flags]. [end quote] Regarding the "Support for non-Y2038-safe kernels" section, I'm not sure if that can work at all: A kernel that does not have the appropriate system calls will also not have the handlers for a lot of the ioctl commands and possibly other interfaces that rely on a specific structure layout. If we can instead enforce that __USE_TIME_BITS64 is only set with a minimal version of kernel headers and that it implies binary compatibility with no older kernel version, we could avoid those problems. On your note "The implementation needs further thinking about, as application code defining _TIME_BITS=64 and gets built against new kernel headers and old GLIBC headers, then GLIBC will use 32-bit time_t and kern
