> 
> I forgot uncommenting the memory barrier in aufs_nopage() for older
> kernels. I intended to use it in this week's release. Sorry.
> Have you already tried uncommenting the memory barrier (without the
> serialization by mmap_sem)? And still the problem happens?

That was the first thing I tried, when I saw the commented memory 
barrier in the suspect code. I believe I still was able to reproduce
the failure, however I can retest to be certain.


> 
> > Note that when the vma enters aufs_nopage(), its vm_file seems to be 
> > pointing to the underlying nfs file? Is this because another thread
> > is racing against aufs_nopage() as well? Note also when filemap_nopage()
> 
> I think the race condition happend as you guessed.
> And aufs_nopage() supports this condition by waiting for the vm_file is
> reverted.

Can you explain this further? Is this line from aufs_nopage()

 wait_event(wq, (file = au_robr_safe_file(vma)));

supposed to wait until vm_file is reverted by another thread? If so, 
maybe it is this functionality that isn't working in our kernel. Could
you give suggestions for debugging this possibility?

> I hope the memory barrier which I forgot to uncomment will help you.

I will retry this to be certain, but I think I was still able to recreate
the bug with this memory barrier uncommented. The full fix required the
test patch that serialized access to aufs_nopage() for tasks with shared
mm.

Thanks for your help!
mark
 
> 
> Junjiro Okajima
> 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Reply via email to