Hi Davidlohr,
On 09/13/2016 10:33 AM, Davidlohr Bueso wrote:
@@ -1751,12 +1820,17 @@ SYSCALL_DEFINE4(semtimedop, int, semid,
struct sembuf __user *, tsops,
if (sop->sem_num >= max)
max = sop->sem_num;
if (sop->sem_flg & SEM_UNDO)
-undos = 1;
+
This is the main workhorse that deals with semop user calls
such that the waitforzero or semval update operations, on the
set, can complete on not as the sma currently stands. Currently,
the set is iterated twice (setting semval, then backwards for
the sempid value). Slowpaths, and particularly SEM
On Mon, 12 Sep 2016, Manfred Spraul wrote:
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
Hi Davidlohr,
On 09/12/2016 01:53 PM, Davidlohr Bueso wrote:
This is the main workhorse that deals with semop user calls
such that the waitforzero or semval update operations, on the
set, can complete on not as the sma currently stands. Currently,
the set is iterated twice (setting semval, then
This is the main workhorse that deals with semop user calls
such that the waitforzero or semval update operations, on the
set, can complete on not as the sma currently stands. Currently,
the set is iterated twice (setting semval, then backwards for
the sempid value). Slowpaths, and particularly SEM
5 matches
Mail list logo