32 bit systems using 'time_t' will break in the year 2038, so
we modify the code appropriately.
This patch removes the cast to 'time_t' in the assignment statement
since we are eventually removing the time_t definition from the kernel
as an effort to solve the y2038 problem.
This change impacts the layout of the structure retrieving profile
data as it is being used in a vendor specific command that can get
sent from user space and thus requires change in the ioctl interface.
Signed-off-by: Amitoj Kaur Chawla <amitoj1606(a)gmail.com>
---
drivers/scsi/bfa/bfa_fcpim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/bfa/bfa_fcpim.c b/drivers/scsi/bfa/bfa_fcpim.c
index 6730340..e5c211f 100644
--- a/drivers/scsi/bfa/bfa_fcpim.c
+++ b/drivers/scsi/bfa/bfa_fcpim.c
@@ -1478,7 +1478,7 @@ bfa_itnim_get_ioprofile(struct bfa_itnim_s *itnim,
return BFA_STATUS_IOPROFILE_OFF;
itnim->ioprofile.index = BFA_IOBUCKET_MAX;
- itnim->ioprofile.io_profile_start_time = (u32)(time_t)
+ itnim->ioprofile.io_profile_start_time = (u32)
bfa_io_profile_start_time(itnim->bfa);
itnim->ioprofile.clock_res_mul = bfa_io_lat_clock_res_mul;
itnim->ioprofile.clock_res_div = bfa_io_lat_clock_res_div;
--
1.9.1
Changes the defintion of the pointer _expiry from time_t to
time64_t. This is to handle the Y2038 problem where time_t
will overflow in 2038. The change is safe because the kernel
subsystems that call dns_query pass NULL.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Aya Mahfouz <mahfouz.saif.elyazal(a)gmail.com>
---
Changelog:
v1: The changes were originally made by Arnd Bergmann in
relation to time_t. I've broken down a patch sent to me to
two independent patches.
include/linux/dns_resolver.h | 2 +-
net/dns_resolver/dns_query.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/dns_resolver.h b/include/linux/dns_resolver.h
index cc92268..6ac3cad 100644
--- a/include/linux/dns_resolver.h
+++ b/include/linux/dns_resolver.h
@@ -27,7 +27,7 @@
#ifdef __KERNEL__
extern int dns_query(const char *type, const char *name, size_t namelen,
- const char *options, char **_result, time_t *_expiry);
+ const char *options, char **_result, time64_t *_expiry);
#endif /* KERNEL */
diff --git a/net/dns_resolver/dns_query.c b/net/dns_resolver/dns_query.c
index 4677b6f..ecc28cf 100644
--- a/net/dns_resolver/dns_query.c
+++ b/net/dns_resolver/dns_query.c
@@ -67,7 +67,7 @@
* Returns the size of the result on success, -ve error code otherwise.
*/
int dns_query(const char *type, const char *name, size_t namelen,
- const char *options, char **_result, time_t *_expiry)
+ const char *options, char **_result, time64_t *_expiry)
{
struct key *rkey;
const struct user_key_payload *upayload;
--
2.4.3
--
Kind Regards,
Aya Saif El-yazal Mahfouz
You have received a new fax.
Please, download fax document attached to this email.
Scanned at: Tue, 17 Nov 2015 19:33:14 +0300
Scanned by: Reginald Fritz
Resolution: 600 DPI
Pages sent: 4
Document name: scanned-0000619186.doc
Filesize: 184 Kb
Scanned in: 35 seconds
Thanks for using Interfax service!
The hpfs code uses time_t which will overflow at 2038.
If time_t is only internal used without being stored on disk, simply
replacing it with time64_t is fine. Otherwise, since the range of
time has been already lost when it is stored on disk, the only thing
we can do is a cast between 32-bit value and time64_t so as to remove
time_t.
DengChao (2):
fs:hpfs:Remove internal using time_t
fs:hpfs:Remove time_t used on disk
fs/hpfs/hpfs_fn.h | 26 ++++++++++++++++++++++----
fs/hpfs/namei.c | 21 +++++++++++++++------
2 files changed, 37 insertions(+), 10 deletions(-)
--
1.9.1
A new fax document for you.
Please check your fax document in the attachment to this e-mail.
Scan duration: 57 seconds
Date of scan: Tue, 17 Nov 2015 00:37:47 +0300
From: Adam Newell
Pages scanned: 3
Fax name: document-0000827154.doc
Filesize: 216 Kb
Scan quality: 500 DPI
Thank you for using Interfax!
What is the correct set of compile tests needed for these y2038 changes?
I've simply done 32 and 64 bit compiles and am concerned with what I may
be missing.
Please point me to any relevant documentation.
Thanks,
Alison
Here is the fourth version for converting parport device(ppdev) to
y2038 safe. The first three could found at [1], [2], [3].
An y2038 safe application/kernel use 64bit time_t(aka time64_t)
instead of 32bit time_t. There are the 5 cases need to support:
summary |u:arch |u:tv_sec |k:arch |k:tv_sec
-------------------|-------|---------|-------|--------
32_y2038_unsafe |32 |32 |32 |32
32_y2038_safe |32 |64 |32 |64
compat_y2038_unsafe|32 |32 |64 |64
compat_y2038_safe |32 |64 |64 |64
64_y2038_safe |64 |64 |64 |64
notes:
1. xxx_y2038_safe/unsafe. 32 means app running on the 32bit
kernel. Compat means 32bit app running on 64bit kernel. 64
means 64bit app running on 64bit kernel.
2. 1.3.5 are the original one, we need keep the compatability.
2,4 is new one we need to support.
There are different ways to do this. Convert to 64bit time and/or
define COMPAT_USE_64BIT_TIME 0 or 1 to indicate y2038 safe or unsafe.
But it is not mean that we need to convert all the time relative
struct to 64bit. Because some time relative struct(e.g. timeval in
ppdev.c) is mainly the offset of the real time.
The main issue in ppdev.c is PPSETTIME/PPGETTIME which transfer
timeval between user space and kernel. My approach here is handle them
as different ioctl command.
Build successful on arm64 and arm.
Changes since V3:
1. create pp_set_timeout, pp_get_timeout to reduce the duplicated
code in my patch according to the suggestion of arnd.
I use div_u64_rem instead of jiffies_to_timespec64 because
it could save a divide operaion.
[1] https://lists.linaro.org/pipermail/y2038/2015-June/000522.html
[2] https://lists.linaro.org/pipermail/y2038/2015-June/000567.html
[3] https://lists.linaro.org/pipermail/y2038/2015-November/001093.html
Bamvor Jian Zhang (2):
ppdev: convert to y2038 safe
ppdev: add support for compat ioctl
drivers/char/ppdev.c | 91 ++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 71 insertions(+), 20 deletions(-)
--
2.1.4
You have a new fax!
To view it please open the attachment.
Pages scanned: 8
Author: Ronald Williams
Date of scan: Sun, 15 Nov 2015 19:23:36 +0300
Scan time: 52 seconds
File size: 155 Kb
Scan quality: 500 DPI
File name: document-00000125821.doc
Thanks for choosing Interfax!
