Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Date:   Wed, 22 Nov 2023 11:44:53 -0800
From:   Breno Leitao <leitao@debian.org>
To:     Mark Pearson <mpearson-lenovo@squebb.ca>
Cc:     platform-driver-x86@vger.kernel.org, hdegoede@redhat.com,
        ilpo.jarvinen@linux.intel.com,
        ibm-acpi-devel@lists.sourceforge.net, mario.limonciello@amd.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] platform/x86: Add support for improved performance
 mode
Message-ID: <20231122194453.GA497690@gmail.com>
References: <mpearson-lenovo@squebb.ca>
 <20231113165453.6335-1-mpearson-lenovo@squebb.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231113165453.6335-1-mpearson-lenovo@squebb.ca>
Precedence: bulk

On Mon, Nov 13, 2023 at 11:54:33AM -0500, Mark Pearson wrote:
> @@ -10355,6 +10361,17 @@ static int dytc_profile_set(struct platform_profile_handler *pprof,
>  	if (err)
>  		goto unlock;
>  
> +	/* Set TMS mode appropriately (enable for performance), if available */
> +	if (dytc_ultraperf_cap) {
> +		int cmd;
> +
> +		cmd = DYTC_SET_COMMAND(DYTC_FUNCTION_TMS, DYTC_NOMODE,
> +				       profile == PLATFORM_PROFILE_PERFORMANCE);
> +		err = dytc_command(cmd, &output);
> +		if (err)
> +			return err;

Aren't you returning holding the 'dytc_mutex' mutex?

From what I understand, in the first line of this function you get the lock,
and release later, at the exit, so, returning without releasing the lock might
be dangerous. Here is a summary of how I read this function with your change:


	mutex_lock_interruptible(&dytc_mutex);
	...
	err = dytc_command(cmd, &output);
	if (err)
		return err;

unlock:
	mutex_unlock(&dytc_mutex);
	return err;


I think "goto unlock" might solve it.