Re: BUG #16990: Random PANIC in qemu user context - Mailing list pgsql-bugs

From Andres Freund
Subject Re: BUG #16990: Random PANIC in qemu user context
Date
Msg-id 20210504070010.qopwlhomkyzvq6tu@alap3.anarazel.de
Whole thread Raw
In response to Re: BUG #16990: Random PANIC in qemu user context  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Hi,

On 2021-05-02 18:19:58 -0400, Tom Lane wrote:
> Paul Guyot <pguyot@kallisys.net> writes:
> > QEMU user emulation documentation mentions something specific to threading on ARM.
> > https://qemu.readthedocs.io/en/latest/user/main.html
> >> Threading:
> >> On Linux, QEMU can emulate the clone syscall and create a real host thread (with a separate virtual CPU) for each
emulatedthread. Note that not all targets currently emulate atomic operations correctly. x86 and Arm use a global lock
inorder to preserve their semantics.
 
> 
> Oooh, that's pretty suggestive.  I wonder just when that "global lock" is
> taken or released.  Maybe the timing of it is such that it interferes
> with ever seeing our lock as free?

The way it talks about threads makes me wonder if possibly cross-process
shared memory wasn't fully taken into account when using the emulated
atomics?

It's also not hard to imagine problems that exist for ll/sc style atomic
operations but not for cmpxchg/xadd/... - just acquiring a lock when ll
or sc are executing isn't sufficient, as it needs to fail if there are
any *non-atomic* writes to the relevant memory too. Which won't know to
acquire the lock...

Greetings,

Andres Freund



pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ALTER CONSTRAINT on a partitioned FK isn't working
Next
From: PG Bug reporting form
Date:
Subject: BUG #16991: regclass is not case sensitive causing "relation does not exist" error