Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1669078 > unrolled thread

[PATCH 2/2] selftests: lib: prime_numbers: update presence check

Started bySumit Semwal <sumit.semwal@linaro.org>
First post2017-06-19 15:50 +0200
Last post2017-06-19 17:20 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 2/2] selftests: lib: prime_numbers: update presence check Sumit Semwal <sumit.semwal@linaro.org> - 2017-06-19 15:50 +0200
    Re: [PATCH 2/2] selftests: lib: prime_numbers: update presence check Chris Wilson <chris@chris-wilson.co.uk> - 2017-06-19 16:00 +0200
      Re: [PATCH 2/2] selftests: lib: prime_numbers: update presence check Sumit Semwal <sumit.semwal@linaro.org> - 2017-06-19 16:50 +0200
        Re: [PATCH 2/2] selftests: lib: prime_numbers: update presence check Sumit Semwal <sumit.semwal@linaro.org> - 2017-06-19 17:20 +0200

#1669078 — [PATCH 2/2] selftests: lib: prime_numbers: update presence check

FromSumit Semwal <sumit.semwal@linaro.org>
Date2017-06-19 15:50 +0200
Subject[PATCH 2/2] selftests: lib: prime_numbers: update presence check
Message-ID<tU5e2-3jx-9@gated-at.bofh.it>
The test for prime numbers doesn't differentiate between missing
prime_numbers.ko and failure in prime_numbers.ko.

Update it to check for presence of the file itself to skip, therefore
correctly exercising the test failure case.

Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 tools/testing/selftests/lib/prime_numbers.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/lib/prime_numbers.sh b/tools/testing/selftests/lib/prime_numbers.sh
index da4cbcd766f5..492f0dcdf088 100755
--- a/tools/testing/selftests/lib/prime_numbers.sh
+++ b/tools/testing/selftests/lib/prime_numbers.sh
@@ -1,8 +1,9 @@
 #!/bin/sh
 # Checks fast/slow prime_number generation for inconsistencies
 
-if ! /sbin/modprobe -q -r prime_numbers; then
-	echo "prime_numbers: [SKIP]"
+if ! find /lib/modules/$(uname -r) -type f -name prime_numbers.ko | grep -q .;
+then
+	echo "prime_numbers: prime_numbers.ko not found: [SKIP]"
 	exit 77
 fi
 
-- 
2.7.4

[toc] | [next] | [standalone]


#1669082

FromChris Wilson <chris@chris-wilson.co.uk>
Date2017-06-19 16:00 +0200
Message-ID<tU5nI-3mQ-5@gated-at.bofh.it>
In reply to#1669078
Quoting Sumit Semwal (2017-06-19 14:44:32)
> The test for prime numbers doesn't differentiate between missing
> prime_numbers.ko and failure in prime_numbers.ko.
> 
> Update it to check for presence of the file itself to skip, therefore
> correctly exercising the test failure case.

modprobe -r shouldn't be executing the module? But you still need to
unload the module before you can load it with the selftest module
parameters. If you can't unload the module due to an earlier failure,
you cannot discern whether or not the module itself is at fault, so
still want to SKIP.
-Chris

[toc] | [prev] | [next] | [standalone]


#1669139

FromSumit Semwal <sumit.semwal@linaro.org>
Date2017-06-19 16:50 +0200
Message-ID<tU6a7-3UW-17@gated-at.bofh.it>
In reply to#1669082
Hi Chris,

On 19 June 2017 at 19:21, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Sumit Semwal (2017-06-19 14:44:32)
>> The test for prime numbers doesn't differentiate between missing
>> prime_numbers.ko and failure in prime_numbers.ko.
>>
>> Update it to check for presence of the file itself to skip, therefore
>> correctly exercising the test failure case.
>
> modprobe -r shouldn't be executing the module? But you still need to
> unload the module before you can load it with the selftest module
> parameters. If you can't unload the module due to an earlier failure,
> you cannot discern whether or not the module itself is at fault, so
> still want to SKIP.

My bad here: I missed the '-r' in the first modprobe.

I am wondering if 'modprobe -q -n' won't suffice, as it is a dry-run
only, but will still search for the module? Unless of course, there's
something specific about '-q -r' that seems better still?

Shuah,
Could you please disregard this patch, and the other patch I sent:
will send out a new version soon.

> -Chris

Best,
Sumit.

[toc] | [prev] | [next] | [standalone]


#1669218

FromSumit Semwal <sumit.semwal@linaro.org>
Date2017-06-19 17:20 +0200
Message-ID<tU6D9-4lE-51@gated-at.bofh.it>
In reply to#1669139
On 19 June 2017 at 20:27, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Sumit Semwal (2017-06-19 15:46:20)
>> Hi Chris,
>>
>> On 19 June 2017 at 19:21, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> > Quoting Sumit Semwal (2017-06-19 14:44:32)
>> >> The test for prime numbers doesn't differentiate between missing
>> >> prime_numbers.ko and failure in prime_numbers.ko.
>> >>
>> >> Update it to check for presence of the file itself to skip, therefore
>> >> correctly exercising the test failure case.
>> >
>> > modprobe -r shouldn't be executing the module? But you still need to
>> > unload the module before you can load it with the selftest module
>> > parameters. If you can't unload the module due to an earlier failure,
>> > you cannot discern whether or not the module itself is at fault, so
>> > still want to SKIP.
>>
>> My bad here: I missed the '-r' in the first modprobe.
>>
>> I am wondering if 'modprobe -q -n' won't suffice, as it is a dry-run
>> only, but will still search for the module? Unless of course, there's
>> something specific about '-q -r' that seems better still?
>
> I think there are two things to be tested here, both causing a SKIP.
>
>  - If the module doesn't exist at all; modprobe -q -n seems sensible for
>    querying its existence.
>
>  - If the module cannot be [un]loaded; for which I was using the
>    modprobe -q -r. If we can't unload the module, then we can't test :)

:) Right; then the question is, for prime_numbers.ko, do we need to
differentiate between these 2 SKIPs?

The unloading of the prime_numbers module before running the test is
required since it isn't a standalone test module - unlike the
test_bitmap and test_printf ones.

So then, for prime_numbers: if distinguishing between the two cases
you mentioned above isn't important, we can just keep your original
code. If it is important to distinguish, I can add the -q -n test to
query existence separately.

For test_bitmap and test_printf tests, I think I will just go ahead
with -q -n itself, since we can assume that the test modules will only
be loaded/unloaded via these tests I guess?

>
> -Chris

Best,
Sumit.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web