Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp827439rwb; Mon, 26 Sep 2022 06:24:53 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6oFyC6AqgSySVv5y1gzLKsS+Ml1BYSGumcI51iTElZPAB9wx/ftSYIu2aywcJkJxwKIHQz X-Received: by 2002:a17:90b:3c90:b0:205:bd08:79ae with SMTP id pv16-20020a17090b3c9000b00205bd0879aemr4848082pjb.194.1664198692530; Mon, 26 Sep 2022 06:24:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664198692; cv=none; d=google.com; s=arc-20160816; b=Ugn95ztuzqHwcZkF6dfV/pUhUkC6NSNUiiBPFX0y86dXoo9nAd+FRi4IQUo596C3ah nOCJWEpNoTz1f4EADK5TzAhpu14ksxv1OG7KXJ/ULRrAoL88ykSOi124iDCdHm3vWWX9 ULFGcm5PULaIEUuAoyhT8DKwZvL6ZSlCEQ60kRqW/zS70VAPd3MSvi8kKzOlxeBCO6si BcyaMsMrd7sDBDbzlYUvg0SVbqqrRlIRVuyN2MJKVgav81jTSLw8zncww3tRIg7C8C7T GEo9siHmp6oXkASvokl9spQllou23oF2eTLgSSDnYYbka/omYNzUa/ozzZxduy2kQRqB zBNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=bKqKeNZnIDqp8/Laz7ovbmtuMmIzamzSKktsHK1V4ac=; b=vdRTqyVjxNpjzY40kjnFBWxQrQkX5eRqzz4GxEj4U1OuwvY6oYj1seyGTZYVC8wwbb 9MJoxisM6GsvGmscFBpQ0ntWI0d2q5JI30v+h3XOZE636jMA1Ps7pQ/farrM183srBn6 uUFJ8jzE+WljVlGcy6mpUIKJ7S8EA0bfxj4WCy+PcwUBrPYpet6jZRdoSiUZM4mkYtk3 C7JBlDI07OCqrl7aqznpJleVpZMv7eRW4CvFAw3hhs0BIDgAGJUU0phEIkKeZ25jL0XC RlS2C2rWqpQF2Q1JIh3w1qVwoR64ql2ejebYagWE14aKd/HlUWaix92ucHufouRT+7W7 Pzww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n7-20020a170902d2c700b0017555e9de54si11785897plc.427.2022.09.26.06.24.40; Mon, 26 Sep 2022 06:24:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239473AbiIZMLT (ORCPT + 99 others); Mon, 26 Sep 2022 08:11:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239424AbiIZMK7 (ORCPT ); Mon, 26 Sep 2022 08:10:59 -0400 Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 034AE81684; Mon, 26 Sep 2022 03:57:11 -0700 (PDT) Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id D61A31C09D7; Mon, 26 Sep 2022 12:40:39 +0200 (CEST) Date: Mon, 26 Sep 2022 12:40:42 +0200 From: Pavel Machek To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Liang He , Thomas Bogendoerfer , Sasha Levin Subject: Re: [PATCH 4.9 10/30] mips/pic32/pic32mzda: Fix refcount leak bugs Message-ID: <20220926104042.GD8978@amd> References: <20220926100736.153157100@linuxfoundation.org> <20220926100736.537955607@linuxfoundation.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zbGR4y+acU1DwHSi" Content-Disposition: inline In-Reply-To: <20220926100736.537955607@linuxfoundation.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --zbGR4y+acU1DwHSi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > [ Upstream commit eb9e9bc4fa5fb489c92ec588b3fb35f042ba6d86 ] >=20 > of_find_matching_node(), of_find_compatible_node() and > of_find_node_by_path() will return node pointers with refcout > incremented. We should call of_node_put() when they are not > used anymore. True. But we absolutely should not call put when we still use the reference. > +++ b/arch/mips/pic32/pic32mzda/init.c > @@ -131,13 +131,18 @@ static int __init pic32_of_prepare_platform_data(st= ruct of_dev_auxdata *lookup) > np =3D of_find_compatible_node(NULL, NULL, lookup->compatible); > if (np) { > lookup->name =3D (char *)np->name; > - if (lookup->phys_addr) > + if (lookup->phys_addr) { > + of_node_put(np); > continue; > + } > if (!of_address_to_resource(np, 0, &res)) > lookup->phys_addr =3D res.start; > + of_node_put(np); > } > } As we stored np->name in lookup, we should not be putting that node, we are still using it. Best regards, Pavel --=20 DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany --zbGR4y+acU1DwHSi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAmMxgaoACgkQMOfwapXb+vKqygCfXpKlHSst+dGtKDekJry/dOhh JUMAn2T9uxpsKom/nI/vOyoqyApFhOFK =yziF -----END PGP SIGNATURE----- --zbGR4y+acU1DwHSi--