Re: [PATCH 1/2] vfs: make real_lookup do dentry revalidation with i_mutex held

[Ian Kent <raven@themaw.net>]

Ian Kent wrote:
> Sage Weil wrote:
>> Hi Ian,
>>
>> Have you had a chance to look at getting autofs4 lookup/revalidate 
>> adjusted so that this real_lookup() fix[1] can go in?
>>
>> Please let me know if there is anything I can do to help here.  If you're 
>> still occupied, I'm happy to spin something up and send it your way... 
>> just let me know.
> 
> Sorry, I haven't had time to do more on this.
> There is also the issue of what to do about removing the autofs module
> and renaming autofs4 to autofs, as this will break the autofs module.
> 
> I did start contacting people I think would want to know about this but
> haven't gone further than an initial mail.
> 
> The other thing is that this patch was originally written quite a while
> ago and, although it appears to work ok, I'm not sure it's quite what we
> need.

I'm continuing with this now, but there's a deadlock in there somewhere!

> 
> Sorry for delaying you.
> 
>> thanks-
>> sage
>>
>>
>> [1] http://marc.info/?l=linux-fsdevel&m=123749395609697&w=2
>>
>>
>> On Fri, 3 Apr 2009, Ian Kent wrote:
>>
>>> Sage Weil wrote:
>>>>> Latest here works OK.
>>>>>
>>>>> I haven't finished checking yet but it looks like the patch below works 
>>>>> OK. I started with a 2.6.29 build with your two patches but it was a 
>>>>> little broken so I fell back to a Fedora 2.6.27 based kernel without the
>>>>> two revalidate pacthes to debug it. So I still need to test the result 
>>>>> against 2.6.29 again. I also don't have any real way to test for the three 
>>>>> process race we discussed where the revalidate isn't followed by a 
>>>>> ->lookup() but with both of your patches applied that shouldn't be a 
>>>>> problem (as we discussed).
>>>>>
>>>>> I've not run checkpatch.pl against the patch either at this stage.
>>>> That's good news...
>>> I'm still working on this too.
>>> I have some pressing work so it may be a while before I'm totally happy
>>> with the patch. Didn't you say you were expecting a 2.6.31 time frame
>>> for this?
>>>
>>>>  
>>>>> There is a further issue and that is regarding the autofs module.
>>>>>
>>>>> I can't see updating autofs for this being practical (although I haven't 
>>>>> actually looked yet). I suspect quite a bit of work would be needed. The 
>>>>> fact is that autofs isn't used much any more and it really should be 
>>>>> replaced with the autofs4 module at some point. But that's a fairly tricky 
>>>>> exercise and will likely cause some user space breakage. It will require 
>>>>> an updated module-init-tools to add "alais autofs4 autofs" for modprobe 
>>>>> backward compatibility and will break for any explicit checks for the 
>>>>> presence of the "autofs4" module.
>>>> Hmm.  Well, I assume autofs needs to work properly before this gets 
>>>> changed, though, right?  Should I see what I can do with it?  I took a 
>>>> quick look, and I don't think it will take too much to make it behave.  
>>>> It looks like the main thing is to make the lookup call to try_fill_dentry 
>>>> return any existing dentry in place of the one the vfs provides.
>>> Yes, or be replaced by what is currently the autofs4 module. The autofs
>>> v2 communication protocol surely can't be being used any more and the
>>> autofs4 module supports versions 3, 4 and 5. In fact I received a mail
>>> from HPA recently suggesting he supports doing this.
>>>
>>> I had a quick look as well. I think you'll find it isn't quite as simple
>>> as that. I'll have a closer look as soon as I get a chance.
>>>
>>>
>>> Ian
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
> 
>