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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0389EB64DA for ; Mon, 26 Jun 2023 08:13:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229492AbjFZINX (ORCPT ); Mon, 26 Jun 2023 04:13:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229790AbjFZINS (ORCPT ); Mon, 26 Jun 2023 04:13:18 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0FB5A10E7 for ; Mon, 26 Jun 2023 01:12:59 -0700 (PDT) Date: Mon, 26 Jun 2023 10:12:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1687767176; h=from:from: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=ieJMa1dJGSeBQ+5q42kvQ0aAwTr385DfbQKxpY80eJY=; b=IgG+lBKQBgg9H8LdKmQ8ypTwQqagxrKjxmmRdAW8dlqjmExvsJ7u6Rn9HiUDllJJ5hez9Q M85Kbzb9hu8kmT5rYmioCqBTqiWQJ+E+e6z+AFBPbxl71X0T6HsYz911uizKvWak5XbMZT 3ndKHvticc/yMbZsBTGbhapUxnznG6Jq8+fNSZKVx8pcB4SxleIZfJddGVvl3T6wld6V5e ktpQx1ib0ydwYFUzvkyrwFFuggu3cNUffpsweJoUJLT9C3WhrxWue5hh3FmpmN5iDp1som t2CDRc+NC1kRlDCrYTbSi1FwYWTYw0tDAKhnPJdd1KDv4LoJpIhRpDyvuCjYtQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1687767176; h=from:from: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=ieJMa1dJGSeBQ+5q42kvQ0aAwTr385DfbQKxpY80eJY=; b=imivjTsUAOGZ3TGDtu6GA8nDyVCkx2kGtQLzCLhB+1IN2eYad2VW4HiTO+RfnyH6p3qQl6 aRurbMNxTP5jbIAw== From: Sebastian Andrzej Siewior To: Tetsuo Handa 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 Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() Message-ID: <20230626081254.XmorFrhs@linutronix.de> References: <20230623171232.892937-1-bigeasy@linutronix.de> <20230623171232.892937-2-bigeasy@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-06-24 15:54:12 [+0900], Tetsuo Handa wrote: > Why not to do the same on the end side? >=20 > 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). Looking at other locking primitives (spin_lock_unlock(), mutex_unlock(),=E2=80=A6) 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. Sebastian