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

From: Greg Kroah-Hartman <gregkh@linuxfoundation•org>
To: Tingwei Zhang <tingwei@codeaurora•org>
Cc: tsoni@codeaurora•org,
	Sai Prakash Ranjan <saiprakash.ranjan@codeaurora•org>,
	Kim Phillips <kim.phillips@arm•com>,
	Mathieu Poirier <mathieu.poirier@linaro•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>,
	Mao Jinlong <jinlmao@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 13:07:07 +0200	[thread overview]
Message-ID: <20200723110707.GA1960107@kroah.com> (raw)
In-Reply-To: <20200723042802.22511-7-tingwei@codeaurora.org>

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?

> 
> 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?

> +				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?

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