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 X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C457C433F5 for ; Tue, 7 Sep 2021 16:53:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EF530610C9 for ; Tue, 7 Sep 2021 16:53:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EF530610C9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 5A6D7900002; Tue, 7 Sep 2021 12:53:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 557846B0072; Tue, 7 Sep 2021 12:53:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44596900002; Tue, 7 Sep 2021 12:53:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2E45E6B0071 for ; Tue, 7 Sep 2021 12:53:13 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E5B358249980 for ; Tue, 7 Sep 2021 16:53:12 +0000 (UTC) X-FDA: 78561372624.40.8FB874D Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf30.hostedemail.com (Postfix) with ESMTP id 985E5E001980 for ; Tue, 7 Sep 2021 16:53:12 +0000 (UTC) Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 142AE610A3; Tue, 7 Sep 2021 16:53:11 +0000 (UTC) Date: Tue, 7 Sep 2021 12:53:09 -0400 From: Steven Rostedt To: Vlastimil Babka Cc: Liam Howlett , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Andrew Morton , Michel Lespinasse , Matthew Wilcox Subject: Re: [PATCH v2] mmap_lock: Change trace and locking order Message-ID: <20210907125309.7af5cd19@gandalf.local.home> In-Reply-To: References: <20210903022041.1843024-1-Liam.Howlett@oracle.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf30.hostedemail.com: domain of "SRS0=ZahN=N5=goodmis.org=rostedt@kernel.org" designates 198.145.29.99 as permitted sender) smtp.mailfrom="SRS0=ZahN=N5=goodmis.org=rostedt@kernel.org" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 985E5E001980 X-Stat-Signature: wr8bnhg97jxzqyyi7w565ts787u7k9kh X-HE-Tag: 1631033592-761124 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 Mon, 6 Sep 2021 17:00:18 +0200 Vlastimil Babka wrote: > On 9/3/21 04:21, Liam Howlett wrote: > > Print to the trace log before releasing the lock to avoid racing with > > other trace log printers of the same lock type. > > That description could use more details maybe? Agreed, perhaps add something like this: Due to the tracing of taking the mmap_lock happened outside the lock itself, the trace can become confusing, making it look like more than one task has the same lock: task-749 [006] .... 14437980: mmap_lock_acquire_returned: mm=00000000c94d28b8 memcg_path= write=true success=true task-750 [007] .... 14437981: mmap_lock_acquire_returned: mm=00000000c94d28b8 memcg_path= write=true success=true task-749 [006] .... 14437983: mmap_lock_released: mm=00000000c94d28b8 memcg_path= write=true When in actuality the following occurred: task-749 [006] - take mmap_lock task-749 [006] - trace taking of mmap_lock task-749 [006] - release mmap_lock task-750 [007] - take mmap_lock task-750 [007] - trace taking of mmap_lock task-749 [006] - trace releasing of mmap_lock Although the mmap_lock was taken and released then taken again by another process, the lack of protection around the tracing of the activity caused it to show the events out of order. If the tracing of the taking and releasing of the mmap_lock is done inside the lock, it will protect this from happening. Andrew, I see you took this into your tree. Not sure if you sent it to Linus yet. Perhaps add the above to the patch if you have not yet sent it (with Liam's permission of course). Seeing that the patch has this as a link in the commit, at the very least, the above explanation will be archived. -- Steve > > > Signed-off-by: Liam R. Howlett > > Suggested-by: Steven Rostedt (VMware) > > Acked-by: Vlastimil Babka