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.