[igt-dev] [PATCH i-g-t] lib/igt_kmod: Allow some leeway in igt_kmod_unload_r

[Cavitt, Jonathan]

-----Original Message-----
From: Kamil Konieczny <kamil.konieczny at linux.intel.com> 
Sent: Wednesday, January 18, 2023 11:32 AM
To: igt-dev at lists.freedesktop.org
Cc: chris.p.wilson at linux.intel.com; Cavitt, Jonathan <jonathan.cavitt at intel.com>; Parupalli, Sandeep Kumar <sandeep.kumar.parupalli at intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t] lib/igt_kmod: Allow some leeway in igt_kmod_unload_r
> 
> Hi Jonathan,
> 
> On 2023-01-18 at 08:06:31 -0800, Jonathan Cavitt wrote:
> > kmod_module_remove_module occasionally returns EAGAIN for mei_gsc
> > in the setup of some gem_lmem_swapping subtests.  Just because
> > EAGAIN is returned doesn't mean the module is lost and unable to
> > be unloaded.  Try again some number of times (currently 20) before
> > giving up.
> > 
> > Retries will occur for -EBUSY and -EAGAIN, as these imply the
> > system is waiting for the target module can simply be waited for.
> > All other errors exit immediately, but as the context for each
> > error informs their relative severity, no warnings will be issued.
> > 
> > Signed-off-by: Jonathan Cavitt <jonathan.cavitt at intel.com>
> > CC: Stuart Summers <stuart.summers at intel.com>
> > CC: Sandeep Kumar Parupalli <sandeep.kumar.parupalli at intel.com>
> > CC: Chris Wilson <chris.p.wilson at linux.intel.com>
> > Reviewed-by: Chris Wilson <chris.p.wilson at linux.intel.com>
> > ---
> >  lib/igt_kmod.c | 35 ++++++++++++++++++++++++++++++++---
> >  1 file changed, 32 insertions(+), 3 deletions(-)
> > 
> > diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
> > index 17090110c..4aa5320d0 100644
> > --- a/lib/igt_kmod.c
> > +++ b/lib/igt_kmod.c
> > @@ -253,8 +253,11 @@ out:
> >  
> >  static int igt_kmod_unload_r(struct kmod_module *kmod, unsigned int flags)
> >  {
> > +#define MAX_TRIES	20
> > +#define SLEEP_DURATION	500000
> >  	struct kmod_list *holders, *pos;
> > -	int err = 0;
> > +	int err, tries;
> > +	const char *mod_name = kmod_module_get_name(kmod);
> >  
> >  	holders = kmod_module_get_holders(kmod);
> >  	kmod_list_foreach(pos, holders) {
> > @@ -269,7 +272,6 @@ static int igt_kmod_unload_r(struct kmod_module *kmod, unsigned int flags)
> >  		return err;
> >  
> >  	if (igt_kmod_is_loading(kmod)) {
> > -		const char *mod_name = kmod_module_get_name(kmod);
> >  		igt_debug("%s still initializing\n", mod_name);
> >  		err = igt_wait(!igt_kmod_is_loading(kmod), 10000, 100);
> >  		if (err < 0) {
> > @@ -279,7 +281,34 @@ static int igt_kmod_unload_r(struct kmod_module *kmod, unsigned int flags)
> >  		}
> >  	}
> >  
> > -	return kmod_module_remove_module(kmod, flags);
> > +	for (tries = 0; tries < MAX_TRIES; tries++) {
> > +		err = kmod_module_remove_module(kmod, flags);
> > +
> > +		/* Only loop in the following cases */
> > +		if (err != -EBUSY && err != -EAGAIN)
> > +			break;
> > +
> > +		igt_debug("Module %s failed to unload with err: %d on attempt: %i\n",
> > +			  mod_name, err, tries + 1);
> > +
> > +		if (MAX_TRIES - tries - 1)
> ------------------ ^
> This should be tries < MAX_TRIES - 1

I'm using "tries != MAX_TRIES - 1", which should also work as long as the for-loop doesn't somehow overflow.
Here, the two are logically equivalent:

tries != MAX_TRIES - 1
tries - tries != MAX_TRIES - 1 - tries
0 != MAX_TRIES - tries - 1

... I'll clean it up for clarity...

> 
> > +			usleep(SLEEP_DURATION);
> > +	}
> > +
> > +	if (err == -ENOENT)
> > +		igt_debug("Module %s could not be found or does not exist. err: %d\n",
> > +			  mod_name, err);
> > +	else if (err == -ENOTSUP)
> > +		igt_debug("Module %s cannot be unloaded. err: %d\n",
> > +			  mod_name, err);
> > +	else if (err)
> > +		igt_debug("Module %s failed to unload with err: %d after ~%.1fms\n",
> > +			  mod_name, err, SLEEP_DURATION*tries/1000.);
> > +	else if (tries)
> > +		igt_debug("Module %s unload took ~%.1fms over %i attempts\n",
> > +			  mod_name, SLEEP_DURATION*tries/1000., tries + 1);
> 
> What about one final else with igt_debug about success at first try ?

Generally speaking, should we really be printing debug information when a
function behaves as intended?  I don't believe so, but if you want me to add
that debug message there I'll do it.
-Jonathan Cavitt

> 
> Regards,
> Kamil
> 
> > +
> > +	return err;
> >  }
> >  
> >  /**
> > -- 
> > 2.25.1
> > 
>