Message ID | 20230713135440.3651409-1-ryan.roberts@arm.com |
---|---|
Headers | show |
Series | selftests/mm fixes for arm64 | expand |
On 7/13/23 06:54, Ryan Roberts wrote: > arm64 does not support the soft-dirty PTE bit. However there are tests > in `madv_populate` and `soft-dirty` which assume it is supported and > cause spurious failures to be reported when preferred behaviour would be > to mark the tests as skipped. > > Unfortunately, the only way to determine if the soft-dirty dirty bit is > supported is to write to a page, then see if the bit is set in > /proc/self/pagemap. But the tests that we want to conditionally execute > are testing precicesly this. So if we introduced this feature check, we > could accedentally turn a real failure (on a system that claims to > support soft-dirty) into a skip. ... > diff --git a/tools/testing/selftests/mm/soft-dirty.c b/tools/testing/selftests/mm/soft-dirty.c > index cc5f144430d4..8a2cd161ec4d 100644 > --- a/tools/testing/selftests/mm/soft-dirty.c > +++ b/tools/testing/selftests/mm/soft-dirty.c Hi Ryan, Probably very similar to what David is requesting: given that arm64 definitively does not support soft dirty, I'd suggest that we not even *build* the soft dirty tests on arm64! There is no need to worry about counting, skipping or waiving such tests, either. Because it's just a non-issue: one does not care about test status for something that is documented as "this feature is simply unavailable here". thanks,
On 15/07/2023 01:04, John Hubbard wrote: > On 7/13/23 06:54, Ryan Roberts wrote: >> arm64 does not support the soft-dirty PTE bit. However there are tests >> in `madv_populate` and `soft-dirty` which assume it is supported and >> cause spurious failures to be reported when preferred behaviour would be >> to mark the tests as skipped. >> >> Unfortunately, the only way to determine if the soft-dirty dirty bit is >> supported is to write to a page, then see if the bit is set in >> /proc/self/pagemap. But the tests that we want to conditionally execute >> are testing precicesly this. So if we introduced this feature check, we >> could accedentally turn a real failure (on a system that claims to >> support soft-dirty) into a skip. > > ... > >> diff --git a/tools/testing/selftests/mm/soft-dirty.c >> b/tools/testing/selftests/mm/soft-dirty.c >> index cc5f144430d4..8a2cd161ec4d 100644 >> --- a/tools/testing/selftests/mm/soft-dirty.c >> +++ b/tools/testing/selftests/mm/soft-dirty.c > > Hi Ryan, > > Probably very similar to what David is requesting: given that arm64 > definitively does not support soft dirty, I'd suggest that we not even > *build* the soft dirty tests on arm64! > > There is no need to worry about counting, skipping or waiving such > tests, either. Because it's just a non-issue: one does not care about > test status for something that is documented as "this feature is simply > unavailable here". OK fair enough. I'll follow this approach for v2. Thanks for the review! > > > thanks,
On 13/07/2023 15:16, Mark Brown wrote: > On Thu, Jul 13, 2023 at 02:54:32PM +0100, Ryan Roberts wrote: >> The selftests runner pipes the test program's stdout to tap_prefix. The >> presence of the pipe means that the test program sets its stdout to be >> fully buffered (as aposed to line buffered when directly connected to >> the terminal). The block buffering means that there is often content in >> the buffer at fork() time, which causes the output to end up duplicated. >> This was causing problems for mm:cow where test results were duplicated >> 20-30x. >> >> Solve this by using `stdbuf`, when available to force the test program >> to use line buffered mode. This means previously printf'ed results are >> flushed out of the program before any fork(). > > This is going to be useful in general since not all selftests use the > kselftest helpers but it'd probably also be good to make > ksft_print_header() also make the output unbuffered so that if setbuf > isn't installed on the target system or the tests are run standalone we > don't run into issues there. Even if the test isn't corrupting data > having things unbuffered is going to be good for making sure we don't > drop any output if the test dies. > >> + if [ -x /usr/bin/stdbuf ]; then >> + stdbuf="/usr/bin/stdbuf --output=L " >> + fi > > Might be more robust to use type -p to find stdbuf in case it's in /bin > or something? Just looking at making this change; run_selftest.sh's shebang is for sh, and sh's type doesn't support the -p option. So I'm inclined to leave it as is. There are multiple other places in the script where /usr/bin is hardcoded when looking for programs too. Shout if you violently disagree.