Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751444AbbHAKTc (ORCPT ); Sat, 1 Aug 2015 06:19:32 -0400 Received: from nautica.notk.org ([91.121.71.147]:36231 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751180AbbHAKTa (ORCPT ); Sat, 1 Aug 2015 06:19:30 -0400 Date: Sat, 1 Aug 2015 12:19:13 +0200 From: Dominique Martinet To: Al Viro Cc: Linus Torvalds , Hugh Dickins , "J. Bruce Fields" , Dominique Martinet , Linux Kernel Mailing List , linux-fsdevel , David Howells Subject: Re: v4.2-rc dcache regression, probably 75a6f82a0d10 Message-ID: <20150801101913.GA24028@nautica> References: <20150731205036.GA3752@nautica> <20150801072603.GV17109@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150801072603.GV17109@ZenIV.linux.org.uk> 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: 1939 Lines: 53 Al Viro wrote on Sat, Aug 01, 2015: > And that has turned the check done to an inode that *was* ours at some > point (i.e. fetching it had been followed by checking that ->d_seq had > been still valid) into something completely unprotected. Suppose we > are in lazy mode and somebody had evicted nd->path.dentry after we'd looked > it up and before that check. Sure, its ->d_seq had been bumped by that, > and we would've failed anyway. With ECHILD. Which, unlike ENOTDIR, is > "repeat in non-lazy mode". That sounds like a good find, I was looking at how to claim/protect the entry somehow as well but I just have no idea... > Folks, could you check if this fixes the problems you are seeing? > > diff --git a/fs/namei.c b/fs/namei.c > index ae4e4c1..b16c3a7 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -1954,7 +1954,11 @@ OK: > continue; > } > } > - if (unlikely(!d_can_lookup(nd->path.dentry))) > + if (unlikely(!d_can_lookup(nd->path.dentry))) { > + if (nd->flags & LOOKUP_RCU) { > + if (unlazy_walk(nd, NULL, 0)) > + return -ECHILD; > + } > return -ENOTDIR; > } > } Unfortunately, still happens for me. I had to adapt a bit because using an old kernel (4bf46a272), will try again with a recent master to doublecheck, but I had a break on the "if (nd->flags & LOOKUP_RCU)" check: - sometimes fails without ever hitting the check. I think this fixes the "ENOTDIR" I had described, but there's at least another way to fail? - When we do hit it, we're into LOOKUP_RCU at this point alright, unlazy_walk fails and we try again without RCU -- can confirm the recovery process goes OK (well, that it went OK at least once) Thanks, -- Dominique -- 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/