linux-kernel - Re: [RFC][BUGFIX][PATCH 1/2] memcg: fix charge bypass route of migration

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, 15 Apr 2010 15:56:11 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Daisuke Nishimura <nishimura@....nes.nec.co.jp>
Cc:	LKML <linux-kernel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>,
	Mel Gorman <mel@....ul.ie>, Rik van Riel <riel@...hat.com>,
	Minchan Kim <minchan.kim@...il.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC][BUGFIX][PATCH 1/2] memcg: fix charge bypass route of
 migration

On Thu, 15 Apr 2010 15:43:24 +0900
Daisuke Nishimura <nishimura@....nes.nec.co.jp> wrote:

> On Thu, 15 Apr 2010 12:05:16 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> wrote:
> > I'd like to wait until next mmotm comes out. (So, [RFC]) I'll rebase
> > This patch is based on
> >  mmotm-2010/04/05
> >  +
> >  mm-migration-take-a-reference-to-the-anon_vma-before-migrating.patch
> >  mm-migration-do-not-try-to-migrate-unmapped-anonymous-pages.patch
> >  mm-share-the-anon_vma-ref-counts-between-ksm-and-page-migration.patch
> >  mm-migration-allow-the-migration-of-pageswapcache-pages.patch
> >  memcg-fix-prepare-migration.patch
> > 
> > ==
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
> > 
> > This is an additonal fix to memcg-fix-prepare-migration.patch
> > 
> > Now, try_charge can bypass charge if TIF_MEMDIE at el are marked on the caller.
> > In this case, the charge is bypassed. This makes accounts corrupted.
> > (PageCgroup will be marked as PCG_USED even if bypassed, and css->refcnt
> >  can leak.)
> > 
> > This patch clears passed "*memcg" in bypass route.
> > 
> > Because usual page allocater passes memcg=NULL, this patch only affects
> > some special case as
> >   - move account
> >   - migration
> >   - swapin.
> > 
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
> > ---
> >  mm/memcontrol.c |    7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > Index: mmotm-temp/mm/memcontrol.c
> > ===================================================================
> > --- mmotm-temp.orig/mm/memcontrol.c
> > +++ mmotm-temp/mm/memcontrol.c
> > @@ -1606,8 +1606,12 @@ static int __mem_cgroup_try_charge(struc
> >  	 * MEMDIE process.
> >  	 */
> >  	if (unlikely(test_thread_flag(TIF_MEMDIE)
> > -		     || fatal_signal_pending(current)))
> > +		     || fatal_signal_pending(current))) {
> > +		/* Showing we skipped charge */
> > +		if (memcg)
> > +			*memcg = NULL;
> >  		goto bypass;
> > +	}
> > 
> I'm sorry, I can't understand what this part fixes.
> We set *memcg to NULL at "bypass" part already:
> 
>    1740 bypass:
>    1741         *memcg = NULL;
>    1742         return 0;
> 
> and __mem_cgroup_try_charge() is never called with @memcg == NULL, IIUC.
> 

I totally missed that..Sigh.


> >  	/*
> >  	 * We always charge the cgroup the mm_struct belongs to.
> > @@ -2523,7 +2527,6 @@ int mem_cgroup_prepare_migration(struct 
> >  		ret = __mem_cgroup_try_charge(NULL, GFP_KERNEL, ptr, false);
> >  		css_put(&mem->css);
> >  	}
> > -	*ptr = mem;
> >  	return ret;
> >  }
> >  
> I sent a patch to Andrew to fix this part yesterday :)
> 

Ok, ignore this patch.

-Kame

--
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/