From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Schermerhorn Subject: Re: [PATCH][RFC] fix kernel BUG at mm/migrate.c:719! in 2.6.26-rc5-mm3 Date: Tue, 17 Jun 2008 15:28:42 -0400 Message-ID: <1213730922.8707.57.camel@lts-notebook> References: <20080611225945.4da7bb7f.akpm@linux-foundation.org> <20080617163501.7cf411ee.nishimura@mxp.nes.nec.co.jp> <1213724798.8707.41.camel@lts-notebook> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Hugh Dickins Cc: Daisuke Nishimura , Andrew Morton , Rik van Riel , Kosaki Motohiro , Nick Piggin , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On Tue, 2008-06-17 at 19:33 +0100, Hugh Dickins wrote: > On Tue, 17 Jun 2008, Lee Schermerhorn wrote: > > > > Now I wonder if the assertion that newpage count == 1 could be violated? > > I don't see how. We've just allocated and filled it and haven't > > unlocked it yet, so we should hold the only reference. Do you agree? > > Disagree: IIRC, excellent example of the kind of assumption > that becomes invalid with Nick's speculative page references. > > Someone interested in the previous use of the page may have > incremented the refcount, and in due course will find that > it's got reused for something else, and will then back off. > Yeah. Kosaki-san mentioned that we'd need some rework for the speculative page cache work. Looks like we'll need to drop the VM_BUG_ON(). I need to go read up on the new invariants we can trust with the speculative page cache. Thanks, Lee -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759212AbYFQT32 (ORCPT ); Tue, 17 Jun 2008 15:29:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757194AbYFQT3U (ORCPT ); Tue, 17 Jun 2008 15:29:20 -0400 Received: from g5t0006.atlanta.hp.com ([15.192.0.43]:46811 "EHLO g5t0006.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751828AbYFQT3T (ORCPT ); Tue, 17 Jun 2008 15:29:19 -0400 Subject: Re: [PATCH][RFC] fix kernel BUG at mm/migrate.c:719! in 2.6.26-rc5-mm3 From: Lee Schermerhorn To: Hugh Dickins Cc: Daisuke Nishimura , Andrew Morton , Rik van Riel , Kosaki Motohiro , Nick Piggin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-testers@vger.kernel.org In-Reply-To: References: <20080611225945.4da7bb7f.akpm@linux-foundation.org> <20080617163501.7cf411ee.nishimura@mxp.nes.nec.co.jp> <1213724798.8707.41.camel@lts-notebook> Content-Type: text/plain Organization: HP/OSLO Date: Tue, 17 Jun 2008 15:28:42 -0400 Message-Id: <1213730922.8707.57.camel@lts-notebook> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2008-06-17 at 19:33 +0100, Hugh Dickins wrote: > On Tue, 17 Jun 2008, Lee Schermerhorn wrote: > > > > Now I wonder if the assertion that newpage count == 1 could be violated? > > I don't see how. We've just allocated and filled it and haven't > > unlocked it yet, so we should hold the only reference. Do you agree? > > Disagree: IIRC, excellent example of the kind of assumption > that becomes invalid with Nick's speculative page references. > > Someone interested in the previous use of the page may have > incremented the refcount, and in due course will find that > it's got reused for something else, and will then back off. > Yeah. Kosaki-san mentioned that we'd need some rework for the speculative page cache work. Looks like we'll need to drop the VM_BUG_ON(). I need to go read up on the new invariants we can trust with the speculative page cache. Thanks, Lee From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH][RFC] fix kernel BUG at mm/migrate.c:719! in 2.6.26-rc5-mm3 From: Lee Schermerhorn In-Reply-To: References: <20080611225945.4da7bb7f.akpm@linux-foundation.org> <20080617163501.7cf411ee.nishimura@mxp.nes.nec.co.jp> <1213724798.8707.41.camel@lts-notebook> Content-Type: text/plain Date: Tue, 17 Jun 2008 15:28:42 -0400 Message-Id: <1213730922.8707.57.camel@lts-notebook> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Hugh Dickins Cc: Daisuke Nishimura , Andrew Morton , Rik van Riel , Kosaki Motohiro , Nick Piggin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-testers@vger.kernel.org List-ID: On Tue, 2008-06-17 at 19:33 +0100, Hugh Dickins wrote: > On Tue, 17 Jun 2008, Lee Schermerhorn wrote: > > > > Now I wonder if the assertion that newpage count == 1 could be violated? > > I don't see how. We've just allocated and filled it and haven't > > unlocked it yet, so we should hold the only reference. Do you agree? > > Disagree: IIRC, excellent example of the kind of assumption > that becomes invalid with Nick's speculative page references. > > Someone interested in the previous use of the page may have > incremented the refcount, and in due course will find that > it's got reused for something else, and will then back off. > Yeah. Kosaki-san mentioned that we'd need some rework for the speculative page cache work. Looks like we'll need to drop the VM_BUG_ON(). I need to go read up on the new invariants we can trust with the speculative page cache. Thanks, Lee -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org