Skip to content

Commit 4cbcb7e

Browse files
committed
Fix mislabeling of PROC_QUEUE->links as PGPROC, fixing UBSan on 32bit
ProcSleep() used a PGPROC* variable to point to PROC_QUEUE->links.next, because that does "the right thing" with SHMQueueInsertBefore(). While that largely works, it's certainly not correct and unnecessary - we can just use SHM_QUEUE* to point to the insertion point. Noticed when testing a 32bit of postgres with undefined behavior sanitizer. UBSan noticed that sometimes the supposed PGPROC wasn't sufficiently aligned (required since 46d6e5f, ensured indirectly, via ShmemAllocRaw() guaranteeing cacheline alignment). For now fix this by using a SHM_QUEUE* for the insertion point. Subsequently we should replace all the use of PROC_QUEUE and SHM_QUEUE with ilist.h, but that's a larger change that we don't want to backpatch. Backpatch to all supported versions - it's useful to be able to run postgres under UBSan. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20221117014230.op5kmgypdv2dtqsf@awork3.anarazel.de Backpatch: 11-
1 parent 80cd1a6 commit 4cbcb7e

File tree

1 file changed

+14
-10
lines changed
  • src/backend/storage/lmgr

1 file changed

+14
-10
lines changed

src/backend/storage/lmgr/proc.c

Lines changed: 14 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1068,11 +1068,11 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
10681068
uint32 hashcode = locallock->hashcode;
10691069
LWLock *partitionLock = LockHashPartitionLock(hashcode);
10701070
PROC_QUEUE *waitQueue = &(lock->waitProcs);
1071+
SHM_QUEUE *waitQueuePos;
10711072
LOCKMASK myHeldLocks = MyProc->heldLocks;
10721073
bool early_deadlock = false;
10731074
bool allow_autovacuum_cancel = true;
10741075
int myWaitStatus;
1075-
PGPROC *proc;
10761076
PGPROC *leader = MyProc->lockGroupLeader;
10771077
int i;
10781078

@@ -1114,21 +1114,24 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
11141114
* we are only considering the part of the wait queue before my insertion
11151115
* point.
11161116
*/
1117-
if (myHeldLocks != 0)
1117+
if (myHeldLocks != 0 && waitQueue->size > 0)
11181118
{
11191119
LOCKMASK aheadRequests = 0;
1120+
SHM_QUEUE *proc_node;
11201121

1121-
proc = (PGPROC *) waitQueue->links.next;
1122+
proc_node = waitQueue->links.next;
11221123
for (i = 0; i < waitQueue->size; i++)
11231124
{
1125+
PGPROC *proc = (PGPROC *) proc_node;
1126+
11241127
/*
11251128
* If we're part of the same locking group as this waiter, its
11261129
* locks neither conflict with ours nor contribute to
11271130
* aheadRequests.
11281131
*/
11291132
if (leader != NULL && leader == proc->lockGroupLeader)
11301133
{
1131-
proc = (PGPROC *) proc->links.next;
1134+
proc_node = proc->links.next;
11321135
continue;
11331136
}
11341137
/* Must he wait for me? */
@@ -1165,24 +1168,25 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
11651168
}
11661169
/* Nope, so advance to next waiter */
11671170
aheadRequests |= LOCKBIT_ON(proc->waitLockMode);
1168-
proc = (PGPROC *) proc->links.next;
1171+
proc_node = proc->links.next;
11691172
}
11701173

11711174
/*
1172-
* If we fall out of loop normally, proc points to waitQueue head, so
1173-
* we will insert at tail of queue as desired.
1175+
* If we iterated through the whole queue, cur points to the waitQueue
1176+
* head, so we will insert at tail of queue as desired.
11741177
*/
1178+
waitQueuePos = proc_node;
11751179
}
11761180
else
11771181
{
11781182
/* I hold no locks, so I can't push in front of anyone. */
1179-
proc = (PGPROC *) &(waitQueue->links);
1183+
waitQueuePos = &waitQueue->links;
11801184
}
11811185

11821186
/*
1183-
* Insert self into queue, ahead of the given proc (or at tail of queue).
1187+
* Insert self into queue, at the position determined above.
11841188
*/
1185-
SHMQueueInsertBefore(&(proc->links), &(MyProc->links));
1189+
SHMQueueInsertBefore(waitQueuePos, &MyProc->links);
11861190
waitQueue->size++;
11871191

11881192
lock->waitMask |= LOCKBIT_ON(lockmode);

0 commit comments

Comments
 (0)