Messages in this thread | | | Date | Sat, 7 Sep 2002 19:27:36 +0100 | From | Jamie Lokier <> | Subject | Re: Question about pseudo filesystems |
| |
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/
| |