Re: Question about pseudo filesystems

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

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