From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Dipankar Sarma <dipankar@in.ibm.com>,
Andrew Morton <akpm@osdl.org>,
Alan Stern <stern@rowland.harvard.edu>,
Eric Dumazet <dada1@cosmosbay.com>,
linux-kernel@vger.kernel.org
Subject: Re: PATCH? rcu_do_batch: fix a pure theoretical memory ordering race
Date: Mon, 4 Dec 2006 08:43:53 -0800 [thread overview]
Message-ID: <20061204164353.GA1793@linux.vnet.ibm.com> (raw)
In-Reply-To: <20061202212517.GA1199@oleg>
On Sun, Dec 03, 2006 at 12:25:17AM +0300, Oleg Nesterov wrote:
> On top of rcu-add-a-prefetch-in-rcu_do_batch.patch
>
> rcu_do_batch:
>
> struct rcu_head *next, *list;
>
> while (list) {
> next = list->next; <------ [1]
> list->func(list);
> list = next;
> }
>
> We can't trust *list after list->func() call, that is why we load list->next
> beforehand. However I suspect in theory this is not enough, suppose that
>
> - [1] is stalled
>
> - list->func() marks *list as unused in some way
>
> - another CPU re-uses this rcu_head and dirties it
The memory allocators are required to do whatever is required to
ensure that the first CPU is no longer accessing the memory before
allocating it to the second CPU.
So we should not need to do this -- and if we did, we would have
serious problems throughout the kernel.
Thanx, Paul
> - [1] completes and gets a wrong result
>
> This means we need a barrier in between. mb() looks more suitable, but I think
> rmb() should suffice.
>
> Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
>
> --- 19-rc6/kernel/rcupdate.c~rdp 2006-12-02 20:46:03.000000000 +0300
> +++ 19-rc6/kernel/rcupdate.c 2006-12-02 21:04:12.000000000 +0300
> @@ -236,6 +236,8 @@ static void rcu_do_batch(struct rcu_data
> list = rdp->donelist;
> while (list) {
> next = list->next;
> + /* complete the load above before we call ->func() */
> + smp_rmb();
> prefetch(next);
> list->func(list);
> list = next;
>
prev parent reply other threads:[~2006-12-04 16:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-02 21:25 PATCH? rcu_do_batch: fix a pure theoretical memory ordering race Oleg Nesterov
2006-12-03 17:34 ` Eric Dumazet
2006-12-03 20:01 ` Oleg Nesterov
2006-12-03 20:34 ` Eric Dumazet
2006-12-03 22:12 ` Oleg Nesterov
2006-12-03 23:08 ` Eric Dumazet
2006-12-03 23:46 ` Oleg Nesterov
2006-12-04 16:43 ` Paul E. McKenney [this message]
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=20061204164353.GA1793@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@osdl.org \
--cc=dada1@cosmosbay.com \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=stern@rowland.harvard.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox