@jwseigh As always, much depends on your exact implementation. But what if the RSEQ reader picked up the pointer, took an unrelated long-running interrupt, took (and responded to) the membarrier IPI, then took another unrelated long-running interrupt? I do not believe that this would cause RSEQ to retry (though I might be missing something).
In that scenario, how is the updater to know that it should avoid reclaiming the object whose pointer the RSEQ reader will eventually store into its hazard pointer?
(I get the blog post: If you can uninterruptibly load and store the pointer, then membarrier() will either force the reader to see the new pointer or force the updater to see the updated hazard pointer.
I do not understand how your RSEQ trick works. Not yet, anyway.)