sf...@users.sourceforge.net:
>
> Xavier Chantry:
> > I can reproduce the bug on all my machines, so it shouldn't be too
> > difficult to reproduce. Applying the following hunk is enough to trigger
> > the bug.
>
> Unfortunately still I don't have enough time.
> I understand this bug has a big impact for you and any other user who
> have applied aufs3-mmap.patch. As soon as I get the time, I'm sure I
> will dive into this problem.
I've thought about the problem a little (still I'm busy).
It looks like a race condition around mm->mmap_sem.
- get_file(file);
+ vma_get_file(vma);
up_read(&mm->mmap_sem);
error = vfs_fsync(file, 0);
- fput(file);
+ vma_fput(vma);
if (error || start >= end)
goto out;
down_read(&mm->mmap_sem);
Since this fput/vma_fput is between up(mmap_sem) and down(mmap_sem),
vma_fput() is not protected, and got vm_file NULL unexpectedly. It
means vma->vm_file is changed (or being changed) by someone else (other
thread in your case) after up_read(&mm->mmap_sem). This is surely a bug
in aufs[34]-mmap.patch. It shoule be done such like this essentially.
get_file(file);
pr = vma->vm_prfile;
;;;
fput(file);
if (pr)
fput(pr);
The fix will look a little smarter than above.
I hope I can post the fix in a few weeks.
J. R. Okajima
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
