[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090812132539.GD29200@redhat.com>
Date: Wed, 12 Aug 2009 16:25:40 +0300
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Gregory Haskins <gregory.haskins@...il.com>
Cc: netdev@...r.kernel.org, virtualization@...ts.linux-foundation.org,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>, hpa@...or.com,
paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCHv2 2/2] vhost_net: a kernel-level virtio server
On Wed, Aug 12, 2009 at 09:01:35AM -0400, Gregory Haskins wrote:
> I think I understand what your comment above meant: You don't need to
> do synchronize_rcu() because you can flush the workqueue instead to
> ensure that all readers have completed.
Yes.
> But if thats true, to me, the
> rcu_dereference itself is gratuitous,
Here's a thesis on what rcu_dereference does (besides documentation):
reader does this
A: sock = n->sock
B: use *sock
Say writer does this:
C: newsock = allocate socket
D: initialize(newsock)
E: n->sock = newsock
F: flush
On Alpha, reads could be reordered. So, on smp, command A could get
data from point F, and command B - from point D (uninitialized, from
cache). IOW, you get fresh pointer but stale data.
So we need to stick a barrier in there.
> and that pointer is *not* actually
> RCU protected (nor does it need to be).
Heh, if readers are lockless and writer does init/update/sync,
this to me spells rcu.
--
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists