Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp9103379pxu; Mon, 28 Dec 2020 06:43:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJypbyssnsfBNz6MCb1ekx73ZuchZS5Sq8uTkG+WV2VGg4NXG68mQpDJDsiPll0GCzzW8XeS X-Received: by 2002:aa7:d74f:: with SMTP id a15mr43019778eds.344.1609166602311; Mon, 28 Dec 2020 06:43:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609166602; cv=none; d=google.com; s=arc-20160816; b=IKTahx7eT6NX3P9h744kJaK9gO7RBKHBgSKp9lkInvnUK4KPFvwzQOXyvkI3VRabFA UCbcAkYo8/r55wNRk/hia87/FHUNVi2V+Jxq5iD9CcP5iYwJ87xI/ilPL/16cmgDk6bJ LwvjKIPUsuoTT1fflRkRDj3E/A6m3dUB39icjSs0Ae5RPl3hfH+VdGHKaXVbqxaLTYK6 hdcAvKmm//LzoWnm3V5AwBqyLmSQBU4P0MYkAbb9HgTZSOVLILQWOUt6jiEo4FsJUmLF 37jGaxoXoITdOFVHUpy5KsV58R/DPzFXv2DrmUEALxFOAdPIBYxzHZcopWtdcrXXswm3 2ymA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=C3xO9cNJP2KmiGy4EaMqUTBB1ykvsjRbudg2SebtIKU=; b=xYqbGwawcmmPF1BCOTkmS7cJKoNGSFrosOBII1H2X2ZHyne12NveQId040fOn41EkJ qEBTLhHpGaabAkywIDqNkK35smxj+zg52ojVaCpzmhN1AgmFSGj7SfFdWX41yCSRkNNU 1LLniipHjQ56+cS7Z0OBE9KO5yxp+wUyZtPmST4hLsfLNebZ7/BD01YO7gPComyHCa3n J6FgoEQ+nnyGJbaCWEG0E0PYUHNoGk1eOmXMQhiKbqmfX7iqv/122Jz0xfprAtqbJUQb eM9uK+JXUobQU765V30QJMkpFPKfmGmyvRJ3zBpZxr9SJBfRcouIEW+hMACK+8lzjEf3 7PCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=uIyHc9yd; 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=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gw24si18237792ejb.715.2020.12.28.06.42.59; Mon, 28 Dec 2020 06:43:22 -0800 (PST) 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=@linuxfoundation.org header.s=korg header.b=uIyHc9yd; 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=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2505832AbgL1Ok4 (ORCPT + 99 others); Mon, 28 Dec 2020 09:40:56 -0500 Received: from mail.kernel.org ([198.145.29.99]:36430 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2502473AbgL1O2g (ORCPT ); Mon, 28 Dec 2020 09:28:36 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C6EC620739; Mon, 28 Dec 2020 14:27:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609165676; bh=I2cXp1MT7EnjWf0cayzQn7ATh5TaaXPWvohR2tD1TEU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uIyHc9ydFlRa5c3HJw5tMWNJGex/n4zECohOuI4cGQ7Lp8VEs5O7nbkgGP0JC2TFk 3Vnc+dF0JlsnzDtNMNW0HZGGn7NzAeQbqB8fh6fYCVY6rdIzJS8WyK4dX5lUZhU/Iq kWB1DMI8CwtMu1y251pP3Zm7YyokcrWzG9xI+U+Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Ahmed S. Darwish" , "Peter Zijlstra (Intel)" Subject: [PATCH 5.10 574/717] Documentation: seqlock: s/LOCKTYPE/LOCKNAME/g Date: Mon, 28 Dec 2020 13:49:32 +0100 Message-Id: <20201228125048.421617679@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201228125020.963311703@linuxfoundation.org> References: <20201228125020.963311703@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ahmed S. Darwish commit cf48647243cc28d15280600292db5777592606c5 upstream. Sequence counters with an associated write serialization lock are called seqcount_LOCKNAME_t. Fix the documentation accordingly. While at it, remove a paragraph that inappropriately discussed a seqlock.h implementation detail. Fixes: 6dd699b13d53 ("seqlock: seqcount_LOCKNAME_t: Standardize naming convention") Signed-off-by: Ahmed S. Darwish Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20201206162143.14387-2-a.darwish@linutronix.de Signed-off-by: Greg Kroah-Hartman --- Documentation/locking/seqlock.rst | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) --- a/Documentation/locking/seqlock.rst +++ b/Documentation/locking/seqlock.rst @@ -89,7 +89,7 @@ Read path:: .. _seqcount_locktype_t: -Sequence counters with associated locks (``seqcount_LOCKTYPE_t``) +Sequence counters with associated locks (``seqcount_LOCKNAME_t``) ----------------------------------------------------------------- As discussed at :ref:`seqcount_t`, sequence count write side critical @@ -115,27 +115,26 @@ The following sequence counters with ass - ``seqcount_mutex_t`` - ``seqcount_ww_mutex_t`` -The plain seqcount read and write APIs branch out to the specific -seqcount_LOCKTYPE_t implementation at compile-time. This avoids kernel -API explosion per each new seqcount LOCKTYPE. +The sequence counter read and write APIs can take either a plain +seqcount_t or any of the seqcount_LOCKNAME_t variants above. -Initialization (replace "LOCKTYPE" with one of the supported locks):: +Initialization (replace "LOCKNAME" with one of the supported locks):: /* dynamic */ - seqcount_LOCKTYPE_t foo_seqcount; - seqcount_LOCKTYPE_init(&foo_seqcount, &lock); + seqcount_LOCKNAME_t foo_seqcount; + seqcount_LOCKNAME_init(&foo_seqcount, &lock); /* static */ - static seqcount_LOCKTYPE_t foo_seqcount = - SEQCNT_LOCKTYPE_ZERO(foo_seqcount, &lock); + static seqcount_LOCKNAME_t foo_seqcount = + SEQCNT_LOCKNAME_ZERO(foo_seqcount, &lock); /* C99 struct init */ struct { - .seq = SEQCNT_LOCKTYPE_ZERO(foo.seq, &lock), + .seq = SEQCNT_LOCKNAME_ZERO(foo.seq, &lock), } foo; Write path: same as in :ref:`seqcount_t`, while running from a context -with the associated LOCKTYPE lock acquired. +with the associated write serialization lock acquired. Read path: same as in :ref:`seqcount_t`.