Skip to contentSkip to conversation

syscall/fcntl33.c: fix test on FUSE fs

PATCH New Alexey Kodanev 2 participants 3 messages Apr 19, 2016 – Apr 20, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 syscall/fcntl33.c: fix test on FUSE fs

Even though a child process is waiting for a parent to be in 'S' state before triggering SIGIO, the signal might come earlier than sigtimedwait() being invoked in the parent process. As a result the parent waited for the event that had already happened.

I can only think about that the parent process may be in a sleep state somehow while executing open() syscall on which it might sleep while running it on FUSE FS:
vfs -> fuse kernel driver -> userspace implementation.

It can be fixed if we move open() before fork.

---
 testcases/kernel/syscalls/fcntl/fcntl33.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)
testcases/kernel/syscalls/fcntl/fcntl33.c +6 -5
index 2d69866..13616c6 100644
@@ -146,16 +146,17 @@ static void setup(void)
 
 static void do_test(int i)
 {
-	pid_t cpid;
+	fd = SAFE_OPEN(cleanup, "file", O_RDONLY);
+
+	pid_t cpid = tst_fork();
 
-	cpid = tst_fork();
 	if (cpid < 0)
 		tst_brkm(TBROK | TERRNO, cleanup, "fork() failed");
 
-	if (cpid == 0)
+	if (cpid == 0) {
+		SAFE_CLOSE(NULL, fd);
 		do_child(i);
-
-	fd = SAFE_OPEN(cleanup, "file", O_RDONLY);
+	}
 
 	TEST(fcntl(fd, F_SETLEASE, test_cases[i].lease_type));
 	if (TEST_RETURN == -1) {
Signature · 1 line
1.7.1
#1 lore raw

PATCH 1/1 syscall/fcntl33.c: fix test on FUSE fs

Hi!

Quoted 9 lines

Even though a child process is waiting for a parent to be in 'S' state before triggering SIGIO, the signal might come earlier than sigtimedwait() being invoked in the parent process. As a result the parent waited for the event that had already happened.

I can only think about that the parent process may be in a sleep state somehow while executing open() syscall on which it might sleep while running it on FUSE FS:
vfs -> fuse kernel driver -> userspace implementation.

That sounds plausible to me. Depending on the actuall FUSE filesystem it may do basically anything.

Quoted 21 lines

It can be fixed if we move open() before fork.

---
 testcases/kernel/syscalls/fcntl/fcntl33.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)
testcases/kernel/syscalls/fcntl/fcntl33.c +3 -2
index 2d69866..13616c6 100644
@@ -146,16 +146,17 @@ static void setup(void)
 
 static void do_test(int i)
 {
-	pid_t cpid;
+	fd = SAFE_OPEN(cleanup, "file", O_RDONLY);
+
+	pid_t cpid = tst_fork();
 
-	cpid = tst_fork();

testcases/kernel/syscalls/fcntl/fcntl33.c static void setup(void) · line 159

Quoted 10 lines
testcases/kernel/syscalls/fcntl/fcntl33.c +3 -3
 	if (cpid < 0)
 		tst_brkm(TBROK | TERRNO, cleanup, "fork() failed");
 
-	if (cpid == 0)
+	if (cpid == 0) {
+		SAFE_CLOSE(NULL, fd);
 		do_child(i);
-
-	fd = SAFE_OPEN(cleanup, "file", O_RDONLY);
+	}

Looks good.

Another possible solution would be to use checkpoints and wait in the child before we call tst_process_state_wait() and wake it up from parent just before we call the fcntl(). But that would be more complicated than this.

Signature · 2 lines
Cyril Hrubis
[email protected]
#2 lore raw

PATCH 1/1 syscall/fcntl33.c: fix test on FUSE fs

Hi,

Quoted 21 lines · Cyril Hrubis
  
  static void do_test(int i)
  {
testcases/kernel/syscalls/fcntl/fcntl33.c +6 -5
-	pid_t cpid;
+	fd = SAFE_OPEN(cleanup, "file", O_RDONLY);
+
+	pid_t cpid = tst_fork();
 
-	cpid = tst_fork();
  	if (cpid < 0)
  		tst_brkm(TBROK | TERRNO, cleanup, "fork() failed");
 
-	if (cpid == 0)
+	if (cpid == 0) {
+		SAFE_CLOSE(NULL, fd);
  		do_child(i);
-
-	fd = SAFE_OPEN(cleanup, "file", O_RDONLY);
+	}

Looks good.

Quoted 4 lines

Another possible solution would be to use checkpoints and wait in the child before we call tst_process_state_wait() and wake it up from parent just before we call the fcntl(). But that would be more complicated than this.

Yes, it would be a more portable alternative instead of waiting for a sleep state in a child.

Applied the original patch which has a simpler fix.

Thanks,
Alexey