Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 1 Oct 2002 11:10:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 1 Oct 2002 11:10:54 -0400 Received: from dsl-213-023-043-077.arcor-ip.net ([213.23.43.77]:18587 "EHLO starship") by vger.kernel.org with ESMTP id ; Tue, 1 Oct 2002 11:10:53 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Richard.Zidlicky@stud.informatik.uni-erlangen.de, zippel@linux-m68k.org Subject: Re: 2.4 mm trouble [possible lru race] Date: Tue, 1 Oct 2002 17:12:21 +0200 X-Mailer: KMail [version 1.3.2] Cc: linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org References: <200210011420.QAA13868@faui02b.informatik.uni-erlangen.de> In-Reply-To: <200210011420.QAA13868@faui02b.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1969 Lines: 50 On Tuesday 01 October 2002 16:20, Richard.Zidlicky@stud.informatik.uni-erlangen.de wrote: > > > > The theoretical lru race possibly spotted in the wild... > > > > > > > > Now I am wondering if that is just coincidence or why m68k hit that > > > error so reliably.. is it supposed to have any effect at all on > > > UP? > > > > Are you running UP+preempt? > > no preempt or anything fancy, m68k vanila 2.4.19 (well almost). I'm having real trouble spotting substantive change in the patch that would affect a UP kernel. I believe you when you say it fixes your problem, but we don't know why, and it is worth making some effort to find out why. Ah wait, I see one candidate, would you like to try: * the page as well. */ if (page->buffers) { /* avoid to free a locked page */ - get_page(page); spin_unlock(&pagemap_lru_lock); + get_page(page); and see if your bug comes back? There are a couple of other changes that could be considered substantive by stretching one's imagination enough, but this is the leading candidate. Oh wait, you could also try this, a little further down: + page_cache_release(page); spin_lock(&pagemap_lru_lock); - put_page_nofree(page); By the way, the original patch you posted was reversed and your editor apparently took the liberty of cleaning up some whitespace in the file. Generally, we try do avoid patch chunks that just, e.g., change bogus spaces to tabs, and save those for official whitespace patches. -- Daniel - 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/