From owner-freebsd-bugs@FreeBSD.ORG Sun Aug 19 08:50:02 2007 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 4B73416A41B for ; Sun, 19 Aug 2007 08:50: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 298AF13C45A for ; Sun, 19 Aug 2007 08:50: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.1/8.14.1) with ESMTP id l7J8o24I090753 for ; Sun, 19 Aug 2007 08:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7J8o1xj090752; Sun, 19 Aug 2007 08:50:02 GMT (envelope-from gnats) Resent-Date: Sun, 19 Aug 2007 08:50:02 GMT Resent-Message-Id: <200708190850.l7J8o1xj090752@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, Ighighi Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC0F216A421 for ; Sun, 19 Aug 2007 08:46:58 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id AAB9113C48A for ; Sun, 19 Aug 2007 08:46:58 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l7J8kw83035536 for ; Sun, 19 Aug 2007 08:46:58 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.1/8.14.1/Submit) id l7J8kwR1035535; Sun, 19 Aug 2007 08:46:58 GMT (envelope-from nobody) Message-Id: <200708190846.l7J8kwR1035535@www.freebsd.org> Date: Sun, 19 Aug 2007 08:46:58 GMT From: Ighighi To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/115619: Unfinished (uncompliant?) support for POSIX shared memory X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2007 08:50:02 -0000 >Number: 115619 >Category: kern >Synopsis: Unfinished (uncompliant?) support for POSIX shared memory >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Aug 19 08:50:01 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Ighighi >Release: 6.2-STABLE >Organization: >Environment: FreeBSD orion 6.2-STABLE FreeBSD 6.2-STABLE #0: Fri Aug 17 22:35:58 VET 2007 root@orion:/usr/obj/usr/src/sys/CUSTOM i386 >Description: Take a look at the minimalist file-based support in src/lib/libc/gen/posixshm.c: http://www.FreeBSD.org/cgi/cvsweb.cgi/~checkout~/src/lib/libc/gen/posixshm.c and the POSIX pages for shm_open() at shm_unlink(): http://www.opengroup.org/onlinepubs/000095399/functions/shm_open.html http://www.opengroup.org/onlinepubs/000095399/functions/shm_unlink.html Quoting the POSIX shm_open() page: "If name begins with the slash character, then processes calling shm_open() with the same value of name refer to the same shared memory object, as long as that name has not been removed. If name does not begin with the slash character, the the effect is implementation-defined. The interpretation of slash characters other than the leading slash character in name is implementation-defined." The only portable way to create a POSIX shared memory object is using "/[^/]*" (in regexp format) for names, but it's impossible in FreeBSD unless you're a root user since it directly uses the root filesystem. If, on the other hand, we're the root user, the root filesystem must be mounted read/write and we'd be somehow "violating" hier(7). The next paragraph of the same POSIX shm_open says: "The FD_CLOEXEC file descriptor flag associated with the new file descriptor is set." This isn't currently done on FreeBSD. >How-To-Repeat: >Fix: A possible solution for the first problem would be to dedicate a configurable (via a sysctl() or getenv() or whatever) directory, at least for "/[^/]*" names, that could be optionally mounted in memory for speed. It is more or less like /dev/shm on some Linux distros, but it could be done cleaner and better. It appears Darwin implemented both shm_open() and shm_unlink() as system calls. [Open]Solaris uses /tmp and tries to avoid a ENAMETOOLONG by using a MD5 hash of the name and does the FD_CLOEXEC part. See shm.c and pos4obj.[ch] at: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/rt/ An excerpt from pos4obj.c: /* * If the path is path_max - strlen(type) characters or less, * the name of the file to use will be the path prefixed by * the type. * * In the special case where the path is longer than * path_max - strlen(type) characters, we create a string based on the * MD5 hash of the path. We prefix that string with a '.' to * make it obscure, and create a directory in objroot with * that name. In that directory, we create a directory named * after the type of object requested. Inside the type * directory, the filename will be the path of the object. This * prevents collisions in all namespaces. * * Example: * Let objroot = "/tmp/", path = "/", and type = ".MQD" * Let the MD5 hash of "" = "" * * The desired file is /tmp/./.MQD/ */ I could help extend the current support through libc, any comments are welcome. At the very least, the shm_open(3) manpage should contain a BUGS section warning the user of these problems. FWIW, most of this PR applies to DragonFly as well. >Release-Note: >Audit-Trail: >Unformatted: