From: Thomas Schmitt scdbackup@gmx.net
Change the return type of function iso_date() from int to time64_t, to avoid truncating to the 1902..2038 date range.
After this patch, the reported timestamps should fall into the range reported in the s_time_min/s_time_max fields.
Signed-off-by: Thomas Schmitt scdbackup@gmx.net Cc: stable@vger.kernel.org Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627 Fixes: 34be4dbf87fc ("isofs: fix timestamps beyond 2027") Fixes: 5ad32b3acded ("isofs: Initialize filesystem timestamp ranges") [arnd: expand changelog text slightly] Signed-off-by: Arnd Bergmann arnd@arndb.de --- fs/isofs/isofs.h | 2 +- fs/isofs/util.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/isofs/isofs.h b/fs/isofs/isofs.h index dcdc191ed183..c3473ca3f686 100644 --- a/fs/isofs/isofs.h +++ b/fs/isofs/isofs.h @@ -106,7 +106,7 @@ static inline unsigned int isonum_733(u8 *p) /* Ignore bigendian datum due to broken mastering programs */ return get_unaligned_le32(p); } -extern int iso_date(u8 *, int); +extern time64_t iso_date(u8 *, int);
struct inode; /* To make gcc happy */
diff --git a/fs/isofs/util.c b/fs/isofs/util.c index e88dba721661..348af786a8a4 100644 --- a/fs/isofs/util.c +++ b/fs/isofs/util.c @@ -16,10 +16,10 @@ * to GMT. Thus we should always be correct. */
-int iso_date(u8 *p, int flag) +time64_t iso_date(u8 *p, int flag) { int year, month, day, hour, minute, second, tz; - int crtime; + time64_t crtime;
year = p[0]; month = p[1];
On Thu, Oct 20, 2022 at 06:00:29PM +0200, Arnd Bergmann wrote:
From: Thomas Schmitt scdbackup@gmx.net
Change the return type of function iso_date() from int to time64_t, to avoid truncating to the 1902..2038 date range.
After this patch, the reported timestamps should fall into the range reported in the s_time_min/s_time_max fields.
Signed-off-by: Thomas Schmitt scdbackup@gmx.net Cc: stable@vger.kernel.org Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627 Fixes: 34be4dbf87fc ("isofs: fix timestamps beyond 2027") Fixes: 5ad32b3acded ("isofs: Initialize filesystem timestamp ranges") [arnd: expand changelog text slightly] Signed-off-by: Arnd Bergmann arnd@arndb.de
Looks good to me, Acked-by: Christian Brauner (Microsoft) brauner@kernel.org
On Thu, 2022-10-20 at 18:00 +0200, Arnd Bergmann wrote:
From: Thomas Schmitt scdbackup@gmx.net
Change the return type of function iso_date() from int to time64_t, to avoid truncating to the 1902..2038 date range.
After this patch, the reported timestamps should fall into the range reported in the s_time_min/s_time_max fields.
Signed-off-by: Thomas Schmitt scdbackup@gmx.net Cc: stable@vger.kernel.org Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627 Fixes: 34be4dbf87fc ("isofs: fix timestamps beyond 2027") Fixes: 5ad32b3acded ("isofs: Initialize filesystem timestamp ranges") [arnd: expand changelog text slightly] Signed-off-by: Arnd Bergmann arnd@arndb.de
fs/isofs/isofs.h | 2 +- fs/isofs/util.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/isofs/isofs.h b/fs/isofs/isofs.h index dcdc191ed183..c3473ca3f686 100644 --- a/fs/isofs/isofs.h +++ b/fs/isofs/isofs.h @@ -106,7 +106,7 @@ static inline unsigned int isonum_733(u8 *p) /* Ignore bigendian datum due to broken mastering programs */ return get_unaligned_le32(p); } -extern int iso_date(u8 *, int); +extern time64_t iso_date(u8 *, int); struct inode; /* To make gcc happy */ diff --git a/fs/isofs/util.c b/fs/isofs/util.c index e88dba721661..348af786a8a4 100644 --- a/fs/isofs/util.c +++ b/fs/isofs/util.c @@ -16,10 +16,10 @@
- to GMT. Thus we should always be correct.
*/ -int iso_date(u8 *p, int flag) +time64_t iso_date(u8 *p, int flag) { int year, month, day, hour, minute, second, tz;
- int crtime;
- time64_t crtime;
year = p[0]; month = p[1];
Reviewed-by: Jeff Layton jlayton@kernel.org
On Thu 20-10-22 18:00:29, Arnd Bergmann wrote:
From: Thomas Schmitt scdbackup@gmx.net
Change the return type of function iso_date() from int to time64_t, to avoid truncating to the 1902..2038 date range.
After this patch, the reported timestamps should fall into the range reported in the s_time_min/s_time_max fields.
Signed-off-by: Thomas Schmitt scdbackup@gmx.net Cc: stable@vger.kernel.org Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627 Fixes: 34be4dbf87fc ("isofs: fix timestamps beyond 2027") Fixes: 5ad32b3acded ("isofs: Initialize filesystem timestamp ranges") [arnd: expand changelog text slightly] Signed-off-by: Arnd Bergmann arnd@arndb.de
Thanks! I've added the patch to my tree and will push it to Linus.
Honza
fs/isofs/isofs.h | 2 +- fs/isofs/util.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/isofs/isofs.h b/fs/isofs/isofs.h index dcdc191ed183..c3473ca3f686 100644 --- a/fs/isofs/isofs.h +++ b/fs/isofs/isofs.h @@ -106,7 +106,7 @@ static inline unsigned int isonum_733(u8 *p) /* Ignore bigendian datum due to broken mastering programs */ return get_unaligned_le32(p); } -extern int iso_date(u8 *, int); +extern time64_t iso_date(u8 *, int); struct inode; /* To make gcc happy */ diff --git a/fs/isofs/util.c b/fs/isofs/util.c index e88dba721661..348af786a8a4 100644 --- a/fs/isofs/util.c +++ b/fs/isofs/util.c @@ -16,10 +16,10 @@
- to GMT. Thus we should always be correct.
*/ -int iso_date(u8 *p, int flag) +time64_t iso_date(u8 *p, int flag) { int year, month, day, hour, minute, second, tz;
- int crtime;
- time64_t crtime;
year = p[0]; month = p[1]; -- 2.29.2
On Mon 24-10-22 14:26:14, Jan Kara wrote:
On Thu 20-10-22 18:00:29, Arnd Bergmann wrote:
From: Thomas Schmitt scdbackup@gmx.net
Change the return type of function iso_date() from int to time64_t, to avoid truncating to the 1902..2038 date range.
After this patch, the reported timestamps should fall into the range reported in the s_time_min/s_time_max fields.
Signed-off-by: Thomas Schmitt scdbackup@gmx.net Cc: stable@vger.kernel.org Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627 Fixes: 34be4dbf87fc ("isofs: fix timestamps beyond 2027") Fixes: 5ad32b3acded ("isofs: Initialize filesystem timestamp ranges") [arnd: expand changelog text slightly] Signed-off-by: Arnd Bergmann arnd@arndb.de
Thanks! I've added the patch to my tree and will push it to Linus.
Oh, I have noticed Andrew has merged the patch already into his tree. So dropped from mine.
Honza
On Mon, 24 Oct 2022 16:51:21 +0200 Jan Kara jack@suse.cz wrote:
Thanks! I've added the patch to my tree and will push it to Linus.
Oh, I have noticed Andrew has merged the patch already into his tree. So dropped from mine.
You could have just added it and I'd drop my copy when Stephen tells us of the duplicate. But whatever.
Maybe you owe us an ISOFS MAINTAINERS entry ;)
On Mon 24-10-22 13:55:17, Andrew Morton wrote:
On Mon, 24 Oct 2022 16:51:21 +0200 Jan Kara jack@suse.cz wrote:
Thanks! I've added the patch to my tree and will push it to Linus.
Oh, I have noticed Andrew has merged the patch already into his tree. So dropped from mine.
You could have just added it and I'd drop my copy when Stephen tells us of the duplicate. But whatever.
Yeah, I know. But since I've just pulled the patch in I figured it's less work if I just take it out as well ;)
Maybe you owe us an ISOFS MAINTAINERS entry ;)
Yeah, I can see isofs currently has no entry in MAINTAINERS. OK, I'll add some ;)
Honza
linux-stable-mirror@lists.linaro.org
-
Andrew Morton -
Arnd Bergmann -
Christian Brauner -
Jan Kara -
Jeff Layton