On 09/16/2012 09:07 PM, Hugh Dickins wrote:
>> What was the way that
>> Hugh used to reproduce the other issue?
>
> I've lost track of which issue is "other".
The other was meant to be the BUG I hit.
> To reproduce Sasha's interval_tree.c warnings, all I had to do was switch
> on CONFIG_DEBUG_VM
On Thu, Sep 20, 2012 at 03:27:11PM -0700, Hugh Dickins wrote:
> On Fri, 21 Sep 2012, Fengguang Wu wrote:
> > On Sat, Sep 15, 2012 at 11:26:23AM +0200, Sasha Levin wrote:
> > > On 09/15/2012 02:00 AM, Michel Lespinasse wrote:
> > > > All right. Hugh managed to reproduce the issue on his suse laptop,
On Fri, 21 Sep 2012, Fengguang Wu wrote:
> On Sat, Sep 15, 2012 at 11:26:23AM +0200, Sasha Levin wrote:
> > On 09/15/2012 02:00 AM, Michel Lespinasse wrote:
> > > All right. Hugh managed to reproduce the issue on his suse laptop, and
> > > I came up with a fix.
> > >
> > > The problem was that in m
On Sat, 15 Sep 2012, Jiri Slaby wrote:
> On 09/15/2012 02:00 AM, Michel Lespinasse wrote:
> > All right. Hugh managed to reproduce the issue on his suse laptop, and
> > I came up with a fix.
> >
> > The problem was that in mremap, the new vma's vm_{start,end,pgoff}
> > fields need to be updated be
On 09/15/2012 02:00 AM, Michel Lespinasse wrote:
> All right. Hugh managed to reproduce the issue on his suse laptop, and
> I came up with a fix.
>
> The problem was that in mremap, the new vma's vm_{start,end,pgoff}
> fields need to be updated before calling anon_vma_clone() so that the
> new vma
On 09/15/2012 02:00 AM, Michel Lespinasse wrote:
> All right. Hugh managed to reproduce the issue on his suse laptop, and
> I came up with a fix.
>
> The problem was that in mremap, the new vma's vm_{start,end,pgoff}
> fields need to be updated before calling anon_vma_clone() so that the
> new vma
On Fri, Sep 14, 2012 at 3:46 PM, Michel Lespinasse wrote:
> On Fri, Sep 14, 2012 at 3:14 PM, Sasha Levin wrote:
>> On 09/04/2012 11:20 AM, Michel Lespinasse wrote:
>>> Add a CONFIG_DEBUG_VM_RB build option for the previously existing
>>> DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid
On Fri, Sep 14, 2012 at 3:14 PM, Sasha Levin wrote:
> On 09/04/2012 11:20 AM, Michel Lespinasse wrote:
>> Add a CONFIG_DEBUG_VM_RB build option for the previously existing
>> DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid using
>> recursive algorithms, we can expose it a bit more.
>>
>
On 09/15/2012 12:14 AM, Sasha Levin wrote:
> On 09/04/2012 11:20 AM, Michel Lespinasse wrote:
>> Add a CONFIG_DEBUG_VM_RB build option for the previously existing
>> DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid using
>> recursive algorithms, we can expose it a bit more.
>>
>> Also ext
On 09/04/2012 11:20 AM, Michel Lespinasse wrote:
> Add a CONFIG_DEBUG_VM_RB build option for the previously existing
> DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid using
> recursive algorithms, we can expose it a bit more.
>
> Also extend this code to validate_mm() after stack expans
Add a CONFIG_DEBUG_VM_RB build option for the previously existing
DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid using
recursive algorithms, we can expose it a bit more.
Also extend this code to validate_mm() after stack expansion, and to
check that the vma's start and last pgoffs have
11 matches
Mail list logo
