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;
MIME-Version: 1.0
References: <20230619112253.v2.1.I13f060c10549ef181603e921291bdea95f83033c@changeid>
 <35f6212e-69f8-432f-a5c8-99ed5c844f11@moroto.mountain> <CAC=S1njwxLfw7LcnXkgY7pbiFaqvNQVyAzHVhK9+nYJC63d=Zw@mail.gmail.com>
 <32fa8c0e-26f4-4ee4-889a-4037530c128d@kadam.mountain> <658d32f2-a71b-4dc2-bff9-649fadf41889@kadam.mountain>
In-Reply-To: <658d32f2-a71b-4dc2-bff9-649fadf41889@kadam.mountain>
From:   Fei Shao <fshao@chromium.org>
Date:   Mon, 19 Jun 2023 18:34:11 +0800
Message-ID: <CAC=S1njbLadG+JP38pOrek8RFHYC+En_YXDPaYEbErn8OxFH7g@mail.gmail.com>
Subject: Re: [PATCH v2] clk: Fix memory leak in devm_clk_notifier_register()
To:     Dan Carpenter <dan.carpenter@linaro.org>
Cc:     Stephen Boyd <sboyd@kernel.org>,
        Jerome Brunet <jbrunet@baylibre.com>,
        Michael Turquette <mturquette@baylibre.com>,
        linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
        Markus Elfring <Markus.Elfring@web.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Jun 19, 2023 at 5:57=E2=80=AFPM Dan Carpenter <dan.carpenter@linaro=
.org> wrote:
> The other reason to include stack traces is so that if someone else
> runs into the same bug they can find your patch by googling their stack
> trace.
>
> Normal users aren't going to be running kmemleak.  And people doing
> testing work for companies are hopefully going to pull this fix in via
> the stable tree so they'll get this patch automatically that way so
> they won't see it either.
>
> But if the stack trace is like a NULL dereference bug, then users
> absolutely do notice that kind of thing.  You should always include
> those kind of stack traces.

If that's the case, I can leave a retrospective trace record here:

unreferenced object 0xffffff80c4e34a00 (size 256):
  comm "swapper/0", pid 1, jiffies 4294667967 (age 288.740s)
  hex dump (first 32 bytes):
    00 4a e3 c4 80 ff ff ff 00 4a e3 c4 80 ff ff ff  .J.......J......
    1c 2a 7a ae d8 ff ff ff a0 b0 af af d8 ff ff ff  .*z.............
  backtrace:
    [<000000007d72e65c>] __kmem_cache_alloc_node+0x198/0x240
    [<00000000dfce47ef>] __kmalloc_node_track_caller+0x6c/0x1b8
    [<00000000b6c409fe>] __devres_alloc_node+0x60/0x104
    [<0000000081112baf>] devm_clk_notifier_register+0x44/0xc8
    [<0000000070bfe318>] devm_mtk_clk_mux_notifier_register+0x60/0x74
    [<000000000242235f>] clk_mt8188_reg_mfg_mux_notifier+0x84/0xb4
    [<00000000f67ce424>] clk_mt8188_topck_probe+0x1b8/0x2e4
    [<0000000006eef8cd>] platform_probe+0x12c/0x17c
    [<00000000eacf783c>] really_probe+0x1f0/0x4d8
    [<00000000f321a3f0>] __driver_probe_device+0x160/0x230
    [<00000000bbeed898>] driver_probe_device+0x6c/0x148
    [<000000007d5af62b>] __driver_attach+0x164/0x20c
    [<00000000c5c25e77>] bus_for_each_dev+0xf4/0x144
    [<00000000e2c0100f>] driver_attach+0x50/0x60
    [<00000000cc421ec0>] bus_add_driver+0x2a8/0x458
    [<000000007814168a>] driver_register+0x16c/0x29c

It's up to the maintainers for the next step and I'll follow the call.

Regards,
Fei