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 4462A3FB3B for ; Mon, 22 Jan 2024 16:46: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=1705941977; cv=none; b=qv2hzwpEf5XKXlsSZMPbo/dcw45NFJpkq4NoF1JPqnFdTjuEdWEWDVp/kvPAgrsNa1aQGtuCgjPoGAQHn33Qq0AX3i88peDoujvHdgY4vEG7ju/PSMmcWEB+Xq71Dd+XNkBFyBzug703ZPpaQjRg3v9zfYP1WMV7SGKlrA0tDg4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705941977; c=relaxed/simple; bh=Ky6TuzpBuK8teEOWfhPPInB3LvoxxinV7RLy7GUKkC0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FNhvCF97AVlSyBsR1Z8lnyWzax2JDVFf70j5jwtnwbCRhqxmgskbD1RWtLxyEcfQDYZfZZC0+kEVCCCZ3ds1hNOkwR0tpCGCZciVH25sbxqCdIqdRP29WIqlrcmvh+mBwUPMOWWdPT+xjcC7qbvKJHaBjczYaDa/Z6xqPrV6h9s= 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 3FA35C43390; Mon, 22 Jan 2024 16:46:15 +0000 (UTC) Date: Mon, 22 Jan 2024 11:47:43 -0500 From: Steven Rostedt To: Geert Uytterhoeven , Linus Torvalds Cc: 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: <20240122114743.7e46b7cb@gandalf.local.home> In-Reply-To: References: <20240117143548.595884070@goodmis.org> <20240117143810.531966508@goodmis.org> <20240122100630.6a400dd3@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 17:23:29 +0100 Geert Uytterhoeven wrote: > > +/* Just try to make something consistent and unique */ > > +static int eventfs_dir_ino(struct event_inode *ei, const char *name) > > eventfs_inode Heh, I fixed that, but must have created the patch before catching it. :-/ > > > +{ > > + unsigned long sip = (unsigned long)ei; > > + > > + sip += strhash(name) + EVENTFS_DIR_INODE_INO; > > + sip = siphash_1u32((int)sip, &inode_key); > > + > > + /* keep it positive */ > > + return sip & ((1U << 31) - 1); > > +} > > + > > /* > > * The eventfs_inode (ei) itself is protected by SRCU. It is released from > > * its parent's list and will have is_freed set (under eventfs_mutex). > > Thanks, find is happy now the directories have different inode numbers. > The files still have identical inodes numbers, I hope that doesn't cause > any issues... Well, I guess I should ask Linus. Linus, I can add this patch to make sure directory inodes are unique, as it causes a regression in find, but keep the file inodes the same. I can see how the issue is with directories, as find (and probably other applications) check for invalid directory loops. But with files, there should be no issue. It could just think it's another hard link. The question I have is, should this just make dir inodes unique and keep files the same, as this patch does? Or make all inodes unique? This is assuming that my algorithm is good enough to not leak kernel addresses. I could also chop it down to 28 bits, as that's probably still "good enough" to keep things unique. return sip & ((1U << 28) - 1); That would make it even harder to unhash to get an address. -- Steve