On Monday, April 16, 2007 05:27:17 PM -0400 Tom Keiser <[EMAIL PROTECTED]> wrote:
System call jump tables are assumed to be quasi-static on most platforms. A fairly obvious optimization is to not worry about synchronizing lookups.
In fact, _this_ is why the Linux maintainers (and, to varying extents, maintainers of other kernels) are opposed to loadable system calls. In Linux, there is no lock on system call table lookups, and active system calls do not constitute references on the modules which provide them. This means it is possible to unload a module while its system call is running or, worse, in the time between when a system call table lookup happens and when control is transferred to the module providing the system call. In addition, on some platforms, system call table entries are too large to be written atomically, which means you can have a lookup that results in a partially-written (read: invalid) pointer.
In AFS, we generally ignore this problem, as we expect the module to be loaded during system startup, at a point when no one is trying to make AFS system calls, and not unloaded until shutdown. This doesn't make the problem go away, but the risk is small enough that we have not ever seen a problem reported as a result of this situation.
Dean, you need to understand that afsd is not even close to the only thing that makes AFS system calls; the AFS system call interface is a published interface which is used by a wide variety of programs and libraries, many of which are not part of OpenAFS. Furthermore, we are commited even in the afsd/kernel case to avoid flag-day incompatibilities where both sides of an interface must change at exactly the same time.
When we added support for an alternate user/kernel interface on Linux (via /proc/fs/openafs/afs_ioctl), we did so _very_ slowly, and only because we were afraid a time would come when it would become impossible to support the old interface. At present, the old interface is still supported whenever possible (which is most of the time), and is used preferentially when available.
At this time, I do not see an urgent need to replace the AFS system call interface on Solaris with something else.
-- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
