On Fri, 2005-11-18 at 09:12, 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. :^) > 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?
I think the problem is with cached_lookup(). It is the only place which calls ->revalidate() holding the parent's inode-semaphore AFAICT. note: cached_lookup() is only called from __lookup_hash() and __lookup_hash() is always called holding the semaphore. VFS experts agree? RP > > Will Taber > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
