Received: by 10.192.165.148 with SMTP id m20csp2419573imm; Sun, 6 May 2018 14:33:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr1SOkM14Gn+qy7o8Ox6eD+huvHH6zoH/6adLhSsXunb6AnBuzPdEmdZISxuDbswrHW7PP0 X-Received: by 2002:a17:902:848e:: with SMTP id c14-v6mr32510419plo.129.1525642409253; Sun, 06 May 2018 14:33:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525642409; cv=none; d=google.com; s=arc-20160816; b=o6uukvhVq37HsE2zVg9eo02c0tY97x20EZitiXOvW1hclDomhvXeuMkn8MRvO2m4u+ ky8SDhX9Eh9WSq5D41VWAnUxTA3MGL9g0zxlHHLrcEUH8KFppZWctNmqgxJv1RnaHOMb dYGJvpgfQZCpCeG3jyFMSYjsYRwgsGKnoOkF3ASF7idrZFz32yNJ7INhn5f4SuWUdFnh pEg1/K4qX65uCg3BFU8PmrKo0vrluCyzi2Lt1IsHQ6OrICphkXGZjNae+sQ+nPuDWFI/ VTU878+ihv3wTHMZCyGKFXBFEcWPzPZwqd0/bQFqRMvj2hT/TGadnY6R6yQnKw+kyyLw pIUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=3qNxw9rhLEfTpbmZ1nmufDAoe+sTRzAaN825t4CJHl0=; b=N0p4lYqIfIt0RWjqLzYEkvPwN12uGUkOfqh4N1w+XIrbZqGoqkOgKWj3szCwDIRcla Sj9vVMtthAkzZILbmiVn2i1HF0qkMJCMvH/7Lal1Fm3FIRDwD1ND3azklm4SXw+c+4Vl uofpl24qdE06PEWreTzLlIrXKxGfETGrY3LtLYDSkxAXRnEfAnznUNntYeF/HfDHfXrA pqb1nD3Sq3ptJYU5ngFJa0jCFYaTT2pvmx08/x5B/CLjd5XXORAvW8UMLyyt8C4ozMMQ hQ1yIj+kBvKwnS0f1IdZqJvvtfJEXQCmMMjZRHezel6ZgSIS7hg7ApB1QOcwos/+jZWJ BP2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y199si16636400pfb.284.2018.05.06.14.33.14; Sun, 06 May 2018 14:33:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751934AbeEFVc4 (ORCPT + 99 others); Sun, 6 May 2018 17:32:56 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:46728 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751910AbeEFVcx (ORCPT ); Sun, 6 May 2018 17:32:53 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fFRGx-0002rn-Pi; Sun, 06 May 2018 21:32:47 +0000 Date: Sun, 6 May 2018 22:32:47 +0100 From: Al Viro To: John Paul Adrian Glaubitz Cc: Martin Steigerwald , Matthew Wilcox , dsterba@suse.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jens Axboe , linux-m68k@lists.linux-m68k.org, Debian m68k Subject: Re: moving affs + RDB partition support to staging? Message-ID: <20180506213247.GM30522@ZenIV.linux.org.uk> References: <20180425154602.GA8546@bombadil.infradead.org> <20180425203029.GQ21272@twin.jikos.cz> <20180426025717.GA32430@bombadil.infradead.org> <1613268.lKBQxPXt8J@merkaba> <76ca15e2-7b43-8b02-43e1-9ee65ab85356@physik.fu-berlin.de> <20180506005946.GI30522@ZenIV.linux.org.uk> <20180506073955.GJ30522@ZenIV.linux.org.uk> <20180506204622.GL30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180506204622.GL30522@ZenIV.linux.org.uk> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 06, 2018 at 09:46:23PM +0100, Al Viro wrote: > I'm fixing that pile of crap (along with the NFS exports > one and, hopefully, rename mess as well). HOWEVER, I am not going > to take over the damn thing - David has violated the 11th > commandment (Thou Shalt Never Volunteer), so he gets to joy of > learning that codebase and taking care of it from now on. Same scenario on link(2) ends up with * ST_LINKFILE created, inserted into the link chain and left around, without being present in any hash chain * target becoming positive hashed dentry, as if link(2) has succeeded, so dcache lookups will be finding it (for a while) * unlink(2) on source will have very interesting effects, what with the attempts to move ST_FILE entry into the directory presumed to contain ST_LINKFILE one, removing ST_LINKFILE from it at the same time.