public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: [Patch 2/2] Staging: winbond: Memory & urb freed
Date: Fri, 31 May 2013 16:39:58 +0000	[thread overview]
Message-ID: <20130531163958.GW23987@mwanda> (raw)
In-Reply-To: <51A8C27B.9090003@gmail.com>

On Fri, May 31, 2013 at 09:48:58PM +0530, Harsh Kumar wrote:
> 
> 
> On Friday 31 May 2013 09:27 PM, Dan Carpenter wrote:
> > On Fri, May 31, 2013 at 09:02:11PM +0530, Harsh Kumar wrote:
> >> Memory & urb should be freed before exiting from the function, I think.
> >>
> > 
> > They are freed in Wb35Reg_EP0VM_complete() so this patch will make
> > the system crash right away.  Btw, there are tons of real bugs that
> > I know about but which I don't fix because I don't know what the
> > right thing to do is.
> > 
> 
> Ohh! Sorry, I missed it. That is why I was not sure about submitting this 
> change. I need to be more thorough in checking this stuff. 
> 
> I have general question - Generally, shouldn't allocation and freeing up the 
> memory be in the same function so that it is easy to make sure that everything 
> is freed up after completion of task? Is it because there maybe certain cases 
> where that may not be feasible or desirable to do so?

Unfortunately kernel programming will never be 100% easy...  :P  In
the end you will learn the tricks just like I did.  Here was my
thought process here:
1) The commit message was not convincing.
2) The memory was saved to reg->reg_first.
3) Follow the Wb35Reg_EP0VM_start() call to the urb_submit point.
4) See that we pass Wb35Reg_EP0VM_complete() to urb_submit function.
   I have worked on usb drivers before so I suspected that
   Wb35Reg_EP0VM_complete() frees the urb.
5) Vefiried that this is true.  Done.

Or alternatively:
3) Find reg_first in Wb35Reg_EP0VM_complete() and see that we free
   it.

Make sure you have cscope configured in vim.  Also in vim the '*'
button searches.

If you think you have found a bug but you're not sure, feel free to
ask on kernel janitors.  Probably for new code it's not the right
mailing list but for code audits it's fine.

regards,
dan carpenter

  parent reply	other threads:[~2013-05-31 16:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-31 15:44 [Patch 2/2] Staging: winbond: Memory & urb freed Harsh Kumar
2013-05-31 15:57 ` Dan Carpenter
2013-05-31 16:30 ` Harsh Kumar
2013-05-31 16:39 ` Dan Carpenter [this message]
2013-05-31 16:46 ` Julia Lawall
2013-05-31 17:12 ` Harsh Kumar

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=20130531163958.GW23987@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox