On 2015-05-27 15:39:14 -0400, Robert Haas wrote:
> On Mon, May 25, 2015 at 10:05 PM, Andres Freund <andres@anarazel.de> wrote:
> > Hm. So we have a *occasional* stack size exceeded failure and an
> > occasional spinlock error in test_shm_mq. I'm inclined to think that
> > this is a shm_mq problem, and not a more general locking problem - it
> > seems likely, but not guaranteed, that that'd have materialized
> > elsewhere.
>
> I think the problem might be that the spinlock-based memory barrier is
> not re-entrant. Suppose some kind of barrier operation is in process,
> and we've acquired the dummy spnlock but not yet released it. Just
> then, we receive a signal. Since the shm_mq code sets
> set_latch_on_sigusr1, procsignal_sigusr1_handler will set MyLatch.
> SetLatch now includes barrier operations, so we'll try to acquire and
> release the spinlock despite already holding it. Oops.
Oh wow, that's bad, and could explain a couple of the problems we're
seing. One possible way to fix is to replace the sequence with if
(!TAS(spin)) S_UNLOCK();. But that'd mean TAS() has to be a barrier,
even if the lock isn't free - which e.g. isn't the case for PowerPC's
implementation :(