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; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:43 EST