This patch proposes still iterating the set twice, but the first
scan is read-only, and we perform the actual updates afterward,
once we know that the call will succeed. In order to not suffer
from the overhead of dealing with sops that act on the same sem_num,
such (rare )cases use perform_atomic_semop_slow(), which is exactly
what we have now. Duplicates are detected before grabbing sem_lock,
and uses simple a 64-bit variable to enable the sem_num-th bit.
Of course, this means that semops calls with a sem_num larger than
64 (SEMOPM_FAST, for now, as this is really about the nsops), will
take the _slow() alternative; but many real-world workloads only
work on a handful of semaphores in a given set, thus good enough
for the common case.
Can you create a 2nd definition, instead of reusing SEMOPM_FAST?
SEMOPM_FAST is about nsops, to limit stack usage.
Now you introduce a limit regarding sem_num.
+static int perform_atomic_semop(struct sem_array *sma, struct sem_queue *q)Do we really have to copy the whole function? Would it be possible to leave it as one function, with tests inside?
+{
@@ -1751,12 +1820,17 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf __user *, tsops,At least for nsops=2, sops[0].sem_num !=sops[1].sem_num can detect absense of duplicated ops regardless of the array size.
if (sop->sem_num >= max)
max = sop->sem_num;
if (sop->sem_flg & SEM_UNDO)
- undos = 1;
+ undos = true;
if (sop->sem_op != 0)
- alter = 1;
+ alter = true;
+ if (sop->sem_num < SEMOPM_FAST && !dupsop) {
+ if (dup & (1 << sop->sem_num))
+ dupsop = 1;
+ else
+ dup |= 1 << sop->sem_num;
+ }
}
Should we support that?