public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Elliot Berman <quic_eberman@quicinc.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Andrew Halaney <ahalaney@redhat.com>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Rudraksha Gupta <guptarud@gmail.com>,
	"Linux regression tracking (Thorsten Leemhuis)"
	<regressions@leemhuis.info>, <linux-arm-msm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH 2/2] firmware: qcom: scm: fall back to kcalloc() for no SCM device bound
Date: Mon, 9 Sep 2024 14:04:09 -0700	[thread overview]
Message-ID: <20240909131842193-0700.eberman@hu-eberman-lv.qualcomm.com> (raw)
In-Reply-To: <20240909-tzmem-null-ptr-v1-2-96526c421bac@linaro.org>

On Mon, Sep 09, 2024 at 08:38:45PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> Older platforms don't have an actual SCM device tied into the driver
> model and so there's no struct device which to use with the TZ Mem API.
> We need to fall-back to kcalloc() when allocating the buffer for
> additional SMC arguments on such platforms which don't even probe the SCM
> driver and never create the TZMem pool.
> 
> Fixes: 449d0d84bcd8 ("firmware: qcom: scm: smc: switch to using the SCM allocator")
> Reported-by: Rudraksha Gupta <guptarud@gmail.com>
> Closes: https://lore.kernel.org/lkml/692cfe9a-8c05-4ce4-813e-82b3f310019a@gmail.com/<S-Del>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  drivers/firmware/qcom/qcom_scm-smc.c | 28 ++++++++++++++++++++++++----
>  1 file changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm-smc.c b/drivers/firmware/qcom/qcom_scm-smc.c
> index 2b4c2826f572..13f72541033c 100644
> --- a/drivers/firmware/qcom/qcom_scm-smc.c
> +++ b/drivers/firmware/qcom/qcom_scm-smc.c
> @@ -147,6 +147,15 @@ static int __scm_smc_do(struct device *dev, struct arm_smccc_args *smc,
>  	return 0;
>  }
>  
> +static void smc_args_free(void *ptr)
> +{
> +	if (qcom_scm_get_tzmem_pool())

I'm a little concerned about this check. I didn't think making SCM calls
without the SCM device probed was possible until this report. We do
worry about that in the downstream kernel. So, I'm not sure if this
scenario is currently possible in the upstream kernel.

It's possible that some driver makes SCM call in parallel to SCM device
probing. Then, it might be possible for qcom_scm_get_tzmem_pool() to
return NULL at beginning of function and then a valid pointer by the
time we're freeing the ptr.

- Elliot

> +		qcom_tzmem_free(ptr);
> +	else
> +		kfree(ptr);
> +}
> +
> +DEFINE_FREE(smc_args, void *, if (!IS_ERR_OR_NULL(_T)) smc_args_free(_T));
>  
>  int __scm_smc_call(struct device *dev, const struct qcom_scm_desc *desc,
>  		   enum qcom_scm_convention qcom_convention,
> @@ -155,7 +164,7 @@ int __scm_smc_call(struct device *dev, const struct qcom_scm_desc *desc,
>  	struct qcom_tzmem_pool *mempool = qcom_scm_get_tzmem_pool();
>  	int arglen = desc->arginfo & 0xf;
>  	int i, ret;
> -	void *args_virt __free(qcom_tzmem) = NULL;
> +	void *args_virt __free(smc_args) = NULL;
>  	gfp_t flag = atomic ? GFP_ATOMIC : GFP_KERNEL;
>  	u32 smccc_call_type = atomic ? ARM_SMCCC_FAST_CALL : ARM_SMCCC_STD_CALL;
>  	u32 qcom_smccc_convention = (qcom_convention == SMC_CONVENTION_ARM_32) ?
> @@ -173,9 +182,20 @@ int __scm_smc_call(struct device *dev, const struct qcom_scm_desc *desc,
>  		smc.args[i + SCM_SMC_FIRST_REG_IDX] = desc->args[i];
>  
>  	if (unlikely(arglen > SCM_SMC_N_REG_ARGS)) {
> -		args_virt = qcom_tzmem_alloc(mempool,
> -					     SCM_SMC_N_EXT_ARGS * sizeof(u64),
> -					     flag);
> +		/*
> +		 * Older platforms don't have an entry for SCM in device-tree
> +		 * and so no device is bound to the SCM driver. This means there
> +		 * is no struct device for the TZ Mem API. Fall back to
> +		 * kcalloc() on such platforms.
> +		 */
> +		if (mempool)
> +			args_virt = qcom_tzmem_alloc(
> +					mempool,
> +					SCM_SMC_N_EXT_ARGS * sizeof(u64),
> +					flag);
> +		else
> +			args_virt = kcalloc(SCM_SMC_N_EXT_ARGS, sizeof(u64),
> +					    flag);
>  		if (!args_virt)
>  			return -ENOMEM;
>  
> 
> -- 
> 2.43.0
> 

  parent reply	other threads:[~2024-09-09 21:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-09 18:38 [PATCH 0/2] firmware: qcom: scm: fix SMC calls on ARM32 Bartosz Golaszewski
2024-09-09 18:38 ` [PATCH 1/2] firmware: qcom: scm: fix a NULL-pointer dereference Bartosz Golaszewski
2024-09-09 20:06   ` Konrad Dybcio
2024-09-10  6:45   ` Rudraksha Gupta
2024-09-09 18:38 ` [PATCH 2/2] firmware: qcom: scm: fall back to kcalloc() for no SCM device bound Bartosz Golaszewski
2024-09-09 20:10   ` Konrad Dybcio
2024-09-09 21:04   ` Elliot Berman [this message]
2024-09-10  8:37     ` Bartosz Golaszewski
2024-09-10 11:06     ` Dmitry Baryshkov
2024-09-11 11:41       ` Bartosz Golaszewski
2024-09-11 11:55         ` Dmitry Baryshkov
2024-09-11 18:01         ` Rudraksha Gupta
2024-09-11 19:44           ` Bartosz Golaszewski
2024-09-10  6:46   ` Rudraksha Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240909131842193-0700.eberman@hu-eberman-lv.qualcomm.com \
    --to=quic_eberman@quicinc.com \
    --cc=ahalaney@redhat.com \
    --cc=andersson@kernel.org \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=guptarud@gmail.com \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regressions@leemhuis.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox