Re: [Y2038] [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
On 16/06/09, Steve Grubb wrote: > On Thursday, June 09, 2016 07:59:43 PM Richard Guy Briggs wrote: > > On 16/06/09, Steve Grubb wrote: > > > On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote: > > > > struct timespec is not y2038 safe. > > > > Audit timestamps are recorded in string format into > > > > an audit buffer for a given context. > > > > These mark the entry timestamps for the syscalls. > > > > Use y2038 safe struct timespec64 to represent the times. > > > > The log strings can handle this transition as strings can > > > > hold upto 1024 characters. > > > > > > Have you tested this with ausearch or any audit utilities? As an aside, a > > > time stamp that is up to 1024 characters long is terribly wasteful > > > considering how many events we get. > > > > Steve, > > > > I don't expect the size of the time stamp text to change since the > > format isn't being changed and I don't expect the date stamp text length > > to change until Y10K, but you never know what will happen in 8 > > millenia... (Who knows, maybe that damn Linux server in my basement > > will still be running then...) > > > > Isn't the maximum message length MAX_AUDIT_MESSAGE_LENGTH (8970 octets)? > > Bytes, yes. But I was thinking that if its going to get big we should > consider > switching from a base 10 representation to base 16. That would give us back a > few bytes. We discuss this on the linux-audit list rather than the main list. This seems like a false economy to me. If I understand correctly, it will be 285 years before we roll the next text digit. The next binary digit in the internal kernel format is in 22 years. I know there have been discussions about changing to a binary format, which seems to have a lot more to offer than breaking the current format for a few bytes. Is this not the linux-audit main list? Is there another one I am missing? > -Steve - RGB -- Richard Guy Briggs Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635 ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 06/21] fs: udf: Replace CURRENT_TIME with current_fs_time()
On Thu, Jun 9, 2016 at 12:41 AM, Jan Kara wrote: > On Wed 08-06-16 22:04:50, Deepa Dinamani wrote: >> Logical Volume Integrity format is described to have the >> same timestamp format for "Recording Date and time" as >> the other [a,c,m]timestamps. >> Hence using current_fs_time() instead here promises to >> maintain the same granularity as other timestamps. >> > Just one nit below. > >> @@ -2030,7 +2030,7 @@ static void udf_close_lvid(struct super_block *sb) >> - udf_time_to_disk_stamp(&lvid->recordingDateAndTime, CURRENT_TIME); >> + udf_time_to_disk_stamp(&lvid->recordingDateAndTime, >> current_fs_time(sb)); > > Please wrap this line properly so that it does not exceed 80 characters. > Other than that feel free to add: > > Reviewed-by: Jan Kara Thanks, I will take care of this in v2 of the patch series. - Deepa ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
On Thu, Jun 9, 2016 at 7:31 AM, Steve Grubb wrote: > On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote: >> Audit timestamps are recorded in string format into >> an audit buffer for a given context. >> These mark the entry timestamps for the syscalls. >> Use y2038 safe struct timespec64 to represent the times. >> The log strings can handle this transition as strings can >> hold upto 1024 characters. > > Have you tested this with ausearch or any audit utilities? As an aside, a time > stamp that is up to 1024 characters long is terribly wasteful considering how > many events we get. /* AUDIT_BUFSIZ is the size of the temporary buffer used for formatting * audit records. Since printk uses a 1024 byte buffer, this buffer * should be at least that large. */ #define AUDIT_BUFSIZ 1024 The commit text is pointing out that the reserve space ensured in each call to audit_log_vformat is already much more than is needed by this call from audit_log_start. Also, since struct timespec64 is already the same as struct timespec on 64-bit systems, there is really no functional change except on 32-bit machines. Let me know if you want me to try it out on a 32-bit system. -Deepa ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
On Thursday, June 09, 2016 07:59:43 PM Richard Guy Briggs wrote: > On 16/06/09, Steve Grubb wrote: > > On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote: > > > struct timespec is not y2038 safe. > > > Audit timestamps are recorded in string format into > > > an audit buffer for a given context. > > > These mark the entry timestamps for the syscalls. > > > Use y2038 safe struct timespec64 to represent the times. > > > The log strings can handle this transition as strings can > > > hold upto 1024 characters. > > > > Have you tested this with ausearch or any audit utilities? As an aside, a > > time stamp that is up to 1024 characters long is terribly wasteful > > considering how many events we get. > > Steve, > > I don't expect the size of the time stamp text to change since the > format isn't being changed and I don't expect the date stamp text length > to change until Y10K, but you never know what will happen in 8 > millenia... (Who knows, maybe that damn Linux server in my basement > will still be running then...) > > Isn't the maximum message length MAX_AUDIT_MESSAGE_LENGTH (8970 octets)? Bytes, yes. But I was thinking that if its going to get big we should consider switching from a base 10 representation to base 16. That would give us back a few bytes. We discuss this on the linux-audit list rather than the main list. -Steve ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
On 16/06/09, Steve Grubb wrote: > On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote: > > struct timespec is not y2038 safe. > > Audit timestamps are recorded in string format into > > an audit buffer for a given context. > > These mark the entry timestamps for the syscalls. > > Use y2038 safe struct timespec64 to represent the times. > > The log strings can handle this transition as strings can > > hold upto 1024 characters. > > Have you tested this with ausearch or any audit utilities? As an aside, a > time > stamp that is up to 1024 characters long is terribly wasteful considering how > many events we get. Steve, I don't expect the size of the time stamp text to change since the format isn't being changed and I don't expect the date stamp text length to change until Y10K, but you never know what will happen in 8 millenia... (Who knows, maybe that damn Linux server in my basement will still be running then...) Isn't the maximum message length MAX_AUDIT_MESSAGE_LENGTH (8970 octets)? > -Steve > > > Signed-off-by: Deepa Dinamani > > Cc: Paul Moore > > Cc: Eric Paris > > Cc: linux-au...@redhat.com > > --- > > include/linux/audit.h | 4 ++-- > > kernel/audit.c| 10 +- > > kernel/audit.h| 2 +- > > kernel/auditsc.c | 6 +++--- > > 4 files changed, 11 insertions(+), 11 deletions(-) > > > > diff --git a/include/linux/audit.h b/include/linux/audit.h > > index 961a417..2f6a1123 100644 > > --- a/include/linux/audit.h > > +++ b/include/linux/audit.h > > @@ -335,7 +335,7 @@ static inline void audit_ptrace(struct task_struct *t) > > /* Private API (for audit.c only) */ > > extern unsigned int audit_serial(void); > > extern int auditsc_get_stamp(struct audit_context *ctx, > > - struct timespec *t, unsigned int *serial); > > + struct timespec64 *t, unsigned int *serial); > > extern int audit_set_loginuid(kuid_t loginuid); > > > > static inline kuid_t audit_get_loginuid(struct task_struct *tsk) > > @@ -510,7 +510,7 @@ static inline void __audit_seccomp(unsigned long > > syscall, long signr, int code) static inline void audit_seccomp(unsigned > > long syscall, long signr, int code) { } > > static inline int auditsc_get_stamp(struct audit_context *ctx, > > - struct timespec *t, unsigned int *serial) > > + struct timespec64 *t, unsigned int *serial) > > { > > return 0; > > } > > diff --git a/kernel/audit.c b/kernel/audit.c > > index 22bb4f2..6c2f405 100644 > > --- a/kernel/audit.c > > +++ b/kernel/audit.c > > @@ -1325,10 +1325,10 @@ unsigned int audit_serial(void) > > } > > > > static inline void audit_get_stamp(struct audit_context *ctx, > > - struct timespec *t, unsigned int *serial) > > + struct timespec64 *t, unsigned int *serial) > > { > > if (!ctx || !auditsc_get_stamp(ctx, t, serial)) { > > - *t = CURRENT_TIME; > > + ktime_get_real_ts64(t); > > *serial = audit_serial(); > > } > > } > > @@ -1370,7 +1370,7 @@ struct audit_buffer *audit_log_start(struct > > audit_context *ctx, gfp_t gfp_mask, int type) > > { > > struct audit_buffer *ab = NULL; > > - struct timespec t; > > + struct timespec64 t; > > unsigned intuninitialized_var(serial); > > int reserve = 5; /* Allow atomic callers to go up to five > > entries over the normal backlog limit */ > > @@ -1422,8 +1422,8 @@ struct audit_buffer *audit_log_start(struct > > audit_context *ctx, gfp_t gfp_mask, > > > > audit_get_stamp(ab->ctx, &t, &serial); > > > > - audit_log_format(ab, "audit(%lu.%03lu:%u): ", > > -t.tv_sec, t.tv_nsec/100, serial); > > + audit_log_format(ab, "audit(%llu.%03lu:%u): ", > > +(unsigned long long)t.tv_sec, t.tv_nsec/100, > > serial); > > return ab; > > } > > > > diff --git a/kernel/audit.h b/kernel/audit.h > > index cbbe6bb..029d674 100644 > > --- a/kernel/audit.h > > +++ b/kernel/audit.h > > @@ -111,7 +111,7 @@ struct audit_context { > > enum audit_statestate, current_state; > > unsigned intserial; /* serial number for record */ > > int major; /* syscall number */ > > - struct timespec ctime; /* time of syscall entry */ > > + struct timespec64 ctime; /* time of syscall entry */ > > unsigned long argv[4];/* syscall arguments */ > > longreturn_code;/* syscall return code */ > > u64 prio; > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > > index 62ab53d..ecebb3c 100644 > > --- a/kernel/auditsc.c > > +++ b/kernel/auditsc.c > > @@ -1523,7 +1523,7 @@ void __audit_syscall_entry(int major, unsigned long > > a1, unsigned long a2, return; > > > > context->serial = 0; > > - context->ctime = C
Re: [Y2038] [PATCH 18/21] fs: nfs: Make nfs boot time y2038 safe
>>boot_time is represented as a struct timespec. >>struct timespec and CURRENT_TIME are not y2038 safe. >>Overall, the plan is to use timespec64 for all internal >>kernel representation of timestamps. >>CURRENT_TIME will also be removed. >>Use struct timespec64 to represent boot_time. >>And, ktime_get_real_ts64() for the boot_time value. >> >>boot_time is used to construct the nfs client boot verifier. >>This will now wrap in 2106 instead of 2038 on 32-bit systems. >>The server only relies on the value being persistent until >>reboot so the wrapping should be fine. > > We really do not give a damn about wraparound here, since the boot time is > only ever compared for an exact match, and the odds of two reboots occurring > exactly 2^32 * 10^9 nanoseconds apart are cosmically small... > If struct timespec is going away, can we just convert this into a ktime_t? timespec64 is the same as timespec already on 64 bit machines. But, yes, we can use ktime_t here. Did you mean the internal storage value or the wire boo_time used for verifier? In case you don't want to change the wire value, then we will have a division operation, every time the verifier needs to be sent. -Deepa -Deepa ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()
On Thu, Jun 9, 2016 at 12:15 PM, Linus Torvalds wrote: > On Thu, Jun 9, 2016 at 12:35 AM, Jan Kara wrote: >> >> You create line longer than 80 characters for affs and reiserfs. Please >> wrap those lines properly. > > No, please do *NOT* do things like that. > > These kind of mechanical patches should > > (a) be as mechanical as possible (and see elsewhere about why I think > 'sb' should be 'inode' and the patch should have been 95% automated > with a trivial script thanks to that change) > > (b) be made as easy to verify visually as possible. > > That (b) means that a conversion should *not* add whitespace fixups or > add other non-mechanical cleanups, because it's a *lot* easier to see > that a conversion like > > - inode->i_mtime = inode->i_ctime = CURRENT_TIME_SEC; > + inode->i_mtime = inode->i_ctime = current_fs_time(inode); > > makes no other changes, but if you start doing line-splitting or other > transformations (add new variables etc to get at 'sb'), suddenly you > have to verify the patch at a completely different level. > > In other words, it's actually really important to make these kinds of > bulk changes be very very obvious. Including to the point of making > them visually easier to scan as a patch by not making any other > changes. Thanks for the guidelines. Only patches 1 and 4 are mechanical. All others need some kind of inspection/ verification. I will keep these in mind for updating 1 and 4. -Deepa ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 18/21] fs: nfs: Make nfs boot time y2038 safe
On 6/9/16, 01:05, "Deepa Dinamani" wrote: >boot_time is represented as a struct timespec. >struct timespec and CURRENT_TIME are not y2038 safe. >Overall, the plan is to use timespec64 for all internal >kernel representation of timestamps. >CURRENT_TIME will also be removed. >Use struct timespec64 to represent boot_time. >And, ktime_get_real_ts64() for the boot_time value. > >boot_time is used to construct the nfs client boot verifier. >This will now wrap in 2106 instead of 2038 on 32-bit systems. >The server only relies on the value being persistent until >reboot so the wrapping should be fine. We really do not give a damn about wraparound here, since the boot time is only ever compared for an exact match, and the odds of two reboots occurring exactly 2^32 * 10^9 nanoseconds apart are cosmically small... If struct timespec is going away, can we just convert this into a ktime_t? Trond Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()
On Thu, Jun 9, 2016 at 12:35 AM, Jan Kara wrote: > > You create line longer than 80 characters for affs and reiserfs. Please > wrap those lines properly. No, please do *NOT* do things like that. These kind of mechanical patches should (a) be as mechanical as possible (and see elsewhere about why I think 'sb' should be 'inode' and the patch should have been 95% automated with a trivial script thanks to that change) (b) be made as easy to verify visually as possible. That (b) means that a conversion should *not* add whitespace fixups or add other non-mechanical cleanups, because it's a *lot* easier to see that a conversion like - inode->i_mtime = inode->i_ctime = CURRENT_TIME_SEC; + inode->i_mtime = inode->i_ctime = current_fs_time(inode); makes no other changes, but if you start doing line-splitting or other transformations (add new variables etc to get at 'sb'), suddenly you have to verify the patch at a completely different level. In other words, it's actually really important to make these kinds of bulk changes be very very obvious. Including to the point of making them visually easier to scan as a patch by not making any other changes. Linus ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 02/21] fs: ext4: Use current_fs_time() for inode timestamps
On Thu, Jun 9, 2016 at 11:45 AM, Linus Torvalds wrote: > > All existing users and all the ones in this patch (and the others too, > although I didn't go through them very carefully) really would prefer > just passing in the inode directly, rather than the superblock. Actually, there seems to be one exception to that "all existing users", and that one exception (btrfs transacation time) really seems to be broken. Exactly because it's *not* setting an inode time, it shouldn't have used current_fs_time() to begin with, because it is just setting an internal filesystem timestamp. So not making the argument inode-related seems to actually encourage people to misuse this function. Linus ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 02/21] fs: ext4: Use current_fs_time() for inode timestamps
On Wed, Jun 8, 2016 at 10:04 PM, Deepa Dinamani wrote: > CURRENT_TIME_SEC and CURRENT_TIME are not y2038 safe. > current_fs_time() will be transitioned to be y2038 safe > along with vfs. > > current_fs_time() returns timestamps according to the > granularities set in the super_block. All existing users and all the ones in this patch (and the others too, although I didn't go through them very carefully) really would prefer just passing in the inode directly, rather than the superblock. So I don't want to add more users of this broken interface. It was a mistake to use the superblock. The fact that the time granularity exists there is pretty much irrelevant. If every single user wants to use an inode pointer, then that is what the function should get. Linus ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote: > struct timespec is not y2038 safe. > Audit timestamps are recorded in string format into > an audit buffer for a given context. > These mark the entry timestamps for the syscalls. > Use y2038 safe struct timespec64 to represent the times. > The log strings can handle this transition as strings can > hold upto 1024 characters. Have you tested this with ausearch or any audit utilities? As an aside, a time stamp that is up to 1024 characters long is terribly wasteful considering how many events we get. -Steve > Signed-off-by: Deepa Dinamani > Cc: Paul Moore > Cc: Eric Paris > Cc: linux-au...@redhat.com > --- > include/linux/audit.h | 4 ++-- > kernel/audit.c| 10 +- > kernel/audit.h| 2 +- > kernel/auditsc.c | 6 +++--- > 4 files changed, 11 insertions(+), 11 deletions(-) > > diff --git a/include/linux/audit.h b/include/linux/audit.h > index 961a417..2f6a1123 100644 > --- a/include/linux/audit.h > +++ b/include/linux/audit.h > @@ -335,7 +335,7 @@ static inline void audit_ptrace(struct task_struct *t) > /* Private API (for audit.c only) */ > extern unsigned int audit_serial(void); > extern int auditsc_get_stamp(struct audit_context *ctx, > - struct timespec *t, unsigned int *serial); > + struct timespec64 *t, unsigned int *serial); > extern int audit_set_loginuid(kuid_t loginuid); > > static inline kuid_t audit_get_loginuid(struct task_struct *tsk) > @@ -510,7 +510,7 @@ static inline void __audit_seccomp(unsigned long > syscall, long signr, int code) static inline void audit_seccomp(unsigned > long syscall, long signr, int code) { } > static inline int auditsc_get_stamp(struct audit_context *ctx, > - struct timespec *t, unsigned int *serial) > + struct timespec64 *t, unsigned int *serial) > { > return 0; > } > diff --git a/kernel/audit.c b/kernel/audit.c > index 22bb4f2..6c2f405 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -1325,10 +1325,10 @@ unsigned int audit_serial(void) > } > > static inline void audit_get_stamp(struct audit_context *ctx, > -struct timespec *t, unsigned int *serial) > +struct timespec64 *t, unsigned int *serial) > { > if (!ctx || !auditsc_get_stamp(ctx, t, serial)) { > - *t = CURRENT_TIME; > + ktime_get_real_ts64(t); > *serial = audit_serial(); > } > } > @@ -1370,7 +1370,7 @@ struct audit_buffer *audit_log_start(struct > audit_context *ctx, gfp_t gfp_mask, int type) > { > struct audit_buffer *ab = NULL; > - struct timespec t; > + struct timespec64 t; > unsigned intuninitialized_var(serial); > int reserve = 5; /* Allow atomic callers to go up to five > entries over the normal backlog limit */ > @@ -1422,8 +1422,8 @@ struct audit_buffer *audit_log_start(struct > audit_context *ctx, gfp_t gfp_mask, > > audit_get_stamp(ab->ctx, &t, &serial); > > - audit_log_format(ab, "audit(%lu.%03lu:%u): ", > - t.tv_sec, t.tv_nsec/100, serial); > + audit_log_format(ab, "audit(%llu.%03lu:%u): ", > + (unsigned long long)t.tv_sec, t.tv_nsec/100, > serial); > return ab; > } > > diff --git a/kernel/audit.h b/kernel/audit.h > index cbbe6bb..029d674 100644 > --- a/kernel/audit.h > +++ b/kernel/audit.h > @@ -111,7 +111,7 @@ struct audit_context { > enum audit_statestate, current_state; > unsigned intserial; /* serial number for record */ > int major; /* syscall number */ > - struct timespec ctime; /* time of syscall entry */ > + struct timespec64 ctime; /* time of syscall entry */ > unsigned long argv[4];/* syscall arguments */ > longreturn_code;/* syscall return code */ > u64 prio; > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index 62ab53d..ecebb3c 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -1523,7 +1523,7 @@ void __audit_syscall_entry(int major, unsigned long > a1, unsigned long a2, return; > > context->serial = 0; > - context->ctime = CURRENT_TIME; > + ktime_get_real_ts64(&context->ctime); > context->in_syscall = 1; > context->current_state = state; > context->ppid = 0; > @@ -1932,13 +1932,13 @@ EXPORT_SYMBOL_GPL(__audit_inode_child); > /** > * auditsc_get_stamp - get local copies of audit_context values > * @ctx: audit_context for the task > - * @t: timespec to store time recorded in the audit_context > + * @t: timespec64 to store time recorded in the audit_context > * @serial: serial value that is recorded in the audit_context > * > * Also sets the c
Re: [Y2038] [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()
On Wed, Jun 08, 2016 at 10:04:45PM -0700, Deepa Dinamani wrote: > CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will > be transitioned to use 64 bit time along with vfs in a > separate patch. > There is no plan to transistion CURRENT_TIME_SEC to use > y2038 safe time interfaces. [...] > Cc: Bob Copeland OMFS parts look sane, thanks. -- Bob Copeland %% http://bobcopeland.com/ ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 06/21] fs: udf: Replace CURRENT_TIME with current_fs_time()
On Wed 08-06-16 22:04:50, Deepa Dinamani wrote: > CURRENT_TIME is not y2038 safe. > > CURRENT_TIME macro is also not appropriate for filesystems > as it doesn't use the right granularity for filesystem > timestamps. > > Logical Volume Integrity format is described to have the > same timestamp format for "Recording Date and time" as > the other [a,c,m]timestamps. > Hence using current_fs_time() instead here promises to > maintain the same granularity as other timestamps. > > This is also in preparation for the patch that transitions > vfs timestamps to use 64 bit time and hence make them > y2038 safe. As part of the effort current_fs_time() will be > extended to do range checks. Just one nit below. > @@ -2030,7 +2030,7 @@ static void udf_close_lvid(struct super_block *sb) > mutex_lock(&sbi->s_alloc_mutex); > lvidiu->impIdent.identSuffix[0] = UDF_OS_CLASS_UNIX; > lvidiu->impIdent.identSuffix[1] = UDF_OS_ID_LINUX; > - udf_time_to_disk_stamp(&lvid->recordingDateAndTime, CURRENT_TIME); > + udf_time_to_disk_stamp(&lvid->recordingDateAndTime, > current_fs_time(sb)); > if (UDF_MAX_WRITE_VERSION > le16_to_cpu(lvidiu->maxUDFWriteRev)) > lvidiu->maxUDFWriteRev = cpu_to_le16(UDF_MAX_WRITE_VERSION); > if (sbi->s_udfrev > le16_to_cpu(lvidiu->minUDFReadRev)) Please wrap this line properly so that it does not exceed 80 characters. Other than that feel free to add: Reviewed-by: Jan Kara Honza -- Jan Kara SUSE Labs, CR ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()
On Wed 08-06-16 22:04:45, Deepa Dinamani wrote: > CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will > be transitioned to use 64 bit time along with vfs in a > separate patch. > There is no plan to transistion CURRENT_TIME_SEC to use > y2038 safe time interfaces. > > current_fs_time() will also be extended to use superblock > range checking parameters when range checking is introduced. > > This works because alloc_super() fills in the the s_time_gran > in super block to NSEC_PER_SEC. > > Also note that filesystem specific times like the birthtime, > creation time that were using same interfaces to obtain time > retain same logistics. You create line longer than 80 characters for affs and reiserfs. Please wrap those lines properly. Other than that feel free to add: Acked-by: Jan Kara Honza -- Jan Kara SUSE Labs, CR ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038