Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1337567ybl; Tue, 3 Dec 2019 05:42:28 -0800 (PST) X-Google-Smtp-Source: APXvYqznNvm1UyoLSUXU8LqJtK+gQqdlRpBNnKQimKIFEgIgSK3784XkGlPUgAZ3krUMyK+rCixm X-Received: by 2002:aca:554d:: with SMTP id j74mr572415oib.92.1575380548506; Tue, 03 Dec 2019 05:42:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575380548; cv=none; d=google.com; s=arc-20160816; b=yyl+WdfAjamtLa5zE9Q1Z2AUxXTrhLw8oAP+OQq3VX4G6c17VNtYMCWPWYZcGfTDqC MSQ6uk1q+rqOTThNit7PJ+1odE+2pW9PbJjzuiYdLYzxuPmdR8Hh//Vh/5KqOuC6G7BA Gdx9j5H/Q0yQ7WrpmXT4o12DU33nI+EB8y4Zr+URDpXx/+6rqP/E5reI/P1hNe1qG7YN xv0b7sbFYtz7Rp3qiuOFqvvD9HNHyCDwaocNmJZVRB6Mnx/vdSxgLOfdZ306ZY3i4Mgq ko8CgenRBD2Wd5ft0Sydre1VLXHTJLaQL7tEINDXvN4HoQXZyoSilSIcRkuMoFC5ExTj aykA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=PppS9wax9eiv40mbOCxC/meyBbULZD/O6vgjuC09s3E=; b=vUUdnYuaTbthxuAKwwzHkiH2OkfFYz55Yde45J6/2zEvdET+ois2KT673xzaDIagBX jVPoA5D95KXRtHuVjY31Y2gXfcMZklZbgnHscg2s/q3lEChah/KJdHPyohe/Keo3fO6I iB4pDdondT3HMBqW6tTwEBbXoK/D/aTn2CfsNecxJxrd28+vjm+o9orIMSTXxTBjQ6j1 MJQzacDtZyA3sUsoekAfp8f4BADcIJUCGeSJeafT5S856xoZZVeJYG9RIR/0ePdF1j3h rp8Rv6EJeXK33KUx3OWwSbxo4hcK7Ad1aOcp0G190BP+8BH5+xTqu3yRttwH7YGAVGBo iZPA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a127si1351309oif.81.2019.12.03.05.42.16; Tue, 03 Dec 2019 05:42:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726505AbfLCNlf (ORCPT + 99 others); Tue, 3 Dec 2019 08:41:35 -0500 Received: from ms.lwn.net ([45.79.88.28]:52276 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725939AbfLCNlf (ORCPT ); Tue, 3 Dec 2019 08:41:35 -0500 Received: from lwn.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 91DBC60B; Tue, 3 Dec 2019 13:41:33 +0000 (UTC) Date: Tue, 3 Dec 2019 06:41:32 -0700 From: Jonathan Corbet To: Amol Grover Cc: "Paul E . McKenney" , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , rcu@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linuxfoundation.org, Shuah Khan , Madhuparna Bhowmik Subject: Re: [PATCH] doc: listRCU: Add some more listRCU patterns in the kernel Message-ID: <20191203064132.38d75348@lwn.net> In-Reply-To: <20191203063941.6981-1-frextrite@gmail.com> References: <20191203063941.6981-1-frextrite@gmail.com> Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 3 Dec 2019 12:09:43 +0530 Amol Grover wrote: > - Add more information about listRCU patterns taking examples > from audit subsystem in the linux kernel. > > - The initially written audit examples are kept, even though they are > slightly different in the kernel. > > - Modify inline text for better passage quality. > > - Fix typo in code-blocks and improve code comments. > > - Add text formatting (italics, bold and code) for better emphasis. Thanks for improving the documentation! I'll leave the RCU stuff to the experts, but I do have one request... [...] > +When a process exits, ``release_task()`` calls ``list_del_rcu(&p->tasks)`` under > +``tasklist_lock`` writer lock protection, to remove the task from the list of > +all tasks. The ``tasklist_lock`` prevents concurrent list additions/removals > +from corrupting the list. Readers using ``for_each_process()`` are not protected > +with the ``tasklist_lock``. To prevent readers from noticing changes in the list > +pointers, the ``task_struct`` object is freed only after one or more grace > +periods elapse (with the help of ``call_rcu()``). This deferring of destruction > +ensures that any readers traversing the list will see valid ``p->tasks.next`` > +pointers and deletion/freeing can happen in parallel with traversal of the list. > +This pattern is also called an **existence lock**, since RCU pins the object in > +memory until all existing readers finish. Please don't put function names as literal text. If you just say call_rcu(), it will be formatted correctly and cross-linked to the appropriate kerneldoc entry. Saying ``call_rcu()`` defeats that and clutters the plain-text reading experience. Thanks, jon