Messages in this thread | | | Date | Sun, 22 Sep 2013 12:42:05 +0200 | From | Manfred Spraul <> | Subject | Re: [PATCH] ipc/sem.c: fix update sem_otime when calling sem_op in semaphore initialization |
| |
Hi all,
On 09/22/2013 10:26 AM, Mike Galbraith wrote: > On Sun, 2013-09-22 at 10:17 +0200, Mike Galbraith wrote: >> On Sun, 2013-09-22 at 10:11 +0800, Jia He wrote: >>> In commit 0a2b9d4c,the update of semaphore's sem_otime(last semop time) >>> was removed because he wanted to move setting sem->sem_otime to one >>> place. But after that, the initial semop() will not set the otime >>> because its sem_op value is 0(in semtimedop,will not change >>> otime if alter == 1). >>> >>> the error case: >>> process_a(server) process_b(client) >>> semget() >>> semctl(SETVAL) >>> semop() >>> semget() >>> setctl(IP_STAT) >>> for(;;) { <--not successful here >>> check until sem_otime > 0 >>> } Good catch: Since commit 0a2b9d4c, wait-for-zero semops do not update sem_otime anymore.
Let's reverse that part of my commit and move the update of sem_otime back into perform_atomic_semop().
Jia: If perform_atomic_semop() updates sem_otime, then the update in do_smart_update() is not necessary anymore. Thus the whole logic with passing arround "semop_completed" can be removed, too. Are you interested in writing that patch?
>> Why not.. > (pokes evolution's don't-munge-me button) > > ipc,sem: Create semaphores with plausible sem_otime. Mike: no, your patch makes it worse: - wait-for-zero semops still don't update sem_otime - sem_otime is initialized to sem_ctime. That's not mentioned in the sysv standard.
-- Manfred
| |