On 4/15/20 12:29 PM, Leon Romanovsky wrote:
On Wed, Apr 15, 2020 at 10:28:23AM -0700, Ralph Campbell wrote:
On 4/15/20 7:41 AM, Jason Gunthorpe wrote:
On Fri, Mar 20, 2020 at 05:31:05PM -0700, Ralph Campbell wrote:
This series adds basic self tests for HMM and are intended for Jason
Gunthorpe's rdma tree which has a number of HMM patches applied.
Here are some hunks I noticed while testing this:
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2201,7 +2201,8 @@ config TEST_MEMINIT
config TEST_HMM
tristate "Test HMM (Heterogeneous Memory Management)"
- depends on DEVICE_PRIVATE
+ depends on TRANSPARENT_HUGEPAGE
+ select DEVICE_PRIVATE
select HMM_MIRROR
select MMU_NOTIFIER
help
It fails testing if TRANSPARENT_HUGEPAGE is not on
@@ -1097,6 +1071,7 @@ static int dmirror_device_init(struct dmirror_device *mdevice, int id)
spin_lock_init(&mdevice->lock);
cdev_init(&mdevice->cdevice, &dmirror_fops);
+ mdevice->cdevice.owner = THIS_MODULE;
ret = cdev_add(&mdevice->cdevice, dev, 1);
if (ret)
return ret;
The use of cdev without a struct device is super weird, but it still
needs this
diff --git a/tools/testing/selftests/vm/test_hmm.sh b/tools/testing/selftests/vm/test_hmm.sh
index 461e4a99a362cf..0647b525a62564 100755
--- a/tools/testing/selftests/vm/test_hmm.sh
+++ b/tools/testing/selftests/vm/test_hmm.sh
@@ -59,7 +59,7 @@ run_smoke()
echo "Running smoke test. Note, this test provides basic coverage."
load_driver
- ./hmm-tests
+ $(dirname "${BASH_SOURCE[0]}")/hmm-tests
unload_driver
}
Make it runnably reliably
Jason
Thanks for the fixes. I'll apply these and send a v9.
I will also add missing calls to release_mem_region() to free the reserved device private
addresses.
If you decide to ignore my request to avoid addition of special header
file to UAPI, at least don't copy and install that file without some
special CONFIG option (TEST_HMM ???) requested by the users. It also
will be good to get Acked-by on this change from HMM people.
However, I still think that include/uapi/linux/test_hmm.h opens
pandora box of having UAPI files without real promise to keep it
backward compatible.
Thanks
I think that is a valid point. I would expect the test<->driver UAPI to track the kernel
version since the sources are "released" together. I suppose a version number could be
included in the request structure to handle mismatch driver and test program but that
may be overkill.
Are you suggesting that include/linux/test_hmm.h is a better location?