Received: by 2002:a05:7412:d1aa:b0:fc:a2b0:25d7 with SMTP id ba42csp1050158rdb; Tue, 30 Jan 2024 06:39:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IGSc7xWdnBT11gwC+ytwQJKTbMlEY00BvhM/iXMHXgkzF08B1lrCoaNJlvg/rP3PiuiVjxZ X-Received: by 2002:a17:906:41a:b0:a35:ad04:dcbc with SMTP id d26-20020a170906041a00b00a35ad04dcbcmr3888141eja.32.1706625582321; Tue, 30 Jan 2024 06:39:42 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706625582; cv=pass; d=google.com; s=arc-20160816; b=Jh3FB2yYBTaLtmVYKLK0LJVO3+WeNtZwOJ2Y/bYBMYiJa53MeM3a9FsxLXamtsSUIO K1JO2O6V1HzCSgXkzFUoyL2YJhZgs7Im7LlpZz7sC4uiSYJ7rXPGknycFkVmDNkYFG00 QZZ+JJ37LIbLUGO3se6HdZREGRgSTiYNcIoAYLMiVFOuoSq69c9BhdGe93kddKPnaqU/ zzumuy4FTU2IOGh2Y8v00IlC07vLO8nRnSDoHAGj5yVryPkMRs7CGLhIJPJZDJtBU5DA pCijkMvorSyX5b0EZozNyMjVT+zN0mKtnzDl7l2ciA9XJ9VHdAP8EpLtMOPYYPcQHB6K vPcw== 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=A0CZy8P06Jn9Elf9Vu8DOoWkg/UsMF+U+40xS16wNuE=; fh=v9fVoqng7NuDWV3UJtH8WSO7MU+gnXJamvjYkaV9T+M=; b=kbVFLbLB3YABO3eW4knbyYLCpuwF+K99DFa6lBLs7EpTn6Z48b1LqNP+SNRGp8kKn2 58qPMw0iz6+HhJE5Tt4xhTcVEMqYFxzGca9xqqxF1Nt7CaSEGH8R6Y+KGrSEH5aPkT+R KZHRUVDYO3QqQGKpMKn6DGf47hI9Ob77ILwWl6deANApkDSJ3oJ91bxsJJSG80tRaWXG /YWwsReLapzsvKIhpsRQoUFdwl48ti8EpPNDG5NE1oGwApCtKue0gZQEazyWpqJv1+ck opXGglHruTriRZnMR9O1ILZC3rJgzLIjZ2+fZMeDzmHYlIu9a+SfT801UxXCTC5yGae/ TcdQ== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-44763-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44763-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id a27-20020a170906369b00b00a2edc907039si4605925ejc.496.2024.01.30.06.39.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 06:39:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-44763-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-44763-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44763-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 am.mirrors.kernel.org (Postfix) with ESMTPS id 1AA451F27F68 for ; Tue, 30 Jan 2024 14:39:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 69DD67CF08; Tue, 30 Jan 2024 14:39:33 +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 DEDD27C08A; Tue, 30 Jan 2024 14:39:32 +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=1706625572; cv=none; b=I0KwcYdQazS3s7I8A76XQJIl2z+1oY30f56NJEPBuLRufPvTX8DPaP7CIIJmcIXZFPQDZUg+ReRkiE5zijMM5LuSR8Mem+dtDv8Z76ISQJnAZue3TlnB4L4cRkxa928e9sONeJBkJMFwOvmaNnpMQqPXXDy7hfHnFlQzJzhu7rA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706625572; c=relaxed/simple; bh=wqSBbOtqTFhUjK2zJYRQVHTlBD4gJby8xLhIvN0PEhA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FZoZuhQ3lXQLkqRL+ZCCLIs90QdQ59UzWTOYVPyvTUb4oyFRuilDYTKy2HeoZfx1D0/2bq9h90P8wXwWGa4GO2SHTPYQLyib5fqPL6BTL2gkGpMzwfNP+HnTCgvzkzhICKHwTaeFKGH4dI7OB6FL6/EipnvKiYcio/DdWv2HBik= 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 33BA7C433C7; Tue, 30 Jan 2024 14:39:31 +0000 (UTC) Date: Tue, 30 Jan 2024 09:39:42 -0500 From: Steven Rostedt To: Linus Torvalds Cc: kernel test robot , oe-lkp@lists.linux.dev, lkp@intel.com, linux-kernel@vger.kernel.org, Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Christian Brauner , Al Viro , Ajay Kaher , linux-trace-kernel@vger.kernel.org Subject: Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address Message-ID: <20240130093942.56206ff1@gandalf.local.home> In-Reply-To: References: <202401291043.e62e89dc-oliver.sang@intel.com> <20240129152600.7587d1aa@gandalf.local.home> <20240129172200.1725f01b@gandalf.local.home> <20240129174950.5a17a86c@gandalf.local.home> <20240129193549.265f32c8@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 Tue, 30 Jan 2024 01:12:05 -0800 Linus Torvalds wrote: > On Tue, 30 Jan 2024 at 00:43, Linus Torvalds > wrote: > > > > I'll go back to bed, but I think the fix is something trivial like this: > > Almost. > > > + result = ERR_PTR(ENOENT); > > That needs a '-' in front of the ENOENT, otherwise you have a positive > error number and things go wrong very quickly. > > And that does indeed fix the lookup problem, but you end up with the > same problem later when you do the eventfs_remove_dir(). Again the > eventfs data structure changes, but we don't have a reliable dentry > that we can invalidate. > > The dentry cache is just very good at caching those old dentries, and > the interface for eventfs_create_dir() and eventfs_remove_dir() is > just not great. > > If those did an actual path lookup (like eventfs_create_events_dir() > does), we'd have the dentry, and it's trivial to get from dentry to > eventfs_inode. > > But going the other way is the broken thing because of how the > dentries are just temporary caches. > > I suspect the solution is to make eventfs_create_dir() do the same as > the events directory case does, and actually pin the directory dentry > and save it off. I rather not have the create do that because that happens for every event directory. On my machine that's: # find events -type d | wc -l 2102 And that's regardless if tracefs is mounted or not. And that's how many are also created with every instance creation. And doesn't pinning the dentry also require it to be positive? That is, have a full inode allocated with it? I may try something that will still let me get rid of the ei->dentry. > > Oh well. At least I understand what the problem is. Yep! > Now I'm going to try to go back to sleep. Hope you sleep better than I did. We just bought a new mattress, which felt great in the store, but now after 4 or 5 hours sleeping in it, I wake up with a sore back and have to sleep on the couch. And we bought the most expensive "best" mattress in the store :-p Oh, and NY State law has it that you can't return in once it is delivered. -- Steve