Re: BUG #16990: Random PANIC in qemu user context
От | Andres Freund |
---|---|
Тема | Re: BUG #16990: Random PANIC in qemu user context |
Дата | |
Msg-id | 20210504070010.qopwlhomkyzvq6tu@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #16990: Random PANIC in qemu user context (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: