From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261563AbUEQPC5 (ORCPT ); Mon, 17 May 2004 11:02:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261576AbUEQPC5 (ORCPT ); Mon, 17 May 2004 11:02:57 -0400 Received: from fw.osdl.org ([65.172.181.6]:1995 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S261563AbUEQPC4 (ORCPT ); Mon, 17 May 2004 11:02:56 -0400 Date: Mon, 17 May 2004 08:02:48 -0700 (PDT) From: Linus Torvalds To: Larry McVoy cc: Steven Cole , Andrew Morton , William Lee Irwin III , hugh@veritas.com, adi@bitmover.com, scole@lanl.gov, support@bitmover.com, Kernel Mailing List Subject: Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) In-Reply-To: <20040517145217.GA30695@work.bitmover.com> Message-ID: References: <200405132232.01484.elenstev@mesatop.com> <20040517022816.GA14939@work.bitmover.com> <200405162136.24441.elenstev@mesatop.com> <20040517141427.GD29054@work.bitmover.com> <20040517145217.GA30695@work.bitmover.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 17 May 2004, Larry McVoy wrote: > > > And at some point earlier in the process you did an fflush(), or somebody > > else had written a header of n*PAGE_SIZE + 0x4ff bytes, or something like > > that. Since this was the ChangeSet file, I suspect that the "header" is > > the checkin-comment section at the beginning, and the "second phase" is > > the actual key list thing. You know how you write the ChangeSet file > > better than I do. > > I don't think we flush along the way but let me look. Whoops, you're right, > we do. Right where you thought too. But that doesn't explain there being > 3 blocks of nulls (there should NEVER be a null in the s.ChangeSet file, we > don't compress that, it's always ascii). No, no, I'm not claiming that _you_ are writing the NUL bytes. I'm claiming the kernel has a bug that triggers with non-page-aligned starting offsets of writes (because we clear the bytes after "i_size", and we don't synchronize those clears sufficiently), and concurrent flushes. There's probably some other trigger needed too (CONFIG_PREEMPT being just the thing that uncovers the race). > But the bigger problem is that you are missing the point that I mentioned > elsewhere, we are writing to a tmp file, the tmp file is NOT mmapped. No, the mmap thing was Andrew's theory. My theory is that regular "write()" calls can trigger it through the "commit_write()" function. Of course, my theory also depended on a page unlock happening in a place where it didn't actually happen, so the exact details of my theory are crap. I'll need to re-think that part. Linus