public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Li Wang <liwang@redhat.com>
To: ltp@lists.linux.it
Cc: llong@redhat.com
Subject: [LTP] [PATCH] mount03: flip to the next second before doing the access
Date: Mon, 27 Feb 2023 15:21:03 +0800	[thread overview]
Message-ID: <20230227072103.264317-1-liwang@redhat.com> (raw)

Mount03 occasionally reports failure on tmpfs:

  170	mount03.c:214: TINFO: Testing flag MS_STRICTATIME
  171	mount03.c:140: TFAIL: st.st_atime(1677086243) < atime(1677086243)
  172	mount03.c:151: TFAIL: dir_st.st_atime(1677086243) < dir_atime(1677086243)

From Waiman Long:

  Looking at the mount03.c test, it is reading a directory in tmpfs, sleeping for
  1 second and read the directory again. The test fails because the reported atime
  didn't change. Since tmpfs is in memory, access to them can be much faster and I
  believe that a race condition may happen that the two directory reads can happen
  within the same atime even though one second is supposed to have passed. The same
  test pass when applying to a real filesystem. So I believe the assumption made in
  the test may not be totally correct as the time lag can happen in different
  subsystems inside the kernel for time tracking. I believe it is more a test problem
  than a real kernel problem.

  There may be some slight discrepancy in how sleep and the tmpfs file system is
  keeping track of time. If the first access is right at the beginning of a second
  from the tmpfs perspective, the 2nd access may be at the end of that second, but
  not flip to the next second yet. What I would suggest is to sleep a little more
  like usleep(10 000) to make sure that it will flip to the next second before doing
  the access.

Suggested-by: Waiman Long <llong@redhat.com>
Signed-off-by: Li Wang <liwang@redhat.com>
---
 testcases/kernel/syscalls/mount/mount03.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testcases/kernel/syscalls/mount/mount03.c b/testcases/kernel/syscalls/mount/mount03.c
index 60f9963da..98d5933b7 100644
--- a/testcases/kernel/syscalls/mount/mount03.c
+++ b/testcases/kernel/syscalls/mount/mount03.c
@@ -122,7 +122,7 @@ static void test_file_dir_noatime(int update_fatime, int update_datime)
 	SAFE_CLOSEDIR(test_dir);
 	dir_atime = dir_st.st_atime;
 
-	sleep(1);
+	usleep(1001000);
 
 	SAFE_READ(0, otfd, readbuf, sizeof(readbuf));
 	SAFE_FSTAT(otfd, &st);
-- 
2.38.1


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

             reply	other threads:[~2023-02-27  7:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27  7:21 Li Wang [this message]
2023-02-27 11:37 ` [LTP] [PATCH] mount03: flip to the next second before doing the access Cyril Hrubis
2023-02-28  1:31 ` xuyang2018.jy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230227072103.264317-1-liwang@redhat.com \
    --to=liwang@redhat.com \
    --cc=llong@redhat.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox