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 0C945EB64D7 for ; Mon, 26 Jun 2023 14:44:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88D598D0002; Mon, 26 Jun 2023 10:44:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 816298D0001; Mon, 26 Jun 2023 10:44:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B7078D0002; Mon, 26 Jun 2023 10:44:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 59B9F8D0001 for ; Mon, 26 Jun 2023 10:44:21 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id F41E88037D for ; Mon, 26 Jun 2023 14:44:20 +0000 (UTC) X-FDA: 80945169480.02.19516B7 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf28.hostedemail.com (Postfix) with ESMTP id 016E6C001F for ; Mon, 26 Jun 2023 14:44:17 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=hiNpbD7f; spf=pass (imf28.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=pmladek@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687790658; 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:dkim-signature; bh=ZjE5mo/g8PWKT/06H0flzBZRZN1qowN9ixnd893I27M=; b=CDqeUQByKbSeR+Km9D7rypJyxekWie1uG//A0yQfq9iFjkNburjCP3DTEOt2fpqMjGxZbF V6pecOsgKORv0iFqfnVkFwhpcU/E8Q3YYb0wiV7zZwXaeb4orWtia0LeiIuvJT5GQAmalf BTN07Hgd7ayJS1TM5jPYUJ6x7skX8YI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=hiNpbD7f; spf=pass (imf28.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=pmladek@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687790658; a=rsa-sha256; cv=none; b=rLp4hT/ZCJdJLQPi0HaKhRrycywv2tcYlzJHm1CuKQhpmFfgTsHZRbV8/segZZvLpdQO9D h6wqn9F+pKBcx0/j23MgsAYEkPc2CMDli7nki4Dbta6jPh2QeKzX/PcE1gPgQFf1eBhApR Hms4HgBgXcXfkHTvsh6Cz/HX3TzcVBA= Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 2D6DD211E2; Mon, 26 Jun 2023 14:44:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1687790656; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZjE5mo/g8PWKT/06H0flzBZRZN1qowN9ixnd893I27M=; b=hiNpbD7fKe/Q2KeECWUlgTPDoRf1JL3wcXC8r7kQwxX/H/qC9lNMlPdZjIqWc8C8ASV91A BV2NZ38SYt7NuWTKVUlhDOJr6Ms7v0upm6vWI+FR8DoBcPAtGwQEYwslBpTVrJU1Fj4Eog WIbuK13bnTCbXnOWyL7DsBFU1zDqZiA= Received: from suse.cz (unknown [10.100.208.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 6921C2C141; Mon, 26 Jun 2023 14:44:15 +0000 (UTC) Date: Mon, 26 Jun 2023 16:44:14 +0200 From: Petr Mladek To: Sebastian Andrzej Siewior Cc: Tetsuo Handa , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Luis Claudio R. Goncalves" , Andrew Morton , Boqun Feng , Ingo Molnar , John Ogness , Mel Gorman , Michal Hocko , Peter Zijlstra , Thomas Gleixner , Waiman Long , Will Deacon Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() Message-ID: References: <20230623171232.892937-1-bigeasy@linutronix.de> <20230623171232.892937-2-bigeasy@linutronix.de> <20230626081254.XmorFrhs@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230626081254.XmorFrhs@linutronix.de> X-Rspamd-Queue-Id: 016E6C001F X-Rspam-User: X-Stat-Signature: fo8gb6ranstn9kj816pc49kccny56f1m X-Rspamd-Server: rspam01 X-HE-Tag: 1687790657-128368 X-HE-Meta: U2FsdGVkX19o2dK62EKdlqFzLN+M07bYmzrOGkK2PCUOZEkjSBcc/shuOp0lnQ9icGUcHLm25E6geikJ3P9JA3UUaplyt7oRBBes2poPooc8YxnZwcVqwwYeC9+JFgwjufTcS/bUPrPen2au3bfAzu3XOg4lihZh/afvyk5F+hqMB/MiTE0wpDl/e2O4NdCgq0giGRjDq4IayB1dqPdbt4UBFsB2JZ9cDnOoAmbJof9VdGFZ1DGVhjR8txxNsUyP4SBP0F4mYtV76C0eGx9MihBQU/L1AYRaJYncPbMN12p0HDVgSjl9GM7T2BDGRkIcDjfgSLwn/WEeIgISycQcT9mkixCBLslDPjtYnvSlpF9W5i46xjKRu4QnPzcHGBHL54aBQpju9WE+R0ZH8KgHYrBtIK0CexCJ+M5nZ+BFtDlUGUi2sSJFQt9ShUFJ0RpfSdpVGdVyvGyxg8eknqFIXmKfYQjtvsqJ4EuEQ6KIqCNjWFQVmsX+/UZ/ntdacWsRZRA2Ct3xhDv6lH+irGwD5WZwOEtQWwv/P1Wkg/HeAUAIZIOcAH8xdn5xBcC2pG5Hy50oHk4xWfDBczcexKvR03qWZPsUpp40VFKzXPNE73bXRA2lbwEccoWZOesPIDfksXV6sf9uNd23F+kj18ytdfSmKquTkAB7Sqh5+Sh1ogmIj0z4V6DOrdTjT7RtXtG8yemlnn9hvxbhVVMycKwSpatWjxCEpidL8y0qxTAQbA1xFGmHfU28m2e6BeIwoH+yk1PDUolNZMR0NXzJqL+wxP78H0NOJoSCSEY/vtAAIgLcSa3DQHv2r9CRNBQmH9Z79xdsZ1qgfJO8MdO/cu+1TnGFs8P99e8ieCx8ZfjdsnDZGozuzziguUDwYlQD9hIYnv95jgcypjMrzSH1EkoL8kE6T0yg9BvMvdtgz/vLjynFTL3nYzYAPWrz2jId0ht+8BsneSpXHtANHa9NiHN Q2PbjQ/1 qdbaQUfnHk2vhvPqrNtqm5s1MdqLW2yBqB/ilsxWgQcjxt/3AE5GDqaIQSvIswo1IqyR6uMO5Ni6YVxm8C74vMwhZJMr/TO+ZiUS41D3CdrNflJP7eOyqyH7dOIvSzlEtc5azU7ta1Tpf3nnDGbth0F/l/Ydwhz4FDXPBiqO8sklVpzLr2APonxy91JJiIv6FLny1bi2GlKmQ3IjPptld72L1RGVWfz88XI/yCoqb0phiQ4tfX5jcADaSKe29DJslI2Z9Of4DIg2FdH8= 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 2023-06-26 10:12:54, Sebastian Andrzej Siewior wrote: > On 2023-06-24 15:54:12 [+0900], Tetsuo Handa wrote: > > Why not to do the same on the end side? > > > > static inline void do_write_seqcount_end(seqcount_t *s) > > { > > - seqcount_release(&s->dep_map, _RET_IP_); > > do_raw_write_seqcount_end(s); > > + seqcount_release(&s->dep_map, _RET_IP_); > > } > > I don't have a compelling argument for doing it. It is probably better > to release the lock from lockdep's point of view and then really release > it (so it can't be acquired before it is released). If this is true then we should not change the ordering on the _begin side either. I mean that we should call the lockdep code only after the lock is taken. Anyway, both sides should be symmetric. That said, lockdep is about chains of locks and not about timing. We must not call lockdep annotation when the lock is still available for a nested context. So the ordering is probably important only when the lock might be taken from both normal and interrupt context. Anyway, please do not do this change only because of printk(). IMHO, the current ordering is more logical and the printk() problem should be solved another way. Best Regards, Petr