From: Dan Carpenter <error27@gmail.com>
To: Dongliang Mu <dzm91@hust.edu.cn>
Cc: Francois Romieu <romieu@fr.zoreil.com>,
Gencen Gan <u202011061@gmail.com>,
Chas Williams <3chas3@gmail.com>,
linux-atm-general@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, smatch@vger.kernel.org
Subject: Re: [PATCH] atm: he: fix potential ioremap leak of membase in he_dev
Date: Fri, 10 Mar 2023 18:12:39 +0300 [thread overview]
Message-ID: <1c2dae4a-554c-4e88-a27a-bc28426e500d@kili.mountain> (raw)
In-Reply-To: <c379d193-5408-a514-9f37-eb93585557ab@hust.edu.cn>
On Fri, Mar 10, 2023 at 09:15:43PM +0800, Dongliang Mu wrote:
>
>
> On 3/10/23 19:28, Francois Romieu wrote:
> > Gencen Gan <u202011061@gmail.com> :
> > > In the function he_start() in drivers/atm/he.c, there
> > > is no unmapping of he_dev->membase in the branch that
> > > exits due to an error like reset failure, which may
> > > cause a memory leak.
> >
> > Why would he_dev->membase not be unmapped in he_stop() ?
> >
> > he_stop() is paired with he_start() as soon a he_start() returns
> > anything different from 0 in he_init_one(). I see no other place
> > where he_start() is used.
>
> Yes, you're right. We will check more about reports from the static checker
> Smatch.
>
> Smatch should make a false positive here, I think it might be that, Smatch
> has an assumption about do and its paired undo functions. The do function
> should clean up its own allocation operations. And the paired undo function
> can be only called if the do function succeeds.
>
> +cc Dan Carpenter
>
> Maybe @Dan could tell more about this point.
>
Yes. Smatch is assuming that every function cleans up after itself.
Generally this is the way most functions do it.
Perhaps the best option here is to create a new warning for the double
free bug if this patch were applied.
regards,
dan carpenter
prev parent reply other threads:[~2023-03-10 15:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 10:22 [PATCH] atm: he: fix potential ioremap leak of membase in he_dev Gencen Gan
2023-03-10 11:28 ` Francois Romieu
2023-03-10 13:15 ` Dongliang Mu
2023-03-10 15:12 ` Dan Carpenter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1c2dae4a-554c-4e88-a27a-bc28426e500d@kili.mountain \
--to=error27@gmail.com \
--cc=3chas3@gmail.com \
--cc=dzm91@hust.edu.cn \
--cc=linux-atm-general@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.com \
--cc=smatch@vger.kernel.org \
--cc=u202011061@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox