linux-kernel - Re: memcg uncharge page counter mismatch

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]

Date:	Thu, 3 Dec 2015 09:54:52 +0100
From:	Michal Hocko <mhocko@...nel.org>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: memcg uncharge page counter mismatch

On Thu 03-12-15 11:10:06, Minchan Kim wrote:
> On Thu, Dec 03, 2015 at 10:34:04AM +0900, Minchan Kim wrote:
> > On Wed, Dec 02, 2015 at 11:16:43AM +0100, Michal Hocko wrote:
> > > On Tue 01-12-15 22:34:55, Minchan Kim wrote:
> > > > With new test on mmotm-2015-11-25-17-08, I saw below WARNING message
> > > > several times. I couldn't see it with reverting new THP refcount
> > > > redesign.
> > > 
> > > Just a wild guess. What prevents migration/compaction from calling
> > > split_huge_page on thp zero page? There is VM_BUG_ON but it is not clear
> > 
> > I guess migration should work with LRU pages now but zero page couldn't
> > stay there.

Ahh, you are right. I have missed PageLRU check in isolate_migratepages_block
pfn walker.

> > > whether you run with CONFIG_DEBUG_VM enabled.
> > 
> > I enabled VM_DEBUG_VM.
> > 
> > > 
> > > Also, how big is the underflow?
[...]
> > nr_pages 293 new -324
> > nr_pages 16 new -340
> > nr_pages 342 new -91
> > nr_pages 246 new -337
> > nr_pages 15 new -352
> > nr_pages 15 new -367

They are quite large but that is not that surprising if we consider that
we are batching many uncharges at once.
 
> My guess is that it's related to new feature of Kirill's THP 'PageDoubleMap'
> so a THP page could be mapped a pte but !pmd_trans_huge(*pmd) so memcg
> precharge in move_charge should handle it?

I am not familiar with the current state of THP after the rework
unfortunately. So if I got you right then you are saying that
pmd_trans_huge_lock fails to notice a THP so we will not charge it as
THP and only charge one head page and then the tear down path will
correctly recognize it as a THP and uncharge the full size, right?

I have to admit I have no idea how PageDoubleMap works and how can
pmd_trans_huge fail.

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/