Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp505375ybh; Tue, 21 Jul 2020 00:18:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJym2NGRn8tIXjusmVTKbI2TkSToMFVwpDofYcQiYBp+FGL7YRh9XhX9kXpZx23HVE9wu3JV X-Received: by 2002:a17:906:6d56:: with SMTP id a22mr25228287ejt.440.1595315911420; Tue, 21 Jul 2020 00:18:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595315911; cv=none; d=google.com; s=arc-20160816; b=c35Tc7mI7hShIlmTtZmBZPXWRN9rDiAQl8+6uW2vIVW+i9nAH4E1yUHD57YRtShIdC qlEain94j+X7KTBp33nFcGWVaCouOqWCDu2M3fRBQgTN2Ka6rdq6foZ+GlSy0dq85NcR GKdis7+5szwPdophCU/o1Hn7r9VxkwNWz14DVfJsW9ajFjqR7jNXULs0/ahPpFKAawIv bsP7zg59ifzVlQ8p0bX4/ymT8Dv9/q/3c0jv51px3R+/g2GkoGeAzGwS4y8tXV+eY/dL /3BcyZeuSlvLSIjI9eSv+3YhLednmGUdIqT8B4fmqAXB3whQAzT+2jAE6cefKWZ8DEN3 73uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from :dkim-signature:dkim-signature:date; bh=WiErJQ3/pvdDczbHfP7geDKER1phc+abHIAv/TX3dPo=; b=eTGJ8R9gefYCco+noHnWMKeLKmjNcJ+p3uYxwvJMTF98kVVjbqOBW7V+6Zz5K7GssJ eTrYGBN5GllflDwcJSDtQFpqemvQHNhot2Uj8wqKAXNotESIuZJxVA4YTKnslkWfHLVf 6Ymdqadv+IyMOe3ftuBQK5DAiCMrxXCLgf1HGnO3aJYkgd1AqXB2QCA6sIq9TVJ1p8Cm Bz4RKKecF+BFMTk4hunyYhyiS0IofXfH678nEgawrag4Zu5Ch/oeuBfegBw3EpHh+7Db GpHRZfJp0YMg2VctyqSuQB3JmM/KrK4g5NCkBQakQenscZFcK2RBuWIC22RRP7wNlsTi EEbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=tuWETmIT; dkim=neutral (no key) header.i=@vger.kernel.org; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y25si11904981edo.175.2020.07.21.00.18.08; Tue, 21 Jul 2020 00:18:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=tuWETmIT; dkim=neutral (no key) header.i=@vger.kernel.org; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728589AbgGUHPQ (ORCPT + 99 others); Tue, 21 Jul 2020 03:15:16 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:35572 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726818AbgGUHPQ (ORCPT ); Tue, 21 Jul 2020 03:15:16 -0400 Date: Tue, 21 Jul 2020 09:15:11 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1595315712; 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: in-reply-to:in-reply-to:references:references; bh=WiErJQ3/pvdDczbHfP7geDKER1phc+abHIAv/TX3dPo=; b=tuWETmITBNcudRlx7rC5BIgTv+Fx4FzTDnt8NCBKzevVpaDPowcv+/5er4R84GVMcUf+Pc i3sVaD3xsRlNaEvCkwlx9lr/w7GREynhrlsbw8HaJP5itSyiU89M2r2s9hVslcNOMhPycO gl00axSsKy6DI9d1+hW0M1uomRHW188gCmZLDuMcB5/7s5Unx8/J1MuyavhQGGr2GdfQ27 7G9BF0UyAZe1d9PTs08qY1x8ggVwFe5yyLM59JTnifE1QY5g1lM0Z3dAMuJXI/lIVK5+8d y5r9ItPVTgMy91lXVlXlI9q3njQqrg+COL3l5dnRNhX3mN2uIKlhbxNlIUO6bA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1595315712; 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: in-reply-to:in-reply-to:references:references; bh=WiErJQ3/pvdDczbHfP7geDKER1phc+abHIAv/TX3dPo=; b=ZwumFlYaLZltOUD/a6CEqLjmblCs/2U42ruGzV/qYbNKuA7pCxl7oCJbVaboxQpvtl71WK mKzhLC9TkKaED9DA== From: "Ahmed S. Darwish" To: Steven Rostedt , Peter Zijlstra Cc: Ingo Molnar , Will Deacon , Thomas Gleixner , "Paul E. McKenney" , "Sebastian A. Siewior" , LKML , Jonathan Corbet , linux-doc@vger.kernel.org Subject: Re: [PATCH v4 01/24] Documentation: locking: Describe seqlock design and usage Message-ID: <20200721071510.GA1175122@debian-buster-darwi.lab.linutronix.de> References: <20200519214547.352050-1-a.darwish@linutronix.de> <20200720155530.1173732-1-a.darwish@linutronix.de> <20200720155530.1173732-2-a.darwish@linutronix.de> <20200720214400.5ec6a028@oasis.local.home> <20200720215115.4c5276db@oasis.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200720215115.4c5276db@oasis.local.home> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 20, 2020 at 09:51:15PM -0400, Steven Rostedt wrote: > On Mon, 20 Jul 2020 21:44:00 -0400 > Steven Rostedt wrote: > > > > - * This is not as cache friendly as brlock. Also, this may not work well > > > - * for data that contains pointers, because any writer could > > > - * invalidate a pointer that a reader was following. > > > + * See Documentation/locking/seqlock.rst > > > > I absolutely hate it when I see this. > > > > I much rather have the documentation next to the code. Because > > honestly, I trust that comments next to the code will get updated if > > the code changes much more likely than comments buried in the > > Documentation directory. > > > > It's also more likely that I wont even bother looking at the doc > > (because I wont trust it to be up to date) and just read the code and > > try to figure it out. Or look at how others have used it. > > Never mind, > > I see that kerneldoc is added in patch 5, which helps. > Even looking at the current patch #1 *in isolation*, no relevant comments were removed from seqlock.h at all. They were just moved closer to the seqcount_t and seqlock_t structure definitions. The original comments were horrible. They intermingled seqcount_t and seqlock_t descriptions in a *very* ambiguous, sometimes even in the same sentence. It was misleading, as the usage constrains for each data type (especially on the write side) are vastly different. Even the new KCSAN comment, which was freshly merged this release cycle, got tainted by such already-existing incoherence. It kept talking about the "seqlock interface" while it actually meant the seqcount_t interface. Then at the end, it realized the semantical ambiguity and noted how the "seqlock interface" does *not* cover seqlock_t. Moreover, this seqcount_t/seqlock_t documentation intermingling led to the critical usage constraint of disabling preemption before entering a seqcount_t write side critical section never getting explicitly mentioned. This has (naturally) led to a considerable number of buggy call sites, and the fixes are now merged. I've tried to fix the problem at the roots, and basically identified three major problems: 1. The seqcount_t/seqlock_t intermingling is confusing everyone. That is, both of call-site developers *and* core kernel engineers. 2. The big picture of seqlock.h was never expressed in a sufficient detail. 3. The usage constraints for the exported seqlock.h APIs were never explicitly mentioned.. leading to buggy call sites. To fix #1, I've changed the all of the existing seqlock.h comments to explicitly mention either "seqcount_t" or "seqlock_t". Then, divided the the top seqlock.h comment into a seqcount_t part and a seqlock_t one. Afterwards, the whole seqlock.h header file code was grouped into "sections", as seen in patch #4. To fix #2, Documentation/locking/seqlock.rst was introduced and boldly referenced at the header-file top comment. To fix #3, kernel-doc was added for all of the seqlock.h exported APIs. @Peter, kindly note that all of the above *is exactly why* I've resisted hiding the new seqcount_LOCKTYPE_t APIs introduced by this patch series inside generative macros. All the parts that will be referenced by call-site developers are kept both explicit and kernel-doc commented. Thanks! -- Ahmed S. Darwish Linutronix GmbH