From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Vlastimil Babka <vbabka@suse.cz>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [next-20160615] kernel BUG at mm/rmap.c:1251!
Date: Thu, 16 Jun 2016 19:12:16 +0900 [thread overview]
Message-ID: <20160616101216.GT17127@bbox> (raw)
In-Reply-To: <20160616095457.GD432@swordfish>
On Thu, Jun 16, 2016 at 06:54:57PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 11:41), Michal Hocko wrote:
> > On Thu 16-06-16 18:23:45, Sergey Senozhatsky wrote:
> > > On (06/16/16 10:58), Michal Hocko wrote:
> > > > > [..]
> > > > > [ 272.687656] vma ffff8800b855a5a0 start 00007f3576d58000 end 00007f3576f66000
> > > > > next ffff8800b977d2c0 prev ffff8800bdfb1860 mm ffff8801315ff200
> > > > > prot 8000000000000025 anon_vma ffff8800b7e583b0 vm_ops (null)
> > > > > pgoff 7f3576d58 file (null) private_data (null)
> > > > > flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> > > > > [ 272.691793] ------------[ cut here ]------------
> > > > > [ 272.692820] kernel BUG at mm/rmap.c:1251!
> > > >
> > > > Is this?
> > > > page_add_new_anon_rmap:
> > > > VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma)
> > > > [...]
> > >
> > > I think it is
> > >
> > > 1248 void page_add_new_anon_rmap(struct page *page,
> > > 1249 struct vm_area_struct *vma, unsigned long address, bool compound)
> > > 1250 {
> > > 1251 int nr = compound ? hpage_nr_pages(page) : 1;
> > > 1252
> > > 1253 VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
> > > 1254 __SetPageSwapBacked(page);
> > >
> > > > > [ 272.727842] BUG: sleeping function called from invalid context at include/linux/sched.h:2960
> > > >
> > > > If yes then I am not sure we can do much about the this part. BUG_ON in
> > > > an atomic context is unfortunate but the BUG_ON points out a real bug so
> > > > we shouldn't drop it because of the potential atomic context. The above
> > > > VM_BUG_ON should definitely be addressed. I thought that Vlastimil has
> > > > pointed out some issues with the khugepaged lock inconsistencies which
> > > > might lead to issues like this.
> > >
> > > collapse_huge_page() ->mmap_sem fixup patch (http://marc.info/?l=linux-mm&m=146495692807404&w=2)
> > > is in next-20160615. or do you mean some other patch?
> >
> > Yes that's what I meant, but I haven't reviewed the patch to see whether
> > it is correct/complete. It would be good to see whether the issue is
> > related to those changes.
>
> I'll copy-paste one more backtrace I swa today [originally was posted to another
> mail thread].
Please, look at http://lkml.kernel.org/r/20160616100932.GS17127@bbox
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, Vlastimil Babka <vbabka@suse.cz>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [next-20160615] kernel BUG at mm/rmap.c:1251!
Date: Thu, 16 Jun 2016 19:12:16 +0900 [thread overview]
Message-ID: <20160616101216.GT17127@bbox> (raw)
In-Reply-To: <20160616095457.GD432@swordfish>
On Thu, Jun 16, 2016 at 06:54:57PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 11:41), Michal Hocko wrote:
> > On Thu 16-06-16 18:23:45, Sergey Senozhatsky wrote:
> > > On (06/16/16 10:58), Michal Hocko wrote:
> > > > > [..]
> > > > > [ 272.687656] vma ffff8800b855a5a0 start 00007f3576d58000 end 00007f3576f66000
> > > > > next ffff8800b977d2c0 prev ffff8800bdfb1860 mm ffff8801315ff200
> > > > > prot 8000000000000025 anon_vma ffff8800b7e583b0 vm_ops (null)
> > > > > pgoff 7f3576d58 file (null) private_data (null)
> > > > > flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> > > > > [ 272.691793] ------------[ cut here ]------------
> > > > > [ 272.692820] kernel BUG at mm/rmap.c:1251!
> > > >
> > > > Is this?
> > > > page_add_new_anon_rmap:
> > > > VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma)
> > > > [...]
> > >
> > > I think it is
> > >
> > > 1248 void page_add_new_anon_rmap(struct page *page,
> > > 1249 struct vm_area_struct *vma, unsigned long address, bool compound)
> > > 1250 {
> > > 1251 int nr = compound ? hpage_nr_pages(page) : 1;
> > > 1252
> > > 1253 VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
> > > 1254 __SetPageSwapBacked(page);
> > >
> > > > > [ 272.727842] BUG: sleeping function called from invalid context at include/linux/sched.h:2960
> > > >
> > > > If yes then I am not sure we can do much about the this part. BUG_ON in
> > > > an atomic context is unfortunate but the BUG_ON points out a real bug so
> > > > we shouldn't drop it because of the potential atomic context. The above
> > > > VM_BUG_ON should definitely be addressed. I thought that Vlastimil has
> > > > pointed out some issues with the khugepaged lock inconsistencies which
> > > > might lead to issues like this.
> > >
> > > collapse_huge_page() ->mmap_sem fixup patch (http://marc.info/?l=linux-mm&m=146495692807404&w=2)
> > > is in next-20160615. or do you mean some other patch?
> >
> > Yes that's what I meant, but I haven't reviewed the patch to see whether
> > it is correct/complete. It would be good to see whether the issue is
> > related to those changes.
>
> I'll copy-paste one more backtrace I swa today [originally was posted to another
> mail thread].
Please, look at http://lkml.kernel.org/r/20160616100932.GS17127@bbox
next prev parent reply other threads:[~2016-06-16 10:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 8:46 [next-20160615] kernel BUG at mm/rmap.c:1251! Sergey Senozhatsky
2016-06-16 8:46 ` Sergey Senozhatsky
2016-06-16 8:58 ` Michal Hocko
2016-06-16 8:58 ` Michal Hocko
2016-06-16 9:23 ` Sergey Senozhatsky
2016-06-16 9:23 ` Sergey Senozhatsky
2016-06-16 9:41 ` Michal Hocko
2016-06-16 9:41 ` Michal Hocko
2016-06-16 9:54 ` Sergey Senozhatsky
2016-06-16 9:54 ` Sergey Senozhatsky
2016-06-16 10:12 ` Minchan Kim [this message]
2016-06-16 10:12 ` Minchan Kim
2016-06-16 10:18 ` Sergey Senozhatsky
2016-06-16 10:18 ` Sergey Senozhatsky
2016-06-17 8:17 ` Sergey Senozhatsky
2016-06-17 8:17 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160616101216.GT17127@bbox \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=sfr@canb.auug.org.au \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.