Received: by 2002:a05:7412:5112:b0:fa:6e18:a558 with SMTP id fm18csp6795rdb; Mon, 22 Jan 2024 10:07:01 -0800 (PST) X-Google-Smtp-Source: AGHT+IG9cwrWLA6rD8cNfrgBSxgU7O9Q9evVdCuLroDCvWTfzNMuB1nKYM3JeWdLKNlFAryntSjj X-Received: by 2002:a17:902:f7c9:b0:1d0:c986:8ac9 with SMTP id h9-20020a170902f7c900b001d0c9868ac9mr2054720plw.22.1705946821432; Mon, 22 Jan 2024 10:07:01 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705946821; cv=pass; d=google.com; s=arc-20160816; b=qbYYqHi+JCHcSi+jZwpf4dNitZR6MF3jFpUfhsLrqfU052ETQhbTjy/1Ok+W1wZI3f X9EzfdR8Cz3ZJ8XyYMfmucvcDQNnIDA/qxAL9EfpMM2d6wWK8n8ib6wB4v1CN0Eoxxnb nyDeNRmlaCskEtCbubNbhEm5rIZSYW7Mtd0P8WF/E8naWBAuJvWF4OvbVwg7n9dYCCUm DqlaT02Jft8Uych6yIXHNB9OBMiHpgwQFmYHn759QHdRxp1Y5Cf1y9NtriIRRTp290Kg 4ohwqtmCdFvPDAEQZWidmPUu8EDbKa/tRawO4aJHAvxSI1STXRP9S+bJpZ640uRn3Gvg FKXg== 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=j+QWkdVNYWzvOq56SGdpTy9m02//j7rh4q/ZZOYM9qk=; fh=eQrfJbNGpXhvcsxjnQWplevtYiLN55eX1fP6IAXnSt4=; b=DKMnsie9tGmasc8dp4T/7t0WwkdEGKiHRxC62D0TyDD/ks+Jrqo4Nq2GespmQmfkaQ Pfjxt9wlEQgn3BvYRbJx8Y7QWFh4miP3iC/e/4xQQ8z7IANVc+tYyX8PstiE3pnDZkrQ Sw1RSFbEFadMwlK1NYH45MbNkBkN7/RuCJZaC3gxwYTY42EQ+pU7mL9zd0Q3Uxqsaj8p xXrPPj/3wkfwrb+XyeweDKo9nSmJrC1ROdmCoHkcCyJi2B+Fwi4xlmwn/ZmcS9OHmSo1 WisXnOWAPFJzYY8svHCrp0CNbgEpBb4vCAL1WOnjKW4/NdCcrhOmOG3xZq5ck0E5R661 BWcw== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-33716-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-33716-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id a1-20020a170902ee8100b001d5e9f77cf3si8416405pld.79.2024.01.22.10.07.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 10:07:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-33716-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-33716-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-33716-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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 97F58B291F5 for ; Mon, 22 Jan 2024 17:35:48 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B6EC977F1A; Mon, 22 Jan 2024 16:46:17 +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 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