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 E81C3C2BD09 for ; Fri, 12 Jul 2024 21:23:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BE386B008C; Fri, 12 Jul 2024 17:23:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1484A6B0092; Fri, 12 Jul 2024 17:23:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F29D46B0093; Fri, 12 Jul 2024 17:23:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D550E6B008C for ; Fri, 12 Jul 2024 17:23:44 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6A75E1C0626 for ; Fri, 12 Jul 2024 21:23:44 +0000 (UTC) X-FDA: 82332377568.26.067747A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id 888EA100019 for ; Fri, 12 Jul 2024 21:23:42 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OEHnYT68; spf=pass (imf05.hostedemail.com: domain of vbabka@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=vbabka@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720819405; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6AA0jV9xqgF78dDIn62PA2RWC2BKHKZ/7MbMDEPtW2Q=; b=HbYwlzU3RSZjaXgk3pUQRkyN1TYfQ9tGe0/ZzRwU7KMTQ/N7VIZXjx71BzB5HB6gjqDv8c kGrHnnPwRmUSL1fI/vtgwd/H6yt28YYcd2gSNJ8fcdujo+bxxA+As4Ll/PLJFTeryDOsoM hdDAM3ZyMPTVkHlLh+hb+erxAbCc7e8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OEHnYT68; spf=pass (imf05.hostedemail.com: domain of vbabka@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=vbabka@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720819405; a=rsa-sha256; cv=none; b=hviTNtlQSpwpVB0DUOjkhlkYNei4nB3UTii0/PINeB2qhM6U53AgdLGozNlsQfNo4YycTp h68XAFPsnteK08wVBmDlS9cIrAqLSLGOU8lJGpZYQsCG1ut3igXny6oHWQ6HDMc49PgHFC Jbx2TsoZpjAzzGBJv+d1Aywz3lckdC4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 617B061A25; Fri, 12 Jul 2024 21:23:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 518C1C32782; Fri, 12 Jul 2024 21:23:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720819421; bh=H1Gy57KzCc3eyUgQrW961qMwxBDKdGrxcrwV7mZ3ATc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=OEHnYT687xB2lLXSA8JO080M++w9JlX4rQJROadXzckPsmY879R67LOENSXyoP5yR fdYI+OLtpyx+6mllVilQK8Liqb4+X1WiXHHSbzrZiTfcgMwvUJgNEVWwMKOLdnHALm 4Yl1Uwxot0lxLXBvGvVMaw9KG2Vsut6sHGuly2wEv/kEOOzR5ilyRkStEhx9uzbFzz FTY5V6BaJfJnbXTXsy3SNG1WRp0etG9jC0ydE58saotaeTRiVRFjC3N/T68lgj6xro JAJ6HuJTkVT0tFhsbnOY+ipDusxLH7q/e49DuUkTiSz9EBPhkuJhIdc8Wp/MqDfhtV NVmRSCR8XZPJQ== Message-ID: Date: Fri, 12 Jul 2024 23:23:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Possible circular dependency between i_data_sem and folio lock in ext4 filesystem Content-Language: en-US To: Byungchul Park , 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 References: <20240711153846.GG10452@mit.edu> <20240712044420.GA62198@system.software.com> <20240712053150.GA68384@system.software.com> From: "Vlastimil Babka (SUSE)" In-Reply-To: <20240712053150.GA68384@system.software.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 888EA100019 X-Stat-Signature: sui7qgg8tn4iz5csyow9cp5wtcefh8d1 X-HE-Tag: 1720819422-272720 X-HE-Meta: U2FsdGVkX1/hX9j8hk9B/dS1iegD8l2vWKt7PPSM2NODU08HFC2hwCxNGh7CljK5WKSpxvM9P/Rzy532ertvBcxhFyJouToIGO1XP7T+jRUvFHB8K5u9hC0qitNfNJLAQaaB6m1qo4kxlZea/Xz5xYqGZY7iitNu3zwUvZYaPPx4N1/LjPZrmnNYw2asVdFF/ldFPZq1VhVONMi35ZFuPfITXcn1iei3zWeh+E83i3T9Sp5uGlMqtPIz2znzVWVPrAmwFGNt+G4XmU/Hsu3/vFQADibOfFmwCmgmnFw9uFF+xQ0uFjfqjaXeAwGpn8rmCkg6cDCYWCpA4qRU4qEaJ/pzaSkVr3AB2SozwZzIbkN33vZ7zVlM/lQ3C14KKDkfsGOLS1wwsBydM3kP8XzYeBYu4V2tzbtOfxj1L3mqzddQ0hQT+DZi6C/88U2iXjVH1lKttvIxyAr0eoR8UmgoNQznMGX7S+2SDSKIkB4UvfV9AgPMJdFedc2iVdUkaIGmSmtGURWtIxK+BJ/YzlSSgVWeCKqxSpSRETpLpbG0dC1ErBVL6phTs7in9zPN/2UW9GP2hheYkwoJ5n3LDHUXKFBYNHiviTll+GcwVfVEF/SyOR5tU+luU5rds5bz5UUxphg3W2a/vHt4tU5WP0DM8taHnx/39Z7nwidmftyapxNcGv5U6fHSNp3tpUyYimBVUcnyYIHWUBaKkvjUIp1CvPPNxQbhcj7/M5ObP+QZiI9JnDoyHOAx0a2UsvcJVpBd+npMCWWTG3RhKL3dlBQg7D/qPKwtyxeYutaW+6RNAZciBoRgAsILsOr6bFJAltMevDORzgFN2ZVeipfyxhiLhPj+WRdUvoXeV/Sp94sdsCQ+B1VZGGJgiD0QzHXb9FkWEsOkZpHkxeUIHBHdObrlApr581IF/yGriSwEC2CrqEnJq++1xVp/7TzNTa1vOjon8SePBT5SxhvPaeqsBev OQ9xBq/p 7SdyPJHYKdnPOz5kRritcKxCO4Z1HZztQcHWhhASNQJJJF4Scaa/Tko1k3ynB8ER+6Fu9XJJp1Y/ut5HnTze4bdAZRZ8RnyMJfXlELBJS4IdaPBpU/npY5SIie02hvQNBncXSqTr9olBwZTA3LsmeUpES5Z24nOzJEzErIfZdmNCgXJ26OKHR9wiyVSq0RYSvDdV/CZWOLatL1LffaWeUrWDkMNooZ77PYR65NglhM8DNainZcmIvt7Wqu86GoFoE54TlIad0ARLWuwH0LCRoK8PkumROfj2t5eZ5/s6QOv5U31QFuvw7YfSjvXkPghA/TZykX4CX3IFDY/Y0zYHOo3kB5dqooR5S2gs6 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 7/12/24 7:31 AM, Byungchul Park wrote: > On Fri, Jul 12, 2024 at 01:44:20PM +0900, Byungchul Park wrote: >> >> 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. enabling means building with CONFIG_DEPT right? >> > 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 doubt anyone will object making struct page larger for a non-production debugging config option, which AFAIU DEPT is, i.e. in the same area as LOCKDEP or KASAN etc... I can see at least KMSAN already adds some fields to struct page already. >> I already said several times. Doesn't consume struct page. > > Sorry for that. I've changed the code so the current version consumes > it by about two words if enabled. I can place it to page_ext as before > if needed. page_ext is useful if you have a debugging feature that can be compiled in but adds no overhead (memory, nor cpu thanks to static keys) unless enabled on boot time, i.e. page_owner... so for DEPT it seems it would be an unnecessary complication. > Byungchul >