Messages in this thread | | | Date | Fri, 18 Jun 2004 19:55:54 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: anon-vma mprotect merging-extend fix |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |