All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Michael Turquette <mturquette@baylibre.com>,
	DRM DRIVER FOR MSM ADRENO GPU  <linux-arm-msm@vger.kernel.org>,
	"open list:COMMON CLK FRAMEWORK <linux-clk@vger.kernel.org>,
	open  list:DRM DRIVER FOR MSM ADRENO GPU
	<dri-devel@lists.freedesktop.org>,
	 freedreno <freedreno@lists.freedesktop.org>,
	Rob Clark  <robdclark@chromium.org>,
	Daniel Palmer" <daniel@0x0f.com>
Subject: Re: [PATCH] clk: fixed: fix double free in resource managed fixed-factor clock
Date: Thu, 08 Apr 2021 00:32:21 -0700	[thread overview]
Message-ID: <161786714115.3790633.2310701694968142298@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <CAA8EJprrQVPZxV7nhScgTCL7ZKU2c1AicNjOvd2YUEu8pCUxkQ@mail.gmail.com>

Quoting Dmitry Baryshkov (2021-04-07 17:52:01)
>
> Short story: no other patches needed.
> 
> Long story:
> I've checked the rest of devres allocations in clk subsystem.
> Interesting, they use a bit different pattern: they devres_alloc a
> pointer to the clock, then they fill the pointer with the new clock
> data. The release callback would (correctly) free the clock pointer by
> the devres and then devres code would kfree the devres data (clock
> pointer).
> 
> The fixed-factor is unique in this area, because it devres_alloc's a
> clock instance (rather than the pointer) and then fills it, so it
> should not be freed in the release callback (only unregistered) with
> the devres code kfreeing() the instance itself.
> 
> 

Cool thanks for checking. Maybe we should change those other callers in
clk directory to devres alloc the container structure instead of a
pointer. Then we avoid the double allocation. Glad it's not a critical
fix though.

  reply	other threads:[~2021-04-08  7:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-06 23:06 [PATCH] clk: fixed: fix double free in resource managed fixed-factor clock Dmitry Baryshkov
2021-04-06 23:06 ` Dmitry Baryshkov
2021-04-07  9:00 ` Dmitry Baryshkov
2021-04-07  9:00   ` Dmitry Baryshkov
2021-04-07 11:38 ` Daniel Palmer
2021-04-07 11:38   ` Daniel Palmer
2021-04-07 22:41 ` Stephen Boyd
2021-04-07 22:41   ` Stephen Boyd
2021-04-07 22:57   ` Dmitry Baryshkov
2021-04-07 22:57     ` Dmitry Baryshkov
2021-04-07 23:27     ` Stephen Boyd
2021-04-08  0:52       ` Dmitry Baryshkov
2021-04-08  7:32         ` Stephen Boyd [this message]
2021-04-07 23:01 ` Stephen Boyd
2021-04-07 23:01   ` Stephen Boyd

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=161786714115.3790633.2310701694968142298@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel@0x0f.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    /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.