From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25895C433B4 for ; Thu, 8 Apr 2021 07:32:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EBF1661155 for ; Thu, 8 Apr 2021 07:32:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229552AbhDHHcd (ORCPT ); Thu, 8 Apr 2021 03:32:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:52590 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229517AbhDHHcd (ORCPT ); Thu, 8 Apr 2021 03:32:33 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9361760FF1; Thu, 8 Apr 2021 07:32:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617867142; bh=jZ4zDHsdEM1jYSB2eQTevkSyHlCwgLGqYTV1P1wR3Gs=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=M3c095rTrYMuR+s6G1+vNfJ5DjCVapWuu9h3s0451uerGbG5CA0VuFEsvj1mzN4/m ubzQyln2JIeb9dGh6T+A76AkM/xMA3RcX7Xiam34BUoYpDc/IR6psGY/HeaC92lBDh vctId2/MF8xKrSM78Bcb6Fd4fOh7abqPbqXpaU/XdxLQpXAqQZNMfh/dvG+kVBkCHz 0MBmYrCRvYN6dXnwLJX5qs27H1f6zy3K4KA60mH5XR9YEmKG0+gPfPOhAPaXdwa2Gm aU/oLJKHZA3qU85c7XaddzllnIIMwR2kZaNaoeFj+xnkm3a1vlytr2gtns8hGL6YlB BfKZPIz9grXnw== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20210406230606.3007138-1-dmitry.baryshkov@linaro.org> <161783530964.3790633.16412468884239960912@swboyd.mtv.corp.google.com> <161783803315.3790633.10829887417379757624@swboyd.mtv.corp.google.com> Subject: Re: [PATCH] clk: fixed: fix double free in resource managed fixed-factor clock From: Stephen Boyd Cc: Andy Gross , Bjorn Andersson , Michael Turquette , DRM DRIVER FOR MSM ADRENO GPU , "open list:COMMON CLK FRAMEWORK , open list:DRM DRIVER FOR MSM ADRENO GPU , freedreno , Rob Clark , Daniel Palmer" To: Dmitry Baryshkov Date: Thu, 08 Apr 2021 00:32:21 -0700 Message-ID: <161786714115.3790633.2310701694968142298@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Quoting Dmitry Baryshkov (2021-04-07 17:52:01) > > Short story: no other patches needed. >=20 > 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). >=20 > 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. >=20 >=20 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.