On Mon, Jun 01, 2009 at 02:50:29PM -0700, Eric W. Biederman wrote: > From: Eric W. Biederman <ebiederm@xxxxxxxxxxxx> > > Introduce the file_hotplug_lock to protect file->f_op, file->private, > file->f_path from revoke operations. > > The file_hotplug_lock is used typically as: > error = -EIO; > if (!file_hotplug_read_trylock(file)) > goto out; > .... > file_hotplug_read_unlock(file); Why is it called hotplug? Does it have anything to do with hardware? Because every concurrently changed software data structure in the kernel can be "hot"-modified, right? Wouldn't file_revoke_lock be more appropriate? > In addition for a complete solution we need: > - A reliable way the file structures that we need to revoke. > - To wait for but not tamper with ongoing file creation and cleanup. > - A guarantee that all with user space controlled duration are removed. > > The file_hotplug_lock has a very unique implementation necessitated by > the need to have no performance impact on existing code. Classic locking Well, it isn't no performance impact. Function calls, branches, icache and dcache... -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
