From: Hui Su <sh_def@163.com>
To: Ira Weiny <ira.weiny@intel.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/vmalloc.c: check the addr first
Date: Thu, 8 Oct 2020 20:11:25 +0800 [thread overview]
Message-ID: <20201008121125.GA6644@rlk> (raw)
In-Reply-To: <20200928180434.GD458519@iweiny-DESK2.sc.intel.com>
On Mon, Sep 28, 2020 at 11:04:34AM -0700, Ira Weiny wrote:
> On Mon, Sep 28, 2020 at 12:33:37AM +0800, Hui Su wrote:
> > As the comments said, if @addr is NULL, no operation
> > is performed, check the addr first in vfree() and
> > vfree_atomic() maybe a better choice.
>
> I don't see how this change helps anything. kmemleak_free() checks addr so no
> danger there. Also kmemleak_free() contains a pr_debug() which some might find
> useful.
>
> Ira
>
Thanks for your explanations, Ira.
Firstly, as you have said, the kmemleak_free() only unregister a previously
registered object(which shouldn't be NULL), and kmemleak_free() alse check the
ptr whether is NULL, it does no danger here.
Secondly, as you said kmemleak_free() contains a pr_debug() which will be useful,
and i don't think so because this patch only filter out the NULL pointer case, which
may not be useful?(maybe not right?)
Thirdly, let's see kimage_file_prepare_segments() and kimage_file_post_load_cleanup()
in kernel/kexec_file.c.
kimage_file_prepare_segments() uses 'out' label in several places, when reading
files from kernel_fd or initrd_fd or memdup_user cmdline_buf.
The out label will run kimage_file_post_load_cleanup(), which will do vfree()
for ->kernel_buf and ->initrd_buf and ->cmdline_buf and so on...
Supposing the arch_kexec_kernel_image_probe() failed, and it goto out, then it
still vfree(->initrd_buf). In this case we can return faster if we check param
addr first in vfree().
In this case maybe we should use more Precise labels?
All above is my opinion, thanks.
> >
> > Signed-off-by: Hui Su <sh_def@163.com>
> > ---
> > mm/vmalloc.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index be4724b916b3..1cf50749a209 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -2305,10 +2305,11 @@ void vfree_atomic(const void *addr)
> > {
> > BUG_ON(in_nmi());
> >
> > - kmemleak_free(addr);
> > -
> > if (!addr)
> > return;
> > +
> > + kmemleak_free(addr);
> > +
> > __vfree_deferred(addr);
> > }
> >
> > @@ -2340,13 +2341,13 @@ void vfree(const void *addr)
> > {
> > BUG_ON(in_nmi());
> >
> > + if (!addr)
> > + return;
> > +
> > kmemleak_free(addr);
> >
> > might_sleep_if(!in_interrupt());
> >
> > - if (!addr)
> > - return;
> > -
> > __vfree(addr);
> > }
> > EXPORT_SYMBOL(vfree);
> > --
> > 2.25.1
> >
> >
> >
prev parent reply other threads:[~2020-10-08 12:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-27 16:33 [PATCH] mm/vmalloc.c: check the addr first Hui Su
2020-09-28 18:04 ` Ira Weiny
2020-10-08 12:11 ` Hui Su [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=20201008121125.GA6644@rlk \
--to=sh_def@163.com \
--cc=akpm@linux-foundation.org \
--cc=ira.weiny@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.