From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: panic in do_last() Date: Fri, 18 Apr 2014 03:17:09 +0100 Message-ID: <20140418021707.GH18016@ZenIV.linux.org.uk> References: <20140418015750.GG18016@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Howells , linux-fsdevel@vger.kernel.org, Hugh Dickins To: Lin Ming Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:34657 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750970AbaDRCRL (ORCPT ); Thu, 17 Apr 2014 22:17:11 -0400 Content-Disposition: inline In-Reply-To: <20140418015750.GG18016@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Apr 18, 2014 at 02:57:50AM +0100, Al Viro wrote: > Where is it in do_last()? Hard to tell without even the hex dump of > oopsing code (and trying to reproduce it here hasn't produced any oopsen > so far). Hmm... Still no oopsen, but it looks like it *is* possible to get screwed there. RCU mode isn't a problem, AFAICS (we'll fail on d_seq mismatch in complete_walk() and that will be the end of it), but non-lazy mode *can* get buggered. We are holding a reference to nd->path.dentry and that's enough to prevent positive-to-negative transition, but negative-to-positive is fair game. So it does happen and we end up with nd->inode being set to NULL. And _that_ promptly blows up on if (!S_ISREG(nd->inode->i_mode)) will_truncate = false; Actually, it might very well be the only source of breakage - that late in the game (already out of RCU mode, for starters) we don't give a damn about nd->inode. Ah, actually there's also BUG_ON(inode != path->dentry->d_inode); in symlink case (similar "negative to positive", but it will be a symlink(2), not creat(2)). Pointless BUG_ON, actually... The reason why your reordering hadn't done any good is that CPU cache is free to reorder behind your back - no barriers between these two stores. I'd still like the disassembly of your do_last() and the missing hex dump...