All of lore.kernel.org
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dave.bueso@gmail.com>
To: me@bobcopeland.com
Cc: linux-karma-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] omfs: fix memory leak
Date: Mon, 05 Jul 2010 01:12:39 -0400	[thread overview]
Message-ID: <1278306759.3811.24.camel@cowboy> (raw)
In-Reply-To: <20100704113711.GA15067@hash.localnet>

On Sun, 2010-07-04 at 07:37 -0400, me@bobcopeland.com wrote:
> On Sat, Jul 03, 2010 at 10:33:48PM -0400, Davidlohr Bueso wrote:
> > Hi,
> > 
> > In omfs_fill_super(), when returning on error, sbi is not being freed.
> > 
> > Thanks,
> > Davidlohr.
> 
> Hi Davidlohr,
> 
> I don't think this is right:
> 
> fill_super:
>   err = omfs_fill_super()
>   if (err)
>      deactivate_locked_super(sb)
>         kill_sb()
>           generic_shutdown_super()
>             sop->put_super()
>   ...
>   omfs_put_super()
>     kfree(sbi->s_imap);
>     kfree(sbi);
> 
> So your change would cause a crash at the first kfree in omfs_put_super().
> 
> It looks fine to me as-is, or am I missing something?

Thanks for the reply, Bob. Please bare with me, as I am learning about
the VFS workings. To my knowledge this would happen:

a user tries to mount a omfs partition:
	omfs_get_sb() -> omfs_fill_super()

If omfs_fill_super() fails, in this case 'ret' being a non 0 value, the
mount will not be completed, hence the previously allocated 'sbi'
variable will not be freed.

Isn't put_super() called to free data when things run "normally", like
for unmounting? So this function does two things:

kfree(sbi->s_imap)
kfree(sbi)

However, in omfs_get_imap() 'sbi->s_imap' is freed upon failure, so
wouldn't this also crash on the first kfree in omfs_put_super()?
Wouldn't this be the same for freeing sbi upon failure in
omfs_fill_super()?

Now, the patch I sent is compile-tested only, so it might crash it. I
will test it properly.

If what I just said is complete nonsense, please enlighten me.

Thanks,
Davidlohr

> 
> > 
> > Signed-off-by: Davidlohr Bueso <dave@gnu.org>
> > ---
> >  fs/omfs/inode.c |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> > 
> > diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c
> > index 089839a..253846e 100644
> > --- a/fs/omfs/inode.c
> > +++ b/fs/omfs/inode.c
> > @@ -523,12 +523,14 @@ static int omfs_fill_super(struct super_block *sb, void *data, int silent)
> >  	}
> >  	printk(KERN_DEBUG "omfs: Mounted volume %s\n", omfs_rb->r_name);
> >  
> > -	ret = 0;
> > +	ret = 0; /* success */
> >  out_brelse_bh2:
> >  	brelse(bh2);
> >  out_brelse_bh:
> >  	brelse(bh);
> >  end:
> > +	if (ret != 0)
> > +		kfree(sbi);
> >  	return ret;
> >  }
> 



WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave.bueso@gmail.com>
To: me@bobcopeland.com
Cc: linux-fsdevel@vger.kernel.org,
	linux-karma-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] omfs: fix memory leak
Date: Mon, 05 Jul 2010 01:12:39 -0400	[thread overview]
Message-ID: <1278306759.3811.24.camel@cowboy> (raw)
In-Reply-To: <20100704113711.GA15067@hash.localnet>

On Sun, 2010-07-04 at 07:37 -0400, me@bobcopeland.com wrote:
> On Sat, Jul 03, 2010 at 10:33:48PM -0400, Davidlohr Bueso wrote:
> > Hi,
> > 
> > In omfs_fill_super(), when returning on error, sbi is not being freed.
> > 
> > Thanks,
> > Davidlohr.
> 
> Hi Davidlohr,
> 
> I don't think this is right:
> 
> fill_super:
>   err = omfs_fill_super()
>   if (err)
>      deactivate_locked_super(sb)
>         kill_sb()
>           generic_shutdown_super()
>             sop->put_super()
>   ...
>   omfs_put_super()
>     kfree(sbi->s_imap);
>     kfree(sbi);
> 
> So your change would cause a crash at the first kfree in omfs_put_super().
> 
> It looks fine to me as-is, or am I missing something?

Thanks for the reply, Bob. Please bare with me, as I am learning about
the VFS workings. To my knowledge this would happen:

a user tries to mount a omfs partition:
	omfs_get_sb() -> omfs_fill_super()

If omfs_fill_super() fails, in this case 'ret' being a non 0 value, the
mount will not be completed, hence the previously allocated 'sbi'
variable will not be freed.

Isn't put_super() called to free data when things run "normally", like
for unmounting? So this function does two things:

kfree(sbi->s_imap)
kfree(sbi)

However, in omfs_get_imap() 'sbi->s_imap' is freed upon failure, so
wouldn't this also crash on the first kfree in omfs_put_super()?
Wouldn't this be the same for freeing sbi upon failure in
omfs_fill_super()?

Now, the patch I sent is compile-tested only, so it might crash it. I
will test it properly.

If what I just said is complete nonsense, please enlighten me.

Thanks,
Davidlohr

> 
> > 
> > Signed-off-by: Davidlohr Bueso <dave@gnu.org>
> > ---
> >  fs/omfs/inode.c |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> > 
> > diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c
> > index 089839a..253846e 100644
> > --- a/fs/omfs/inode.c
> > +++ b/fs/omfs/inode.c
> > @@ -523,12 +523,14 @@ static int omfs_fill_super(struct super_block *sb, void *data, int silent)
> >  	}
> >  	printk(KERN_DEBUG "omfs: Mounted volume %s\n", omfs_rb->r_name);
> >  
> > -	ret = 0;
> > +	ret = 0; /* success */
> >  out_brelse_bh2:
> >  	brelse(bh2);
> >  out_brelse_bh:
> >  	brelse(bh);
> >  end:
> > +	if (ret != 0)
> > +		kfree(sbi);
> >  	return ret;
> >  }
> 



------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

  reply	other threads:[~2010-07-05  5:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-04  2:33 [PATCH] omfs: fix memory leak Davidlohr Bueso
2010-07-04  2:33 ` Davidlohr Bueso
2010-07-04 11:37 ` me
2010-07-05  5:12   ` Davidlohr Bueso [this message]
2010-07-05  5:12     ` Davidlohr Bueso
2010-07-05 14:00     ` [linux-karma-devel] " me
2010-07-05 14:00       ` me
2010-07-06  4:50       ` [linux-karma-devel] " Davidlohr Bueso
2010-07-06 15:45         ` me
2010-07-06 15:45           ` me

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=1278306759.3811.24.camel@cowboy \
    --to=dave.bueso@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-karma-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@bobcopeland.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 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.