Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 25 Dec 2000 04:50:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 25 Dec 2000 04:50:40 -0500 Received: from neon-gw.transmeta.com ([209.10.217.66]:19973 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Mon, 25 Dec 2000 04:50:30 -0500 Date: Mon, 25 Dec 2000 01:19:50 -0800 (PST) From: Linus Torvalds To: "Marco d'Itri" cc: Alexander Viro , linux-kernel@vger.kernel.org Subject: Re: innd mmap bug in 2.4.0-test12 In-Reply-To: <20001225005303.A205@wonderland.linux.it> Message-ID: 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, 25 Dec 2000, Marco d'Itri wrote: > On Dec 24, Linus Torvalds wrote: > > > /* The page is dirty, or locked, move to inactive_dirty list. */ > > if (page->buffers || TryLockPage(page)) { > > ... > > > >and change the test to > > > > if (page->buffers || PageDirty(page) || TryLockPage(page)) { > Done, no change. > Got some articles, restarted the server, all is good. > Got other articles, rebooted and the files now differ. Willing to test some more? Add a printk() to __remove_inode_page() that complains whenever it removes a dirty page. Oh, in order to not see this with swap pages (which _can_ be removed when they are dirty, if all users of them are gone), add a PageClearDirty() to "remove_from_swap_cache()" so that we don't get false positives.. Do you get any messages? I don't think you will, but it should be tested. You might mark it a BUG(), so tht we'll get a stack-trace if it happens. Assuming we don't lose any PG_dirty bits, we might of course just lose it from the page tables themselves before it ever even gets to "struct page". I'm just surprised that it seems to be so repeatable for you - it sounds like we _never_ actually write out the dirty pages to disk. It's not that we can lose the dirty bit occasionally, we seem to lose it every time in your setup. I wonder if it's something specific innd does. Like "msync()" just being broken or similar. But the code looks sane. Hmm.. Can you send me an "strace" of innd when this happens? > And I have another problem: I'm experiencing random hangs using X[1] with > 2.4.0-test12. That's probably the infinite loop in the tty task queue handling, should be fixed in test13-pre3 or so. Linus - 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/