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 AEBBDEB64D7 for ; Mon, 26 Jun 2023 09:26:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1DCB8D0002; Mon, 26 Jun 2023 05:26:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ECE388D0001; Mon, 26 Jun 2023 05:26:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D96C08D0002; Mon, 26 Jun 2023 05:26:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CB94E8D0001 for ; Mon, 26 Jun 2023 05:26:32 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 91F17AFDE1 for ; Mon, 26 Jun 2023 09:26:32 +0000 (UTC) X-FDA: 80944368624.12.1901E81 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf18.hostedemail.com (Postfix) with ESMTP id AC3311C0005 for ; Mon, 26 Jun 2023 09:26:29 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=none (imf18.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687771590; 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; bh=qMGdABYNNLtTgzWcvXOa/YXOb1QqSFenmE1pT1flhqk=; b=j2G/oVu+bsqv3j9bkADQfMftdfkEu3jop/5a71BKe1bNCoGaeqhXIrGnz0Qh+583tEDCxb H55zehUrh2JQbMuJYhGYszUb9WanxPxU8PzyTG7FtDKSwhYadCX9B5NaFeO6ywei8M9R1w 6IUAsQUxDfVTWfqVVUy5CuKzBFhEzlE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687771590; a=rsa-sha256; cv=none; b=AgX8ogLaTGZi1xHL5iY/RH5sIHRIvgblqRlf9WRsFequUjjlOa2/5lr32y/LpX9SLB0yYE KC6Lrs5G45ondO4tB+6yWwHV5jrw4Nw0AtYw3gW7ObPKLy+2NuzxizRgx5bRH9+VJBksCA gWRPmK/ya7zIBZ1l8qfIwn94Ix9BPR0= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=none (imf18.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp; dmarc=none Received: from fsav117.sakura.ne.jp (fsav117.sakura.ne.jp [27.133.134.244]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 35Q9PvVm092315; Mon, 26 Jun 2023 18:25:57 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav117.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav117.sakura.ne.jp); Mon, 26 Jun 2023 18:25:57 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav117.sakura.ne.jp) Received: from [192.168.1.6] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 35Q9PuMm092312 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jun 2023 18:25:57 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <0a0c768c-227d-c0cd-1b91-5a884d161c1b@I-love.SAKURA.ne.jp> Date: Mon, 26 Jun 2023 18:25:56 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() Content-Language: en-US To: Sebastian Andrzej Siewior Cc: 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 , Petr Mladek , Thomas Gleixner , Waiman Long , Will Deacon References: <20230623171232.892937-1-bigeasy@linutronix.de> <20230623171232.892937-2-bigeasy@linutronix.de> <20230626081254.XmorFrhs@linutronix.de> From: Tetsuo Handa In-Reply-To: <20230626081254.XmorFrhs@linutronix.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: AC3311C0005 X-Rspam-User: X-Stat-Signature: fwnj74p1ao5k6tpfaxe8tauzpprm5ish X-Rspamd-Server: rspam03 X-HE-Tag: 1687771589-495529 X-HE-Meta: U2FsdGVkX1/vA2QsMe11Z0i1f8vlcYpWO0QYCr7kUhZkcG9D8fQmihnxBWqZsDjerVyal9cZ8PY1vZ+IAuqcf1gfuV6yL8qLAv3Rg88WHv2CoFF4Su7yq9bN2hq1ewVmntd22Up13cO83BJyMMG2T27UjfZMBl+d1qgaC+FDHO3nMJ7H5z8UxtK0BMkAQGMTeXNzuIBdJF4xhjbZbSU1j/uulDKC6uDtoVcNjhl4gibR+qTaFba/YSXe7QQ6JRJbabRh5bMk9JeYzwoV45H7hF2UXpiyQPE0ULWrsYqLQ+wisSBbQEafhGJWk43BlfIDg3mLQmf9rvt4M5nT4g1Dwy/Dug8H69v9iXYDd3AIBtExKfZky1WJTgh/k4o8gbYX3DAmW1eyL4g9zHO3Z9wRvrxLBSyIR1bVCXNZdCb1+FwhCIF3yGh7yt90l7RLZo0DGBty92AhNFEh8bgpXKUm9nfWKEVs3gR88mHvs+xWouuRrmgFzA/hAQeOChj1Gt8kS+nPlCMaWlabstRsI6kwiQh/4WZ2NEAkO8Vzza8gyXOGdKLNSKwV3+Shcnm4vTfNEqZMqz3TBTyYUtDFlQ/HfzGT+xiM4hxTzxNkovH9o2BJC5gingcU3TcsN84bO1z9Ilfqob0xmRYlJfSswSB3RSpqGk71wHdwgCuPZxsyMldLbPOLE1tSw8iG8VdxJgYh+s0nfsLfNyG+tfj4TLquWvZEFQOzfl/7NhHBShlCV44lWcB+QmgESJJDZqGAosHU8lAWSua8O1KLn6m5xx79BZbj3m+soWwX1hKUizmejIYxXqBgtRuWhxWonO2cFUA+NTx/KTb3LYUK8tJ2mFnzbFEPcD8o2dolImeNtrUwjtFKI+PaffMru0dJnfbSUFx8fCXQW8ssJoJh+HKNKmnHmej6Tc52K1UNeLzFUnH8SKLF4SUqp2nQSkjbPxUYP2WVxXMMDLW5pWrTVCU5BKv s5T0JMUX bjJ6XgTlLzmaBnkmFB2LtvprtfnQL8Dfn7elk0pLvgUCISZGiHrlU0kfc1ybcHpn0cIF1JnIZPPOet8rc1S8dOTXiyK4fiuMU/l/Px1QqFeJ+Pw4coWrFwsEFqbAfdkd6/w4q52NNJIXqGVkiFnje4AS/eXkMqONbhYZCrR823hnflBECKQxwq5V02bf4KnNwdjtGcVzfybm570xdST829tGYrOWbWU+zoZdQQPF4CynZC2P+lLr13JytEJIR8FZouSqaRv2XnYgwnavfzPfHidJo/8tXEdpiTW64UsQkD/LbIl6dr8pxTVuHbr5pkbVR5LTJzIzc9DU5VhgUqlfpZk/JnA== 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 2023/06/26 17:12, 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). We must do it because this is a source of possible printk() deadlock. Otherwise, I will nack on PATCH 2/2. > > Looking at other locking primitives (spin_lock_unlock(), > mutex_unlock(),…) that is what they do in the unlock path: lockdep > annotation followed by the actual operation. Therefore I would keep the > current ordering to remain in-sync with the other primitives.