A few tests not belong to syscall category about ltp HOT 5 CLOSED

dirtypipe.c, dirtyc0w_shmem.c, dirtyc0w.c are also in runtest/cve (some of the tests in runtest/cve are also in runtest/syscalls).

I'm not sure about prot_hsymlinks.c, but we actually don't have any runtest specific to security (many tests are kind of security). We have runtest/cve, but that one is for CVE entries only (some of these tests are also in runtest/syscalls). Old runtest/securebits is libcap and linux/securebits.h specific. We also have runtest/cap_bounds, We could merge these into single and rename it to runtest/capability, but first, it'd be better to check whether these old tests are even relevant nowadays.

from ltp.

Hi,
Thanks for the explanation! I probably didn't understand our test suite that well, so my word on "security" is confusing. My question actually why are prot_hsymlinks, dirtyc0w, dirtyc0w_shmem, dirtypipe included in syscall tests. I am not super clear which syscall they are testing.

Thanks!

from ltp.

I guess at the time of adding prot_hsymlinks in 18f6767 there was no better place. I guess at the time syscalls was a default runtest file (while some runtests are very small, which is waste of booting SUT, syscalls is too big).

dirtyc0w_shmem.c is obvious (shmem) and I guess dirtyc0w.c just went it it. dirtypipe.c tests pipe.

Also, given about other problems (missing tests for new functionality, old tests are buggy or needs to be cleaned up and rewritten into new API, some tests should be even deleted as they are not relevant any more) having tests is a wrong runtest file as a minor theoretical detail.

from ltp.

Unless you write a very simple unit test it's often not easy to tell which syscall you are testing testing. If you write a stress test that reads and write a file, do you test read or write? It's actually both and that is still a simple example. More complicated tests use dozen of syscalls and sometimes it's not a clear cut which one is the syscall under a test. The whole runtest structure in LTP is flawed because of that, because that means that tests are going to be duplicated among runtest files, and you cannot really do better unless you change the whole concept of how tests are executed.

from ltp.

Can we close this issue?

from ltp.