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: <20190612100906.xllp2bfgmadvbh2q@box>
Date:   Wed, 12 Jun 2019 13:09:06 +0300
From:   "Kirill A. Shutemov" <kirill@...temov.name>
To:     Yang Shi <yang.shi@...ux.alibaba.com>
Cc:     ktkhai@...tuozzo.com, kirill.shutemov@...ux.intel.com,
        hannes@...xchg.org, mhocko@...e.com, hughd@...gle.com,
        shakeelb@...gle.com, rientjes@...gle.com,
        akpm@...ux-foundation.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] mm: thp: make deferred split shrinker memcg aware

On Tue, Jun 11, 2019 at 10:06:36PM -0700, Yang Shi wrote:
> 
> 
> On 6/11/19 7:47 PM, Kirill A. Shutemov wrote:
> > On Fri, Jun 07, 2019 at 02:07:37PM +0800, Yang Shi wrote:
> > > +	/*
> > > +	 * The THP may be not on LRU at this point, e.g. the old page of
> > > +	 * NUMA migration.  And PageTransHuge is not enough to distinguish
> > > +	 * with other compound page, e.g. skb, THP destructor is not used
> > > +	 * anymore and will be removed, so the compound order sounds like
> > > +	 * the only choice here.
> > > +	 */
> > > +	if (PageTransHuge(page) && compound_order(page) == HPAGE_PMD_ORDER) {
> > What happens if the page is the same order as THP is not THP? Why removing
> 
> It may corrupt the deferred split queue since it is never added into the
> list, but deleted here.
> 
> > of destructor is required?
> 
> Due to the change to free_transhuge_page() (extracted deferred split queue
> manipulation and moved before memcg uncharge since page->mem_cgroup is
> needed), it just calls free_compound_page(). So, it sounds pointless to
> still keep THP specific destructor.
> 
> It looks there is not a good way to tell if the compound page is THP in
> free_page path or not, we may keep the destructor just for this?

Other option would be to move mem_cgroup_uncharge(page); from
__page_cache_release() to destructors. Destructors will be able to
call it as it fits.

-- 
 Kirill A. Shutemov

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ