From: David Howells <dhowells@redhat.com>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: dhowells@redhat.com, linux-afs@lists.infradead.org,
linux-fsdevel@vger.kernel.org,
Zhihao Cheng <chengzhihao1@huawei.com>,
Yi Zhang <yi.zhang@huawei.com>,
linux-kernel@vger.kernel.org
Subject: Re: [v2] afs: Fix memory leak in afs_put_sysnames()
Date: Mon, 01 Jun 2020 19:52:09 +0100 [thread overview]
Message-ID: <1358845.1591037529@warthog.procyon.org.uk> (raw)
In-Reply-To: <a28fd20e-1f9e-d070-4d2e-2bee89f39154@web.de>
Markus Elfring <Markus.Elfring@web.de> wrote:
> > Fix afs_put_sysnames() to actually free the specified afs_sysnames
> > object after its reference count has been decreased to zero and its
> > contents have been released.
>
> * How do you think about to omit the word "Fix" because of the provided tag?
Quite often I might put introductory paragraphs before that, so I prefer to
begin the paragraph that states a fix with that verb. There may also be
auxiliary changes associated with it that aren't directly fixes but need to be
made because of the fix change.
> * Is freeing and releasing an item a duplicate operation anyhow?
You're missing the point. afs_put_sysnames() does release the things the
object points to (ie. the content), but not the object itself.
> >> Will it matter to mention the size of the data structure "afs_sysnames"?
> >
> > Why is it necessary to do so?
>
> I suggest to express the impact of the missed function call "kfree".
I would hope that anyone reading the patch could work the impact out for
themselves. Just specifying the size of a struct isn't all that useful - it
may be wildly variable by arch (eg. 32/64) and config option (eg. lockdep)
anyway. Add to that rounding and packing details from the memory subsys,
along with the pinning effect of something you can't get rid of.
Of more use would be specifying the frequency or likelyhood of such a leak but
unless it's especially high, it's probably not worth mentioning.
David
next prev parent reply other threads:[~2020-06-01 18:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 14:40 [PATCH v2] afs: Fix memory leak in afs_put_sysnames() Markus Elfring
2020-06-01 17:08 ` David Howells
2020-06-01 18:04 ` [v2] " Markus Elfring
2020-06-01 18:52 ` David Howells [this message]
2020-06-02 5:51 ` Markus Elfring
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=1358845.1591037529@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=Markus.Elfring@web.de \
--cc=chengzhihao1@huawei.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yi.zhang@huawei.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