linux-kernel - Re: memcg: fix fatal livelock in kswapd

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:	Tue, 3 May 2011 08:38:17 +0200
From:	Johannes Weiner <hannes@...xchg.org>
To:	James Bottomley <James.Bottomley@...e.de>
Cc:	Ying Han <yinghan@...gle.com>,
	Chris Mason <chris.mason@...cle.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Paul Menage <menage@...gle.com>,
	Li Zefan <lizf@...fujitsu.com>,
	containers@...ts.linux-foundation.org,
	Balbir Singh <balbir@...ux.vnet.ibm.com>
Subject: Re: memcg: fix fatal livelock in kswapd

On Mon, May 02, 2011 at 06:58:18PM -0500, James Bottomley wrote:
> On Mon, 2011-05-02 at 16:14 -0700, Ying Han wrote:
> > On Mon, May 2, 2011 at 3:48 PM, Johannes Weiner <hannes@...xchg.org> wrote:
> > > I am very much for removing this hack.  There is still more scan
> > > pressure applied to memcgs in excess of their soft limit even if the
> > > extra scan is happening at a sane priority level.  And the fact that
> > > global reclaim operates completely unaware of memcgs is a different
> > > story.
> > >
> > > However, this code came into place with v2.6.31-8387-g4e41695.  Why is
> > > it only now showing up?
> > >
> > > You also wrote in that thread that this happens on a standard F15
> > > installation.  On the F15 I am running here, systemd does not
> > > configure memcgs, however.  Did you manually configure memcgs and set
> > > soft limits?  Because I wonder how it ended up in soft limit reclaim
> > > in the first place.
> 
> It doesn't ... it's standard FC15 ... the mere fact of having memcg
> compiled into the kernel is enough to do it (conversely disabling it at
> compile time fixes the problem).

Does this mean you have not set one up yourself, or does it mean that
you have checked no other software is setting up a soft-limited memcg?

Right now, I still don't see how we could enter the problematic path
without one memcg exceeding its soft limit.

So if you have not done this yet, can you check the cgroup fs for
memcgs, their memory.soft_limit_in_bytes and .usage_in_bytes right
before you would run the workload that reproduces the problem?

> > curious as well. if we have workload to reproduce it, i would like to try
> 
> Well, the only one I can suggest is the one that produces it (large
> untar).  There seems to be something magical about the memory size (mine
> is 2G) because adding more also seems to make the problem go away.

I'll try to reproduce this on my F15 as well.
--
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/