Re: [PATCH v4 06/20] coresight: add try_get_module() in coresight_grab_device()

From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: tsoni@codeaurora.org,
	Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
	Kim Phillips <kim.phillips@arm.com>,
	Mao Jinlong <jinlmao@codeaurora.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	coresight@lists.linaro.org, Randy Dunlap <rdunlap@infradead.org>,
	Mian Yousaf Kaukab <ykaukab@suse.de>,
	Russell King <linux@armlinux.org.uk>,
	Tingwei Zhang <tingwei@codeaurora.org>,
	Leo Yan <leo.yan@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH v4 06/20] coresight: add try_get_module() in coresight_grab_device()
Date: Thu, 23 Jul 2020 12:04:47 -0600	[thread overview]
Message-ID: <20200723180447.GA1323936@xps15> (raw)
In-Reply-To: <20200723110707.GA1960107@kroah.com>

Hi Greg,

On Thu, Jul 23, 2020 at 01:07:07PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 23, 2020 at 12:27:48PM +0800, Tingwei Zhang wrote:
> > When coresight device is in an active session, driver module of
> > that device should not be removed. Use try_get_module() in
> > coresight_grab_device() to prevent module to be unloaded.
> 
> Are you sure this works?  Why is it needed at all?  Why not just tear
> down the children properly when a module is removed so that you don't
> need this at all?

Using the terms parent and child is somewhat ambiguous...  This is not a
parent-child relationship but simply an association between devices, something
like port 1 on device "parent" is connected to port 2 on device "child".  The
parent-child nomenclature was chosen to reflect that a device appears before
another in a coresight path.  Otherwise there is no other relation between
devices, hence the choice of using try_get_module()/put_module() to prevent
drivers from being taken away.  I'd be happy to proceed differently but haven't
found better options.

Going back to parent/child, we could have chosen left/right, up/down or A/B, all
of which are just as confusion. 

> 
> > 
> > Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
> > ---
> >  drivers/hwtracing/coresight/coresight.c | 27 +++++++++++++++++++++----
> >  1 file changed, 23 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> > index b7151c5f81b1..17bc76ea86ae 100644
> > --- a/drivers/hwtracing/coresight/coresight.c
> > +++ b/drivers/hwtracing/coresight/coresight.c
> > @@ -640,7 +640,7 @@ struct coresight_device *coresight_get_sink_by_id(u32 id)
> >   * don't appear on the trace path, they should be handled along with the
> >   * the master device.
> >   */
> > -static void coresight_grab_device(struct coresight_device *csdev)
> > +static int coresight_grab_device(struct coresight_device *csdev)
> >  {
> >  	int i;
> >  
> > @@ -648,10 +648,25 @@ static void coresight_grab_device(struct coresight_device *csdev)
> >  		struct coresight_device *child;
> >  
> >  		child  = csdev->pdata->conns[i].child_dev;
> > -		if (child && child->type == CORESIGHT_DEV_TYPE_HELPER)
> > +		if (child && child->type == CORESIGHT_DEV_TYPE_HELPER) {
> > +			if (!try_module_get(child->dev.parent->driver->owner))
> 
> Why the child's parent?  Why not the child itself?

The device structure of each coresight_device is not associated with a driver.
It is there to take advantages of device goodies such as dev.type, dev.group,
dev.release and dev.bus.  Coresight IP blocks are discovered on the AMBA bus and as
such amba_device::dev::driver holds the driver itself.  In coresight_register()
the association coresigth::dev::parent = amba_device::dev is made.

> 
> 
> > +				goto err;
> 
> What about the error given to you here?  Why throw that away?
> 
> >  			pm_runtime_get_sync(child->dev.parent);
> > +		}
> >  	}
> > +	if (!try_module_get(csdev->dev.parent->driver->owner))
> > +		goto err;
> 
> You don't reduce the child's parent's driver owner module reference
> here?

Here @parent is referencing the current device.  Now that helper devices
connected to any of its outgoing ports have been enabled (and a reference count 
to the helper device driver incremented), a reference count to the current device
driver can also be incremented. 

I hope this clarify what is going on here.  It is a little unorthodox but so is
coresight.

Thanks,
Mathieu

> 
> Ugh, that's a horid sentence :(
> 
> >  	pm_runtime_get_sync(csdev->dev.parent);
> > +	return 0;
> > +err:
> > +	for (i--; i >= 0; i--) {
> > +		struct coresight_device *child;
> > +
> > +		child  = csdev->pdata->conns[i].child_dev;
> > +		if (child && child->type == CORESIGHT_DEV_TYPE_HELPER)
> > +			pm_runtime_put(child->dev.parent);
> > +	}
> > +	return -ENODEV;
> >  }
> >  
> >  /*
> > @@ -663,12 +678,15 @@ static void coresight_drop_device(struct coresight_device *csdev)
> >  	int i;
> >  
> >  	pm_runtime_put(csdev->dev.parent);
> > +	module_put(csdev->dev.parent->driver->owner);
> >  	for (i = 0; i < csdev->pdata->nr_outport; i++) {
> >  		struct coresight_device *child;
> >  
> >  		child  = csdev->pdata->conns[i].child_dev;
> > -		if (child && child->type == CORESIGHT_DEV_TYPE_HELPER)
> > +		if (child && child->type == CORESIGHT_DEV_TYPE_HELPER) {
> >  			pm_runtime_put(child->dev.parent);
> > +			module_put(child->dev.parent->driver->owner);
> > +		}
> >  	}
> >  }
> >  
> > @@ -721,7 +739,8 @@ static int _coresight_build_path(struct coresight_device *csdev,
> >  	if (!node)
> >  		return -ENOMEM;
> >  
> > -	coresight_grab_device(csdev);
> > +	if (coresight_grab_device(csdev))
> > +		return -ENODEV;
> 
> Why not return the error given to you?
> 
> 
> thanks,
> 
> greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel