All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@linaro.org>
To: Mario Limonciello <superm1@kernel.org>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	mario.limonciello@amd.com, Shyam-sundar.S-k@amd.com,
	"Hans de Goede" <hdegoede@redhat.com>,
	platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH v2] platform/x86/amd: pmf: Use device managed allocations
Date: Fri, 9 May 2025 10:53:02 +0300	[thread overview]
Message-ID: <aB20XiyxaZPE21jp@stanley.mountain> (raw)
In-Reply-To: <08862428-d104-4255-bf91-4223abda10cd@kernel.org>

On Thu, May 08, 2025 at 02:33:54PM -0500, Mario Limonciello wrote:
> On 5/7/2025 4:44 AM, Ilpo Järvinen wrote:
> > On Tue, 6 May 2025, Mario Limonciello wrote:
> > 
> > > From: Mario Limonciello <mario.limonciello@amd.com>
> > > 
> > > If setting up smart PC fails for any reason then this can lead to
> > > a double free when unloading amd-pmf.  This is because dev->buf was
> > > freed but never set to NULL and is again freed in amd_pmf_remove().
> > > 
> > > To avoid subtle allocation bugs in failures leading to a double free
> > > change all allocations into device managed allocations.
> > > 
> > > Fixes: 5b1122fc4995f ("platform/x86/amd/pmf: fix cleanup in amd_pmf_init_smart_pc()")
> > > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> > > ---
> > > v1->v2:
> > >   * Correct commit message with correct offending function root cause
> > >   * Switch to device managed allocations.
> > > 
> > >   drivers/platform/x86/amd/pmf/core.c   |  3 +--
> > >   drivers/platform/x86/amd/pmf/tee-if.c | 30 ++++++++-------------------
> > >   2 files changed, 10 insertions(+), 23 deletions(-)
> > > 
> > > diff --git a/drivers/platform/x86/amd/pmf/core.c b/drivers/platform/x86/amd/pmf/core.c
> > > index 96821101ec773..395c011e837f1 100644
> > > --- a/drivers/platform/x86/amd/pmf/core.c
> > > +++ b/drivers/platform/x86/amd/pmf/core.c
> > > @@ -280,7 +280,7 @@ int amd_pmf_set_dram_addr(struct amd_pmf_dev *dev, bool alloc_buffer)
> > >   			dev_err(dev->dev, "Invalid CPU id: 0x%x", dev->cpu_id);
> > >   		}
> > > -		dev->buf = kzalloc(dev->mtable_size, GFP_KERNEL);
> > > +		dev->buf = devm_kzalloc(dev->dev, dev->mtable_size, GFP_KERNEL);
> > >   		if (!dev->buf)
> > >   			return -ENOMEM;
> > >   	}
> > > @@ -493,7 +493,6 @@ static void amd_pmf_remove(struct platform_device *pdev)
> > >   	mutex_destroy(&dev->lock);
> > >   	mutex_destroy(&dev->update_mutex);
> > >   	mutex_destroy(&dev->cb_mutex);
> > > -	kfree(dev->buf);
> > >   }
> > >   static const struct attribute_group *amd_pmf_driver_groups[] = {
> > > diff --git a/drivers/platform/x86/amd/pmf/tee-if.c b/drivers/platform/x86/amd/pmf/tee-if.c
> > > index d3bd12ad036ae..50c082a78cd9e 100644
> > > --- a/drivers/platform/x86/amd/pmf/tee-if.c
> > > +++ b/drivers/platform/x86/amd/pmf/tee-if.c
> > > @@ -532,13 +532,13 @@ int amd_pmf_init_smart_pc(struct amd_pmf_dev *dev)
> > >   	dev->policy_base = devm_ioremap_resource(dev->dev, dev->res);
> > >   	if (IS_ERR(dev->policy_base)) {
> > >   		ret = PTR_ERR(dev->policy_base);
> > > -		goto err_free_dram_buf;
> > > +		goto err_cancel_work;
> > >   	}
> > > -	dev->policy_buf = kzalloc(dev->policy_sz, GFP_KERNEL);
> > > +	dev->policy_buf = devm_kzalloc(dev->dev, dev->policy_sz, GFP_KERNEL);
> > 
> > Hi Mario,
> > 
> > Isn't ->policy_buf freed and another allocated in amd_pmf_get_pb_data()
> > and this patch lacks any changes around there?? That switch of the buffer
> > has been the reason why I've not suggested using devm_*() for earlier for
> > it.
> > 
> > Please check all related code to the pointers you're changing if there
> > are other similar traps you have not taken into account.
> 
> Ah, thanks I thought I caught them all but missed that instance.
> 
> A few options that come to mind:
> 1) instead make the very first allocation POLICY_BUF_MAX_SZ, and then never
> reallocate for the life of the driver.
> 2) Don't allow sideloading a bigger policy than the original one in the
> firmware.
> 3) Don't switch all 3 to device managed like this patch, just switch the two
> that can and fix the one broken one causing a double free.
> 4) Switch the case you pointed out to use devm_kfree() and re-allocate at
> that time.
> 
> Anyone with a preference?  I lean upon option 4.
> 

I feel like Option 3 is the worst...

I didn't have a problem with your v1 patch if we had fix the
amd_pmf_tee_deinit() bug as well and probably deleted the
second kfree().

I think there is a race with the debugfs sideloader, but it's
debugfs and root only so if you hit that race, then you deserve
it.

regards,
dan carpenter


      reply	other threads:[~2025-05-09  7:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07  2:07 [PATCH v2] platform/x86/amd: pmf: Use device managed allocations Mario Limonciello
2025-05-07  7:27 ` Dan Carpenter
2025-05-07  9:44 ` Ilpo Järvinen
2025-05-08 19:33   ` Mario Limonciello
2025-05-09  7:53     ` Dan Carpenter [this message]

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=aB20XiyxaZPE21jp@stanley.mountain \
    --to=dan.carpenter@linaro.org \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=mario.limonciello@amd.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=superm1@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.