[Ocfs2-devel] [PATCH v4 17/26] fs: ocfs2: Use time64_t to represent orphan scan times

[Ocfs2-devel] [PATCH v4 17/26] fs: ocfs2: Use time64_t to represent orphan scan times

[Deepa Dinamani]

struct timespec is not y2038 safe.
Use time64_t which is y2038 safe to represent orphan
scan times.
time64_t is sufficient here as only the seconds delta
times are relevant.

Also use appropriate time functions that return time in
time64_t format. Time functions now return monotonic
time instead of real time as only delta scan times are
relevant and these values are not persistent across
reboots.

The format string for the debug print is still using long
as this is only the time elapsed since the last scan and
long is sufficient to represent this value.

Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: ocfs2-devel at oss.oracle.com
---
 fs/ocfs2/journal.c | 4 ++--
 fs/ocfs2/ocfs2.h   | 2 +-
 fs/ocfs2/super.c   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c
index a244f14..d5e5fa7 100644
--- a/fs/ocfs2/journal.c
+++ b/fs/ocfs2/journal.c
@@ -1947,7 +1947,7 @@ static void ocfs2_queue_orphan_scan(struct ocfs2_super *osb)
 	 */
 	seqno++;
 	os->os_count++;
-	os->os_scantime = CURRENT_TIME;
+	os->os_scantime = ktime_get_seconds();
 unlock:
 	ocfs2_orphan_scan_unlock(osb, seqno);
 out:
@@ -2004,7 +2004,7 @@ void ocfs2_orphan_scan_start(struct ocfs2_super *osb)
 	struct ocfs2_orphan_scan *os;
 
 	os = &osb->osb_orphan_scan;
-	os->os_scantime = CURRENT_TIME;
+	os->os_scantime = ktime_get_seconds();
 	if (ocfs2_is_hard_readonly(osb) || ocfs2_mount_local(osb))
 		atomic_set(&os->os_state, ORPHAN_SCAN_INACTIVE);
 	else {
diff --git a/fs/ocfs2/ocfs2.h b/fs/ocfs2/ocfs2.h
index e63af7d..7e5958b 100644
--- a/fs/ocfs2/ocfs2.h
+++ b/fs/ocfs2/ocfs2.h
@@ -224,7 +224,7 @@ struct ocfs2_orphan_scan {
 	struct ocfs2_super 	*os_osb;
 	struct ocfs2_lock_res 	os_lockres;     /* lock to synchronize scans */
 	struct delayed_work 	os_orphan_scan_work;
-	struct timespec		os_scantime;  /* time this node ran the scan */
+	time64_t		os_scantime;  /* time this node ran the scan */
 	u32			os_count;      /* tracks node specific scans */
 	u32  			os_seqno;       /* tracks cluster wide scans */
 	atomic_t		os_state;              /* ACTIVE or INACTIVE */
diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c
index 603b28d..bf3ca30 100644
--- a/fs/ocfs2/super.c
+++ b/fs/ocfs2/super.c
@@ -337,7 +337,7 @@ static int ocfs2_osb_dump(struct ocfs2_super *osb, char *buf, int len)
 		out += snprintf(buf + out, len - out, "Disabled\n");
 	else
 		out += snprintf(buf + out, len - out, "%lu seconds ago\n",
-				(get_seconds() - os->os_scantime.tv_sec));
+				(unsigned long)(ktime_get_seconds() - os->os_scantime));
 
 	out += snprintf(buf + out, len - out, "%10s => %3s  %10s\n",
 			"Slots", "Num", "RecoGen");
-- 
1.9.1

[Ocfs2-devel] [PATCH v4 18/26] fs: ocfs2: Replace CURRENT_TIME macro

[Deepa Dinamani]

CURRENT_TIME is not y2038 safe.

Use y2038 safe ktime_get_real_seconds() here for timestamps.
struct heartbeat_block's hb_seq and deletetion time are already
64 bits wide and accommodate times beyond y2038.

Also use y2038 safe ktime_get_real_ts64() for on disk inode
timestamps.
These are also wide enough to accommodate time64_t.

Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: ocfs2-devel at oss.oracle.com
---
 fs/ocfs2/cluster/heartbeat.c | 2 +-
 fs/ocfs2/inode.c             | 2 +-
 fs/ocfs2/namei.c             | 6 ++++--
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index 636abcb..9158c98 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -741,7 +741,7 @@ static inline void o2hb_prepare_block(struct o2hb_region *reg,
 	hb_block = (struct o2hb_disk_heartbeat_block *)slot->ds_raw_block;
 	memset(hb_block, 0, reg->hr_block_bytes);
 	/* TODO: time stuff */
-	cputime = CURRENT_TIME.tv_sec;
+	cputime = ktime_get_real_seconds();
 	if (!cputime)
 		cputime = 1;
 
diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
index c56a767..382401d 100644
--- a/fs/ocfs2/inode.c
+++ b/fs/ocfs2/inode.c
@@ -703,7 +703,7 @@ static int ocfs2_remove_inode(struct inode *inode,
 		goto bail_commit;
 	}
 
-	di->i_dtime = cpu_to_le64(CURRENT_TIME.tv_sec);
+	di->i_dtime = cpu_to_le64(ktime_get_real_seconds());
 	di->i_flags &= cpu_to_le32(~(OCFS2_VALID_FL | OCFS2_ORPHANED_FL));
 	ocfs2_journal_dirty(handle, di_bh);
 
diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c
index e2747d8..6a7bf9a 100644
--- a/fs/ocfs2/namei.c
+++ b/fs/ocfs2/namei.c
@@ -516,6 +516,7 @@ static int __ocfs2_mknod_locked(struct inode *dir,
 	struct ocfs2_extent_list *fel;
 	u16 feat;
 	struct ocfs2_inode_info *oi = OCFS2_I(inode);
+	struct timespec64 ts;
 
 	*new_fe_bh = NULL;
 
@@ -564,10 +565,11 @@ static int __ocfs2_mknod_locked(struct inode *dir,
 	fe->i_last_eb_blk = 0;
 	strcpy(fe->i_signature, OCFS2_INODE_SIGNATURE);
 	fe->i_flags |= cpu_to_le32(OCFS2_VALID_FL);
+	ktime_get_real_ts64(&ts);
 	fe->i_atime = fe->i_ctime = fe->i_mtime =
-		cpu_to_le64(CURRENT_TIME.tv_sec);
+		cpu_to_le64(ts.tv_sec);
 	fe->i_mtime_nsec = fe->i_ctime_nsec = fe->i_atime_nsec =
-		cpu_to_le32(CURRENT_TIME.tv_nsec);
+		cpu_to_le32(ts.tv_nsec);
 	fe->i_dtime = 0;
 
 	/*
-- 
1.9.1

[Ocfs2-devel] [GIT PULL] [PATCH v4 00/26] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

[Deepa Dinamani]

Thank you for the suggestion.

> Who are you execting to pull this huge patch series?

The last pull request was addressed to Al as per Arnd's suggestion.
I'm not completely sure who should it be addressed to.

> Why not just introduce the new api call, wait for that to be merged, and
> then push the individual patches through the different subsystems?
> After half of those get ignored, then provide a single set of patches
> that can go through Andrew or my trees.

Arnd and I tried to do this a few ways.

We can try to introduce the api first like you suggest.

There are a few Acks already on the patches.
And, patches 2-5 also need to be merged through some common tree like
yours or Andrew's as you suggest.

So, if everyone is ok, I could do the following:

1. Post patches 1-5 for rc-2.
2. Post all other patches to respective maintainers after rc-2
3. Then after patches get ignored or merged, post remaining as a
series for you or Andrew to pick up.

-Deepa

[Ocfs2-devel] [GIT PULL] [PATCH v4 00/26] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

[Greg KH]

On Tue, Aug 16, 2016 at 11:18:52AM -0700, Deepa Dinamani wrote:
> Thank you for the suggestion.
> 
> > Who are you execting to pull this huge patch series?
> 
> The last pull request was addressed to Al as per Arnd's suggestion.
> I'm not completely sure who should it be addressed to.
> 
> > Why not just introduce the new api call, wait for that to be merged, and
> > then push the individual patches through the different subsystems?
> > After half of those get ignored, then provide a single set of patches
> > that can go through Andrew or my trees.
> 
> Arnd and I tried to do this a few ways.
> 
> We can try to introduce the api first like you suggest.
> 
> There are a few Acks already on the patches.
> And, patches 2-5 also need to be merged through some common tree like
> yours or Andrew's as you suggest.
> 
> So, if everyone is ok, I could do the following:
> 
> 1. Post patches 1-5 for rc-2.

-rc2 is already released, and we aren't adding new apis this late in the
release cycle, sorry.

> 2. Post all other patches to respective maintainers after rc-2
> 3. Then after patches get ignored or merged, post remaining as a
> series for you or Andrew to pick up.

The apis need to be aimed for 4.9-rc1, it's too late for 4.8, sorry.

greg k-h

[Ocfs2-devel] [GIT PULL] [PATCH v4 00/26] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

[Arnd Bergmann]

On Monday, August 15, 2016 6:23:12 PM CEST Greg KH wrote:
> On Sat, Aug 13, 2016 at 03:48:12PM -0700, Deepa Dinamani wrote:
> > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros.
> > The macros are not y2038 safe. There is no plan to transition them into being
> > y2038 safe.
> > ktime_get_* api's can be used in their place. And, these are y2038 safe.
> 
> Who are you execting to pull this huge patch series?

Dave Chinner suggested to have Al Viro pick up the whole series.

> Why not just introduce the new api call, wait for that to be merged, and
> then push the individual patches through the different subsystems?
> After half of those get ignored, then provide a single set of patches
> that can go through Andrew or my trees.

That was the original approach for v4.7, but (along with requesting
a number of reworks that Deepa incorporated), Linus preferred doing
the API change done in one chunk, see
https://patchwork.kernel.org/patch/9134249/

	Arnd