Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753279AbbGaR7v (ORCPT ); Fri, 31 Jul 2015 13:59:51 -0400 Received: from nautica.notk.org ([91.121.71.147]:40968 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752520AbbGaR7t (ORCPT ); Fri, 31 Jul 2015 13:59:49 -0400 Date: Fri, 31 Jul 2015 19:59:30 +0200 From: Dominique Martinet To: Hugh Dickins Cc: Al Viro , Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: v4.2-rc dcache regression, probably 75a6f82a0d10 Message-ID: <20150731175930.GA14449@nautica> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1776 Lines: 38 Hi, Hugh Dickins wrote on Fri, Jul 31, 2015: > I think there's something not quite right with the fs/dcache.c > commit 75a6f82a0d10 ("freeing unlinked file indefinitely delayed"). > > When running my old tmpfs swapping load (two repetitive make -j20 > kernel builds, one on tmpfs, one on ext4 over loop over tmpfs file, > in limited memory with plenty of swapping; rm -rf of both trees > in between the builds): one of the builds, always the ext4 so far, > fails after several hours, one or another header file "No such file > or directory", but the file's there when I check the tree afterwards. > > Sounds like a dcache problem, and 75a6f82a0d10 seemed the only > likely candidate, so I experimented with reverting it yesterday, > and ran successfully for 24 hours. That's a little too soon to > be sure (I've set another run going this morning), but I'd say > 90% certain that is to blame, and thought I'd better alert you > sooner than later - you'll probably guess what's the matter > long before I get back to check today's run. Actually sounds like my thread "Race condition introduced in 4bf46a27 VFS: Impose ordering on accesses of d_inode and d_flags" (in fsdevel only) It's WAY easier to reproduce over a 9P/virtio mount and with multiple level of caches (memory barrier), I was able to track it down to 4bf46a272647d ("VFS: Impose ordering on accesses of d_inode and d_flags") and debug a bit, but this isn't code I'm familiar with so would appreciate if you could tell me what you think. -- Dominique Martinet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/