linux-kernel - Re: [PATCH] mm: compaction: Abort compaction if too many pages are isolated and caller is asynchronous

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]

Message-ID: <20110603020920.GA26753@suse.de>
Date:	Fri, 3 Jun 2011 03:09:20 +0100
From:	Mel Gorman <mgorman@...e.de>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	Minchan Kim <minchan.kim@...il.com>, akpm@...ux-foundation.org,
	Ury Stankevich <urykhy@...il.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, stable@...nel.org
Subject: Re: [PATCH] mm: compaction: Abort compaction if too many pages are
 isolated and caller is asynchronous

On Thu, Jun 02, 2011 at 05:37:54PM +0200, Andrea Arcangeli wrote:
> > There is an explanation in here somewhere because as I write this,
> > the test machine has survived 14 hours under continual stress without
> > the isolated counters going negative with over 128 million pages
> > successfully migrated and a million pages failed to migrate due to
> > direct compaction being called 80,000 times. It's possible it's a
> > co-incidence but it's some co-incidence!
> 
> No idea...

I wasn't able to work on this most of the day but was looking at this
closer this evening again and I think I might have thought of another
theory that could cause this problem.

When THP is isolating pages, it accounts for the pages isolated against
the zone of course. If it backs out, it finds the pages from the PTEs.
On !SMP but PREEMPT, we may not have adequate protection against a new
page from a different zone being inserted into the PTE causing us to
decrement against the wrong zone. While the global counter is fine,
the per-zone counters look corrupted. You'd still think it was the
anon counter tht got screwed rather than the file one if it really was
THP unfortunately so it's not the full picture. I'm going to start
a test monitoring both zoneinfo and vmstat to see if vmstat looks
fine while the per-zone counters that are negative are offset by a
positive count on the other zones that when added together become 0.
Hopefully it'll actually trigger overnight :/

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