Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp1234870rwe; Thu, 25 Aug 2022 19:21:05 -0700 (PDT) X-Google-Smtp-Source: AA6agR4MM1nwaBbsquo1zhHwyLXKvod30qTBy4q6rbKgHLPC8ujAe0x4Tz+trT7pl9z7ZYSyT9pw X-Received: by 2002:a17:906:2bc7:b0:72f:dc70:a3c6 with SMTP id n7-20020a1709062bc700b0072fdc70a3c6mr4087062ejg.645.1661480465394; Thu, 25 Aug 2022 19:21:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661480465; cv=none; d=google.com; s=arc-20160816; b=v+RErvPd9PkZnCllD8Z7cCFw2OjtK4E3+xNafVsalLTY8pdWVnuO0eBUDURdJpwdsY J0Vtr/XgNrgTAqoO7+2inkpOVA/8Cru3s8sXeZk4LO1JO6tRyQmKapsEp1wtDTnzyX4+ WfN4xV5U1aBpn1vHtN2JhKs2EVn62abMz0jwdOshSrA7gKT056xrdVjnH8sBxv/xTDQ+ i4JCn251qi5RxEC/yiIULjTMh1xvyFHEW8lrNpKUQKY+IGykNLBVQXglXmWk3F1UJdLe KPAhC2L1B9niSSal2z+QujZqptyr8f92Dz6PsDHjDU6eXv9NAgQUxGOZUJbv3tsunjIu ReAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:cc:to:from :subject:dkim-signature:dkim-signature; bh=IAy5RIlK+BKXr3TtbnQGrDhGvJvfQnV3J6gfvsVI2SI=; b=M3EK1Jscata4hpNor4mrElSp3T8QTYhFM+iStZ24xFdGWl9oFlTGvANBIA3MhFPdKL xE0z0DY/Gd36RpPqVtO3nLLfdnD7C2OOB5tXcC5MNRBuIMsmgPeM5S3s4yPRf66erky3 X3dpc1pgNZI8v3jZEDeDKdfp6uXDc19QoNkpYTmDF1k9IzbfUuZzPt8Scgn7qOaZmeim eh9uziv9PUMLO8TqGYQQB9NGavTF5KvCQwaKDxfnS51SjGrBullg+1Ye7mO8o0F8GkrT c/gAvGr9jDMbV8g1ho+Qw9tXYaRZA4p+ROPjZBoyKVShfwpBQ4DoqUdB7Rj8FpKWRjHw IwyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Y6yj7S4o; dkim=neutral (no key) header.i=@suse.de header.b=Ua0xxjne; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d35-20020a056402402300b00447f4482f9asi96281eda.443.2022.08.25.19.20.40; Thu, 25 Aug 2022 19:21:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-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; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Y6yj7S4o; dkim=neutral (no key) header.i=@suse.de header.b=Ua0xxjne; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244036AbiHZCRW (ORCPT + 99 others); Thu, 25 Aug 2022 22:17:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244739AbiHZCRS (ORCPT ); Thu, 25 Aug 2022 22:17:18 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DEAB9CB5D9; Thu, 25 Aug 2022 19:17:11 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 60F5A20781; Fri, 26 Aug 2022 02:17:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1661480230; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IAy5RIlK+BKXr3TtbnQGrDhGvJvfQnV3J6gfvsVI2SI=; b=Y6yj7S4oNnQdmlZED4Sv2odlp45fzx1VpVUavURqmBrMe1lS8cFAWL7Vr+fDDacDg86PBP xlvopoqEdpGN90wF/FxrX0wXM+JlFXMjdgunwCGmCPt3lUXRcZ1z+75W46z72RDtladjCl Xmgy1l2RHbiBbHMnt2HUgbQqm5i7H48= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1661480230; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IAy5RIlK+BKXr3TtbnQGrDhGvJvfQnV3J6gfvsVI2SI=; b=Ua0xxjneF59o45AsOnrN7VuFr9bOCgaBvcGGtWeZBzHmtOxoOIbXZjZ66XIWEE++e7f+I0 QZ6LBjQNCDAYrTAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 4057313A65; Fri, 26 Aug 2022 02:16:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id J8SJOhotCGNZMQAAMHmgww (envelope-from ); Fri, 26 Aug 2022 02:16:58 +0000 Subject: [PATCH 02/10] VFS: move EEXIST and ENOENT tests into lookup_hash_update() From: NeilBrown To: Al Viro , Linus Torvalds , Daire Byrne , Trond Myklebust , Chuck Lever Cc: Linux NFS Mailing List , linux-fsdevel@vger.kernel.org, LKML Date: Fri, 26 Aug 2022 12:10:43 +1000 Message-ID: <166147984373.25420.5973159222199992210.stgit@noble.brown> In-Reply-To: <166147828344.25420.13834885828450967910.stgit@noble.brown> References: <166147828344.25420.13834885828450967910.stgit@noble.brown> User-Agent: StGit/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,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-nfs@vger.kernel.org Moving common error handling into lookup_hash_update() simplifies callers. A future patch will export this functionality to nfsd, and the more code we put in the interface, the less code will be needed in nfsd. EEXIST is returned if LOOKUP_EXCL is set and dentry is positivie. ENOENT is returned if LOOKUP_CREAT is NOT set and dentry is negative. This involves seting LOOKUP_EXCL in cases where it wasn't before. In particular, when creating a non-dir named "foo/", we want the EEXIST error, but don't want to actually create anything. Some filesystems assume LOOKUP_EXCL implies LOOKUP_CREATE, so ensure it does when calling ->lookup(). Signed-off-by: NeilBrown --- fs/namei.c | 58 ++++++++++++++++++++++++++++++++++------------------------ 1 file changed, 34 insertions(+), 24 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index c008dfd01e30..09c2d007814a 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1562,7 +1562,13 @@ static struct dentry *lookup_dcache(const struct qstr *name, { struct dentry *dentry = d_lookup(dir, name); if (dentry) { - int error = d_revalidate(dentry, flags); + int error; + /* Some filesystems assume EXCL -> CREATE, so make + * sure it does. + */ + if (!(flags & LOOKUP_CREATE)) + flags &= ~LOOKUP_EXCL; + error = d_revalidate(dentry, flags); if (unlikely(error <= 0)) { if (!error) d_invalidate(dentry); @@ -1621,6 +1627,8 @@ static struct dentry *__lookup_hash(const struct qstr *name, * or shared lock depending on the fs preference, then do a lookup, * and then set the DCACHE_PAR_UPDATE bit on the child if a shared lock * was taken on the parent. + * If LOOKUP_EXCL, name should not already exist, else -EEXIST + * If not LOOKUP_CREATE, name should already exist, else -ENOENT */ static struct dentry *lookup_hash_update( const struct qstr *name, @@ -1651,6 +1659,24 @@ static struct dentry *lookup_hash_update( dput(dentry); goto retry; } + if (flags & LOOKUP_EXCL) { + if (d_is_positive(dentry)) { + d_lookup_done(dentry); + d_unlock_update(dentry); + dput(dentry); + err = -EEXIST; + goto out_err; + } + } + if (!(flags & LOOKUP_CREATE)) { + if (!dentry->d_inode) { + d_lookup_done(dentry); + d_unlock_update(dentry); + dput(dentry); + err = -ENOENT; + goto out_err; + } + } return dentry; out_err: @@ -3868,7 +3894,7 @@ static struct dentry *filename_create_one(struct qstr *last, struct path *path, struct dentry *dentry; bool want_dir = lookup_flags & LOOKUP_DIRECTORY; unsigned int reval_flag = lookup_flags & LOOKUP_REVAL; - unsigned int create_flags = LOOKUP_CREATE | LOOKUP_EXCL; + unsigned int create_flag = LOOKUP_CREATE; int err2; int error; @@ -3879,26 +3905,16 @@ static struct dentry *filename_create_one(struct qstr *last, struct path *path, * '/', and a directory wasn't requested. */ if (last->name[last->len] && !want_dir) - create_flags = 0; + /* Name was foo/bar/ but not creating a directory, so + * we won't try to create - result will be either -ENOENT + * or -EEXIST. + */ + create_flag = 0; dentry = lookup_hash_update(last, path->dentry, - reval_flag | create_flags, wq); + reval_flag | create_flag | LOOKUP_EXCL, wq); if (IS_ERR(dentry)) goto drop_write; - error = -EEXIST; - if (d_is_positive(dentry)) - goto fail; - - /* - * Special case - lookup gave negative, but... we had foo/bar/ - * From the vfs_mknod() POV we just have a negative dentry - - * all is fine. Let's be bastards - you had / on the end, you've - * been asking for (non-existent) directory. -ENOENT for you. - */ - if (unlikely(!create_flags)) { - error = -ENOENT; - goto fail; - } if (unlikely(err2)) { error = err2; goto fail; @@ -4292,10 +4308,6 @@ int do_rmdir(int dfd, struct filename *name) error = PTR_ERR(dentry); if (IS_ERR(dentry)) goto exit3; - if (!dentry->d_inode) { - error = -ENOENT; - goto exit4; - } error = security_path_rmdir(&path, dentry); if (error) goto exit4; @@ -4435,8 +4447,6 @@ int do_unlinkat(int dfd, struct filename *name) if (last.name[last.len]) goto slashes; inode = dentry->d_inode; - if (d_is_negative(dentry)) - goto slashes; ihold(inode); error = security_path_unlink(&path, dentry); if (error)