From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from chiara.csoma.elte.hu (chiara.csoma.elte.hu [157.181.71.18]) by kvack.org (8.8.7/8.8.7) with ESMTP id GAA18758 for ; Fri, 29 Jan 1999 06:29:44 -0500 Date: Fri, 29 Jan 1999 12:20:43 +0100 (CET) From: MOLNAR Ingo Reply-To: MOLNAR Ingo Subject: Re: [patch] fixed both processes in D state and the /proc/ oopses [Re: [patch] Fixed the race that was oopsing Linux-2.2.0] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Andrea Arcangeli Cc: Linus Torvalds , "Stephen C. Tweedie" , linux-kernel@vger.rutgers.edu, werner@suse.de, mlord@pobox.com, "David S. Miller" , gandalf@szene.CH, adamk@3net.net.pl, kiracofe.8@osu.edu, ksi@ksi-linux.COM, djf-lists@ic.NET, tomh@taz.ccs.fau.edu, Alan Cox , linux-mm@kvack.org List-ID: On Fri, 29 Jan 1999, Andrea Arcangeli wrote: > Another way to tell the same: "how can I be sure that I am doing an > atomic_inc(&mm->count) on a mm->count that was just > 0, and more > important on an mm that is still allocated? " you are misunderstanding how atomic_inc_and_test() works. The processor guarantees this. This is the crux of SMP atomic operations. How otherwise could we reliably build read-write spinlocks. yes, there is no atomic_inc_and_test() yet. (it's a bit tricky to implement but pretty much analogous to read-write locks, we probably need to shift values down by one to get the 'just increased from -1 to 0' event via the zero flag, and get the 'just decreased from 0 to -1' event via the sign flag.) Also note that this is all fiction yet because we _are_ holding the kernel lock for these situations in 2.2. -- mingo -- To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://humbolt.geo.uu.nl/Linux-MM/