* [LTP] [PATCH] syscalls/utime03: relax the check for 1 second difference
@ 2025-02-20 9:28 Jan Stancek
2025-02-20 10:51 ` Petr Vorel
2025-02-20 11:17 ` Cyril Hrubis
0 siblings, 2 replies; 11+ messages in thread
From: Jan Stancek @ 2025-02-20 9:28 UTC (permalink / raw)
To: ltp; +Cc: liwan
The test is using tst_get_fs_timestamp() which is using REALTIME_COARSE
clock, which is slightly less accurate. Back in 2022 we added extra log
message to print also min and max time. In those rare instances where
it fails this extra log shows it failed by one second difference.
Relax the check a little. Tested on aarch64 VMs, where it's usually
reproducible after couple hundred iterations.
Signed-off-by: Jan Stancek <jstancek@redhat.com>
---
testcases/kernel/syscalls/utime/utime03.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testcases/kernel/syscalls/utime/utime03.c b/testcases/kernel/syscalls/utime/utime03.c
index 564e1de3dd77..abc2e6338af6 100644
--- a/testcases/kernel/syscalls/utime/utime03.c
+++ b/testcases/kernel/syscalls/utime/utime03.c
@@ -70,7 +70,7 @@ static void run(void)
SAFE_SETEUID(user_uid);
mintime = tst_get_fs_timestamp();
TST_EXP_PASS(utime(TEMP_FILE, NULL));
- maxtime = tst_get_fs_timestamp();
+ maxtime = tst_get_fs_timestamp() + 1;
SAFE_SETEUID(root_uid);
SAFE_STAT(TEMP_FILE, &statbuf);
--
2.43.0
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [LTP] [PATCH] syscalls/utime03: relax the check for 1 second difference
2025-02-20 9:28 [LTP] [PATCH] syscalls/utime03: relax the check for 1 second difference Jan Stancek
@ 2025-02-20 10:51 ` Petr Vorel
2025-02-20 11:17 ` Cyril Hrubis
1 sibling, 0 replies; 11+ messages in thread
From: Petr Vorel @ 2025-02-20 10:51 UTC (permalink / raw)
To: Jan Stancek; +Cc: liwan, ltp
Hi Jan,
> The test is using tst_get_fs_timestamp() which is using REALTIME_COARSE
> clock, which is slightly less accurate. Back in 2022 we added extra log
> message to print also min and max time. In those rare instances where
> it fails this extra log shows it failed by one second difference.
LGTM.
Acked-by: Petr Vorel <pvorel@suse.cz>
> Relax the check a little. Tested on aarch64 VMs, where it's usually
> reproducible after couple hundred iterations.
Thanks for testing!
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [LTP] [PATCH] syscalls/utime03: relax the check for 1 second difference
2025-02-20 9:28 [LTP] [PATCH] syscalls/utime03: relax the check for 1 second difference Jan Stancek
2025-02-20 10:51 ` Petr Vorel
@ 2025-02-20 11:17 ` Cyril Hrubis
2025-02-20 13:44 ` Jan Stancek
1 sibling, 1 reply; 11+ messages in thread
From: Cyril Hrubis @ 2025-02-20 11:17 UTC (permalink / raw)
To: Jan Stancek; +Cc: liwan, ltp
Hi!
> The test is using tst_get_fs_timestamp() which is using REALTIME_COARSE
> clock, which is slightly less accurate. Back in 2022 we added extra log
> message to print also min and max time. In those rare instances where
> it fails this extra log shows it failed by one second difference.
>
> Relax the check a little. Tested on aarch64 VMs, where it's usually
> reproducible after couple hundred iterations.
Aren't we just masking a kernel bug here? Back then we discussed this
with kernel devs and they told us that filesystems use REALTIME_COARSE
internally, so this shouldn't really fail.
What filesystem is this? Does it, by chance, use more granual
timestamps?
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [LTP] [PATCH] syscalls/utime03: relax the check for 1 second difference
2025-02-20 11:17 ` Cyril Hrubis
@ 2025-02-20 13:44 ` Jan Stancek
2025-02-21 8:24 ` Jan Stancek
0 siblings, 1 reply; 11+ messages in thread
From: Jan Stancek @ 2025-02-20 13:44 UTC (permalink / raw)
To: Cyril Hrubis; +Cc: liwan, ltp
On Thu, Feb 20, 2025 at 12:17 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> > The test is using tst_get_fs_timestamp() which is using REALTIME_COARSE
> > clock, which is slightly less accurate. Back in 2022 we added extra log
> > message to print also min and max time. In those rare instances where
> > it fails this extra log shows it failed by one second difference.
> >
> > Relax the check a little. Tested on aarch64 VMs, where it's usually
> > reproducible after couple hundred iterations.
>
> Aren't we just masking a kernel bug here? Back then we discussed this
> with kernel devs and they told us that filesystems use REALTIME_COARSE
> internally, so this shouldn't really fail.
I see the failures resurfacing around 6.13-rc1.
From commit 4e40eff0b573 ("fs: add infrastructure for multigrain timestamps")
the comment on current_time() now says "Return FS time (possibly fine-grained)".
Maybe we hit a point where internals changed? I'll see if I can narrow
it down further
with bisect.
>
> What filesystem is this? Does it, by chance, use more granual
> timestamps?
I saw it fail on ext2, ext3 and xfs.
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [LTP] [PATCH] syscalls/utime03: relax the check for 1 second difference
2025-02-20 13:44 ` Jan Stancek
@ 2025-02-21 8:24 ` Jan Stancek
2025-02-24 11:24 ` [LTP] [PATCH v2] syscalls/utime03: use realtime clock for upper bound check Jan Stancek
0 siblings, 1 reply; 11+ messages in thread
From: Jan Stancek @ 2025-02-21 8:24 UTC (permalink / raw)
To: Cyril Hrubis; +Cc: liwan, ltp
On Thu, Feb 20, 2025 at 2:44 PM Jan Stancek <jstancek@redhat.com> wrote:
>
> On Thu, Feb 20, 2025 at 12:17 PM Cyril Hrubis <chrubis@suse.cz> wrote:
> >
> > Hi!
> > > The test is using tst_get_fs_timestamp() which is using REALTIME_COARSE
> > > clock, which is slightly less accurate. Back in 2022 we added extra log
> > > message to print also min and max time. In those rare instances where
> > > it fails this extra log shows it failed by one second difference.
> > >
> > > Relax the check a little. Tested on aarch64 VMs, where it's usually
> > > reproducible after couple hundred iterations.
> >
> > Aren't we just masking a kernel bug here? Back then we discussed this
> > with kernel devs and they told us that filesystems use REALTIME_COARSE
> > internally, so this shouldn't really fail.
>
> I see the failures resurfacing around 6.13-rc1.
> From commit 4e40eff0b573 ("fs: add infrastructure for multigrain timestamps")
> the comment on current_time() now says "Return FS time (possibly fine-grained)".
It is the series that adds multigrain timestamps. So we could make the maxtime
use REALTIME clock if "+1" second feels too broad.
>
> Maybe we hit a point where internals changed? I'll see if I can narrow
> it down further
> with bisect.
>
> >
> > What filesystem is this? Does it, by chance, use more granual
> > timestamps?
>
> I saw it fail on ext2, ext3 and xfs.
>
> >
> > --
> > Cyril Hrubis
> > chrubis@suse.cz
> >
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 11+ messages in thread
* [LTP] [PATCH v2] syscalls/utime03: use realtime clock for upper bound check
2025-02-21 8:24 ` Jan Stancek
@ 2025-02-24 11:24 ` Jan Stancek
2025-02-24 15:41 ` Cyril Hrubis
0 siblings, 1 reply; 11+ messages in thread
From: Jan Stancek @ 2025-02-24 11:24 UTC (permalink / raw)
To: ltp; +Cc: chhrubis
This test rarely fails with recent kernels (after 6.13-rc1):
tst_test.c:1833: TINFO: === Testing on ext4 ===
tst_test.c:1170: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
mke2fs 1.47.2 (1-Jan-2025)
tst_test.c:1182: TINFO: Mounting /dev/loop0 to /tmp/LTP_uti42UpHj/mntpoint fstyp=ext4 flags=0
utime03.c:74: TPASS: utime(TEMP_FILE, NULL) passed
utime03.c:80: TFAIL: utime() did not set expected atime, mintime: 1738291930, maxtime: 1738291930, st_atime: 1738291931
utime03.c:85: TFAIL: utime() did not set expected mtime, mintime: 1738291930, maxtime: 1738291930, st_mtime: 1738291931
Since 4e40eff0b573 ("fs: add infrastructure for multigrain timestamps"),
filesystem can use more precise clock to update the inode.
Relax the check by using realtime clock for upper bound check.
Signed-off-by: Jan Stancek <jstancek@redhat.com>
---
testcases/kernel/syscalls/utime/utime03.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/testcases/kernel/syscalls/utime/utime03.c b/testcases/kernel/syscalls/utime/utime03.c
index 564e1de3dd77..56eb9e722896 100644
--- a/testcases/kernel/syscalls/utime/utime03.c
+++ b/testcases/kernel/syscalls/utime/utime03.c
@@ -55,6 +55,7 @@ static void run(void)
struct utimbuf utbuf;
struct stat statbuf;
time_t mintime, maxtime;
+ struct timespec ts;
utbuf.modtime = time(0) - 5;
utbuf.actime = utbuf.modtime + 1;
@@ -70,7 +71,8 @@ static void run(void)
SAFE_SETEUID(user_uid);
mintime = tst_get_fs_timestamp();
TST_EXP_PASS(utime(TEMP_FILE, NULL));
- maxtime = tst_get_fs_timestamp();
+ tst_clock_gettime(CLOCK_REALTIME, &ts);
+ maxtime = ts.tv_sec;
SAFE_SETEUID(root_uid);
SAFE_STAT(TEMP_FILE, &statbuf);
--
2.43.0
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [LTP] [PATCH v2] syscalls/utime03: use realtime clock for upper bound check
2025-02-24 11:24 ` [LTP] [PATCH v2] syscalls/utime03: use realtime clock for upper bound check Jan Stancek
@ 2025-02-24 15:41 ` Cyril Hrubis
2025-02-24 16:06 ` Jan Stancek
2025-02-25 11:39 ` [LTP] [PATCH v3] provide separate functions for getting start and end fs timestamps Jan Stancek
0 siblings, 2 replies; 11+ messages in thread
From: Cyril Hrubis @ 2025-02-24 15:41 UTC (permalink / raw)
To: Jan Stancek; +Cc: ltp, chhrubis
Hi!
> This test rarely fails with recent kernels (after 6.13-rc1):
> tst_test.c:1833: TINFO: === Testing on ext4 ===
> tst_test.c:1170: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
> mke2fs 1.47.2 (1-Jan-2025)
> tst_test.c:1182: TINFO: Mounting /dev/loop0 to /tmp/LTP_uti42UpHj/mntpoint fstyp=ext4 flags=0
> utime03.c:74: TPASS: utime(TEMP_FILE, NULL) passed
> utime03.c:80: TFAIL: utime() did not set expected atime, mintime: 1738291930, maxtime: 1738291930, st_atime: 1738291931
> utime03.c:85: TFAIL: utime() did not set expected mtime, mintime: 1738291930, maxtime: 1738291930, st_mtime: 1738291931
>
> Since 4e40eff0b573 ("fs: add infrastructure for multigrain timestamps"),
> filesystem can use more precise clock to update the inode.
>
> Relax the check by using realtime clock for upper bound check.
>
> Signed-off-by: Jan Stancek <jstancek@redhat.com>
> ---
> testcases/kernel/syscalls/utime/utime03.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/testcases/kernel/syscalls/utime/utime03.c b/testcases/kernel/syscalls/utime/utime03.c
> index 564e1de3dd77..56eb9e722896 100644
> --- a/testcases/kernel/syscalls/utime/utime03.c
> +++ b/testcases/kernel/syscalls/utime/utime03.c
> @@ -55,6 +55,7 @@ static void run(void)
> struct utimbuf utbuf;
> struct stat statbuf;
> time_t mintime, maxtime;
> + struct timespec ts;
>
> utbuf.modtime = time(0) - 5;
> utbuf.actime = utbuf.modtime + 1;
> @@ -70,7 +71,8 @@ static void run(void)
> SAFE_SETEUID(user_uid);
> mintime = tst_get_fs_timestamp();
> TST_EXP_PASS(utime(TEMP_FILE, NULL));
> - maxtime = tst_get_fs_timestamp();
> + tst_clock_gettime(CLOCK_REALTIME, &ts);
> + maxtime = ts.tv_sec;
> SAFE_SETEUID(root_uid);
> SAFE_STAT(TEMP_FILE, &statbuf);
There are six testcases that use tst_get_fs_timestamp() is this the only
one that fails?
Also if we are going to do this, we should at least put the code to the
library and introduce two different functions one for the start
timestamp and one for the end timestamp and make use of that in all the
test
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [LTP] [PATCH v2] syscalls/utime03: use realtime clock for upper bound check
2025-02-24 15:41 ` Cyril Hrubis
@ 2025-02-24 16:06 ` Jan Stancek
2025-02-25 11:39 ` [LTP] [PATCH v3] provide separate functions for getting start and end fs timestamps Jan Stancek
1 sibling, 0 replies; 11+ messages in thread
From: Jan Stancek @ 2025-02-24 16:06 UTC (permalink / raw)
To: Cyril Hrubis; +Cc: ltp, chhrubis
On Mon, Feb 24, 2025 at 4:41 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> > This test rarely fails with recent kernels (after 6.13-rc1):
> > tst_test.c:1833: TINFO: === Testing on ext4 ===
> > tst_test.c:1170: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
> > mke2fs 1.47.2 (1-Jan-2025)
> > tst_test.c:1182: TINFO: Mounting /dev/loop0 to /tmp/LTP_uti42UpHj/mntpoint fstyp=ext4 flags=0
> > utime03.c:74: TPASS: utime(TEMP_FILE, NULL) passed
> > utime03.c:80: TFAIL: utime() did not set expected atime, mintime: 1738291930, maxtime: 1738291930, st_atime: 1738291931
> > utime03.c:85: TFAIL: utime() did not set expected mtime, mintime: 1738291930, maxtime: 1738291930, st_mtime: 1738291931
> >
> > Since 4e40eff0b573 ("fs: add infrastructure for multigrain timestamps"),
> > filesystem can use more precise clock to update the inode.
> >
> > Relax the check by using realtime clock for upper bound check.
> >
> > Signed-off-by: Jan Stancek <jstancek@redhat.com>
> > ---
> > testcases/kernel/syscalls/utime/utime03.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/testcases/kernel/syscalls/utime/utime03.c b/testcases/kernel/syscalls/utime/utime03.c
> > index 564e1de3dd77..56eb9e722896 100644
> > --- a/testcases/kernel/syscalls/utime/utime03.c
> > +++ b/testcases/kernel/syscalls/utime/utime03.c
> > @@ -55,6 +55,7 @@ static void run(void)
> > struct utimbuf utbuf;
> > struct stat statbuf;
> > time_t mintime, maxtime;
> > + struct timespec ts;
> >
> > utbuf.modtime = time(0) - 5;
> > utbuf.actime = utbuf.modtime + 1;
> > @@ -70,7 +71,8 @@ static void run(void)
> > SAFE_SETEUID(user_uid);
> > mintime = tst_get_fs_timestamp();
> > TST_EXP_PASS(utime(TEMP_FILE, NULL));
> > - maxtime = tst_get_fs_timestamp();
> > + tst_clock_gettime(CLOCK_REALTIME, &ts);
> > + maxtime = ts.tv_sec;
> > SAFE_SETEUID(root_uid);
> > SAFE_STAT(TEMP_FILE, &statbuf);
>
> There are six testcases that use tst_get_fs_timestamp() is this the only
> one that fails?
Good point. I managed to reproduce it with utime01 as well:
utime01.c:50: TFAIL: utime() did not set expected mtime, pre_time:
1740411917, post_time: 1740411917, st_mtime: 1740411918
utime01.c:55: TFAIL: utime() did not set expected atime, pre_time:
1740411917, post_time: 1740411917, st_atime: 1740411918
>
> Also if we are going to do this, we should at least put the code to the
> library and introduce two different functions one for the start
> timestamp and one for the end timestamp and make use of that in all the
> test
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 11+ messages in thread
* [LTP] [PATCH v3] provide separate functions for getting start and end fs timestamps
2025-02-24 15:41 ` Cyril Hrubis
2025-02-24 16:06 ` Jan Stancek
@ 2025-02-25 11:39 ` Jan Stancek
2025-02-25 13:18 ` Cyril Hrubis
1 sibling, 1 reply; 11+ messages in thread
From: Jan Stancek @ 2025-02-25 11:39 UTC (permalink / raw)
To: ltp
Tests using tst_get_fs_timestamp() rarely fail with recent kernels,
for example (after 6.13-rc1):
tst_test.c:1833: TINFO: === Testing on ext4 ===
tst_test.c:1170: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
mke2fs 1.47.2 (1-Jan-2025)
tst_test.c:1182: TINFO: Mounting /dev/loop0 to /tmp/LTP_uti42UpHj/mntpoint fstyp=ext4 flags=0
utime03.c:74: TPASS: utime(TEMP_FILE, NULL) passed
utime03.c:80: TFAIL: utime() did not set expected atime, mintime: 1738291930, maxtime: 1738291930, st_atime: 1738291931
utime03.c:85: TFAIL: utime() did not set expected mtime, mintime: 1738291930, maxtime: 1738291930, st_mtime: 1738291931
Since 4e40eff0b573 ("fs: add infrastructure for multigrain timestamps"),
filesystem can use more precise clock to update the inode.
Provide two versions of the function, for collecting start and end
timestamp, where latter one uses more precise clock.
Old function is renamed to tst_clock_get_timestamp() and used as
a helper function.
Signed-off-by: Jan Stancek <jstancek@redhat.com>
---
include/tst_clocks.h | 21 +++++++++++++++++--
lib/tst_clocks.c | 20 ++++++++++++++----
.../kernel/syscalls/ipc/msgrcv/msgrcv01.c | 4 ++--
.../kernel/syscalls/ipc/msgsnd/msgsnd01.c | 4 ++--
.../kernel/syscalls/ipc/shmctl/shmctl01.c | 4 ++--
testcases/kernel/syscalls/utime/utime01.c | 6 +++---
testcases/kernel/syscalls/utime/utime02.c | 6 +++---
testcases/kernel/syscalls/utime/utime03.c | 4 ++--
8 files changed, 49 insertions(+), 20 deletions(-)
diff --git a/include/tst_clocks.h b/include/tst_clocks.h
index 06d2d03bef33..8b7f33d4f387 100644
--- a/include/tst_clocks.h
+++ b/include/tst_clocks.h
@@ -20,15 +20,32 @@ int tst_clock_settime(clockid_t clk_id, struct timespec *ts);
*/
const char *tst_clock_name(clockid_t clk_id);
+/*
+ * Returns timestamp (seconds passed) for the specified clock.
+ * TBROKs on error.
+ */
+time_t tst_clock_get_timestamp(clockid_t clk_id);
+
/*
* Returns current system time for file/IPC operations, which may slightly lag
- * behind time() return values.
+ * behind time() return values. Meant to be used as lower bound in atime/mtime
+ * checks.
*
* The reason for this is that the time() syscall reads the nanosecond timer at
* the time of the call and adds it to the kernel current time, because of that
* accumulation may cause it jump one second ahead compared to the kernel time
* stamp that is used for IPC and filesystems.
*/
-time_t tst_get_fs_timestamp(void);
+time_t tst_fs_timestamp_start(void);
+
+/*
+ * Returns current system time for file/IPC operation, using clock
+ * which has higher precision. Meant to be used as higher bound in atime/mtime
+ * checks.
+ *
+ * The reason for separate start/end functions is to cover features like
+ * multigrain timestamps, which update atime/mtime using more precise clock.
+ */
+time_t tst_fs_timestamp_end(void);
#endif /* TST_CLOCKS__ */
diff --git a/lib/tst_clocks.c b/lib/tst_clocks.c
index 29f4b420c373..fba4a4f7ba51 100644
--- a/lib/tst_clocks.c
+++ b/lib/tst_clocks.c
@@ -144,15 +144,27 @@ const char *tst_clock_name(clockid_t clk_id)
}
}
-time_t tst_get_fs_timestamp(void)
+time_t tst_clock_get_timestamp(clockid_t clk_id)
{
struct timespec ts;
int ret;
- ret = tst_clock_gettime(CLOCK_REALTIME_COARSE, &ts);
+ ret = tst_clock_gettime(clk_id, &ts);
- if (ret < 0)
- tst_brk(TBROK | TERRNO, "clock_gettime(CLOCK_REALTIME_COARSE)");
+ if (ret < 0) {
+ tst_brk(TBROK | TERRNO, "clock_gettime(%s)",
+ tst_clock_name(clk_id));
+ }
return ts.tv_sec;
}
+
+time_t tst_fs_timestamp_start(void)
+{
+ return tst_clock_get_timestamp(CLOCK_REALTIME_COARSE);
+}
+
+time_t tst_fs_timestamp_end(void)
+{
+ return tst_clock_get_timestamp(CLOCK_REALTIME);
+}
diff --git a/testcases/kernel/syscalls/ipc/msgrcv/msgrcv01.c b/testcases/kernel/syscalls/ipc/msgrcv/msgrcv01.c
index 9df20a61e38e..58bfd27716a2 100644
--- a/testcases/kernel/syscalls/ipc/msgrcv/msgrcv01.c
+++ b/testcases/kernel/syscalls/ipc/msgrcv/msgrcv01.c
@@ -26,13 +26,13 @@ static void verify_msgrcv(void)
SAFE_MSGSND(queue_id, &snd_buf, MSGSIZE, 0);
- before_rcv = tst_get_fs_timestamp();
+ before_rcv = tst_fs_timestamp_start();
TEST(msgrcv(queue_id, &rcv_buf, MSGSIZE, 1, 0));
if (TST_RET == -1) {
tst_res(TFAIL | TTERRNO, "msgrcv failed");
return;
}
- after_rcv = tst_get_fs_timestamp();
+ after_rcv = tst_fs_timestamp_end();
if (strcmp(rcv_buf.mtext, snd_buf.mtext) == 0)
tst_res(TPASS, "message received(%s) = message sent(%s)",
diff --git a/testcases/kernel/syscalls/ipc/msgsnd/msgsnd01.c b/testcases/kernel/syscalls/ipc/msgsnd/msgsnd01.c
index 60936be8a355..6d92f3dece11 100644
--- a/testcases/kernel/syscalls/ipc/msgsnd/msgsnd01.c
+++ b/testcases/kernel/syscalls/ipc/msgsnd/msgsnd01.c
@@ -30,13 +30,13 @@ static void verify_msgsnd(void)
struct msqid_ds qs_buf;
time_t before_snd, after_snd;
- before_snd = tst_get_fs_timestamp();
+ before_snd = tst_fs_timestamp_start();
TEST(msgsnd(queue_id, &snd_buf, MSGSIZE, 0));
if (TST_RET == -1) {
tst_res(TFAIL | TTERRNO, "msgsnd() failed");
return;
}
- after_snd = tst_get_fs_timestamp();
+ after_snd = tst_fs_timestamp_end();
SAFE_MSGCTL(queue_id, IPC_STAT, &qs_buf);
diff --git a/testcases/kernel/syscalls/ipc/shmctl/shmctl01.c b/testcases/kernel/syscalls/ipc/shmctl/shmctl01.c
index 1eec0798930f..e86cd71031af 100644
--- a/testcases/kernel/syscalls/ipc/shmctl/shmctl01.c
+++ b/testcases/kernel/syscalls/ipc/shmctl/shmctl01.c
@@ -242,9 +242,9 @@ static int get_shm_idx_from_id(int shm_id)
static void setup(void)
{
- ctime_min = tst_get_fs_timestamp();
+ ctime_min = tst_fs_timestamp_start();
shm_id = SAFE_SHMGET(IPC_PRIVATE, SHM_SIZE, IPC_CREAT | SHM_RW);
- ctime_max = tst_get_fs_timestamp();
+ ctime_max = tst_fs_timestamp_end();
shm_idx = get_shm_idx_from_id(shm_id);
diff --git a/testcases/kernel/syscalls/utime/utime01.c b/testcases/kernel/syscalls/utime/utime01.c
index 2a74f8952d64..9e985ec3761d 100644
--- a/testcases/kernel/syscalls/utime/utime01.c
+++ b/testcases/kernel/syscalls/utime/utime01.c
@@ -31,7 +31,7 @@ static void run(void)
struct stat stat_buf;
time_t pre_time, post_time;
- utbuf.modtime = tst_get_fs_timestamp() - 5;
+ utbuf.modtime = tst_fs_timestamp_start() - 5;
utbuf.actime = utbuf.modtime + 1;
TST_EXP_PASS_SILENT(utime(TEMP_FILE, &utbuf));
SAFE_STAT(TEMP_FILE, &stat_buf);
@@ -39,11 +39,11 @@ static void run(void)
TST_EXP_EQ_LI(stat_buf.st_atime, utbuf.actime);
TST_EXP_EQ_LI(stat_buf.st_mtime, utbuf.modtime);
- pre_time = tst_get_fs_timestamp();
+ pre_time = tst_fs_timestamp_start();
TST_EXP_PASS(utime(TEMP_FILE, NULL), "utime(%s, NULL)", TEMP_FILE);
if (!TST_PASS)
return;
- post_time = tst_get_fs_timestamp();
+ post_time = tst_fs_timestamp_end();
SAFE_STAT(TEMP_FILE, &stat_buf);
if (stat_buf.st_mtime < pre_time || stat_buf.st_mtime > post_time)
diff --git a/testcases/kernel/syscalls/utime/utime02.c b/testcases/kernel/syscalls/utime/utime02.c
index 52185d839e65..5ed83298796d 100644
--- a/testcases/kernel/syscalls/utime/utime02.c
+++ b/testcases/kernel/syscalls/utime/utime02.c
@@ -48,7 +48,7 @@ static void run(void)
struct stat stat_buf;
time_t pre_time, post_time;
- utbuf.modtime = tst_get_fs_timestamp() - 5;
+ utbuf.modtime = tst_fs_timestamp_start() - 5;
utbuf.actime = utbuf.modtime + 1;
TST_EXP_PASS_SILENT(utime(TEMP_FILE, &utbuf));
SAFE_STAT(TEMP_FILE, &stat_buf);
@@ -56,11 +56,11 @@ static void run(void)
TST_EXP_EQ_LI(stat_buf.st_atime, utbuf.actime);
TST_EXP_EQ_LI(stat_buf.st_mtime, utbuf.modtime);
- pre_time = tst_get_fs_timestamp();
+ pre_time = tst_fs_timestamp_start();
TST_EXP_PASS(utime(TEMP_FILE, NULL), "utime(%s, NULL)", TEMP_FILE);
if (!TST_PASS)
return;
- post_time = tst_get_fs_timestamp();
+ post_time = tst_fs_timestamp_end();
SAFE_STAT(TEMP_FILE, &stat_buf);
if (stat_buf.st_mtime < pre_time || stat_buf.st_mtime > post_time)
diff --git a/testcases/kernel/syscalls/utime/utime03.c b/testcases/kernel/syscalls/utime/utime03.c
index 564e1de3dd77..aa0dcef250c8 100644
--- a/testcases/kernel/syscalls/utime/utime03.c
+++ b/testcases/kernel/syscalls/utime/utime03.c
@@ -68,9 +68,9 @@ static void run(void)
}
SAFE_SETEUID(user_uid);
- mintime = tst_get_fs_timestamp();
+ mintime = tst_fs_timestamp_start();
TST_EXP_PASS(utime(TEMP_FILE, NULL));
- maxtime = tst_get_fs_timestamp();
+ maxtime = tst_fs_timestamp_end();
SAFE_SETEUID(root_uid);
SAFE_STAT(TEMP_FILE, &statbuf);
--
2.43.0
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [LTP] [PATCH v3] provide separate functions for getting start and end fs timestamps
2025-02-25 11:39 ` [LTP] [PATCH v3] provide separate functions for getting start and end fs timestamps Jan Stancek
@ 2025-02-25 13:18 ` Cyril Hrubis
2025-02-28 12:22 ` Jan Stancek
0 siblings, 1 reply; 11+ messages in thread
From: Cyril Hrubis @ 2025-02-25 13:18 UTC (permalink / raw)
To: Jan Stancek; +Cc: ltp
Hi!
Now it looks good :-)
Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [LTP] [PATCH v3] provide separate functions for getting start and end fs timestamps
2025-02-25 13:18 ` Cyril Hrubis
@ 2025-02-28 12:22 ` Jan Stancek
0 siblings, 0 replies; 11+ messages in thread
From: Jan Stancek @ 2025-02-28 12:22 UTC (permalink / raw)
To: Cyril Hrubis; +Cc: ltp
On Tue, Feb 25, 2025 at 2:18 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> Now it looks good :-)
>
> Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
Pushed.
Thanks,
Jan
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-02-28 12:23 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-02-20 9:28 [LTP] [PATCH] syscalls/utime03: relax the check for 1 second difference Jan Stancek
2025-02-20 10:51 ` Petr Vorel
2025-02-20 11:17 ` Cyril Hrubis
2025-02-20 13:44 ` Jan Stancek
2025-02-21 8:24 ` Jan Stancek
2025-02-24 11:24 ` [LTP] [PATCH v2] syscalls/utime03: use realtime clock for upper bound check Jan Stancek
2025-02-24 15:41 ` Cyril Hrubis
2025-02-24 16:06 ` Jan Stancek
2025-02-25 11:39 ` [LTP] [PATCH v3] provide separate functions for getting start and end fs timestamps Jan Stancek
2025-02-25 13:18 ` Cyril Hrubis
2025-02-28 12:22 ` Jan Stancek
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.