Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1132320rwb; Thu, 22 Sep 2022 10:30:02 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4JUUiWLFP7+qOeti0NqYFpcwcfJG4HBPXGYMl08aEgFf0HL6J0qY9J/aT0sS29zDra+iCX X-Received: by 2002:a17:903:32cf:b0:178:3d49:45b0 with SMTP id i15-20020a17090332cf00b001783d4945b0mr4251308plr.5.1663867801883; Thu, 22 Sep 2022 10:30:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663867801; cv=none; d=google.com; s=arc-20160816; b=UGreUzib4zCXdomlVvOYywM5xsjqwNzCv8whUWFMn/LHcKgyUpGLgeY1AHYIMxQtzG mbdZ28l597P9Yt6hqycBvB5NeMONJMnysO+iDfdKbHOcqN2+St0OGawJfzZa7ce4hc02 JY89HLB0rgk72ahmxBiz7sBHC0hnqVmc8aEjnpBosKacfWUm91fKfPpRv82XPe1dElXS 9/BWZbOy/PQOkDKYxytnGnTaPFz2Er5vaJ/XcP0Ok7YJ6BidDkpPzJxArWSSqRJjVGY2 LqZgzqWVoub+pMabPXjsNr+CCQKVDjr0MXupc5Nb7lIVAC0XnD13Ijq9dKCn3yFBQLDx 4h4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=NsLp670RdI3g1jDRkVkeaW3CVX2HSxEN1Ogh5i9k9LY=; b=pIGut8Jb7DPbcAkU2YSkYGjUHZIvVcGU0WiLH7c7D+7QYrptoGXsoKa4hmFRfLslwW 516eUHUwVI+W+6dfouMAGPEO+lMRyoxltZbacjzuln3Pvp+C6nDJCWrd4oePWupRvDjF EoyFZtPvXrhRg3JoMDzjg6LML+GUYwQ+u8pY2NGEusw9agYrB24jJT/aWq/QbyyboyNR tKxptMOOFYG6S89HEfFD0etk00VneJPJcGOqubvdbSMOoWqodVab9T3Co4WGB5P3kmCk Hul2S8UaZ96ihF/k4riUzigiTfy4pQAfit3FHlej5+swbLHEyYmFvNvYZwzfzDNcXkWZ 39bA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@semihalf.com header.s=google header.b=IEKLSGYZ; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=semihalf.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x2-20020a656aa2000000b00434369f0878si7308326pgu.436.2022.09.22.10.29.27; Thu, 22 Sep 2022 10:30:01 -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; dkim=pass header.i=@semihalf.com header.s=google header.b=IEKLSGYZ; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=semihalf.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230293AbiIVRIb (ORCPT + 99 others); Thu, 22 Sep 2022 13:08:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230187AbiIVRI2 (ORCPT ); Thu, 22 Sep 2022 13:08:28 -0400 Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 791BEFF3EA for ; Thu, 22 Sep 2022 10:08:27 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id x23-20020a056830409700b00655c6dace73so6630250ott.11 for ; Thu, 22 Sep 2022 10:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=NsLp670RdI3g1jDRkVkeaW3CVX2HSxEN1Ogh5i9k9LY=; b=IEKLSGYZyAft4XxWcA4PD4UttV+HgJmCgq5nMaXUm4o2EF1aOrqRwi/FjAPgXePFO5 1ioPjw3VrpI42US2WJWHxn0GCPmZUch7f5WDUnnF6MKmI8f0XJdriigXi4iChVKnQ25m iscb/XcXlYEB3a8Pco4Nxcl0te/TwAFzeS85BH4mjJJWMYAAHScb5hT/nsR9VBjQ6WCo sROWS/3uxZymCkF6Ps/YA3DK4rau/j/1SPrCKcHMdRbBrO2Uw8FIZUsIbap3cgvpJffW j1AznO+MB1ZOgWS2AMbMuzhi9nR3L8jy+PtF2/9eYYryjUTgo7EU7BMub6gFsARSyVH2 /0VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=NsLp670RdI3g1jDRkVkeaW3CVX2HSxEN1Ogh5i9k9LY=; b=xSfwMM6kbhP2YYieGKovMzhhMo/yjH0GdBDaSBIpWylbGHoy90pu7ak0l03doqRzSD FaBdpie1r1r3BjVCMfJxF0WLD2AYZSCHbsrf2u5xhWJ/HO70irOsxD0sBi/nh5sLdhaM opzrMRdOgvidgrk4a0Osi6G34LEPRJI5cev7LZTYRE8gI7YRIg1mBh1GQEWTsdfjXPMz lXD3EAVHzWNZLLJkll7o3hkwtBVIWkIf0di0RwHnyUM9uIHvid8hqGkOuJU0diDYViU6 yWyAJLZRcnZghuCKThVE6xyGfov+dB4NtrX8g6MHfiSEQlrKljlAkSI8iERNzne8QJ+Q HOOg== X-Gm-Message-State: ACrzQf10ih5AMIwZzaJNtXZuM8GTtd5yplH5DsNOaKrM29KQEyEkFj6v kQBWKHze63RvcgEXNZ/LEdTnU8qZLuUnw/Mudg/S5g== X-Received: by 2002:a9d:7a8a:0:b0:656:284c:d5bd with SMTP id l10-20020a9d7a8a000000b00656284cd5bdmr2142775otn.52.1663866506690; Thu, 22 Sep 2022 10:08:26 -0700 (PDT) MIME-Version: 1.0 References: <20220921114444.2247083-1-gregkh@linuxfoundation.org> In-Reply-To: From: Marcin Wojtas Date: Thu, 22 Sep 2022 19:08:16 +0200 Message-ID: Subject: Re: [PATCH net] net: mvpp2: debugfs: fix problem with previous memory leak fix To: "Russell King (Oracle)" Cc: Greg Kroah-Hartman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 Hi, Thank you both for the patches. czw., 22 wrz 2022 o 18:05 Russell King (Oracle) napisa=C5=82(a): > > On Wed, Sep 21, 2022 at 01:44:44PM +0200, Greg Kroah-Hartman wrote: > > In commit fe2c9c61f668 ("net: mvpp2: debugfs: fix memory leak when usin= g > > debugfs_lookup()"), if the module is unloaded, the directory will still > > be present if the module is loaded again and creating the directory wil= l > > fail, causing the creation of additional child debugfs entries for the > > individual devices to fail. > > > > As this module never cleaned up the root directory it created, even whe= n > > loaded, and unloading/loading a module is not a normal operation, none > > of would normally happen. > > > > To clean all of this up, use a tiny reference counted structure to hold > > the root debugfs directory for the driver, and then clean it up when th= e > > last user of it is removed from the system. This should resolve the > > previously reported problems, and the original memory leak that > > fe2c9c61f668 ("net: mvpp2: debugfs: fix memory leak when using > > debugfs_lookup()") was attempting to fix. > > For the record... I have a better fix for this, but I haven't been able > to get it into a state suitable for submission yet. > > http://www.home.armlinux.org.uk/~rmk/misc/mvpp2-debugfs.diff > > Not yet against the net tree. Might have time tomorrow to do that, not > sure at the moment. Medical stuff is getting in the way. :( > I'd lean towards this version - it is a bit more compact. I'll try to test that tomorrow or during the weekend. Best regards, Marcin