mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Aaron Sierra <asierra@xes-inc.com>
To: DaeSeok Youn <daeseok.youn@gmail.com>
Cc: martyn welch <martyn.welch@ge.com>,
	manohar vanga <manohar.vanga@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	lisa@xenapiadmin.com, yongjun wei <yongjun_wei@trendmicro.com.cn>,
	devel <devel@driverdev.osuosl.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] staging: vme: fix memory leak in vme_user_probe()
Date: Thu, 27 Mar 2014 09:30:10 -0500 (CDT)	[thread overview]
Message-ID: <202482763.23002.1395930610691.JavaMail.zimbra@xes-inc.com> (raw)
In-Reply-To: <CAHb8M2AX_KA3T2--yd3_ia9cjKpoEGUacW8zph6V6e_r_6_nuw@mail.gmail.com>


----- Original Message -----
> From: "DaeSeok Youn" <daeseok.youn@gmail.com>
> Sent: Wednesday, March 26, 2014 8:47:51 PM
>
> 2014-03-27 3:51 GMT+09:00 Aaron Sierra <asierra@xes-inc.com>:
> > ----- Original Message -----
> >> From: "Daeseok Youn" <daeseok.youn@gmail.com>
> >> Sent: Tuesday, March 25, 2014 10:01:48 PM
> >> Subject: [PATCH] staging: vme: fix memory leak in vme_user_probe()
> >>
> >>
> >> If vme_master_request() returns NULL when it failed,
> >> it need to free buffers for master.
> >>
> >> And also removes unreachable code in vme_user_probe().
> >>
> >> Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
> >> ---
> >>  drivers/staging/vme/devices/vme_user.c |    9 +++------
> >>  1 files changed, 3 insertions(+), 6 deletions(-)
> >
> > Nice catches Daeseok. I don't maintain this driver, but I have some
> > suggestions below.
> >
> >>
> >> diff --git a/drivers/staging/vme/devices/vme_user.c
> >> b/drivers/staging/vme/devices/vme_user.c
> >> index 7927927..ffb4eee 100644
> >> --- a/drivers/staging/vme/devices/vme_user.c
> >> +++ b/drivers/staging/vme/devices/vme_user.c
> >> @@ -776,7 +776,8 @@ static int vme_user_probe(struct vme_dev *vdev)
> >>               image[i].kern_buf = kmalloc(image[i].size_buf, GFP_KERNEL);
> >>               if (image[i].kern_buf == NULL) {
> >>                       err = -ENOMEM;
> >> -                     goto err_master_buf;
> >> +                     vme_master_free(image[i].resource);
> >> +                     goto err_master;
> >>               }
> >>       }
> >
> > I think it would be nice to keep all of the cleanup under the err_master
> > label.
> Actually, I changed like "err_slave" doing. When it failed to alloc
> buffer for slave,
> just called vme_slave_free(image[i].slave) and cleanup under the err_slave.

I do like the error path symmetry provided by your patch.

> >
> > That could be done by changing the kern_buf allocation in this part to
> > a devm_kmalloc. Then devm handles the kern_buf freeing entirely.
> I didn't know about devm_kmalloc(), I will check that function. Thanks!
> 
> >
> >>
> >> @@ -819,8 +820,6 @@ static int vme_user_probe(struct vme_dev *vdev)
> >>
> >>       return 0;
> >>
> >> -     /* Ensure counter set correcty to destroy all sysfs devices */
> >> -     i = VME_DEVS;
> >>  err_sysfs:
> >>       while (i > 0) {
> >>               i--;
> >> @@ -830,12 +829,10 @@ err_sysfs:
> >>
> >>       /* Ensure counter set correcty to unalloc all master windows */
> >>       i = MASTER_MAX + 1;
> >> -err_master_buf:
> >> -     for (i = MASTER_MINOR; i < (MASTER_MAX + 1); i++)
> >> -             kfree(image[i].kern_buf);
> >>  err_master:
> >>       while (i > MASTER_MINOR) {
> >>               i--;
> >> +             kfree(image[i].kern_buf);
> >>               vme_master_free(image[i].resource);
> >>       }
> >
> > Using devm_kmalloc as mentioned above, the while loop could be
> > simplified to this:
> >
> > err_master:
> >         while (i >= MASTER_MINOR) {
> >                 vme_master_free(image[i].resource);
> >                 i--;
> >         }
> It would be nice, but when it failed to vme_master_request() and than
> go to err_master,
> image[i].resource must be NULL. So a NULL exception has occurred in
> vme_master_free().
> 
> I think vme_master{slave}_free() need to check NULL and it can be
> possible to change code as your comment.
> please check for me. :-)

You are correct that vme_master_free() assumes that the resource being
freed is not NULL. I should have recognized that case. That could easily
be handled by testing the resource again in the loop, but I see the
benefit of the symmetry of your change.

-Aaron

> 
> >
> > If not moving to devm, this should be safe even though the first
> > kern_buf may be NULL:
> >
> > err_master:
> >         while (i >= MASTER_MINOR) {
> >                 kfree(image[i].kern_buf);
> >                 vme_master_free(image[i].resource);
> >                 i--;
> >         }
> kfree() is ok. But vme_master_free() function has an problem as mentioned
> above.
> 
> Thanks for review.
> Daeseok Youn.
> >
> > -Aaron
> >
> >>
> >> --
> >> 1.7.4.4
> >>
> >>
> >>
> 

  reply	other threads:[~2014-03-27 14:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-26  3:01 Daeseok Youn
2014-03-26 18:51 ` Aaron Sierra
2014-03-27  1:47   ` DaeSeok Youn
2014-03-27 14:30     ` Aaron Sierra [this message]
2014-03-27 23:53       ` DaeSeok Youn

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=202482763.23002.1395930610691.JavaMail.zimbra@xes-inc.com \
    --to=asierra@xes-inc.com \
    --cc=daeseok.youn@gmail.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lisa@xenapiadmin.com \
    --cc=manohar.vanga@gmail.com \
    --cc=martyn.welch@ge.com \
    --cc=yongjun_wei@trendmicro.com.cn \
    /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

Powered by JetHome