Re: [PATCH 1/2] Use faster check for modules in backtrace on 64bit

[Peter Zijlstra]

On Tue, Sep 30, 2014 at 10:10:00PM +0200, Andi Kleen wrote:
> > > Also I investigated it now, but we don't have RCU support for rbtrees.
> > > So it would need some kind of locking for the reader, which is a show
> > > stopper.
> > 
> > Nah, we can trivially do that with a seqlock. Not read side locking
> > required in the normal case.
> 
> I'm not convinced. It wouldn't surprise me if it was possible
> to generate endless cycles with rcu freed memory on some rebalancing
> operation.

I don't think so, every (tree) rotation still maintains the tree as a
tree, therefore downward iteration will always get you to the end.

You might temporarily run in circles until you observe the new pointers,
but that is not a problem, and strictly limited to however long it takes
for the new pointers to become visible on the iterating CPU.

Deletion should not be a problem either, if the deleted node retains
pointers, they'll point back into the tree, and by the previous
argument, downward iteration terminates.

> If you think I'm wrong please show working code.

That is unrelated to the above, you're just not willing to work on it.
Which is fine, then this problem will remain for a little while longer.

> Also please explain clearly for the module maintainers and me
> what the problem with my original simple trivially show
> to be correct solution is.

It is not correct, you yourself said there were false positives with it.
But the biggest issue is that its x86_64 only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/