Re: [PATCH 3/3] mm: debug code to verify rb_subtree_gap updates are safe

2012-11-12 Thread Rik van Riel
On 11/12/2012 06:51 AM, Michel Lespinasse wrote: Using the trinity fuzzer, Sasha Levin uncovered a case where rb_subtree_gap wasn't correctly updated. Digging into this, the root cause was that vma insertions and removals require both an rbtree insert or erase operation (which may trigger tree

[PATCH 3/3] mm: debug code to verify rb_subtree_gap updates are safe

2012-11-12 Thread Michel Lespinasse
Using the trinity fuzzer, Sasha Levin uncovered a case where rb_subtree_gap wasn't correctly updated. Digging into this, the root cause was that vma insertions and removals require both an rbtree insert or erase operation (which may trigger tree rotations), and an update of the next vma's gap

[PATCH 3/3] mm: debug code to verify rb_subtree_gap updates are safe

2012-11-12 Thread Michel Lespinasse
Using the trinity fuzzer, Sasha Levin uncovered a case where rb_subtree_gap wasn't correctly updated. Digging into this, the root cause was that vma insertions and removals require both an rbtree insert or erase operation (which may trigger tree rotations), and an update of the next vma's gap

Re: [PATCH 3/3] mm: debug code to verify rb_subtree_gap updates are safe

2012-11-12 Thread Rik van Riel
On 11/12/2012 06:51 AM, Michel Lespinasse wrote: Using the trinity fuzzer, Sasha Levin uncovered a case where rb_subtree_gap wasn't correctly updated. Digging into this, the root cause was that vma insertions and removals require both an rbtree insert or erase operation (which may trigger tree