From owner-freebsd-bugs@FreeBSD.ORG Wed May 14 22:10:03 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6D731065672 for ; Wed, 14 May 2008 22:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CAE6D8FC14 for ; Wed, 14 May 2008 22:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4EMA20A053315 for ; Wed, 14 May 2008 22:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4EMA2bO053314; Wed, 14 May 2008 22:10:02 GMT (envelope-from gnats) Resent-Date: Wed, 14 May 2008 22:10:02 GMT Resent-Message-Id: <200805142210.m4EMA2bO053314@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Mike van der Schaar Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CC991065677 for ; Wed, 14 May 2008 22:01:57 +0000 (UTC) (envelope-from freebsd@lab.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id D141F8FC16 for ; Wed, 14 May 2008 22:01:56 +0000 (UTC) (envelope-from freebsd@lab.upc.edu) Received: from localhost (lab.eupvg.upc.es [147.83.140.219]) by dash.upc.es (8.14.1/8.13.1) with SMTP id m4EHHQLB011535 for FreeBSD-gnats-submit@freebsd.org; Wed, 14 May 2008 19:17:54 +0200 Message-Id: <200805141554.m4EFsdGh000994@legendre.labnet> Date: Wed, 14 May 2008 17:54:39 +0200 (CEST) From: Mike van der Schaar To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: kern/123685: p1003_1b.nsems can become negative/semaphore counter incorrect X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mike van der Schaar List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2008 22:10:03 -0000 >Number: 123685 >Category: kern >Synopsis: p1003_1b.nsems can become negative/semaphore counter incorrect >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed May 14 22:10:02 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Mike van der Schaar >Release: FreeBSD 7.0-RELEASE i386 >Organization: >Environment: System: FreeBSD legendre.labnet 7.0-RELEASE FreeBSD 7.0-RELEASE #1: Wed May 14 15:39:42 CEST 2008 root@legendre.labnet:/usr/obj/usr/src/sys/LEGENDRE i386 >Description: When a posix sempahore is created, but the number of semaphores is already at its maximum, it is immediately freed again in uipc_sem.c:sem_create():229. The nsems counter is not updated before freeing the semaphore. But in uipc_sem.c:sem_free():451 the semaphore counter is always decreased. This effectively allows the creation of more than 30 semaphores, while the counter stays at 30. When semaphores are then freed at a later point the counter will become negative. >How-To-Repeat: The program just forces more than 30 semaphores to be created. After running the semaphore counter should be at -5 (10 too many, only half of those are allowed). #include #include #include #include #include #include #include int main(void) { int i; char name[16]; sem_t *sem[40]; memset( sem, 0, sizeof(sem_t *)*40 ); for ( i = 0; i < 40; i++ ) { sprintf( name, "/sem_%.3d", i ); sem[i] = sem_open( name, O_CREAT|O_EXCL, S_IRUSR|S_IWUSR, 1 ); } for ( i = 0; i < 40; i++ ) { if ( sem[i] ) sem_close( sem[i] ); sprintf( name, "/sem_%.3d", i ); sem_unlink( name ); } return 0; } After executing : (legendre:~) mike> sysctl p1003_1b p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 1 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 200112 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 1 p1003_1b.realtime_signals: 200112 p1003_1b.semaphores: 0 p1003_1b.fsync: 0 p1003_1b.shared_memory_objects: 1 p1003_1b.synchronized_io: 0 p1003_1b.timers: 200112 p1003_1b.aio_listio_max: -1 p1003_1b.aio_max: -1 p1003_1b.aio_prio_delta_max: -1 p1003_1b.delaytimer_max: 2147483647 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 62 p1003_1b.sem_nsems_max: 30 p1003_1b.sem_value_max: -1 p1003_1b.sigqueue_max: 128 p1003_1b.timer_max: 32 p1003_1b.nsems: -5 >Fix: One solution would be to increase the counter directly after the semaphore is created and added to the list. If the check for the maximum number of semaphores can be moved up before creating and adding the semaphore, without affecting efficiency too much because of the extra mtx_lock, then that might be better. >Release-Note: >Audit-Trail: >Unformatted: