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 F2F81C433FE for ; Fri, 4 Mar 2022 11:39:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 337C58D0002; Fri, 4 Mar 2022 06:39:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 298B28D0001; Fri, 4 Mar 2022 06:39:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 139A18D0002; Fri, 4 Mar 2022 06:39:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id F0FF28D0001 for ; Fri, 4 Mar 2022 06:39:43 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A863F8249980 for ; Fri, 4 Mar 2022 11:39:43 +0000 (UTC) X-FDA: 79206509046.28.F9B85F7 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by imf19.hostedemail.com (Postfix) with ESMTP id 4AD441A001E for ; Fri, 4 Mar 2022 11:39:43 +0000 (UTC) Received: by mail-pj1-f41.google.com with SMTP id ge19-20020a17090b0e1300b001bcca16e2e7so10385511pjb.3 for ; Fri, 04 Mar 2022 03:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=T0KWcfrVhfRiQuPhzFUu+oUHR0+0iQuCKbqqyufUMXA=; b=BS4C5Y1tL4r8PWIRqTmC6gS0HaL1ikR+470ZGcTaIa4wFQYparRJpFgi8byBxYfS+3 h+/0V9Om3+A1FxjtUhzi8xUX8SQHq+v8HkFoG+J6SemhINeDJSnxowDMKlAz8H8duGxN dQUqq+1LAnYBfNHP7SN7AA2Kj/WI0bj5UMk5D1tTDQS+yqA1Cfs9LXdRBoRhuywGMkHh uxofCQJrdhXypoU+Kck6or68lCBk3WDfd06ViBAREudViDBHavC9dOljVk6YKVx+g6tI ywHzdC7NPv1PVpGFaSAGB5AQ+PPtoXYZIHynTx/iBcL2C16vxnOubx0fFVbm7AZnrUe7 ko/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=T0KWcfrVhfRiQuPhzFUu+oUHR0+0iQuCKbqqyufUMXA=; b=XMyx2r48tSHfBcTISbrZS/nB9dXu9kxS/J3kxwQAkZhLCCY3OyURqrNWr+u3HXPXtn 76k34Oz84FWKzgr8nvoGsgw4E4JjyHC9N/HeglsP9sIScvu/JyQabyDpfV7ghs3PnUJj +7vJVkQD7XyEPLPxJE/acN3QYeeNMFSB6DqVDzsLF5cxBCF4RigwAcpzMpHYnDUqpgoZ h5/a1XDQQwx+sKsjHYlmJwP35txAVe0FnBYvobZizojBJpeADT0O9z5GgR95sWzVgW9N k7CUsFiMii4ofeyvLiAtBcPUp+adPfyw/GWSmFb+I3W+T3RdnqbEeGfdGglzcpDwVM+I 8aPg== X-Gm-Message-State: AOAM5329zf4VCZuTGmLfg80tD1iX+XtIEWA6LiEigjqsOKRyQn6FyRp6 nN/Emn9dwysKf7gsNJsGt/8= X-Google-Smtp-Source: ABdhPJwUeGy/HJBpt8MjGZ13EzUfgfohEC7mxxbk5v1dgWi77zTAJpDwQo+/X8i3EoW7ntQ/oQ2ZNw== X-Received: by 2002:a17:90b:390c:b0:1bf:2d83:c70c with SMTP id ob12-20020a17090b390c00b001bf2d83c70cmr1346393pjb.217.1646393982299; Fri, 04 Mar 2022 03:39:42 -0800 (PST) Received: from ip-172-31-19-208.ap-northeast-1.compute.internal (ec2-18-181-137-102.ap-northeast-1.compute.amazonaws.com. [18.181.137.102]) by smtp.gmail.com with ESMTPSA id e18-20020a63d952000000b00372a1295210sm4394691pgj.51.2022.03.04.03.39.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Mar 2022 03:39:41 -0800 (PST) Date: Fri, 4 Mar 2022 11:39:29 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Byungchul Park Cc: torvalds@linux-foundation.org, damien.lemoal@opensource.wdc.com, linux-ide@vger.kernel.org, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org, peterz@infradead.org, will@kernel.org, tglx@linutronix.de, rostedt@goodmis.org, joel@joelfernandes.org, sashal@kernel.org, daniel.vetter@ffwll.ch, chris@chris-wilson.co.uk, duyuyang@gmail.com, johannes.berg@intel.com, tj@kernel.org, tytso@mit.edu, willy@infradead.org, david@fromorbit.com, amir73il@gmail.com, bfields@fieldses.org, gregkh@linuxfoundation.org, kernel-team@lge.com, linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@kernel.org, minchan@kernel.org, hannes@cmpxchg.org, vdavydov.dev@gmail.com, sj@kernel.org, jglisse@redhat.com, dennis@kernel.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, vbabka@suse.cz, ngupta@vflare.org, linux-block@vger.kernel.org, paolo.valente@linaro.org, josef@toxicpanda.com, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, jack@suse.cz, jack@suse.com, jlayton@kernel.org, dan.j.williams@intel.com, hch@infradead.org, djwong@kernel.org, dri-devel@lists.freedesktop.org, airlied@linux.ie, rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com, hamohammed.sa@gmail.com Subject: Re: [PATCH v4 22/24] dept: Don't create dependencies between different depths in any case Message-ID: References: <1646377603-19730-1-git-send-email-byungchul.park@lge.com> <1646377603-19730-23-git-send-email-byungchul.park@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1646377603-19730-23-git-send-email-byungchul.park@lge.com> X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4AD441A001E X-Stat-Signature: c3u3xefyobbjeykrsudmna7oirdxqquq Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BS4C5Y1t; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.216.41 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-HE-Tag: 1646393983-401330 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: On Fri, Mar 04, 2022 at 04:06:41PM +0900, Byungchul Park wrote: > Dept already prevents creating dependencies between different depths of > the class indicated by *_lock_nested() when the lock acquisitions happen > consecutively. > > lock A0 with depth > lock_nested A1 with depth + 1 > ... > unlock A1 > unlock A0 > > Dept does not create A0 -> A1 dependency in this case, either. > > However, once another class cut in, the code becomes problematic. When > Dept tries to create real dependencies, it does not only create real > ones but also wrong ones between different depths of the class. > > lock A0 with depth > lock B > lock_nested A1 with depth + 1 > ... > unlock A1 > unlock B > unlock A0 > > Even in this case, Dept should not create A0 -> A1 dependency. > > So let Dept not create wrong dependencies between different depths of > the class in any case. > > Reported-by: 42.hyeyoo@gmail.com > Signed-off-by: Byungchul Park > --- > kernel/dependency/dept.c | 9 +-------- > 1 file changed, 1 insertion(+), 8 deletions(-) > > diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c > index 5d4efc3..cc1b3a3 100644 > --- a/kernel/dependency/dept.c > +++ b/kernel/dependency/dept.c > @@ -1458,14 +1458,7 @@ static void add_wait(struct dept_class *c, unsigned long ip, > > eh = dt->ecxt_held + i; > if (eh->ecxt->class != c || eh->nest == ne) > - break; > - } > - > - for (; i >= 0; i--) { > - struct dept_ecxt_held *eh; > - > - eh = dt->ecxt_held + i; > - add_dep(eh->ecxt, w); > + add_dep(eh->ecxt, w); > } > > if (!wait_consumed(w) && !rich_stack) { > -- > 1.9.1 > > Works as expected, Thanks! I would report if there is anything else interesting. Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> -- Thank you, You are awesome! Hyeonggon :-)