Re: Another idea for simplifying locking in kernel/module.c

[Rusty Russell <rusty@rustcorp.com.au>]

In message <200301100910.BAA31409@adam.yggdrasil.com> you write:
> Rusty Russell wrote:
> >In message <200301070219.SAA12905@adam.yggdrasil.com> you write:
> >> 	Here is a way to replace all of the specialized "stop CPU"
> >> locking code in kernel/module.c with an rw_semaphore by using
> >> down_read_trylock in try_module_get() and down_write when beginning to
> >> unload the module.
> 
> >And now you can't modularize netfilter modules.
> 
> 	Why not?  Last time you went looking in the networking code
> for an example of something that had to increment a module reference
> in a context where blocking was not allowed you ended up conceding
> that you example was incorrect.

No, you're thinking of the IPv4 stack.  I didn't use netfilter as an
example, because that opens me to "well, FIX NETFILTER then!".  If it
were the only case, it's probably arguable.

The problems with netfilter modules are exactly why I started looking
at module locking over two years ago.

> 	I just booted my gateway machine to a kernel using my
> aforemetioned patch and various netfilter modules.  I've surfed the
> web, FTP'ed file and run irc through it.  It seems to be okay.

Sure!  That's because the netfilter modules use a horrific hack, by
keeping their own "usage" counts and then spinning (potentially
forever) on unload until it hits zero.

Logically the skb->nfct would have an owner field in it.

Now, performance.  You want a brlock, at least: the performance of
either the security infrastructure or netfilter modules is going to
suck horribly with anything else.  And the bogolock used in module.c
is even lighter weight than a brlock, with its associated atomic ops.

Hope that clarifies...
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.