From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C683AC2BD09 for ; Fri, 12 Jul 2024 04:44:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4717A6B0096; Fri, 12 Jul 2024 00:44:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 421E26B0099; Fri, 12 Jul 2024 00:44:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3107E6B009C; Fri, 12 Jul 2024 00:44:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 14DA26B0096 for ; Fri, 12 Jul 2024 00:44:31 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C3814A091A for ; Fri, 12 Jul 2024 04:44:30 +0000 (UTC) X-FDA: 82329859500.01.06013E9 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf08.hostedemail.com (Postfix) with ESMTP id 22ADF160017 for ; Fri, 12 Jul 2024 04:44:27 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720759453; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y9eSUdmPxSzwq1qPNPVwmeu5OUaHu9v49soR/HZhqbs=; b=RYPwyX8OCR8x5goBWa2ENj6H+ABw+vuHaV8ug/8vhHyGkDAvgezr1a0D3Wf6S0JxcNP8+v DkFBuA+YtDHYP29dfIQHEkYKgtDbUcfgeB3CREfh6TUAUOL7W3tKei7yxPk8tgNqgUqZHt 9v3EdAqsa4IYv1M7w6Aen0tPSdaR0RE= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720759453; a=rsa-sha256; cv=none; b=iTKJRGPPd83DKtQGcDgjJZMkN9BE2eFIlI0NnZYQBT0Kxi9LlL7DsCq/Rtoi/xjJNAWu7R cVdtZ4qzaxjJ2qnwxQPavS1u6l5yOji4CfKZeAkYbflmLI/yuXWqqU3w3faSfvsyp0+qT3 VBYvH9vBL0bEE7oSi/G6iYwCqASBO2c= X-AuditID: a67dfc5b-3c9ff7000001d7ae-32-6690b4a9ed96 Date: Fri, 12 Jul 2024 13:44:20 +0900 From: Byungchul Park To: Theodore Ts'o Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Linux Memory Management List , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, max.byungchul.park@sk.com, Gwan-gyeong Mun , kernel_team@skhynix.com Subject: Re: Possible circular dependency between i_data_sem and folio lock in ext4 filesystem Message-ID: <20240712044420.GA62198@system.software.com> References: <20240711153846.GG10452@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240711153846.GG10452@mit.edu> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsXC9ZZnke7KLRPSDGbOU7KY2GNgcfH1HyaL mfPusFns2XuSxeLemv+sFq09P9kd2Dx2zrrL7rF4z0smj02fJrF7NJ05yuzxeZNcAGsUl01K ak5mWWqRvl0CV0bvvG62gqmSFQ8+/2RqYDwr3MXIySEhYCKx8s9bVhh7/upnYDaLgKrErVWf 2EFsNgF1iRs3fjKD2CICihK3Wr4A2VwczAINTBI9n7cxgiSEBRIkXsw8DWbzClhIbDr4AaxZ SKBY4tP3VcwQcUGJkzOfsIDYzAJaEjf+vWTqYuQAsqUllv/jAAlzCuhKHDvdD1YuKqAscWDb cSaQXRICG9gkzhyezwJxqKTEwRU3WCYwCsxCMnYWkrGzEMYuYGRexSiUmVeWm5iZY6KXUZmX WaGXnJ+7iREY0Mtq/0TvYPx0IfgQowAHoxIPb8D1/jQh1sSy4srcQ4wSHMxKIryeZ4FCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEeY2+lacICaQnlqRmp6YWpBbBZJk4OKUaGKNuthtOzPbmFJ3s PVUo99HDHcfv6k+06zhwOv3ZW9NJsw458JceebEj5v2JZS+nKiu7/Ws83P5RmPGW0Y1yQe77 nWyHNh9Ujzydsvcy+0HBIz+OFDB0LfjbNVFZ69sF8wfyF47ttqr28N+VtSTW9i0nw2WL3X9N 1fSe1lxZ+XB3+wM9a9Efv1SVWIozEg21mIuKEwErOwYXZAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsXC5WfdrLtyy4Q0g3O7xSwm9hhYXHz9h8ni 8NyTrBYz591hs9iz9ySLxb01/1ktZrTlWbT2/GR34PDYOesuu8fiPS+ZPDZ9msTu0XTmKLPH t9seHotffGDy+LxJLoA9issmJTUnsyy1SN8ugSujd143W8FUyYoHn38yNTCeFe5i5OSQEDCR mL/6GSuIzSKgKnFr1Sd2EJtNQF3ixo2fzCC2iICixK2WL0A2FwezQAOTRM/nbYwgCWGBBIkX M0+D2bwCFhKbDn4AaxYSKJb49H0VM0RcUOLkzCcsIDazgJbEjX8vmboYOYBsaYnl/zhAwpwC uhLHTveDlYsKKEsc2HacaQIj7ywk3bOQdM9C6F7AyLyKUSQzryw3MTPHVK84O6MyL7NCLzk/ dxMjMFyX1f6ZuIPxy2X3Q4wCHIxKPLwB1/vThFgTy4orcw8xSnAwK4nwep4FCvGmJFZWpRbl xxeV5qQWH2KU5mBREuf1Ck9NEBJITyxJzU5NLUgtgskycXBKNTDulfI6FJlyo+X/0Y2tRod1 hY7xnpf3iK45VRuX89QtQawpRtVBPrpC+C6n7VK9+MXmmZs+6JwWc3TdtPdMyfqDKS/LdFTO i4v6maat+PEo7lSY/1XBH38KbtkULnZw1nFttSv0WDZH5Nnm5arsB8T+iNt6bA4yuCvxv+72 FAbPJ8ttUg79iFViKc5INNRiLipOBAC+MjDuUwIAAA== X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 22ADF160017 X-Stat-Signature: 5ze7geyf4su6ojs656o9otfck6f5c1o1 X-HE-Tag: 1720759467-769773 X-HE-Meta: U2FsdGVkX1/YeYw4/Di9txN28f7Y29UpmFjFAzera9AOsWSa7iQqw5lUwjjGpO8P9Qx3cdn4s4ShrvOX+P9LqwMm93R0kiLRqSynnGoRHMmHh3KSXUkXdgsU0O1y2MKL+SSMRIcfm0pC03pM5WXQmJ8f1eJKXfuoSCKjBLcxbk9QlnSb2fproeTNSyHW615lwHiw+qJxkCkhkBiUjUxUe+0PGF0CvZzvJ7Jt7OkjqIHqpZkAupepcCjAdV9a1A1F2q4JBzvbMtiGP7EMR2GUrwpwMUq5yYdJ2FKvhfqlf3Q4Y51QgQtwpAFIf8CSW1oJkbMSDBAhXpV6zv5LSRVojtUhcS/ZAQ/kdZeFOGt8MCTOFEs9FBt91o3H11BY9Zn18+alczY3MeqAbzhb69CstK9hvw2VErMAUhzEVDEG+WLvfouhdzm0dNYkLiS2CDvbU/aXGBYNFDcglsiraFuYlUr7/26cOnDqds7XyG6YLW6lAdjJVbNR5M2WHXvgaFupqV4N/vIvA3idYXCfsKMDro9VFh722MmWsxo9ZX+MyuMHJs9OMMqHh8m4nLDxhyBPvbFbvqCXyR+cZfELvLj2uSYxY1mogNjOQnYjuBZyBKcWAoueGIXZJ9sbmIl/1DOzDHZ0sfWisiZDXyRtMO1nEQJGRXaoIU/9NTdbFcD2Li+p8oUTbCNfEArzMhOU10ILT0p7yjQBJCOTtx3NxQrOqX8mqCemrkImpy53e4girFoAKB4owu3cr0lfxgqDMfiBMcMF4Sm7mUYzOe8SWCsj9TNHGZDiMTL/tL18Muceuz+3jnSu9wdKe+E0/b0PyeG7cXiQkZoeOEiHqoDO5MwFTp8N0k9OjRPN80krpV8lc6FsXUqSyTe+2xhRT/Ls9UX66XquuGsLe+lW9tDhEvqfjuH090xHkPHCrDvIG86lg4qCSdMvmtp1b9uJeH7Q4LvXMS8DLxaYjUlppL/L77b A8MOUhKG lynF4j6z11X1FpJ2u6ya01BDu3dSOdDCo585FOccNAR1CLYCBePSvTM9B4g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jul 11, 2024 at 11:38:46AM -0400, Theodore Ts'o wrote: > On Thu, Jul 11, 2024 at 09:07:53PM +0900, Hyeonggon Yoo wrote: > > Hi folks, > > > > Byungchul, Gwan-gyeong and I are investigating possible circular > > dependency reported by a dependency tracker named DEPT [1], which is > > able to report possible circular dependencies involving folio locks > > and other forms of dependencies that are not locks (i.e., wait for > > completion). > > > > Below are two similar reports from DEPT where one context takes > > i_data_sem and then folio lock in ext4_map_blocks(), while the other > > context takes folio lock and then i_data_sem during processing of > > pwrite64() system calls. We're reaching out due to a lack of > > understanding of ext4 and file system internals. > > > > The points in question are: > > > > - Can the two contexts actually create a dependency between each other > > in ext4? In other words, do their uses of folio lock make them belong > > to the same lock classes? > > No. > > > - Are there any locking rules in ext4 that ensure these two contexts > > will never be considered as the same lock class? > > It's inherent is the code path. In one of the stack traces, we are > using the page cache for the bitmap allocation block (in other words, a metadata > block). In the other stack trace, the page cache belongs to a regular > file (in other words, a data block). > > So this is a false positive with DEPT, which has always been one of > the reasons why I've been dubious about the value of DEPT in terms of > potential for make-work for mantainer once automated systems like > syzbot try to blindly use and it results in huge numbers of false > positive reports that we then have to work through as an unfunded > mandate. What a funny guy... He did neither 1) insisting it's a bug in your code nor 3) insisting DEPT is a great tool, but just asking if there's any locking rules based on the *different acqusition order* between folio lock and i_data_sem that he observed anyway. I don't think you are a guy who introduces bugs, but the thing is it's hard to find a *document* describing locking rules. Anyone could get fairly curious about the different acquisition order. It's an open source project. You are responsible for appropriate document as well. I don't understand why you act to DEPT like that by the way. You don't have to becasue: 1. I added the *EXPERIMENTAL* tag in Kconfig as you suggested, which will prevent autotesting until it's considered stable. However, the report from DEPT can be a good hint to someone. 2. DEPT can locate code where needs to be documented even if it's not a real bug. It could even help better documentation. DEPT hurts neither code nor performance unless enabling it. > If you want to add lock annotations into the struct page or even > struct folio, I cordially invite you to try running that by the mm > developers, who will probably tell you why that is a terrible idea > since it bloats a critical data structure. I already said several times. Doesn't consume struct page. Byungchul > Cheers, > > - Ted