Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756746Ab1BQQ0p (ORCPT ); Thu, 17 Feb 2011 11:26:45 -0500 Received: from cantor2.suse.de ([195.135.220.15]:54298 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752716Ab1BQQ0n (ORCPT ); Thu, 17 Feb 2011 11:26:43 -0500 Date: Thu, 17 Feb 2011 17:26:41 +0100 From: Michal Hocko To: Linus Torvalds Cc: Ingo Molnar , linux-mm@kvack.org, LKML Subject: Re: BUG: Bad page map in process udevd (anon_vma: (null)) in 2.6.38-rc4 Message-ID: <20110217162641.GC3781@tiehlicka.suse.cz> References: <20110216185234.GA11636@tiehlicka.suse.cz> <20110216193700.GA6377@elte.hu> <20110217090910.GA3781@tiehlicka.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2455 Lines: 65 On Thu 17-02-11 08:13:50, Linus Torvalds wrote: > On Thu, Feb 17, 2011 at 1:09 AM, Michal Hocko wrote: > > > > I have seen that thread but I didn't think it is related. I thought > > this is an another anon_vma issue. But you seem to be right that the > > offset pattern can be related. > > Hey, maybe it turns out to be about anon_vma's in the end, but I see > no big reason to blame them per se. And we haven't had all that much > churn wrt anon_vma's this release window, so I wouldn't expect > anything exciting unless you're actively using transparent hugepages. > And iirc, Eric was not using them (or memory compaction). I am using transparent hugepages: $ grep -i huge /proc/vmstat nr_anon_transparent_hugepages 24 and this is the usual number that I can see with my day-to-day workload. > I'd be more likely to blame either the new path lookup (which uses > totally new RCU freeing of inodes _and_ > INIT_LIST_HEAD(&inode->i_dentry)), but I'm not seeing how that could > break either (I've gone through that patch many times). > > And in addition, I don't see why others wouldn't see it (I've got > DEBUG_PAGEALLOC and SLUB_DEBUG_ON turned on myself, and I know others > do too). > > So I'm wondering what triggers it. Must be something subtle. > > > OK. I have just booted with the same kernel and the config turned on. > > Let's see if I am able to reproduce. > > Thanks. It might have been good to turn on SLUB_DEBUG_ON and > DEBUG_LIST too, but PAGEALLOC is the big one. I can try those later as well. Currently I am not able to trigger the issue. I am running rmmod wireless stack + modproble it back in the loop because this was the last thing before I saw the bug last time. Let's see if it changes later. > > > Btw. > > $ objdump -d ./vmlinux-2.6.38-rc4-00001-g07409af-vmscan-test | grep 0x1e68 > > > > didn't print out anything. Do you have any other way to find out the > > structure? > > Nope, that's roughly what I did to (in addition to doing all the .ko > files and checking for 0xe68 too). Ohh, I forgot about modules. Just did it and also nothing found. -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- 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/