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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180725025106.GA99093@rodete-desktop-imager.corp.google.com>
Date:   Wed, 25 Jul 2018 11:51:06 +0900
From:   Minchan Kim <minchan@...nel.org>
To:     Matthew Wilcox <willy@...radead.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 Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote:
> > On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> > > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > > > Hi Tino,
> > > > 
> > > > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > > > > Hi,
> > > > > 
> > > > > The first build I used was from the master branch of the mainline kernel,
> > > > > somewhere between rc5 and rc6. I have just reproduced the bug with 4.17.9
> > > > > and 4.18-rc6. Kernel messages below.
> > > > > 
> > > > > The bug does not appear on 4.14.57. I can test more versions if it helps.
> > > > 
> > > > Could you try 4.15?
> > > > 
> > > > I think it's a regression of struct page field reordring and it started from
> > > > v4.16. 
> > > > 
> > > > page->units for zsmalloc is used as offset of first object on the zspage,
> > > > However, below patch unified it with page->_refcount.
> > > 
> > > No it didn't.  It's in a union with _mapcount, which is where it was before
> > > my patches.
> > > 
> > > It's entiely possible that my patches caused this, but the explanation
> > > you're offering is wrong.
> > 
> > Before your patch, _mapcount and _refcount is separated space so we can use
> > _mapcount for page->units for non-mapped pages because units is unified with
> > _mapcount. However, with your patch, now units is unified with _refcount.
> 
> No.  That's completely untrue.
> 
>         union {         /* This union is 4 bytes in size. */
>                 atomic_t _mapcount;
>                 unsigned int page_type;
>                 unsigned int active;            /* SLAB */
>                 int units;                      /* SLOB */
>         };
> 
>         atomic_t _refcount;
> 
> There is NOTHING in a union with _refcount.
> 


Confusing. Matthew, what am I missing?

Before:

counters consumes 8 bytes
units and _refcount consumes each 4 bytes so memory space is not overlapped.

        union {
                unsigned long counters;
                struct {

                        union {
                                atomic_t _mapcount;
                                unsigned int active;            /* SLAB */
                                struct {                        /* SLUB */
                                        unsigned inuse:16;
                                        unsigned objects:15;
                                        unsigned frozen:1;
                                };
                                int units;                      /* SLOB */
                        };
                        /*
                         * Usage count, *USE WRAPPER FUNCTION* when manual
                         * accounting. See page_ref.h
                         */
                        atomic_t _refcount;
                };
        };


After:

Now, units is overlapped with _refcount and _mapcount.

        union {
                unsigned long counters;
                unsigned int active;            /* SLAB */
                struct {                        /* SLUB */
                        unsigned inuse:16;
                        unsigned objects:15;
                        unsigned frozen:1;
                };
                int units;                      /* SLOB */
                struct {                        /* Page cache */
                        atomic_t _mapcount;
                        atomic_t _refcount;
                };
        };