All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Amol Grover <frextrite@gmail.com>
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	rcu@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-kernel-mentees@lists.linuxfoundation.org,
	Shuah Khan <skhan@linuxfoundation.org>,
	Madhuparna Bhowmik <madhuparnabhowmik04@gmail.com>
Subject: Re: [PATCH] doc: listRCU: Add some more listRCU patterns in the kernel
Date: Tue, 3 Dec 2019 06:41:32 -0700	[thread overview]
Message-ID: <20191203064132.38d75348@lwn.net> (raw)
In-Reply-To: <20191203063941.6981-1-frextrite@gmail.com>

On Tue,  3 Dec 2019 12:09:43 +0530
Amol Grover <frextrite@gmail.com> 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

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Corbet <corbet@lwn.net>
To: Amol Grover <frextrite@gmail.com>
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
	linux-doc@vger.kernel.org, Lai Jiangshan <jiangshanlai@gmail.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [Linux-kernel-mentees] [PATCH] doc: listRCU: Add some more listRCU patterns in the kernel
Date: Tue, 3 Dec 2019 06:41:32 -0700	[thread overview]
Message-ID: <20191203064132.38d75348@lwn.net> (raw)
In-Reply-To: <20191203063941.6981-1-frextrite@gmail.com>

On Tue,  3 Dec 2019 12:09:43 +0530
Amol Grover <frextrite@gmail.com> 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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

  reply	other threads:[~2019-12-03 13:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03  6:39 [PATCH] doc: listRCU: Add some more listRCU patterns in the kernel Amol Grover
2019-12-03  6:39 ` [Linux-kernel-mentees] " Amol Grover
2019-12-03 13:41 ` Jonathan Corbet [this message]
2019-12-03 13:41   ` Jonathan Corbet
2019-12-04  8:24   ` Amol Grover
2019-12-04  8:24     ` [Linux-kernel-mentees] " Amol Grover
2019-12-04 14:48     ` Jonathan Corbet
2019-12-04 14:48       ` [Linux-kernel-mentees] " Jonathan Corbet
2019-12-04 15:39       ` Joel Fernandes
2019-12-04 15:39         ` [Linux-kernel-mentees] " Joel Fernandes
2019-12-04 15:47         ` Jonathan Corbet
2019-12-04 15:47           ` [Linux-kernel-mentees] " Jonathan Corbet
2019-12-04 16:35           ` Joel Fernandes
2019-12-04 16:35             ` [Linux-kernel-mentees] " Joel Fernandes
2019-12-05 15:14             ` Amol Grover
2019-12-05 15:14               ` [Linux-kernel-mentees] " Amol Grover
2019-12-06  1:08               ` Joel Fernandes
2019-12-06  1:08                 ` [Linux-kernel-mentees] " Joel Fernandes
2019-12-06  8:07 ` [PATCH v2] " Amol Grover
2019-12-06  8:07   ` [Linux-kernel-mentees] " Amol Grover
2019-12-19 16:29   ` Jonathan Corbet
2019-12-19 16:29     ` [Linux-kernel-mentees] " Jonathan Corbet
2019-12-19 16:56     ` Paul E. McKenney
2019-12-19 16:56       ` [Linux-kernel-mentees] " Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191203064132.38d75348@lwn.net \
    --to=corbet@lwn.net \
    --cc=frextrite@gmail.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=madhuparnabhowmik04@gmail.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.