Subject: Re: VFS LKMs & pool_init() panic
To: Martin Husemann <martin@rumolt.teuto.de>
From: Jaromir Dolecek <dolecek@ics.muni.cz>
List: tech-kern
Date: 03/12/2000 20:38:46
Martin Husemann wrote:
> > [...] I like the current approach of VFS lkms,
> > where it's FOO_lkmentry() is just a glue routine
> > with (almost) no knowledge of fs internals (the only thing it needs
> > is a pointer to respective vfsops structure).
> 
> I don't understand this (probably because I didn't look at the source
> in question): there are "LKM global" resources, that should IMHO be cleared
> when the LKM is about to unload, i.e. by FOO_lkmentry. And there are FS
> specific resources that should be cleared at FS unmount time.

They are not "LKM global" resources, i.e. they are not created or
required by the LKM itself. Some filesystems just initialize some
global resources in its' _init routines (see e.g.  msdosfs_init(),
ffs_init(), ntfs_init() etc) which are not strictly per-mounted-filesystem.
Those resources should be freed when the filesystem is detached
via LKM unload. The _contents_ of the global structures is typically
freed on umount (for example memory allocated from msdosfs denode
pool), but the structures themselves may not be, because it would
be too impractical.

Example:

When loading VFS LKM (say msdosfs), LKM's entry routine
calls vfs_attach() routine, giving it a pointer to respective
struct vfsops (e.g. msdosfs_vfsops). When the LKM is unloaded,
vfs_detach() is called. vfs_detach() just removes the fs
from list of supported filesystems and frees some related
resources. No fs-specific global resources are freed however,
so e.g. pool created in msdosfs_init() is not destroyed and
pointers to now-invalid memory locations are left in list of pools.

> The FOO_lkmentry may need some external "clean_xxx()" functions, but it
> doesn't need any knowledge about FS internals.

My point is - if you are going to add clean_xxx() functions, why
not add generic VFS op routine, so that it can be handled by generic
code in vfs_detach() and LKM-specific code would be kept minimal ?

> Is there any other class of resources I overlooked?

Yes, global pool of e.g. denodes for MSDOSFS. The pool is not cleared/destroyed
on (last) umount (it would be too hairy to do so).

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
@@@@  Wanna a real operating system ? Go and get NetBSD, damn!  @@@@