Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp1298955pxa; Fri, 28 Aug 2020 08:57:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4u3TnWSiS3XjnJwsnFqcIsBb08g04wDWzkiTbsF/nwj4CYAhPodoyJMV2Y4u9sUjiWB6S X-Received: by 2002:a17:906:7715:: with SMTP id q21mr2484910ejm.251.1598630235471; Fri, 28 Aug 2020 08:57:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598630235; cv=none; d=google.com; s=arc-20160816; b=vn/zvfu4jC5pHaJK7WhwLe4yElp+hK9BKnWaPjtk8O0TRnrJYUK8g9JasFd+PEnAYV CeEAU11RcesAK+Ui+D3BpluVGF8Nns+B42RktBeFSrm8tb97tyBG6GemtNLnEiIQCzSf 3RvJKs72pBc3V7ehusW0og6ROML4wsbOVWmGJDNsPH0gqg+UC52B589QbAe10Bg2yitI 0eKhSim0NIKddmKh7tNn5mnB5wkr2dRjJlXcomevATpVjKabZcmkpaww7Tfz7FqjAWQ1 DV57lkhWJyxFpX1jA8UvrDbtI8/YNIS2FczGI8sUwzEDExKmDhRrytsT3pB2SN9TLTGJ +KRw== 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=+v1x5gpjq2ajBHuyKkd1qvvtjZcY/E9Y8Ws0PpBuN4k=; b=AYMdhQCEtaP3GcWXPGvkZosFgONVfk27JmOpNvkCcBoCmyquMq/H3i4FBu3n2M2EEC ZbXhn+26ZWw4BCRyvfiX60F3CXvp+1Zjc09XGX3OBLeLrrs0FYfvJpkRibEfzoCSUKvy HAOxE6xdR8e4AxZFkXT5p5C+A9zCHGVRCwPMcbnrbyjxPQnpZ15OjfOcEhEkydBvVTzi 2ZBXxBouFhYQSjnbtTZiWnhVg3PhaG9WLI8prpEZIXsyzH7YLxpKFqXTzphaPR44RAFl dNVyFQd00KFdfdc4P7WJxT0M3PeQjXQEbpsASrIHSm4+mMqFvv4B0i0K4n0/TH/HXEnr xDxw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ha13si993504ejb.211.2020.08.28.08.56.51; Fri, 28 Aug 2020 08:57:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726804AbgH1Pzk (ORCPT + 99 others); Fri, 28 Aug 2020 11:55:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725979AbgH1Pzi (ORCPT ); Fri, 28 Aug 2020 11:55:38 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40C67C06121B; Fri, 28 Aug 2020 08:55:38 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBgix-006DmM-Ca; Fri, 28 Aug 2020 15:55:31 +0000 Date: Fri, 28 Aug 2020 16:55:31 +0100 From: Al Viro To: Konstantin Komarov Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, pali@kernel.org, dsterba@suse.cz, aaptel@suse.com, willy@infradead.org, rdunlap@infradead.org, joe@perches.com, mark@harmstone.com Subject: Re: [PATCH v3 04/10] fs/ntfs3: Add file operations and implementation Message-ID: <20200828155531.GK1236603@ZenIV.linux.org.uk> References: <20200828143938.102889-1-almaz.alexandrovich@paragon-software.com> <20200828143938.102889-5-almaz.alexandrovich@paragon-software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200828143938.102889-5-almaz.alexandrovich@paragon-software.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 28, 2020 at 07:39:32AM -0700, Konstantin Komarov wrote: > +static int ntfs_atomic_open(struct inode *dir, struct dentry *dentry, > + struct file *file, u32 flags, umode_t mode) > +{ > + int err; > + bool excl = !!(flags & O_EXCL); > + struct inode *inode; > + struct ntfs_fnd *fnd = NULL; > + struct ntfs_inode *ni = ntfs_i(dir); > + > + ni_lock(ni); > + > + if (d_in_lookup(dentry)) { > + struct dentry *d; > + > + fnd = fnd_get(&ntfs_i(dir)->dir); > + if (!fnd) { > + err = -ENOMEM; > + goto out; > + } > + > + d = __ntfs_lookup(dir, dentry, fnd); > + if (IS_ERR(d)) { > + err = PTR_ERR(d); > + d = NULL; > + goto out1; > + } > + > + if (d) > + dentry = d; > + > + if (d_really_is_positive(dentry)) { > + if (file->f_mode & FMODE_OPENED) { How do we get FMODE_OPENED here? > + dput(d); > + err = 0; > + } else > + err = finish_no_open(file, d); > + goto out1; > + } > + WARN_ON(d); > + } > + > + if (!(flags & O_CREAT)) { > + err = -ENOENT; > + goto out1; > + } Just return finish_no_open() in that case. And let the caller handle that. > + err = ntfs_create_inode(dir, dentry, file, mode, 0, NULL, 0, excl, fnd, > + &inode); > + > +out1: > + fnd_put(fnd); > +out: > + ni_unlock(ni); > + > + return err; > +} BTW, what's the point of that ni_lock() here? d_in_lookup() is stable regardless of that and any attempts to create something in the parent are serialized by ->i_rwsem. If you want it around the actual file creation, why not take it just there, and replace the open-coded ntfs_lookup() with the call of the real thing? As in if (d_in_lookup(dentry)) { d = ntfs_lookup(....); if (IS_ERR(d)) return d; if (d) dentry = d; } if (!(flags & O_CREAT) || d_really_is_positive(dentry)) return finish_no_open(file, d); /* deal with creation of file */ ni_lock(...); ....