On Tue, 2023-02-21 at 09:22 -0800, Alison Schofield wrote: > On Fri, Feb 17, 2023 at 05:40:24PM -0700, Vishal Verma wrote: > > This test failed intermittently because the ndctl-list operation right > > after a 'modprobe cxl_test' could race the actual nmem devices getting > > loaded. > > > > Since CXL device probes are asynchronous, and cxl_acpi might've kicked > > off a cxl_bus_rescan(), a cxl_flush() (via cxl_wait_probe()) can ensure > > everything is loaded. > > > > Add a plain cxl-list right after the modprobe to allow for a flush/wait > > cycle. > > Is this the preferred method to 'settle', instead of udevadm settle?
Generally, no. Usually cxl tests would use cxl-cli commands, which now have the necessary waits via cxl_wait_probe(), so even a 'udevadm settle' shouldn't be needed. In this case, the first thing we run is ndctl list, which waits for nvdimm things to 'settle', but we were racing with cxl_test coming up, which it (ndctl) knows nothing about. > > > > > Cc: Dave Jiang <dave.ji...@intel.com> > > Suggested-by: Dan Williams <dan.j.willi...@intel.com> > > Signed-off-by: Vishal Verma <vishal.l.ve...@intel.com> > > --- > > test/security.sh | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/test/security.sh b/test/security.sh > > index 04f630e..fb04aa6 100755 > > --- a/test/security.sh > > +++ b/test/security.sh > > @@ -225,6 +225,7 @@ if [ "$uid" -ne 0 ]; then > > fi > > > > modprobe "$KMOD_TEST" > > +cxl list > > setup > > check_prereq "keyctl" > > rc=1 > > > > -- > > 2.39.1 > > > >
