Re: anon-vma mprotect merging-extend fix

[Hugh Dickins]

On Fri, 18 Jun 2004, Andrea Arcangeli wrote:
> yesterday I got a crash bugreport where this BUG_ON bombed with wine.
>.... 
> The problem is that I was not propagating the anon_vma correctly in the
> extend case of mprotect-merging.

Thanks a lot for this alert, Andrea, much appreciated.

Although the 2.6.7 code looks rather different here (vma_merge now does
all mprotect's merging too), and there's a couple of reasons it's harder
to see the problem with mainline (because fork's copy_page_range uses the
quick page_dup_rmap inline, skipping the BUG_ONs in page_add_anon_rmap;
and because anon_vma_prepare is likely to correct the situation by taking
anon_vma from neighbouring vma later), I missed exactly the same point
and we do indeed need a patch for it.

> This adds another robustness BUG_ON to be sure we switch the PG_anon
> bitflag only in unmapped pages, and secondly it makes sure not to merge
> anything if vm_private_data is set on the "other" vma (the one not
> checked internally in is_mergeable_vma). I considered adding another
> parameter to is_mergeable_vma, but I think the above is fine too, such
> construct can be copied as easily without forgetting about the "other"
> vma private_data.

I hope you've not found somewhere the vm_private_data change is actually
needed - because when using that field for the non-linear swapout cursor,
the test in is_mergeable_vma prevented non-linear merges, it seemed a
superfluous test to me, and so I simply removed it.  I say superfluous
because those few vmas which set vm_private_data are already prevented
from merging by VM_SPECIAL flags tests.

> I didn't have much time to look at the status of mainline in the last
> week, I assume Hugh will take care of merging this fix in a way that
> will apply cleanly to mainline.

That's fine, yes, I've now done the patch, will post it separately now.

Thanks again,
Hugh

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/