linux-kernel - Re: [PATCHv2 0/4] zsmalloc: make zspage chain size configurable

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: <Y8QT5IWy1Gx1bbVi@google.com>
Date:   Sun, 15 Jan 2023 23:55:32 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Minchan Kim <minchan@...nel.org>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCHv2 0/4] zsmalloc: make zspage chain size configurable

On (23/01/15 13:04), Matthew Wilcox wrote:
> On Sun, Jan 15, 2023 at 04:18:55PM +0900, Sergey Senozhatsky wrote:
> > So this warning is move_to_new_folio() being called on un-isolated
> > src folio. I had DEBUG_VM disabled so VM_BUG_ON_FOLIO(!folio_test_isolated(src))
> > did nothing, however after mops->migrate_page() it would trigger WARN_ON()
> > because it evaluates folio_test_isolated(src) one more time:
> > 
> > [   59.500580] page:0000000097d97a42 refcount:2 mapcount:1665 mapping:0000000000000000 index:0xffffea00185ce940 pfn:0x113dc4
> > [   59.503239] flags: 0x8000000000000001(locked|zone=2)
> > [   59.505060] raw: 8000000000000001 ffffea00044f70c8 ffffc90000ba7c20 ffffffff81c22582
> > [   59.507288] raw: ffffea00185ce940 ffff88809183fdb0 0000000200000680 0000000000000000
> 
> That is quite the messed-up page.  mapcount is positive, but higher than
> refcount.  And not just a little bit; 1665 vs 2.  But mapping is NULL,
> so it's not anon or file memory.  Makes me think it belongs to a driver
> that's using ->mapcount for its own purposes.  It's not PageSlab.
> 
> Given that you're working on zsmalloc, I took a look and:
> 
> static inline void set_first_obj_offset(struct page *page, unsigned int offset)
> {
>         page->page_type = offset;
> }
> 
> (page_type aliases with mapcount).  So I'm pretty sure this is a
> zsmalloc page.  But mapping should point to zsmalloc_mops.  Not
> really sure what's going on here.  Can you bisect?

Thanks.

Let me try bisecting. From what I can tell it seems that
tags/next-20221226 is the last good and tags/next-20230105
is the first bad kernel.

I'll try to narrow it down from here.