On Wed, Apr 15, 2020 at 12:39:45PM -0700, Ralph Campbell wrote:
>
> 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.
Yes, it is really overkill.
> Are you suggesting that include/linux/test_hmm.h is a better location?
It is one of options, another option maybe similar to that is done in
scripts/mod/modpost.c [1], where C file is generated on the fly.
[1] https://lore.kernel.org/netdev/20200415133648.1306956-5-leon@xxxxxxxxxx
