On Tue, Aug 12, 2014 at 02:41:51PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 12, 2014 at 02:39:36PM -0700, Paul E. McKenney wrote:
> > On Tue, Aug 12, 2014 at 09:06:21AM -0700, Paul E. McKenney wrote:
> > > On Tue, Aug 12, 2014 at 11:03:21AM +0530, Amit Shah wrote:
> >
> > [ . . . ]
> >
> > > > I know of only virtio-console doing this (via userspace only,
> > > > though).
> > >
> > > As in userspace within the guest? That would not work. The userspace
> > > that the qemu is running in might. There is a way to extract ftrace info
> > > from crash dumps, so one approach would be "sendkey alt-sysrq-c", then
> > > pull the buffer from the resulting dump. For all I know, there might also
> > > be some script that uses the qemu "x" command to get at the ftrace buffer.
> > >
> > > Again, I cannot reproduce this, and I have been through the code several
> > > times over the past few days, and am not seeing it. I could start
> > > sending you random diagnostic patches, but it would be much better if
> > > we could get the trace data from the failure.
> >
> > Hearing no objections, random patch #1. The compiler could in theory
> > cause trouble without this patch, so there is some possibility that
> > it is a fix.
>
> #2... This would have been a problem without the earlier patch, but
> who knows? (#1 moved from theoretically possible but not on x86 to
> maybe on x86 given a sufficiently malevolent compiler with the
> patch that you located with bisection.)
#3... This one is theoretically possible, but not on any system that has
a full barrier on lock acquisition. This code did not exist before the
patch you located via bisection, but on the other hand, given that you
were running only two CPUs, it should be dead code anyway. But who knows?
Thanx, Paul
------------------------------------------------------------------------
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 1da605740e8d..70bff565dab6 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2314,6 +2314,7 @@ wait_again:
atomic_long_add(rdp->nocb_gp_count, &rdp->nocb_follower_count);
atomic_long_add(rdp->nocb_gp_count_lazy,
&rdp->nocb_follower_count_lazy);
+ smp_mb__after_atomic(); /* Store *tail before wakeup. */
if (rdp != my_rdp && tail == &rdp->nocb_follower_head) {
/*
* List was empty, wake up the follower.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
