Skipping open(O_WRONLY) test if writeback is enabled does not work reliably

[Smit-tay]

test_examples.py::test_passthrough relies upon "magic" number parameter '-52' to skip (or possibly select by omit the minus, e.g. '52' ) a particular test which happens to be the 52nd test in a long list of tests, and relies upon a counter found in test/test_syscalls.c

test_examples.py::test_passthrough:

       if writeback:
            # When writeback caching is enabled, kernel has to open files for
            # reading even when userspace opens with O_WDONLY. This fails if the
            # filesystem process doesn't have special permission.
            syscall_test_cmd.append('-52')

A Macro helper in test_syscalls.c is used to "skip" or select the test like this:

#define start_test(msg, args...) { \
	if ((select_test && testnum != select_test) || \
	    (testnum == skip_test)) { \
		testnum++; \
		return 0; \
	} \
	__start_test(msg, ##args);		\
}

Logic is fatally flawed due to pre-processor defines possibly changing the number of tests performed
test_syscalls.c

#ifndef __FreeBSD__	
	err += test_mknod();
	err += test_mkfifo();
#endif

or if user is root

test_syscalls.c

if(!is_root) {
		err += test_open_acc(O_RDONLY | O_TRUNC, 0400, EACCES);
		err += test_open_acc(O_WRONLY, 0400, EACCES);
		err += test_open_acc(O_RDWR,   0400, EACCES);
		err += test_open_acc(O_RDONLY, 0200, EACCES);
		err += test_open_acc(O_RDWR,   0200, EACCES);
		err += test_open_acc(O_RDONLY, 0000, EACCES);
		err += test_open_acc(O_WRONLY, 0000, EACCES);
		err += test_open_acc(O_RDWR,   0000, EACCES);
	}

both of which occur in the middle of the list of tests. This implies that the test script "know" compile options used in order to determine which test should be skipped.

Magic number should be removed from test_examples.py. Test skipping/selecting logic should be removed, and test script should be re-written to identify which tests may be called depending upon platform, or user - or rewritten to skip tests by name instead of number.

[Nikratio]

Thanks for the report! Yes, the current state is a fragile hack. Would you be able to provide patch / pull request?