Hi Mike,
On 09/13/2013 08:12 AM, Mike Galbraith wrote:
goto again loop can and does induce livelock in -rt. Remove it.
spin_unlock_wait(lock) in -rt kernels takes/releases the lock in question, so
all it takes to create a self perpetuating loop is for one task to start the
ball rolling by taking the array lock, other tasks see this, and react by
take/release/retry endlessly.
I think your code inherits the race I just sent to you:
The test of complex_count must be after spin_is_locked().
http://marc.info/?l=linux-kernel&m=137919453307294
Could you check that?
Or alternatively: Is my proposed sem_lock() function -rt friendly?
locknum = -1;
+
+ if (nsops == 1 && !sma->complex_count) {
+ sem = sma->sem_base + sops->sem_num;
+ spin_lock(&sem->lock);
+ spin_unlock(&sma->sem_perm.lock);
+ locknum = sops->sem_num;
+ }
A clever idea:
If the decision that the slow path must be used proves to be a false
alarm, switch back to the fast path.
You can even move that block further up and skip the loop over all
per-semaphore arrays.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
