Alexander Viro wrote:
> If your rules are "it's pinned as long as there are opened files created
> by foo()" - very well, there are two variants. The basic idea is the same
> - have sum of ->mnt_count for all vfsmounts of our type bumped whenever we
> call foo() and drop whenever final fput() is done on a file created by foo().
Thanks -- that's what I implemented, except I used a semaphore instead
of a spinlock.
I wanted to check that it's safe to call `mntput' from `->release()',
which seems like quite a dubious thing to depend on. But if you say it
is safe, that's cool.
> > It's a good example of why the module interface is stupidly wrong, and
> > __exit needs to be called by the module unloader, returning 0 if it's
> > ok to unload. Then your __exit can whatever condition it's interested
> > in and, if all is well, do the kern_umount.
>
> BS. Instead of playing silly buggers with "oh, we will start exiting
> and maybe we'll bail out, let's just hope we won't find that we want
> to do that after we'd destroyed something" you need to decide what kind
> of rules you really want for the module lifetime. The rest is trivial.
> Again, variant (a) (which is absolutely straightforward - add one line
> in foo(), modify one line in foo(), delete one line in init) is enough
> to give the desired rules. Optimizing it if needed is not too hard -
> see (b) for one possible variant...
Unfortunately, your suggestion, which I ended up implementing, is not
safe from race conditions.
The problem comes during the call to `->release()'. If that's really
the last reference to the module, than as soon as I call `mntput' the
module might be unloaded. In practice this doesn't happen, but if there
were a long scheduling delay... (see CONFIG_PREEMPT), it could.
-- Jamie
-
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 : Sat Sep 07 2002 - 22:00:32 EST