Linux-kernel mailing list archive 2000-26,: Re: owner field in `struct fs'

# Re: owner field in `struct fs'

Keith Owens (kaos@ocs.com.au)
Tue, 27 Jun 2000 23:33:58 +1000

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Keith Owens: "Re: owner field in `struct fs'"
- Previous message: Rusty Russell: "Re: owner field in `struct fs'"

On Tue, 27 Jun 2000 09:17:01 -0400 (EDT),
Alexander Viro <viro@math.psu.edu> wrote:
>fd=open("/dev/foo") C loaded, A and B pinned down.
>ioctl(fd, SPLAT, 0) register_foo(&foo1), foo1 registered in A.
>close(fd)
>rmmod C
>rmmod A
>woops...

The use count on C must include all entries that it registered and has
not yet unregistered. This is no different from open(), there is a use
count on a module for every open fd. C cannot be unloaded until
unregister_foo(&foo1) has been done which makes A and B safe as well.
I think we are in violent agreement.

>> AFAICT, pinning modules by symbol reference is race safe, all the work
>> is done in module.c under BKL.
>
>BKL on _caller_ of ->open() and ->release() is going to hell. It's one of
>the major contention points, so it will be shifted into methods themselves
>and disappear in case of quite a few filesystem ones (devices will have
>it, indeed, but the most frequent case is ext2_open()/ext2_release()).

Good. But that does not mean that module load and unload cannot rely
on BKL to serialize against each other, especially for symbol
manipulation. Module code could have its own lock instead of BKL but
some bits of module.c can sleep - is the code change worth it for such
low frequency operations?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Keith Owens: "Re: owner field in `struct fs'"
- Previous message: Rusty Russell: "Re: owner field in `struct fs'"