Ian Kent wrote:
On Fri, 2 Dec 2005, Jeff Moyer wrote:
==> Regarding Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix; Ian Kent
<[EMAIL PROTECTED]> adds:
raven> On Thu, 1 Dec 2005, William H. Taber wrote:
So the question is, can anyone provide an example of a path that, upon
calling autofs revalidate or lookup with the i_sem held, not be the
path > that aquired it?
raven> So still no counter example!
Any other process calling lookup_one_len on a file in /net.
raven> I'm afraid this is not an example it's an assertion. "Any other
raven> process" is a little broad I think. You'll need to be more
raven> specific.
Well, I think we've determined that the reported problem doesn't happen
with any in-tree callers. The question, then, is do you want to fix the
locking problem? Two approaches were presented in this thread. I don't
really like the idea of the hack used by devfs, since it relies on implicit
semantics. I haven't given much thought to the second approach, though
(are we sure it can be made to work?). It may require a good deal of
effort, but if it makes things work properly, it's worth considering. I'm
just not sure where it sits in the list of priorities, as I know you've got
a lot on your plate, Ian.
It appears to me that the unhashed directory approach proposed by Will
does not account for directories that exist but don't have current mounts.
I will re-read the posts, I expect I missed something, and give it more
thought.
It doesn't consider that case. You had mentioned it but I had forgotten.
Will
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
