2012/6/27 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>:
> On Sat, 23 Jun 2012 23:58:22 +0900
> Akinobu Mita <akinobu.mita@xxxxxxxxx> wrote:
>
>> This adds two testing scripts with notifier error injection
>
> Can we move these into tools/testing/selftests/, so that a "make
> run_tests" runs these tests?
>
> Also, I don't think it's appropriate that "fault-injection" be in the
> path - that's an implementation detail. What we're testing here is
> memory hotplug, pm, cpu hotplug, etc. So each test would go into, say,
> tools/testing/selftests/cpu-hotplug.
>
> Now, your cpu-hotplug test only tests a tiny part of the cpu-hotplug
> code. But it is a start, and creates the place where additional tests
> will be placed in the future.
>
>
> If the kernel configuration means that the tests cannot be run, the
> attempt should succeed so that other tests are not disrupted. I guess
> that printing a warning in this case is useful.
>
> Probably the selftests will require root permissions - we haven't
> really thought about that much. If these tests require root (I assume
> they do?) then a sensible approach would be to check for that and to
> emit a warning and return "success".
Thanks for your advice.
I'm going to make the following changes on these scripts
1. Change these paths to:
tools/testing/selftests/{cpu,memory}-hotplug/on-off-test.sh
2. Skip tests and exit(0) with a warning if no root or no sysfs
so that a "make run_tests" doesn't stop.
3. Add tests that simply online and offline cpus (or memory blocks)
and then tests with this notifier error injection features if the
kernel supports.
> My overall take on the fault-injection code is that there has been a
> disappointing amount of uptake: I don't see many developers using them
> for whitebox testing their stuff. I guess this patchset addresses
> that, in a way.
I hope so. the impact of notifier error injection is restricted to
the particular kernel functionarity and these scripts are easy to run.
On the other hand, fault injection like failslab has a huge impact
on any kernel components and it often results catastrophe to userspace
even if no kernel bug. I am confident that I can find a certain amount
of kernel bugs with failslab but it requires enough spare time.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href