On Fri, 18 Nov 2005, William H. Taber wrote: > Ian Kent wrote: > > On Fri, 18 Nov 2005, William H. Taber wrote: > > > > > > No, it is actually a little more subtle than that. The problem is that > > > since > > > you can be called from two code paths, one of which get's the lock and one > > > of > > > them doesn't, you are stuck if you find that the lock is held because you > > > don't know who holds it. The danger is that some innocent third party is > > > holding the lock and counting on being protected by it. If you release the > > > lock, then you can be creating the potential for a race in their code and > > > there would be no way to detect it. Their code path would look correct > > > because it is. Not only that but the lock itself could get confused > > > because > > > it would have more unlocks than locks, because presumably the process that > > > thinks it has the lock would eventually unlock as well. I don't know how > > > the > > > semaphores are implemented on all architectures so I don't know if that > > > would > > > be an actual problem or not but it I would be surprised if they all > > > handled > > > that case gracefully. > > > > > > Yes. Thinking about it I hadn't considered the third process. > > > > How can we get advice on this? > > > > Ian > > > Hey, I'm new here. I came here looking for advice. :^)
Ha. It's probably wearing a bit thin for me to say I'm new here but my patch is quite small and I've got a lot to learn and I'm lovin' it. > However, if there is no way to fix this in the autofs code then the only > alternative is to fix the locking in the VFS. So VFS folks, which is the > better solution. Should all callers to d_revalidate get the parent's i_sem > lock or should d_revalidate never be called with the parent i_sem lock and so > we need to change lookup_one_len so that it does not expect the parent i_sem > lock to be held? Maybe. See next post. Ian _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
