linux-kernel - Re: Zram writeback feature unstable with heavy swap utilization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180725025124.GC16271@bombadil.infradead.org>
Date:   Tue, 24 Jul 2018 19:51:24 -0700
From:   Matthew Wilcox <willy@...radead.org>
To:     Minchan Kim <minchan@...nel.org>
Cc:     Tino Lehnig <tino.lehnig@...tabo.de>, ngupta@...are.org,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Zram writeback feature unstable with heavy swap utilization -
 BUG: Bad page state in process...

On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > [  804.485321] BUG: Bad page state in process qemu-system-x86  pfn:1c4b08e
> > [  804.485403] page:ffffe809312c2380 count:0 mapcount:0
> > mapping:0000000000000000 index:0x1
> > [  804.485483] flags: 0x17fffc000000008(uptodate)
> > [  804.485554] raw: 017fffc000000008 0000000000000000 0000000000000001
> > 00000000ffffffff
> > [  804.485632] raw: dead000000000100 dead000000000200 0000000000000000
> > 0000000000000000
> > [  804.485709] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
> > [  804.485782] bad because of flags: 0x8(uptodate)

The message here even tells you what the problem is.  The page
was marked Uptodate at the time that it was allocated.  There aren't
any other flags that alias Uptodate, so somebody is failing to clear
the Uptodate bit when they ought to.

> > [  804.485891] Call Trace:
> > [  804.485899]  dump_stack+0x5c/0x7b
> > [  804.485902]  bad_page+0xba/0x120
> > [  804.485905]  get_page_from_freelist+0x1016/0x1250
> > [  804.485908]  __alloc_pages_nodemask+0xfa/0x250

Also note that this is in the allocation path; this flag isn't checked
at free.  But it is cleared on free, so someone's stomping on page->flags
after they're freed.  I suggest enabling more debugging code.