From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dominique Martinet Subject: Re: v4.2-rc dcache regression, probably 75a6f82a0d10 Date: Fri, 31 Jul 2015 19:59:30 +0200 Message-ID: <20150731175930.GA14449@nautica> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Al Viro , Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Hugh Dickins Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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