Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp91830pxb; Tue, 15 Feb 2022 09:03:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJzmjIb9+9EjOZwEx020AQgj/YC5IdQzb1E6OllEsrIofI8LRsUlJx5odnyHAXWiKaSX5XXa X-Received: by 2002:a05:620a:3c6:: with SMTP id r6mr2581815qkm.390.1644944580084; Tue, 15 Feb 2022 09:03:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644944580; cv=none; d=google.com; s=arc-20160816; b=jKj+gPnom7KGVVlBtTxveKeEDjTlHuTG3PsQpaK4bH2pWGy6ONw0JocCoEW/vO9DCU yArWahJITTrlIxwo+ZL137SviCww2vL5t2qFoxBqOPhOVNacfxekmtKiHRCH0kgvc3RJ mQhGikRu5NBXOGuhdmUz6jKlp4z3xo3EyM1d5ToBlaRvoZNFEgZZYb1AsnkVC7FS4/sR bfjUbLW8ZesP9Nyl0U9cM2Dg9XmdI1V0zAM7ShriBjOWnb8khfxIQQq6iyTKt8ifaD1C 4YF5y1+NyD8BF+D+Vd3RUmWAblUdo+ECY0HLVnhmEnExG3aLSk6UvQnzDHLLTsEYYsQP q4hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=RGGCyYRr+AH/lwwTordz2PG+fBSC9ibjT5WIR+nXryg=; b=zbHxhwjmr9Xt66TJQI+kXNec5QOjpxdK85jf5FsqOpXH7hKsA4SKpGDPJNSh57T5La ewlF5bewz65K63ZId3+00AcVzq4lHDfW7ZTNFuie8MSu4R5T/FXyFyk+V7wHzY2RB1tf 4DZB6c/mz5UPQJjn5U6Pp31HNp4sRsf4lrRlChBx+keVCJHUqIQ08f0LzF1H2eMBevPq s0JYG7/999stWfKyZ+PK03dlHis/CNv92SB2ZP6qKZ7BAA0Y17iSvMlUHDXvuWipuV0z bSwilgiYPh1NXvyjpTy4jNP6wu4nClG1Fr9CoQWxIkRgyDJZ121uHvYh6M6FUHNPG4GJ M9pw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u10si2288506qtc.83.2022.02.15.09.02.42; Tue, 15 Feb 2022 09:03:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241470AbiBOQU5 (ORCPT + 99 others); Tue, 15 Feb 2022 11:20:57 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:40038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241535AbiBOQUt (ORCPT ); Tue, 15 Feb 2022 11:20:49 -0500 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 24AC6E3725; Tue, 15 Feb 2022 08:20:40 -0800 (PST) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nK0ZB-0021jl-Tk; Tue, 15 Feb 2022 16:20:38 +0000 Date: Tue, 15 Feb 2022 16:20:37 +0000 From: Al Viro To: Matthew Wilcox Cc: Miklos Szeredi , Xavier Roche , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Aneesh Kumar K.V" Subject: Re: race between vfs_rename and do_linkat (mv and link) Message-ID: References: <20220214210708.GA2167841@xavier-xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 15, 2022 at 04:17:11PM +0000, Matthew Wilcox wrote: > On Tue, Feb 15, 2022 at 04:06:06PM +0000, Al Viro wrote: > > On Tue, Feb 15, 2022 at 01:37:40PM +0000, Al Viro wrote: > > > On Tue, Feb 15, 2022 at 10:56:29AM +0100, Miklos Szeredi wrote: > > > > > > > Doing "lock_rename() + lookup last components" would fix this race. > > > > "Fucking ugly" is inadequate for the likely results of that approach. > > It's guaranteed to be a source of headache for pretty much ever after. > > > > Does POSIX actually make any promises in that area? That would affect > > how high a cost we ought to pay for that - I agree that it would be nicer > > to have atomicity from userland point of view, but there's a difference > > between hard bug and QoI issue. > > As I understand the original report, it relies on us hitting the nlink == > 0 at exactly the wrong moment. Can't we just restart the entire path > resolution if we find a target with nlink == 0? Sure, it's a lot of > extra work, but you've got to be trying hard to hit it in the first place. touch /tmp/blah exec 42