Received: by 2002:a05:7412:5112:b0:fa:6e18:a558 with SMTP id fm18csp56460rdb; Mon, 22 Jan 2024 11:46:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IF2liUZxQAGtiRXBqnJ3Bkw7gwm6gT2UQdWTgRYrD5K5LrMKtGCtjFfW4QvK3jY369zFPUx X-Received: by 2002:a05:6808:a96:b0:3bd:4cb1:17fe with SMTP id q22-20020a0568080a9600b003bd4cb117femr4814462oij.80.1705952798067; Mon, 22 Jan 2024 11:46:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705952798; cv=pass; d=google.com; s=arc-20160816; b=unCMJzSeY0saNygZWXTDezz7IE99+5tV3bb2r+L0Zk5AE5gzMR0tJnFKLp7kuYT0A/ QJfXReTg0OM0d/IxDR2W8o4d6HtjmVgEgxDeNX2STsqUqg48EBnK7fAN7ayK3x6b1prP UquF/y/bF5ZwLHPg9lj49lsw/biuZ3R5ncCbs2cKJT+0nnovv+QZVdt//LLgjDOsTwTN QGRz5DpzB4ClYpR90Dz1WfDtHoQkuQ6up2BMAb1DZx5rcqhgEhuLJTb3fKWb5hxgoeSL 8QF3iYrQFSD7Pry9A4XG6VgRAskUrZgaMatfQkrSm9JTwA7oscxfoGjjy4vuofFknDJu wKCw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date; bh=c9A8b0DkCzxdvNkRqWHP/lw5UHYld/17yE81c81NHtE=; fh=q1k++DSyA6kA80rEMaWqj/2FiggFQNtzf7HvG1I+Mw4=; b=d6ayP7v+64NDOFSvUvqUvakMqBpxQsGwP0CLqTNMp1KivXW1Kd/C8BgJbHboQqPHyM zwP7oKts4ytOf92XxKrqZzu4YgDtVOXUEgwdiLbkmgc5NJbjP/Tp0fyzRBwYFJ+WGfok dYYTP0oC+tLOtmEYjtOUE0uvW3aGLXL2a+NLbQP6XKIa/x4ENTPDDkkEgM84QRLweph4 4IE4bad9M9vbG06yhWnsAxhlxAxSnLM5CieiT5pFjYsH9XejEOaoelUUDq99VbrkFu5C Ogl4z14pM3FFMgG7Soiudg94MtOcNjM09k0yEJr8tEaqwALwnedX206kQv6OgTYLHCeF 6xjg== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-34080-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-34080-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id y15-20020a05620a0e0f00b0078321c60d62si6142328qkm.762.2024.01.22.11.46.37 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 11:46:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-34080-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-34080-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-34080-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id C85841C26757 for ; Mon, 22 Jan 2024 19:46:37 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B014A482D2; Mon, 22 Jan 2024 19:43:16 +0000 (UTC) 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 3516340BFB for ; Mon, 22 Jan 2024 19:43:16 +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=1705952596; cv=none; b=b8wkiFQpxA9Nf6xnS5/MZ7MplrR8WVmNqWcorbq8PqMkNJxXfXrFaswG+8qrVVBYuBublAH0UAXZ2k/iGDCmjGeQZZvsS8i66TETWkNARmCQFmBqVfCzRQURVr2NGTt07RX3fFjya5GQD58ADnVVPtxVyPasmp5+EZMoFXjnGaw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705952596; c=relaxed/simple; bh=APLT5/CBDphC8mudeBX/2b3K2clsUaZ7Ahhh3sk29lo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KUnrzGb42wYRr7efjgeHr0RyHlSrLHUL/pbt9mudkBbgs+vZ7UTziZDJthMwMZdum2tiAwLCKkOSESYhNbtyuy8QCm5u8cWDwNDJSdJDBKuEJqPAdNAyfPwUcRoVUsIbBzv9s0xNcIPqTZAri/L+V9s7QkSLdP6Qa3pBr4jNAEI= 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 89518C43390; Mon, 22 Jan 2024 19:43:14 +0000 (UTC) Date: Mon, 22 Jan 2024 14:44:43 -0500 From: Steven Rostedt To: Linus Torvalds Cc: Geert Uytterhoeven , Kees Cook , linux-kernel@vger.kernel.org, Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , Christian Brauner , Al Viro , Ajay Kaher Subject: Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files and directories all be the same Message-ID: <20240122144443.0f9cf5b9@gandalf.local.home> In-Reply-To: References: <20240117143548.595884070@goodmis.org> <20240117143810.531966508@goodmis.org> <20240122100630.6a400dd3@gandalf.local.home> <20240122114743.7e46b7cb@gandalf.local.home> X-Mailer: Claws Mail 3.19.1 (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 Mon, 22 Jan 2024 10:19:12 -0800 Linus Torvalds wrote: > On Mon, 22 Jan 2024 at 09:39, Linus Torvalds > wrote: > > > > Actually, why not juist add an inode number to your data structures, > > at least for directories? And just do a static increment on it as they > > get registered? > > > > That avoids the whole issue with possibly leaking kernel address data. > > The 'nlink = 1' thing doesn't seem to make 'find' any happier for this > case, sadly. > > But the inode number in the 'struct eventfs_inode' looks trivial. And > doesn't even grow that structure on 64-bit architectures at least, > because the struct is already 64-bit aligned, and had only one 32-bit > entry at the end. > > On 32-bit architectures the structure size grows, but I'm not sure the > allocation size grows. Our kmalloc() is quantized at odd numbers. > > IOW, this trivial patch seems to be much safer than worrying about > some pointer exposure. I originally wanted to avoid the addition of the 4 bytes, but your comment about it not making a difference on 64bit due to alignment makes sense. Slightly different version below. -- Steve diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c index 6795fda2af19..6b211522a13e 100644 --- a/fs/tracefs/event_inode.c +++ b/fs/tracefs/event_inode.c @@ -34,7 +34,15 @@ static DEFINE_MUTEX(eventfs_mutex); /* Choose something "unique" ;-) */ #define EVENTFS_FILE_INODE_INO 0x12c4e37 -#define EVENTFS_DIR_INODE_INO 0x134b2f5 + +/* Just try to make something consistent and unique */ +static int eventfs_dir_ino(struct eventfs_inode *ei) +{ + if (!ei->ino) + ei->ino = get_next_ino(); + + return ei->ino; +} /* * The eventfs_inode (ei) itself is protected by SRCU. It is released from @@ -396,7 +404,7 @@ static struct dentry *create_dir(struct eventfs_inode *ei, struct dentry *parent inode->i_fop = &eventfs_file_operations; /* All directories will have the same inode number */ - inode->i_ino = EVENTFS_DIR_INODE_INO; + inode->i_ino = eventfs_dir_ino(ei); ti = get_tracefs(inode); ti->flags |= TRACEFS_EVENT_INODE; @@ -802,7 +810,7 @@ static int eventfs_iterate(struct file *file, struct dir_context *ctx) name = ei_child->name; - ino = EVENTFS_DIR_INODE_INO; + ino = eventfs_dir_ino(ei_child); if (!dir_emit(ctx, name, strlen(name), ino, DT_DIR)) goto out_dec; diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h index 12b7d0150ae9..1a574d306ea9 100644 --- a/fs/tracefs/internal.h +++ b/fs/tracefs/internal.h @@ -64,6 +64,7 @@ struct eventfs_inode { struct llist_node llist; struct rcu_head rcu; }; + unsigned int ino; unsigned int is_freed:1; unsigned int is_events:1; unsigned int nr_entries:30;