Hi all,
I have been working on enhancements to the autofs4 kernel (together with
the daemon) module to add support for ghosting (aka. browsable
directories). Doing this has left me with the question of when and how
should locks and semaphores be used.
Some of my questions will only make sense if we assume a preemtive kernel.
I know the question is general, however some examples might get the
discussion started.
First one.
If current pwd is a directory that has just been mounted we need to change
to it. Given the old and the new pwd and vfsmount entries one might:
/* dentry is a pwd of mountpoint so move to it */
if ( current->fs->pwd == pwd && current->fs->pwdmnt == mnt ) {
set_fs_pwd(current->fs, new_mnt, new_pwd);
}
Q. Should the current->fs->lock be held as a read lock during the test?
Q. If so what is to stop pwd and pwdmnt changing when the read lock is
droped and before set_fs_pwd takes the write lock?
Q. How should this actually be done?
Another one.
The dentry cache cache can be modified by heaps of processes. What
locking should be used, if any, when tests are made on dentry values and
during there subsequent use?
For example if the test involves multiple values should we do
something like this:
/* Check for a non-mountpoint directory with no contents */
spin_lock(&dcache_lock);
if (S_ISDIR(dentry->d_inode->i_mode) &&
!d_mountpoint(dentry) &&
list_empty(&dentry->d_subdirs)) {
spin_unlock(&dcache_lock);
...
}
spin_unlock(&dcache_lock);
Q. If so what locking should be done for usage of the dentry within the
if?
Q. What if anything should be done about locking the inode during thses
operations?
And another.
Q. Should a single comparison be protected?
For example:
if ( d_mountpoint(dentry) ) {
...
}
There are two internal structures, a super block info struct attached to
the autofs super block and a dentry info struct attached to autofs
dentrys. How should access to these be protected, a spin lock or
semaphore or both and when (ie. only during change, creation,
destruction)?
I realise these questions are vague and often not relavent since most of
the calls are protected by the global kernel lock in 2.4, but that is
changing with 2.6. Hopefully someone can give me some guidelines so I
can do a through analysis of the autofs4 module.
--
,-._|\ Ian Kent
/ \ Perth, Western Australia
*_.--._/ E-mail: raven@themaw.net
v Web: http://themaw.net/
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
