[lkml]   [2002]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.080 / U:0.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site