Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 30 Aug 2002 17:01:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 30 Aug 2002 17:01:10 -0400 Received: from mx.nlm.nih.gov ([130.14.22.48]:38114 "EHLO mx.nlm.nih.gov") by vger.kernel.org with ESMTP id ; Fri, 30 Aug 2002 17:01:09 -0400 Message-ID: <3D6FDDE9.34C86464@ncbi.nlm.nih.gov> Date: Fri, 30 Aug 2002 17:04:41 -0400 From: Anton Lavrentiev Organization: NCBI NIH X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en, ru MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, lavr@ncbi.nlm.nih.gov CC: cpp-core@ncbi.nlm.nih.gov, torvalds@transmeta.com Subject: BUG:: IPC/semop clobbers PID of the last process performed semop() on the semaphore References: <3CBB23A8.80C0550F@ncbi.nlm.nih.gov> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2555 Lines: 67 Dear Linux Developers: I reported this bug a while ago but seems that it is still there. If "wait for zero" on the IPC semaphore is going to be blocked, then it clobbers PID of the last process, which operated on semaphore, actually reverting the PID to be the PID of the last but one process that made an operation. In particular, if the syscall was interrupted by a signal, restarted, and interrupted again, the PID of last process operated on the semaphore (obtainable via semctl(...GETPID...)) becomes unconditionally zero. The bug comes from the following fragment of file (look at the lines marked with exclamation points) ipc/sem.c, try_atomic_semop(): --------------------------------------------------------------------------- if (!sem_op && curr->semval) /*!!!!!!*/ goto would_block; curr->sempid = (curr->sempid << 16) | pid; /*!!!!!!*/ ........ would_block: if (sop->sem_flg & IPC_NOWAIT) result = -EAGAIN; else result = 1; undo: while (sop >= sops) { curr = sma->sem_base + sop->sem_num; curr->semval -= sop->sem_op; curr->sempid >>= 16; /*!!!!!!*/ --------------------------------------------------------------------------- The simplest fix (that works!) is just to swap the "wait for zero" condition and PID backup, like this: curr->sempid = (curr->sempid << 16) | pid; if (!sem_op && curr->semval) goto would_block; Best regards, Anton Lavrentiev NCBI/NLM/NIH Bethesda MD 20894 P.S. There is a potential bug in the very idea of temporary saving of PID in the spare most significant word of "curr->sempid": if the user requests more that one operation on the same semaphore in the same "sem_op" block, and the fact of blocking is not figured out at the first operation, but later, than backup in 16 upper bits will not work, because there will be two (or more) 16-bit rshifts in restore operation, effectively zeroing "curr->sempid". On the other hand, this is a very odd (and rather "theoretical") situation, cause normally the fact of blocking is checked by "sem_op" first, prior to doing something else without further blocking. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/