Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp16297906rwd; Mon, 26 Jun 2023 08:12:24 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4bM9yhWEhmeEoFke7TSOzZG1CmhgsVJhuPxHzcFemfI6YjssIwRd3GCMDGnvxkX2bf6L1V X-Received: by 2002:a17:902:f542:b0:1b5:91:4693 with SMTP id h2-20020a170902f54200b001b500914693mr10067395plf.1.1687792343861; Mon, 26 Jun 2023 08:12:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687792343; cv=none; d=google.com; s=arc-20160816; b=r/NVunA2Hw4t+kVu4h8RuXipZDlygdafDsR7SrjtDbFY6NTPgG0NPjYt4t40b54OQh EK1Tq7aH9LWIQMOJEuxuvRkrOxf+MR1I69YmGjYN1GBqGvCAasniLKpNcN6GQTPOOoCH uK25W0UB5eLTJo9tbuEo9YAx9a3k/nLkuCgO9Mw/MoIN1tDXqGOVnXEe+QwHsxkz3lkl Thr5/R1UXmtnF+Z+v3FEbEyGMdrsvPukIQ4vHzKDcnCLHoCJBhyEiZXW4qFw52o8kekL egsAXkwnkAtrPbm50cUDsgSn1OPvnZP7iZQcQ4auQWVOsWbjVNstkiOfwUyBrW0HTOmi 2BQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ZjE5mo/g8PWKT/06H0flzBZRZN1qowN9ixnd893I27M=; fh=Yu/oj8pq5ICjVsbokHF3kSQsn2xUb0xQjxecDzqXfII=; b=ijvxat8/FrGSaQR/HYe2yJLAYiHkl1BN/Dh69SUr3GNSN94c/XHb2y3G0I4erZEm5H Go9YESfK+oZZOJoL7C/cxqBIy5ItTORmlWREAd7Cz5JXjj0kudGLeEhuXtMQL1v1wo1K pajdUB90nHfc8I1/5WHMqJVBU4aqvOrQ6gVS/B+2szJB/uRSQiBoggA1fbLaIjW34WKR zOiNeVKVG09adACLvKRJb9jIWrb3L37o2zFH9XVbykKEnRlrc31rjlQ36op74UcQyeEn HV3Gm8yRxGh1J8gtdpDBJs19g6GTx908hASsX6jBCm5QryBsTQdJsEivPdrqPWyPu59/ UnDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=hiNpbD7f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d17-20020a170902ced100b001ab0d2ca17asi5422186plg.457.2023.06.26.08.12.11; Mon, 26 Jun 2023 08:12:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=hiNpbD7f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229604AbjFZOo1 (ORCPT + 99 others); Mon, 26 Jun 2023 10:44:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229781AbjFZOoZ (ORCPT ); Mon, 26 Jun 2023 10:44:25 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 868EA10E2 for ; Mon, 26 Jun 2023 07:44:17 -0700 (PDT) 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-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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