This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu Apr 25 17:31:53 2024 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8HKDJi10817 for ; Tue, 17 Sep 2002 22:13:19 +0200 Received: (qmail 15283 invoked from network); 17 Sep 2002 19:56:14 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 17 Sep 2002 19:56:14 -0000 Received: (qmail 15088 invoked by uid 1000); 17 Sep 2002 19:43:05 -0000 MBOX-Line: From linux-kernel-owner@vger.kernel.org Mon Sep 18 14:05:11 2000 Received: (maildatabase); juh Received: (qmail 3442 invoked by alias); 18 Sep 2000 14:05:10 -0000 Received: (qmail 3240 invoked from network); 18 Sep 2000 13:46:02 -0000 Received: from digger.ds9a.nl (HELO outpost.ds9a.nl) (postfix@213.244.168.211) by spaans.ds9a.nl with SMTP; 18 Sep 2000 13:46:02 -0000 Received: from vger.kernel.org (vger.kernel.org [199.183.24.194]) by outpost.ds9a.nl (Postfix) with ESMTP id 15F5B7504C for ; Mon, 18 Sep 2000 15:46:00 +0200 (CEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 18 Sep 2000 10:00:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 18 Sep 2000 10:00:19 -0400 Received: from hermes.mixx.net ([212.84.196.2]:40456 "HELO hermes.mixx.net") by vger.kernel.org with SMTP id ; Mon, 18 Sep 2000 10:00:16 -0400 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id CAD06F805 for ; Mon, 18 Sep 2000 15:45:02 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 4DA8E2CA6D; Mon, 18 Sep 2000 15:45:02 +0200 (CEST) From: Daniel Phillips Reply-To: Daniel Phillips X-Newsgroups: innominate.list.linux.kernel Subject: Re: The INN/mmap bug Date: Mon, 18 Sep 2000 15:45:01 +0200 Organization: innominate Lines: 61 Distribution: local Message-Id: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: mate.bln.innominate.de 969284702 9571 10.0.0.90 (18 Sep 2000 13:45:02 GMT) X-Complaints-To: news@innominate.de To: Alexander Viro X-Mailer: Mozilla 4.72 [de] (X11; U; Linux 2.4.0-test8 i586) X-Accept-Language: en To: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Alexander Viro wrote: > > On Sun, 17 Sep 2000, Linus Torvalds wrote: > > > On Sun, 17 Sep 2000, Alexander Viro wrote: > > > > > > Looks sane. But I really wonder if we could just do it in > > > create_page_buffers() if page is up-to-date. OTOH it would require attempt > > > to map them all. Comments? > > > > That would certainly simplify a lot. > > > > And as we've seen, simplifying this area would not necessarily be a bad > > thing ;) > > > > Right now I'll just do the minimal fix, though, I think. > > Fine with me. I'll do the full analysis tonight, anyway, and try to write > down the rules for that stuff. One thing that makes me seriously uneasy > is the fact that VM knows about ->buffers - I would be much happier if all > this stuff would be contained in fs/buffer.c. IOW, I'm not sure that > block_flushpage()/try_to_free_buffers() is a happy camper. As you know, I've begun to analyse it;  Canonic buffer states and transitions http://marc.theaimsgroup.com/?l=linux-fsdevel&m=96893011609105&w=2 Since that post I've found one additional useful buffer state (*) bringing the total to 5: 0: undef - Neither data on disk or in cache known to be valid 1: inval - Data on disk known to be invalid (*) 2: known - Data on disk known to be valid 3: dirty - Data in cache known to be valid 4: clean - Data in cache known to match data on disk This is still a lot less that the current 16 states. I'm still waiting for comments on this analysis one way or the other. I think it strikes at the heart of the problem. I already used this way of thinking to find and fix a similar bug in my tailmerging code where __block_prepare_write was wrongly clearing part of a dirty buffer just because ext2_get_block reported it had created a new block. The quick fix was to suppress the buffer_new bit coming back from ext2_get_block if the buffer is dirty. A better fix would be to eliminate the buffer_new bit entirely, but of course this can wait. My contribution to this will be to update the buffer states post and if nobody thinks I'm completely off-base, do a similar one for page states. It seems to me that you and Linus have already found exactly the crevice that this bug lives in. > I'm not proposing it for immediate inclusion, but I don't feel good about > all this code - current rules are too complex and rely on details of > VM/buffer interaction too much for my taste. It may be correct, but it's > not obviously correct... Amen. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/