Return-Path: <linux-kernel-owner+w=401wt.eu-S1751211AbZFSEPe@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751211AbZFSEPe (ORCPT <rfc822;w@1wt.eu>);
	Fri, 19 Jun 2009 00:15:34 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750752AbZFSEP0
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 19 Jun 2009 00:15:26 -0400
Received: from lemon.ertos.nicta.com.au ([203.143.174.143]:52392 "EHLO
	lemon.ken.nicta.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750741AbZFSEP0 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 19 Jun 2009 00:15:26 -0400
Date: Fri, 19 Jun 2009 14:11:21 +1000
Message-ID: <87y6ro6exi.wl%peter@chubb.wattle.id.au>
From: Peter Chubb <peter.chubb@nicta.com.au>
To: linux-kernel@vger.kernel.org, mel@csn.ul.ie
Subject: [BUG] Bad page flags when process using mlock()ed memory exits
User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9
 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 MULE XEmacs/21.4 (patch 21)
 (Educational Television) (i486-linux-gnu)
X-Face: GgFg(Z>fx((4\32hvXq<)|jndSniCH~~$D)Ka:P@e@JR1P%Vr}EwUdfwf-4j\rUs#JR{'h#
 !]])6%Jh~b$VA|ALhnpPiHu[-x~@<"@Iv&|%R)Fq[[,(&Z'O)Q)xCqe1\M[F8#9l8~}#u$S$Rm`S9%
 \'T@`:&8>Sb*c5d'=eDYI&GF`+t[LfDH="MP5rwOO]w>ALi7'=QJHz&y&C&TE_3j!
Organization: National ICT Australia
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-SA-Exim-Connect-IP: 203.143.161.65
X-SA-Exim-Mail-From: peter.chubb@nicta.com.au
X-SA-Exim-Scanned: No (on lemon.ken.nicta.com.au); SA Timed out after 240 secs
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1853
Lines: 44


In recent kernels I've been seeing many mesages of the form:

BUG: Bad page state in process reiserfsck  pfn:79c58
page:c3d03b00 flags:8050000c count:0 mapcount:0 mapping:(null) index:8095
Pid: 3927, comm: reiserfsck Not tainted 2.6.30-test-05456-gda456f1 #60
Call Trace:
 [<c134a67c>] ? printk+0xf/0x13
 [<c10774dc>] bad_page+0xc9/0xe2
 [<c1078041>] free_hot_cold_page+0x5c/0x204
 [<c1078206>] __pagevec_free+0x1d/0x25
 [<c107ac3e>] release_pages+0x14e/0x18e)
 [<c108ef8a>] free_pages_and_swap_cache+0x69/0x82
 [<c1089458>] exit_mmap+0xf6/0x11f
 [<c102afcd>] mmput+0x39/0xaf
 [<c102e534>] exit_mm+0xe5/0xed
 [<c102fa66>] do_exit+0x13f/0x578
 [<c102fefd>] do_group_exit+0x5e/0x85
 [<c102ff37>] sys_exit_group+0x13/0x17
 [<c10031ef>] sysenter_do_call+0x12/0x3c
Disabling lock debugging due to kernel taint

This appears to have been introduced by patch 
    da456f14d2f2d7350f2b9440af79c85a34c7eed5
    page allocator: do not disable interrupts in free_page_mlock()

That patch removed the free_page_mlock() from free_pages_check(), so
if free_hot_cold_page() is called on an Mlocked page (e.g., if a
process that used mlock() calls exit()) free_pages_check() will always
barf, whereas before it would just unlock the page.

Reverting the patch fixed the issue for me (although a straight git
revert isn't enough, because free_page_mlock() has moved from
mm/internal.h to mm/page_alloc.c)

--
Dr Peter Chubb                              peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
           Kernel Engineering Group (KEG): Where Systems Brew.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/