From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3B4144375; Sun, 28 Jan 2024 22:51:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706482274; cv=none; b=QyojlVi31g1B+I7KhRRiND8wdzWT5rzXXFiaYH35Xb/sLSU5NsWMVHRh/SZM7yW6VRr6gQux7BON73z0CTZUs6TvhpSNzy0PypuUMZ0hxyTV5OwSHFdzPyU+axX6ee7pepICNVRf2R+lvPTyV4TIlVzFfevRNSo43cAIXD9off4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706482274; c=relaxed/simple; bh=RdgePR0KOVMfuGg1U7Yj893/E1ek6ofqOQ4gEhYMix4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=PtVvTkwB4oM/danbXOZpErjKooSjoJb94CPFYp8ZAh6HUpzTzrU7uevRobsvDk4csliStujE6y8WnkmdsE800nNyXXLyQfnccfb000ikECs6ViDlVnNfT9qVR32HRLNKoY+qYd8DVsartIL8/Z7cRCKVjXCjApTeTXouzap11w0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1692FC433C7; Sun, 28 Jan 2024 22:51:12 +0000 (UTC) Date: Sun, 28 Jan 2024 17:51:11 -0500 From: Steven Rostedt To: Linus Torvalds Cc: Masami Hiramatsu , Mathieu Desnoyers , LKML , Linux Trace Devel , Christian Brauner , Ajay Kaher , Geert Uytterhoeven , linux-fsdevel Subject: Re: [PATCH] eventfs: Have inodes have unique inode numbers Message-ID: <20240128175111.69f8b973@rorschach.local.home> In-Reply-To: References: <20240126150209.367ff402@gandalf.local.home> <20240126162626.31d90da9@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 27 Jan 2024 13:47:32 -0800 Linus Torvalds wrote: > There are tons of other 'ei->dentry' uses, and I didn't look at those. > Baby steps. But this *seems* like an obvious cleanup, and many small > obvious cleanups later and perhaps the 'ei->dentry' pointer (and the > '->d_children[]' array) can eventually go away. They should all be > entirely useless - there's really no reason for a filesystem to hold > on to back-pointers of dentries. I was working on getting rid of ei->dentry, but then I hit: void eventfs_remove_dir(struct eventfs_inode *ei) { struct dentry *dentry; if (!ei) return; mutex_lock(&eventfs_mutex); dentry = ei->dentry; eventfs_remove_rec(ei, 0); mutex_unlock(&eventfs_mutex); /* * If any of the ei children has a dentry, then the ei itself * must have a dentry. */ if (dentry) simple_recursive_removal(dentry, NULL); } Where it deletes the all the existing dentries in a tree. Is this a valid place to keep ei->dentry? I believe this is what makes the directory disappear from the user's view. But the ei->dentry is there to know that it is in the user's view to begin with. -- Steve