Maxime Chevallier <[email protected]> writes: > The devmem selftest requires accessing /proc/sys/vm/nr_hugepages, > which is only available when hugetlbfs is supported. This isn't the > case on all CPU architectures, for example it isn't supported on ARM > 32-bits on cores that don't support LPAE. > > On these devices, the devmem kselftest doesn't skip gracefully, it hits > an exception while trying to open the nr_hugepages file : > > # Exception| _reserve_hugepages() > # Exception| ~~~~~~~~~~~~~~~~~~^^ > # Exception| File "/usr/lib/kselftests/drivers/net/hw/devmem_lib.py", > line 36, in _reserve_hugepages > # Exception| with open(NR_HUGEPAGES_FILE, 'r+', encoding='utf-8') as f: > # Exception| ~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > # Exception| FileNotFoundError: [Errno 2] No such file or directory: > '/proc/sys/vm/nr_hugepages' > > Let's check if the file exists before trying to open it, and return > immediately if we can't. > > The _reserve_hugepages() runs as part of the "require_devmem()", that > skips if devmem itself isn't supported. Before the blamed commit, this > check was done prior to accessing nr_hugepages, so the problem wasn't > showing. > > This has been found by trying to run the selftest on stmmac, on an > Altera CycloneV SoC (Cortex A9, doesn't support hugepages). > > Fixes: 8ac4255c1e0c ("selftests/net: devmem.py: add check_rx_large_niov") > Signed-off-by: Maxime Chevallier <[email protected]> > --- > tools/testing/selftests/drivers/net/hw/devmem_lib.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tools/testing/selftests/drivers/net/hw/devmem_lib.py > b/tools/testing/selftests/drivers/net/hw/devmem_lib.py > index 3554954a6691..24637fb180ca 100644 > --- a/tools/testing/selftests/drivers/net/hw/devmem_lib.py > +++ b/tools/testing/selftests/drivers/net/hw/devmem_lib.py > @@ -33,6 +33,8 @@ def _restore_nr_hugepages(nr_hugepages): > > def _reserve_hugepages(want=64): > """Raise nr_hugepages to @want and arrange for it to be restored.""" > + if not os.path.exists(NR_HUGEPAGES_FILE): > + return
Maybe raise a KsftSkipEx() would be more robust? No biggie... Reviewed-by: Björn Töpel <[email protected]>
