linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Hillf Danton <hdanton@sina.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	syzbot <syzbot+c48f34012b06c4ac67dd@syzkaller.appspotmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	syzkaller-bugs@googlegroups.com,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Jens Axboe <axboe@kernel.dk>,
	Markus Elfring <Markus.Elfring@web.de>
Subject: Re: kernel BUG at include/linux/swapops.h:LINE!
Date: Wed, 29 Jul 2020 23:11:33 +0100	[thread overview]
Message-ID: <20200729221133.GZ23808@casper.infradead.org> (raw)
In-Reply-To: <20200729195432.GY23808@casper.infradead.org>

On Wed, Jul 29, 2020 at 08:54:32PM +0100, Matthew Wilcox wrote:
> On Wed, Jul 29, 2020 at 10:21:51PM +0300, Kirill A. Shutemov wrote:
> > On Mon, Jul 27, 2020 at 01:03:10PM +0100, Matthew Wilcox wrote:
> > > > It would be interesting to know if the migration entires ever got removed
> > > > for pfn. I mean if remove_migration_pte() got called for it.
> > > > 
> > > > It can be rmap issue too. Maybe it misses PMD on remove_migration_ptes()
> > > > or something.
> > > 
> > > It's not mapped with a PMD.  I tweaked my debugging slightly:
> > > 
> > >  static inline swp_entry_t make_migration_entry(struct page *page, int write)
> > >  {
> > > -       BUG_ON(!PageLocked(compound_head(page)));
> > > +       VM_BUG_ON_PAGE(!PageLocked(page), page);
> > >  
> > > +if (PageHead(page)) dump_page(page, "make entry");
> > > +if (PageTail(page)) printk("pfn %lx order %d\n", page_to_pfn(page), thp_order(thp_head(page)));
> > > 
> > > 1523 page:0000000006f62206 refcount:490 mapcount:1 mapping:0000000000000000 index:0x562b12a00 pfn:0x1dc00
> > > 1523 head:0000000006f62206 order:9 compound_mapcount:0 compound_pincount:0
> > > 1523 anon flags: 0x400000000009003d(locked|uptodate|dirty|lru|active|head|swapbacked)
> > > 1523 raw: 400000000009003d ffffecfd41301308 ffffecfd41b08008 ffff9e9971c00059
> > > 1523 raw: 0000000562b12a00 0000000000000000 000001ea00000000 0000000000000000
> > > 1523 page dumped because: make entry
> > > 1523 pfn 1dc01 order 9
> > > 1523 pfn 1dc02 order 9
> > > 1523 pfn 1dc03 order 9
> > > ...
> > > 
> > > Notice that it's an anonymous page, so it's not related to my work.
> > 
> > I don't have much hope, but could you try if the patch below would blow
> > up?
> 
> Running it now.  Results probably in twenty minutes.

It didn't blow up.  I added a dump_stack() after the call to dump_page()
and got this ...

2922 page:0000000085a5c107 refcount:474 mapcount:1 mapping:0000000000000000 index:0x559e98a00 pfn:0x35200
2922 head:0000000085a5c107 order:9 compound_mapcount:0 compound_pincount:0
2922 anon flags: 0x400000000009003d(locked|uptodate|dirty|lru|active|head|swapbacked)
2922 raw: 400000000009003d ffffe8e5c1bbaf48 ffffe8e5c046ee88 ffffa2e7f3787ec9
2922 raw: 0000000559e98a00 0000000000000000 000001da00000000 0000000000000000
2922 page dumped because: make entry
2922 CPU: 5 PID: 23471 Comm: dd Kdump: loaded Tainted: G        W         5.8.0-rc6-00067-gd8b18bdf9870-dirty #358
2922 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
2922 Call Trace:
2922  dump_stack+0x5e/0x7a
2922  try_to_unmap_one+0x846/0x860
2922  rmap_walk_anon+0x13d/0x2a0
2922  rmap_walk_locked+0x23/0x30
2922  try_to_unmap+0x64/0xbc
2922  split_huge_page_to_list+0x188/0xdb0
2922  deferred_split_scan+0x148/0x240
2922  shrink_slab.constprop.0+0x198/0x330
2922  shrink_node+0x1a8/0x440
2922  try_to_free_pages+0x18f/0x480
2922  __alloc_pages_slowpath.constprop.0+0x297/0xca0
2922  __alloc_pages_nodemask+0x1ba/0x1e0
2922  pagecache_get_page+0xd8/0x330
2922  grab_cache_page_write_begin+0x1c/0x40
2922  iomap_write_begin+0x2d6/0x6d0
2922  iomap_write_actor+0x8b/0x1c0
2922  iomap_apply+0xe3/0x310
2922  iomap_file_buffered_write+0x5c/0x80
2922  xfs_file_buffered_aio_write+0xbd/0x310
2922  xfs_file_write_iter+0xa8/0xc0
2922  new_sync_write+0xf5/0x170
2922  vfs_write+0x191/0x1e0

I think that's interesting because it's not trying to allocate a huge
page itself (I didn't touch the write_begin path).  Rather, I presume
the additional memory pressure from allocating huge pages is causing
anonymous pages to be split to free up memory.

It survived all the way to generic/224 this run, but I don't think
that's relevant.


  reply	other threads:[~2020-07-29 22:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-30 17:05 kernel BUG at include/linux/swapops.h:LINE! syzbot
2020-07-19 21:10 ` syzbot
2020-07-20 23:51   ` Andrew Morton
2020-07-21  0:21     ` Matthew Wilcox
2020-07-21  2:14       ` Matthew Wilcox
2020-07-21 11:11     ` Kirill A. Shutemov
2020-07-21 15:11       ` Jens Axboe
2020-07-23  7:37       ` Hillf Danton
2020-07-24 11:13         ` Kirill A. Shutemov
2020-07-26 16:49           ` Matthew Wilcox
2020-07-27 10:31             ` Kirill A. Shutemov
2020-07-27 12:03               ` Matthew Wilcox
2020-07-27 12:59                 ` Hillf Danton
2020-07-27 13:44                   ` Matthew Wilcox
2020-07-27 14:46                     ` Hillf Danton
2020-07-29 19:21                 ` Kirill A. Shutemov
2020-07-29 19:54                   ` Matthew Wilcox
2020-07-29 22:11                     ` Matthew Wilcox [this message]
2021-05-08 11:24 ` [syzbot] " syzbot

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=20200729221133.GZ23808@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=Markus.Elfring@web.de \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=hannes@cmpxchg.org \
    --cc=hdanton@sina.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=syzbot+c48f34012b06c4ac67dd@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).