Hi Kirill,
On Mon, Apr 14, 2014 at 05:42:18PM +0300, Kirill A. Shutemov wrote:
> I've spent few day trying to understand rmap code. And now I think my
> patch is wrong.
>
> I actually don't see where walk order requirement comes from. It seems all
> operations (insert, remove, foreach) on
Hi Kirill,
On Mon, Apr 14, 2014 at 05:42:18PM +0300, Kirill A. Shutemov wrote:
I've spent few day trying to understand rmap code. And now I think my
patch is wrong.
I actually don't see where walk order requirement comes from. It seems all
operations (insert, remove, foreach) on anon_vma is
ot cause. Let's look to them one by one.
The first bug[1] is "kernel BUG at mm/huge_memory.c:1829!".
It's BUG_ON(mapcount != page_mapcount(page)) in __split_huge_page().
>From my testing I see that page_mapcount() is higher than mapcount here.
I think it happens due to race between
.
The first bug[1] is kernel BUG at mm/huge_memory.c:1829!.
It's BUG_ON(mapcount != page_mapcount(page)) in __split_huge_page().
From my testing I see that page_mapcount() is higher than mapcount here.
I think it happens due to race between zap_huge_pmd() and
page_check_address_pmd
Hi,
On Thu, Apr 10, 2014 at 04:44:36PM +0300, Kirill A. Shutemov wrote:
> Okay, below is my attempt to fix the bug. I'm not entirely sure it's
> correct. Andrea, could you take a look?
The possibility the interval tree implicitly broke the walk order of
the anon_vma list didn't cross my mind,
On 04/10/2014 10:37 AM, Dave Jones wrote:
> On Thu, Apr 10, 2014 at 04:45:58PM +0800, Bob Liu wrote:
> > On Tue, Apr 8, 2014 at 10:37 PM, Sasha Levin
> wrote:
> > > Hi all,
> > >
> > > While fuzzing with trinity inside a KVM tools guest running the latest
> -next
> > > kernel, I've
On Thu, Apr 10, 2014 at 04:45:58PM +0800, Bob Liu wrote:
> On Tue, Apr 8, 2014 at 10:37 PM, Sasha Levin wrote:
> > Hi all,
> >
> > While fuzzing with trinity inside a KVM tools guest running the latest
> > -next
> > kernel, I've stumbled on the following:
> >
>
> Wow! There are so many
ing:
> >
> > [ 1275.253114] kernel BUG at mm/huge_memory.c:1829!
> > [ 1275.253642] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > [ 1275.254775] Dumping ftrace buffer:
> > [ 1275.255631](ftrace buffer empty)
> > [ 1275.256440] Modules link
On Tue, Apr 08, 2014 at 10:37:05AM -0400, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel, I've stumbled on the following:
>
> [ 1275.253114] kernel BUG at mm/huge_memory.c:1829!
> [ 1275.253642] inv
On Tue, Apr 08, 2014 at 10:37:05AM -0400, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel, I've stumbled on the following:
>
> [ 1275.253114] kernel BUG at mm/huge_memory.c:1829!
> [ 1275.253642] inv
without fix. I wanna is there any
place can track those bugs instead of lost in maillist?
It seems this link is out of date
http://codemonkey.org.uk/projects/trinity/bugs-unfixed.php
Thanks,
-Bob
> [ 1275.253114] kernel BUG at mm/huge_memory.c:1829!
> [ 1275.253642] invalid opcode:
without fix. I wanna is there any
place can track those bugs instead of lost in maillist?
It seems this link is out of date
http://codemonkey.org.uk/projects/trinity/bugs-unfixed.php
Thanks,
-Bob
[ 1275.253114] kernel BUG at mm/huge_memory.c:1829!
[ 1275.253642] invalid opcode: [#1] PREEMPT
On Tue, Apr 08, 2014 at 10:37:05AM -0400, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following:
[ 1275.253114] kernel BUG at mm/huge_memory.c:1829!
[ 1275.253642] invalid opcode: [#1] PREEMPT
On Tue, Apr 08, 2014 at 10:37:05AM -0400, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following:
[ 1275.253114] kernel BUG at mm/huge_memory.c:1829!
[ 1275.253642] invalid opcode: [#1] PREEMPT
at mm/huge_memory.c:1829!
[ 1275.253642] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 1275.254775] Dumping ftrace buffer:
[ 1275.255631](ftrace buffer empty)
[ 1275.256440] Modules linked in:
[ 1275.257347] CPU: 20 PID: 22807 Comm: trinity-c299 Not tainted
3.14.0-next
On Thu, Apr 10, 2014 at 04:45:58PM +0800, Bob Liu wrote:
On Tue, Apr 8, 2014 at 10:37 PM, Sasha Levin sasha.le...@oracle.com wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest
-next
kernel, I've stumbled on the following:
Wow! There are
On 04/10/2014 10:37 AM, Dave Jones wrote:
On Thu, Apr 10, 2014 at 04:45:58PM +0800, Bob Liu wrote:
On Tue, Apr 8, 2014 at 10:37 PM, Sasha Levin sasha.le...@oracle.com
wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest
-next
kernel, I've
Hi,
On Thu, Apr 10, 2014 at 04:44:36PM +0300, Kirill A. Shutemov wrote:
Okay, below is my attempt to fix the bug. I'm not entirely sure it's
correct. Andrea, could you take a look?
The possibility the interval tree implicitly broke the walk order of
the anon_vma list didn't cross my mind,
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following:
[ 1275.253114] kernel BUG at mm/huge_memory.c:1829!
[ 1275.253642] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 1275.254775] Dumping ftrace buffer
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following:
[ 1275.253114] kernel BUG at mm/huge_memory.c:1829!
[ 1275.253642] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 1275.254775] Dumping ftrace buffer
20 matches
Mail list logo
