Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3054519pxv; Sun, 27 Jun 2021 17:33:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy1CuWA7B6rhlLpGsaGPw2SpWLwkf7X5N64XtlD5iBg8cA2HQFJ+S4RGAyob72THVRmULkm X-Received: by 2002:aa7:dd57:: with SMTP id o23mr29107251edw.6.1624840398162; Sun, 27 Jun 2021 17:33:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624840398; cv=none; d=google.com; s=arc-20160816; b=ACRKcPCC9DkhSyGaAfZM8VM3OqZR2Y/J0V8IUZRZofmUGNFcL5QlDQy95MuAFqXJee /DoLQ280gRMxQgJXSmE11a+4kgC1JKATjDAZrCj+SF7d8fu9fAz4K6w843hqMi001VJP +zD9FR89pnUFUtT8rishdo8fNtUsKZ47hFO1PoNFRMWbcebai0wFZKsn4Ddu5ntaLnK/ wbaZoxHZJpPKS73P91I7lNMTw8hbgGutZ2VZKBCWsH8m0mjmdRfTQp4+m3Ow5ga6XZkB jW9foapDsb0b2GX4IpjUp6abwltTD6jL7R97046lkgnAV/GG6RFtuJCXWnQmywAxIlS1 vGGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:dkim-signature; bh=n7M28hFUwo0t3z3ukhVUpDX7Pqm41FdcERBzHJotZrA=; b=soP8hyqQytuS3hbmfP3Hlos69dy2/QXQM450IqCsYdqBOTWAUfBz1L3Og6KZbSnD+a x5Ci/FxdCjK6iPIixoC7IOIRatjLPbQ5Qr8o/Bw8DF/pXYZPAczPGbhPhYlevqetBwLx 7yjMgq6R1/EKG9Sx4xlRoIVJILj/sQK0V+HHiHXaGEE+o0Ha53o8ozV9l9I6OKMZaPtI wZ1UNV0SC3h+RL4XFB58WVdxRPAqVfIZbjss4loHRJJlR7wQpnH6MOSfYdKp/6DoEPmn QLShtyGQNr9Os3yxJPTAvBlCouuSkvduO3rj+4I0o9FNDPDTE9e3wAJJRTNs/jZc6G2M 9ZUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Vttc8PSD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ia4si12592105ejc.84.2021.06.27.17.32.43; Sun, 27 Jun 2021 17:33:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Vttc8PSD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231737AbhF1Abu (ORCPT + 99 others); Sun, 27 Jun 2021 20:31:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231689AbhF1Abu (ORCPT ); Sun, 27 Jun 2021 20:31:50 -0400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BD06C061574; Sun, 27 Jun 2021 17:29:24 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id q4so14299037ljp.13; Sun, 27 Jun 2021 17:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=n7M28hFUwo0t3z3ukhVUpDX7Pqm41FdcERBzHJotZrA=; b=Vttc8PSDitkrqIejHH/KizML5yuFrK0gpCQ1idLH//0yA5+x/vWBFuF2I8j7GL1dds QPaXNmd72xs11JmBa7lleshBRWPP4XqBXrU+ngmWNCa0QTLXXoftp+1cyj11HnVQHJkX 90Xjz6fmxkiZoaf8XdYXbCE+mJzD6bOl/uRHTsR5ol3qxS4VzGMVMxraoeDi1NfPx0gj KRpddqrbGes4BaKCLISP1tUjBwNQ56VWSvl1bJdKF7QNi0tew5Qd9GBLaCdQX1bL9/WA ydb9ngQrzeS8/8oXBkIN1bzTPogUt2qqRZWErQUk4ByTtPkoRk+gFoSVc+zxwlhD225Q lg1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=n7M28hFUwo0t3z3ukhVUpDX7Pqm41FdcERBzHJotZrA=; b=HdHMCj1IL/gdiG/5NPeNdO3ryW1KSFZ2f6t0eL137N/BmoWE7iuB1j/o0yK69nYEJJ Z6lK7DH4yijwbnnchXDmaigQM6vfxyQaK1ub51DkA/HuovG9RPRVdqaNgtbL9LXmW4U2 VGlU3b3ril9NktUFQcE4UFt8D2EDB4HBBPgXZNDI4qak8CvOZ54SyaxQkQ96oiGZwjxY /BhDNuzq5XmWYT0CakkStCl5Uv/eSMLh1B8W6Ux3kz2T8J8NjqhvwsHQ1XU4PTEpgosO 9Bnl/CIcv6M3w6ZYlIw8jwCNDg7FugZrl62/Kv1a8cz0VnnhZfDsRm2gClzdim7aDcvs 8CQg== X-Gm-Message-State: AOAM533KWYymQyhVM6MCeVq9I0twA8L/iGTJc9gIbZC0DZS+x0ZLfU/5 cxQiXqL+A9FRLXDodbkEHJTr9bvBn3w= X-Received: by 2002:a2e:b8ca:: with SMTP id s10mr8671391ljp.449.1624840161847; Sun, 27 Jun 2021 17:29:21 -0700 (PDT) Received: from [192.168.2.145] (94-29-37-113.dynamic.spd-mgts.ru. [94.29.37.113]) by smtp.googlemail.com with ESMTPSA id z25sm1162708lfu.22.2021.06.27.17.29.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Jun 2021 17:29:21 -0700 (PDT) Subject: Re: [PATCH 1/1] clk: tegra: tegra124-emc: Fix possible memory leak To: Stephen Boyd , Jonathan Hunter , "Leizhen (ThunderTown)" , Michael Turquette , Peter De Schrijver , Prashant Gaikwad , Thierry Reding , linux-clk , linux-kernel , linux-tegra References: <20210617082759.1008-1-thunder.leizhen@huawei.com> <162466387362.3259633.2364843071785127818@swboyd.mtv.corp.google.com> <162483744494.3259633.12565750309559171999@swboyd.mtv.corp.google.com> From: Dmitry Osipenko Message-ID: <5eb50fd9-1de9-cc61-6443-d84999e22803@gmail.com> Date: Mon, 28 Jun 2021 03:29:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <162483744494.3259633.12565750309559171999@swboyd.mtv.corp.google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 28.06.2021 02:44, Stephen Boyd пишет: > Quoting Leizhen (ThunderTown) (2021-06-25 18:32:46) >> >> >> On 2021/6/26 7:31, Stephen Boyd wrote: >>> Quoting Zhen Lei (2021-06-17 01:27:59) >>>> When krealloc() fails to expand the memory and returns NULL, the original >>>> memory is not released. In this case, the original "timings" scale should >>>> be maintained. >>>> >>>> Fixes: 888ca40e2843 ("clk: tegra: emc: Support multiple RAM codes") The memory is still not released on error and this is not the only one place in that code which doesn't release memory on error. All this code is executed only once during early kernel boot, perhaps not really worthwhile fixing it or at least this should be done properly. >>>> Signed-off-by: Zhen Lei >>>> --- >>> >>> Looks correct, but when does krealloc() return NULL? My read of the >>> kerneldoc is that it would return the original memory if the new >>> allocation "failed". >> >> That must be the wrong description in the document. For example, the original > > Can you fix the kernel doc then? > The doc is clearly saying that it returns NULL, am I missing something? * Return: pointer to the allocated memory or %NULL in case of error