Received: by 2002:a05:7412:d1aa:b0:fc:a2b0:25d7 with SMTP id ba42csp53727rdb; Sun, 28 Jan 2024 13:19:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IEgUfpDupv6MgIRQq8U0yr0iqcMSCFL1haVSxgky+9Yqmhtom8q5DTfiX7lCvPUiVGhnZU5 X-Received: by 2002:a05:620a:3888:b0:783:bd57:a058 with SMTP id qp8-20020a05620a388800b00783bd57a058mr4004144qkn.152.1706476787703; Sun, 28 Jan 2024 13:19:47 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706476787; cv=pass; d=google.com; s=arc-20160816; b=lToJou34IlnL+nXlXfMmQmcOSdHkP/jy4jkyjshHVmRfBIxqANHdCx6/eqIF2Y4/rL 07xa/XUU39iP63zouYLvL323TF/G6lH20lvVifMF7piAw0jdyx/BjJaG6268GXzH54uJ wgf6VBTm8WfWNNkNzGN8T2oVx1cXViKG/Z4oFVo/2lJvKZxXlNB+EXaOmpa2U+m4KM9L brWyiqfgjSJVGw1s+ImubBSTnCI9ODhoIl11xOy1fvUOJVUnHLK6TCLtT6RSzRaxJBSB +6r2F78pN5Qv8xpxuGY19bemY2e6i8rMw+MmeliyPKJF6HSPraCutoW43tkqWqWIoxRE puvg== 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=kPtPy84QUUnk2gdbX4h2ZQzHhPF9tY5czUFRJ14g+2w=; fh=+NHEOwOI8sgHa/emZ3nIKC4IhKoRFLn6O7wLrfs7tlM=; b=VtK5fUKs8scpFPvq5w8oLT38oQ3fsqoo43INHwER8+5QIMB6B/RxoeNvMwM+5pcmDh iYMDxCJBLpPHyQDGigcScKke13CvwNm0sCCeDL+NF1ejnLRxtwalV/icvgYmpv+15bKx dYRbnbz8MqxBuFvAyK0vnRBPKyaxDWXdmYUylvnlwVTEEhnacbAteU5MiY8/7qFZolIM mvALQgF+CJDqzl4qKgAgYhn8Gwp1qMLo2N3b4pSpO0r8fbtLkqQBqlMGTvov0p/dIf3B bItA/kd5guk+Mt1bXyy4uMVFKHXJ8lmQ2cGb465Jd/zKi5igZKRoNPbKrxgksyOeNI37 UQEw== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-41959-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-41959-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 vu15-20020a05620a560f00b0078324088f06si451270qkn.686.2024.01.28.13.19.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Jan 2024 13:19:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-41959-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-41959-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-41959-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 6EDA61C21886 for ; Sun, 28 Jan 2024 21:19:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 109163C474; Sun, 28 Jan 2024 21:19:39 +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 8150D3C068; Sun, 28 Jan 2024 21:19:38 +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=1706476778; cv=none; b=Ts4QLZZROPfuP0rGx3DbDMX1HudeN9ALJIqf+n0qw7rmR6cXBBR+MSycUqVbRi4avn7BJ6NDCQNk6JIQzVpLDvoTV4yauTPQedX7hPqzA69VuCAkwCmepHRfr3uKIhaMrn6ZldHzlhou413mNmECi7bhDOhodAdq0O+4H5w9dBs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706476778; c=relaxed/simple; bh=GUpw5izvhyZ2h4yrNEtqr/QWSWIXNewKupdAHYrEHOI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=unKfjX1I17+Seb0Y2yb+2oUiIXYFiDxhbWwW1Hb943faubJ5Jaf0EXM535gl+L1h32OKIHNYhZFPR4nUL/Yqt93I1GnxxovsDz14XxVGd5WrjlmQwvwu1Gh09rSbGyZq89wlN6xDDwzBU2/kBLMDvQo9ObTSxzIDL0CLuzA/zII= 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 C7446C433F1; Sun, 28 Jan 2024 21:19:36 +0000 (UTC) Date: Sun, 28 Jan 2024 16:19:35 -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: <20240128161935.417d36b3@rorschach.local.home> In-Reply-To: References: <20240126150209.367ff402@gandalf.local.home> <20240126162626.31d90da9@gandalf.local.home> <20240128151542.6efa2118@rorschach.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 Sun, 28 Jan 2024 12:53:31 -0800 Linus Torvalds wrote: > Honestly, you should just *always* do refcounting. No "free after RCU > delay" as an alternative. Just refcount it. > > Now, the RCU delay may be needed if the lookup of said structure > happens under RCU, but no, saying "I use SRCU to make sure the > lifetime is at least X" is just broken. > > The refcount is what gives the lifetime. Any form of RCU-delaying > should then be purely about non-refcounting RCU lookups that may > happen as the thing is dying (and said lookup should *look* at the > refcount and say "oh, this is dead, I'm not returning this". The deleting of the ei is done outside the VFS logic. I use SRCU to synchronize looking at the ei children in the lookup. On deletion, I grab the eventfs_mutex, set ei->is_freed and then wait for SRCU to finish before freeing. The lookup checks ei->is_freed and doesn't do anything if set, but most that logic is under the SRCU, which is what I want to make sure is finished before the ei is deleted. Hmm, I still need the logic for iput(), as dentry->d_fsdata can still access the ei. That's where I need to have the ref counters. For a lookup, I need to up the ref count when I create a new inode for the ei or its children. Then in the iput() I decrement the ei ref count. I can only free the ei if the ref count is zero. The ref count is for knowing if an ei is referenced by a dentry->d_fsdata, and the SRCU is to make sure there's no lookups accessing an ei. -- Steve