From: Rusty Russell <rusty@rustcorp.com.au>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux-kernel@vger.kernel.org, akpm@digeo.com
Subject: Re: [PATCH] fixup loop blkdev, add module_get
Date: Mon, 13 Jan 2003 11:55:47 +1100 [thread overview]
Message-ID: <20030113011128.8150C2C05A@lists.samba.org> (raw)
In-Reply-To: Your message of "Sat, 11 Jan 2003 22:56:20 CDT." <20030112035620.GA25648@gtf.org>
In message <20030112035620.GA25648@gtf.org> you write:
> Sometimes, we are absolutely certain that we have at least one module
> reference "locked open" for us. Loop is an example of such a case: the
> set-fd and clear-fd struct block_device_operations ioctls already have a
> module reference from simply the block device being opened.
>
> Therefore, we can just unconditionally increment the module refcount.
> I added module_get to do this.
Hi Jeff,
We may yet want such a primitive, but I've been resisting it
for the moment.
Firstly, because it's a very specialized and rare case which
lends itself to being abused, and secondly because if I "rmmod --wait"
the module, then such operations which try to hold the module in place
*should* fail. Not doing so is impolite, at least.
Sure, it's a fairly strange corner case, but that argument
cuts both ways.
I prefer this patch (-EBUSY is a little unusual, but as clear as any).
Thoughts?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5-bk/drivers/block/loop.c working-2.5-bk-loop/drivers/block/loop.c
--- linux-2.5-bk/drivers/block/loop.c 2003-01-02 12:45:18.000000000 +1100
+++ working-2.5-bk-loop/drivers/block/loop.c 2003-01-13 11:49:21.000000000 +1100
@@ -642,7 +642,9 @@ static int loop_set_fd(struct loop_devic
int lo_flags = 0;
int error;
- MOD_INC_USE_COUNT;
+ if (!try_module_get(THIS_MODULE))
+ /* I'm going away: pretend I'm not here. */
+ return -EBUSY;
error = -EBUSY;
if (lo->lo_state != Lo_unbound)
@@ -742,7 +744,7 @@ static int loop_set_fd(struct loop_devic
out_putf:
fput(file);
out:
- MOD_DEC_USE_COUNT;
+ module_put(THIS_MODULE);
return error;
}
@@ -814,7 +816,9 @@ static int loop_clr_fd(struct loop_devic
filp->f_dentry->d_inode->i_mapping->gfp_mask = gfp;
lo->lo_state = Lo_unbound;
fput(filp);
- MOD_DEC_USE_COUNT;
+
+ /* This won't drop to zero, since we're inside an ioctl. */
+ module_put(THIS_MODULE);
return 0;
}
next prev parent reply other threads:[~2003-01-13 1:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-12 3:56 [PATCH] fixup loop blkdev, add module_get Jeff Garzik
2003-01-13 0:55 ` Rusty Russell [this message]
2003-01-13 2:03 ` Jeff Garzik
2003-01-13 4:08 ` Rusty Russell
2003-01-13 22:20 ` Roman Zippel
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=20030113011128.8150C2C05A@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=akpm@digeo.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@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