All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jari Ruusu <jariruusu@users.sourceforge.net>
To: Tejun Heo <tj@kernel.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	linux-kernel@vger.kernel.org,
	Rusty Russell <rusty@rustcorp.com.au>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>, Jens Axboe <jens.axboe@oracle.com>
Subject: Re: 2.6.35-rc2 module reference counting broken
Date: Thu, 10 Jun 2010 09:34:32 +0300	[thread overview]
Message-ID: <4C108778.71545BCF@users.sourceforge.net> (raw)
In-Reply-To: 4C0F3C66.1020601@kernel.org

Tejun Heo wrote:
> On 06/09/2010 01:48 AM, Al Viro wrote:
> > Yeah...  bd_start_claiming() grabs a reference to gendisk and we never
> > let it go.  There's your leak...
> 
> Eh, I thought you were cc'd.  Sorry.  This was fixed sometime back by
> Nick and queued in block tree (delayed due to mail misdelivery).
> 
>   http://thread.gmane.org/gmane.linux.file-systems/40655

That one liner patch makes module refcount mismatch go away.

However, I am not sure if that is the right place to insert that
module_put(). The problem with Nick Piggin's (2010-05-25 15:50:21 GMT) patch
is that it makes module refcount temporarily drop to zero.

I added this line right after that "module_put(disk->fops->owner);" fix:

 if(disk->fops->owner){printk("bd_start_claiming: module_refcount=%u\n", module_refcount(disk->fops->owner));}

And that said "module_refcount=0" when I tried it with my silly floppy
module mount+umount test.

Later in the mount system call handling the module refrence count is
incremented. But to me that looks like there is a window of opportunity for
things to go wrong. What is there to prevent module from being removed at
zero refcount?

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

  reply	other threads:[~2010-06-10  6:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-07  5:20 2.6.35-rc2 module reference counting broken Jari Ruusu
2010-06-07  6:44 ` Al Viro
2010-06-08 23:48   ` Al Viro
2010-06-09  7:01     ` Tejun Heo
2010-06-10  6:34       ` Jari Ruusu [this message]
2010-06-10 11:31         ` Tejun Heo

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=4C108778.71545BCF@users.sourceforge.net \
    --to=jariruusu@users.sourceforge.net \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=rusty@rustcorp.com.au \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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.