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 14458C3DA59 for ; Mon, 15 Jul 2024 10:32:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E5546B00A0; Mon, 15 Jul 2024 06:32:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 794D06B00A2; Mon, 15 Jul 2024 06:32:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65C2C6B00A4; Mon, 15 Jul 2024 06:32:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 47D596B00A0 for ; Mon, 15 Jul 2024 06:32:16 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F066841432 for ; Mon, 15 Jul 2024 10:32:15 +0000 (UTC) X-FDA: 82341622230.02.1BC5139 Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf05.hostedemail.com (Postfix) with ESMTP id 4B1BF10001F for ; Mon, 15 Jul 2024 10:32:12 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf05.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721039506; a=rsa-sha256; cv=none; b=ggKpP1JlrUae5HCQFZ3gHehmb4NQ+iWfLUyWdQKd/2zz6r3i7X0p1NhuQEyHySlddQONnb 6w++myUZ23w5v+QgHzxTwQYJzrJtcsyIiQARduwMOwk0CuwKPQfYC0n0Zd2vuKfhnO/xuk SLTTeYl/sNWAEmAfIo4NAThtj4LsJfI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf05.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721039506; 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=mNMV+VoKdFmSVEHoNTLbtCF/gYgXEgnEuTJ3gkwesmE=; b=WAiaTK8B2wpaQb08NijwkU5UNnrSr2k3LnJH+0JafcEiOyhe6yOrKxNK4BK4l1j+DdSJv+ Cz0o6ZWZ/4fLlrwaMBW/TA6ZcPWQiuK8UMgPvk2khgcQyuCN+EcZxmcW7XT8lWbrsweqd9 7hkI11JCH/TyJWf0ahDj3Kcn7Lf0y08= X-AuditID: a67dfc5b-3c9ff7000001d7ae-27-6694faaa4f59 Date: Mon, 15 Jul 2024 19:32:05 +0900 From: Byungchul Park To: "Vlastimil Babka (SUSE)" Cc: Theodore Ts'o , 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: <20240715103205.GA38263@system.software.com> References: <20240711153846.GG10452@mit.edu> <20240712044420.GA62198@system.software.com> <20240712053150.GA68384@system.software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsXC9ZZnoe6qX1PSDH6fUbeY2GNgcfH1HyaL mfPusFns2XuSxeLemv+sFq09P9ktOl7eZ3Fg99g56y67x+I9L5k8Nq3qZPPY9GkSu0fTmaPM Hp83yQWwRXHZpKTmZJalFunbJXBlfPlwjq1ghkjFpvZtbA2MJ/m7GDk5JARMJH5NfcrWxcgB Zp9ZUAwSZhFQlbi6YCcjiM0moC5x48ZPZhBbRMBAYvfm86xdjFwczALzmST6jy1iAUkICyRI vJh5GqyBV8BC4uKzOywgRUICrUwSzS0XmCASghInZz4Ba2AW0JK48e8lE8hiZgFpieX/OEBM TgE7id8TpUAqRAWUJQ5sO84EceYRNokLCwQhbEmJgytusExgFJiFZOgsJENnIQxdwMi8ilEo M68sNzEzx0QvozIvs0IvOT93EyMwwJfV/onewfjpQvAhRgEORiUe3gN7J6cJsSaWFVfmHmKU 4GBWEuH1/jklTYg3JbGyKrUoP76oNCe1+BCjNAeLkjiv0bfyFCGB9MSS1OzU1ILUIpgsEwen VANjqZbJl0f6/RfsL/yR7c7RYzicxnRIMHpO8u3yFG6u2FqtlnLDn58/By9NNT9kuK7T/mzd gyIpmZ1R0n90z3K2SccV36la1ZqetP2Ky0zxV/WTZj5x0I//avPwkOCbXbGz87bOkjE75KK/ v/lwbvfJBDdp3ufah951nhAxXmTUPX2NTHfz74lKLMUZiYZazEXFiQDIhurvbAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsXC5WfdrLvq15Q0g+nrZS0m9hhYXHz9h8ni 8NyTrBYz591hs9iz9ySLxb01/1ktZrTlWbT2/GS36Hh5n8WB02PnrLvsHov3vGTy2LSqk81j 06dJ7B5NZ44ye3y77eGx+MUHJo/Pm+QCOKK4bFJSczLLUov07RK4Mr58OMdWMEOkYlP7NrYG xpP8XYwcHBICJhJnFhR3MXJysAioSlxdsJMRxGYTUJe4ceMnM4gtImAgsXvzedYuRi4OZoH5 TBL9xxaxgCSEBRIkXsw8DdbAK2AhcfHZHRaQIiGBViaJ5pYLTBAJQYmTM5+ANTALaEnc+PeS CWQxs4C0xPJ/HCAmp4CdxO+JUiAVogLKEge2HWeawMg7C0nzLCTNsxCaFzAyr2IUycwry03M zDHVK87OqMzLrNBLzs/dxAgM4GW1fybuYPxy2f0QowAHoxIP74G9k9OEWBPLiitzDzFKcDAr ifB6/5ySJsSbklhZlVqUH19UmpNafIhRmoNFSZzXKzw1QUggPbEkNTs1tSC1CCbLxMEp1cC4 JJmjhmvCh9feVo+3lMR39+Tv8lJTKt//Ro1D8PDcRa+WL/R2mlX/u3zn6+2P0t5Yqnx7y93m 8PrVq9nFWQu53uilHvQzSMowdf27lYVJU6vzq8c1I4tE5je22wqbxE99c37/aKHFrHfL6u9n Gfv6ctUx/W3T+CBfdkSIL3Hh+nm/buixLZJXYinOSDTUYi4qTgQAKIayOlwCAAA= X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 4B1BF10001F X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 11pu63yon9cd3akzxj1hxe53t1u48p81 X-HE-Tag: 1721039532-387564 X-HE-Meta: U2FsdGVkX19tn+T+DB6nmuSnF6r+vCUPWdrpT5OxAR9R+yZW1WusDNoQDb/hR2njmuJGEnT/crPF31vr9QKTwNZbEOjcFS16Jmvkh7UMEq9sU+mqESj9PCMIQEusfLQ9QYxdseN4FyP1RKf8iFHkLPNPtS8ieDTFHaZYwaoiL521fQzqTE52DMFoKIni0LMqjAlVs1g7FjQE3GW2b5L6MYySZu3teXYn/xIN3cWWw0ZJDyf+nDUKXX+k//n0XHLGHsEOa4YmqgSOZFbgwSmRL8RkURKteWnAkUp1AA2T3Qk6I5lHE5U+Nlg+IsoJ+hZkWvZCV3wr5bayGjbb8PqqFozpltaSwkOhemgUQ1lD1Ilgz5HmsouddWvTVj3CaYi4l6hzV0KP18j2FxyC+t0O3lx3U3E7ddAi+wgjP38O5OM/hCq19zo42VaGRnuAgOOnFjrGnM/EF0/WRaR/e2fuh5V7SVQUJmP57Jv6LAU8wWBnyVeltJ6+PF/taWvzLWL9DaCUMr/t9jwv/nhQ5//6QHLXokIIiJqyUqraVjsuYCYqlzqVMpqdvDr2/PAYEzwtONpYwqFLGDPKByzyEYfPs65VxPbFwIce1GZjShB22zLDMLBJ7mjBzCl+odludP818cPQLiH64UnDuiS1rwW9Mt199IDJbGA63so2uTsEgi4U4QdhrnDB+4oL06hk7aU0Dvcczor0qyThbf9TBg3/qL/qtN4P1wBSg2ZYOLboSLQdwZ3r3zHsyeKwbH656wtk5mn80qZ7MtJTLQZ9oXq6MneQSI4N1lS/OxECE6Sj8266ojpctmHTS22CtOfL6xvH2m8f5Xx3Zy77oAwbsAixeKFnOLSYF+EXSWBSbhYr86qkOUQW53AeS8dxNKa+MQrzilibJ+DqbIw1Euk+lqpT2Y7dKIVrCmmmjUxUXdgFSi/qU6kTUVFTtYicE4ZIIZf2G4a32TISfexLCL3vAxB lu725kSA 33J5PRUBh7RzB6aahgLm1G/FE6y2kTxAq5nhHJG+5LxI43MXd+6snQPheQg== 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 Fri, Jul 12, 2024 at 11:23:36PM +0200, Vlastimil Babka (SUSE) wrote: > 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? Yes. > >> > 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 think so. > >> 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. Yeah, I will think it more. However, maybe, as you said, it could introduce a complication. Thanks. Byungchul