On 09/11/2014 06:38 PM, Sasha Levin wrote:
> On 09/11/2014 12:28 PM, Mel Gorman wrote:
>> > Agreed. If 3.17-rc4 looks stable with the VM_BUG_ON then it would be
>> > really nice if you could bisect 3.17-rc4 to linux-next carrying the
>> > VM_BUG_ON(!(val & _PAGE_PRESENT)) check at each bisection po
On 09/11/2014 12:28 PM, Mel Gorman wrote:
> Agreed. If 3.17-rc4 looks stable with the VM_BUG_ON then it would be
> really nice if you could bisect 3.17-rc4 to linux-next carrying the
> VM_BUG_ON(!(val & _PAGE_PRESENT)) check at each bisection point. I'm not
> 100% sure if I'm seeing the same corrup
On Thu, Sep 11, 2014 at 04:39:39AM -0700, Hugh Dickins wrote:
> On Wed, 10 Sep 2014, Sasha Levin wrote:
> > On 09/10/2014 03:36 PM, Hugh Dickins wrote:
> > > Right, and Sasha reports that that can fire, but he sees the bug
> > > with this patch in and without that firing.
> >
> > I've changed tha
On Thu, Sep 11, 2014 at 10:22:42AM -0400, Sasha Levin wrote:
> > The fixed trinity may be counter-productive for now, since we think
> > there is an understandable pte_mknuma() bug coming from that direction,
> > but have not posted a patch for it yet.
>
> I'm still seeing the bug with fixed
On 09/11/2014 07:39 AM, Hugh Dickins wrote:
> On Wed, 10 Sep 2014, Sasha Levin wrote:
>> On 09/10/2014 03:36 PM, Hugh Dickins wrote:
>>> Right, and Sasha reports that that can fire, but he sees the bug
>>> with this patch in and without that firing.
>>
>> I've changed that WARN_ON_ONCE() to a VM_B
On Wed, 10 Sep 2014, Sasha Levin wrote:
> On 09/10/2014 03:36 PM, Hugh Dickins wrote:
> > Right, and Sasha reports that that can fire, but he sees the bug
> > with this patch in and without that firing.
>
> I've changed that WARN_ON_ONCE() to a VM_BUG_ON_VMA() to get some useful
> VMA information
On 09/10/2014 03:36 PM, Hugh Dickins wrote:
>> migrate: debug patch to try identify race between migration completion and
>> mprotect
>> >
>> > A migration entry is marked as write if pte_write was true at the
>> > time the entry was created. The VMA protections are not double checked
>> > when m
On Wed, 10 Sep 2014, Sasha Levin wrote:
> On 09/10/2014 03:09 PM, Hugh Dickins wrote:
> > Thanks for supplying, but the change in inlining means that
> > change_protection_range() and change_protection() are no longer
> > relevant for these traces, we now need to see change_pte_range()
> > instead,
On 09/10/2014 03:09 PM, Hugh Dickins wrote:
> Thanks for supplying, but the change in inlining means that
> change_protection_range() and change_protection() are no longer
> relevant for these traces, we now need to see change_pte_range()
> instead, to confirm that what I expect are ptes are indeed
On Wed, 10 Sep 2014, Mel Gorman wrote:
> On Tue, Sep 09, 2014 at 07:45:26PM -0700, Hugh Dickins wrote:
> >
> > I've been rather assuming that the 9d340902 seen in many of the
> > registers in that Aug26 dump is the pte val in question: that's
> > SOFT_DIRTY|PROTNONE|RW.
The 900s in the latest dum
On Wed, 10 Sep 2014, Sasha Levin wrote:
> On 09/09/2014 10:45 PM, Hugh Dickins wrote:
> > Sasha, you say you're getting plenty of these now, but I've only seen
> > the dump for one of them, on Aug26: please post a few more dumps, so
> > that we can look for commonality.
>
> I wasn't saving older l
On 09/10/2014 08:47 AM, Mel Gorman wrote:
> migrate: debug patch to try identify race between migration completion and
> mprotect
>
> A migration entry is marked as write if pte_write was true at the
> time the entry was created. The VMA protections are not double checked
> when migration entries
On 09/10/2014 09:40 AM, Mel Gorman wrote:
> On Wed, Sep 10, 2014 at 09:12:04AM -0400, Sasha Levin wrote:
>>
>>
>> I've spotted a new trace in overnight fuzzing, it could be related to this
>> issue:
>>
>> [ 3494.324839] general protection fault: [#1] PREEMPT SMP
>> DEBUG_PAGEALLOC
>> [ 3494
On Wed, Sep 10, 2014 at 10:24:40AM -0400, Sasha Levin wrote:
> On 09/10/2014 08:47 AM, Mel Gorman wrote:
> > That site should have checked PROT_NONE but it can't be the same bug
> > that trinity is seeing. Minimally trinity is unaware of MPOL_MF_LAZY
> > according to git grep of the trinity sou
On 09/10/2014 08:47 AM, Mel Gorman wrote:
> That site should have checked PROT_NONE but it can't be the same bug
> that trinity is seeing. Minimally trinity is unaware of MPOL_MF_LAZY
> according to git grep of the trinity source.
Actually, if I'm reading it correctly I think that Trinity handles
On Wed, Sep 10, 2014 at 09:12:04AM -0400, Sasha Levin wrote:
>
>
> I've spotted a new trace in overnight fuzzing, it could be related to this
> issue:
>
> [ 3494.324839] general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 3494.332153] Dumping ftrace buffer:
> [ 3494.332153](
On 09/09/2014 10:45 PM, Hugh Dickins wrote:
> Sasha, you say you're getting plenty of these now, but I've only seen
> the dump for one of them, on Aug26: please post a few more dumps, so
> that we can look for commonality.
I wasn't saving older logs for this issue so I only have 2 traces from
toni
On Tue, Sep 09, 2014 at 07:45:26PM -0700, Hugh Dickins wrote:
> On Tue, 9 Sep 2014, Sasha Levin wrote:
> > On 09/09/2014 05:33 PM, Mel Gorman wrote:
> > > On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote:
> > >> On 09/08/2014 01:18 PM, Mel Gorman wrote:
> > >>> A worse possibility is tha
On Tue, 9 Sep 2014, Sasha Levin wrote:
> On 09/09/2014 05:33 PM, Mel Gorman wrote:
> > On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote:
> >> On 09/08/2014 01:18 PM, Mel Gorman wrote:
> >>> A worse possibility is that somehow the lock is getting corrupted but
> >>> that's also a tough se
On 09/09/2014 05:33 PM, Mel Gorman wrote:
> On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote:
>> On 09/08/2014 01:18 PM, Mel Gorman wrote:
>>> A worse possibility is that somehow the lock is getting corrupted but
>>> that's also a tough sell considering that the locks should be allocated
On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote:
> On 09/08/2014 01:18 PM, Mel Gorman wrote:
> > A worse possibility is that somehow the lock is getting corrupted but
> > that's also a tough sell considering that the locks should be allocated
> > from a dedicated cache. I guess I could
On 09/08/2014 01:18 PM, Mel Gorman wrote:
> A worse possibility is that somehow the lock is getting corrupted but
> that's also a tough sell considering that the locks should be allocated
> from a dedicated cache. I guess I could try breaking that to allocate
> one page per lock so DEBUG_PAGEALLOC
On Thu, Sep 04, 2014 at 05:04:37AM -0400, Sasha Levin wrote:
> On 08/29/2014 09:23 PM, Sasha Levin wrote:
> > On 08/27/2014 11:26 AM, Mel Gorman wrote:
> >> > diff --git a/include/asm-generic/pgtable.h
> >> > b/include/asm-generic/pgtable.h
> >> > index 281870f..ffea570 100644
> >> > --- a/include
On 08/29/2014 09:23 PM, Sasha Levin wrote:
> On 08/27/2014 11:26 AM, Mel Gorman wrote:
>> > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
>> > index 281870f..ffea570 100644
>> > --- a/include/asm-generic/pgtable.h
>> > +++ b/include/asm-generic/pgtable.h
>> > @@ -723,6
On 08/27/2014 11:26 AM, Mel Gorman wrote:
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 281870f..ffea570 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte)
>
>
On 08/27/2014 11:26 AM, Mel Gorman wrote:
> Sasha, how long does it typically take to trigger this? Are you
> using any particular switches for trinity that would trigger the bug
> faster?
It took couple of weeks (I've been running with it since the beginning
of August). I don't have any special t
On Tue, Aug 26, 2014 at 11:16:47PM -0400, Sasha Levin wrote:
> On 08/11/2014 11:28 PM, Sasha Levin wrote:
> > On 08/05/2014 09:04 PM, Sasha Levin wrote:
> >> > Thanks Hugh, Mel. I've added both patches to my local tree and will
> >> > update tomorrow
> >> > with the weather.
> >> >
> >> > Also:
>
On 08/11/2014 11:28 PM, Sasha Levin wrote:
> On 08/05/2014 09:04 PM, Sasha Levin wrote:
>> > Thanks Hugh, Mel. I've added both patches to my local tree and will update
>> > tomorrow
>> > with the weather.
>> >
>> > Also:
>> >
>> > On 08/05/2014 08:42 PM, Hugh Dickins wrote:
>>> >> One thing I di
On 08/05/2014 09:04 PM, Sasha Levin wrote:
> Thanks Hugh, Mel. I've added both patches to my local tree and will update
> tomorrow
> with the weather.
>
> Also:
>
> On 08/05/2014 08:42 PM, Hugh Dickins wrote:
>> One thing I did wonder, though: at first I was reassured by the
>> VM_BUG_ON(!pte_pr
Mel Gorman writes:
> On Wed, Aug 06, 2014 at 12:44:45PM +0530, Aneesh Kumar K.V wrote:
>> > -#define pmd_mknonnuma pmd_mknonnuma
>> > -static inline pmd_t pmd_mknonnuma(pmd_t pmd)
>> > +/*
>> > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist
>> > + * which was inherited f
On Tue, Aug 05, 2014 at 05:42:03PM -0700, Hugh Dickins wrote:
> >
> >
> > I'm attaching a preliminary pair of patches. The first which deals with
> > ARCH_USES_NUMA_PROT_NONE and the second which is yours with a revised
> > changelog. I'm adding Aneesh to the cc to look at the powerpc portion of
On Wed, Aug 06, 2014 at 12:44:45PM +0530, Aneesh Kumar K.V wrote:
> > -#define pmd_mknonnuma pmd_mknonnuma
> > -static inline pmd_t pmd_mknonnuma(pmd_t pmd)
> > +/*
> > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist
> > + * which was inherited from x86. For the purposes of
Mel Gorman writes:
> From d0c77a2b497da46c52792ead066d461e5111a594 Mon Sep 17 00:00:00 2001
> From: Mel Gorman
> Date: Tue, 5 Aug 2014 12:06:50 +0100
> Subject: [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE
>
> ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented
> _P
Thanks Hugh, Mel. I've added both patches to my local tree and will update
tomorrow
with the weather.
Also:
On 08/05/2014 08:42 PM, Hugh Dickins wrote:
> One thing I did wonder, though: at first I was reassured by the
> VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought
> it
On Tue, 5 Aug 2014, Mel Gorman wrote:
> On Mon, Aug 04, 2014 at 04:40:38AM -0700, Hugh Dickins wrote:
> >
> > [INCOMPLETE PATCH] x86,mm: fix pte_special versus pte_numa
> >
> > Sasha Levin has shown oopses on ea0003480048 and ea0003480008
> > at mm/memory.c:1132, running Trinity on differ
On Mon, Aug 04, 2014 at 04:40:38AM -0700, Hugh Dickins wrote:
> On Sat, 2 Aug 2014, 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 spew:
> >
> > [ 2957.087977] BUG: unable to handle
On Sat, 2 Aug 2014, 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 spew:
>
> [ 2957.087977] BUG: unable to handle kernel paging request at ea0003480008
> [ 2957.088008] IP: unmap_page_rang
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following spew:
[ 2957.087977] BUG: unable to handle kernel paging request at ea0003480008
[ 2957.088008] IP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256
mm/memory.c:1277
38 matches
Mail list logo
