From owner-freebsd-bugs@FreeBSD.ORG Sat May 5 13:00:21 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC135106564A for ; Sat, 5 May 2012 13:00:21 +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 6C67C8FC1B for ; Sat, 5 May 2012 13:00:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q45D0LWA051341 for ; Sat, 5 May 2012 13:00:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q45D0LBa051340; Sat, 5 May 2012 13:00:21 GMT (envelope-from gnats) Resent-Date: Sat, 5 May 2012 13:00:21 GMT Resent-Message-Id: <201205051300.q45D0LBa051340@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, Jukka Ukkonen Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6C281065672 for ; Sat, 5 May 2012 12:51:34 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 986788FC17 for ; Sat, 5 May 2012 12:51:34 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q45CpYNZ052900 for ; Sat, 5 May 2012 12:51:34 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q45CpYa1052899; Sat, 5 May 2012 12:51:34 GMT (envelope-from nobody) Message-Id: <201205051251.q45CpYa1052899@red.freebsd.org> Date: Sat, 5 May 2012 12:51:34 GMT From: Jukka Ukkonen To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/167612: The portal file system gets stuck inside portal_open(). ("1 extra fds") 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: Sat, 05 May 2012 13:00:21 -0000 >Number: 167612 >Category: kern >Synopsis: The portal file system gets stuck inside portal_open(). ("1 extra fds") >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat May 05 13:00:21 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Jukka Ukkonen >Release: 9.0-STABLE >Organization: --- >Environment: FreeBSD sleipnir 9.0-STABLE FreeBSD 9.0-STABLE #0: Sat May 5 10:19:05 EEST 2012 root@sleipnir:/usr/obj/usr/src/sys/Sleipnir amd64 >Description: All attempts to refer to any file under the mounted portal file system end up waiting indefinitely. Actually the portal ends up reading STDIN while it should be reading from a command. E.g. the following command should simply list the output from who, but instead it does nothing until ctrl-D is given on the tty... cat /p/pipe/usr/bin/who At the same time the following complaint gets written to syslog... May 5 15:28:36 sleipnir kernel: portal_open: 1 extra fds Apparently the faulty takes place and gets also partially handled within the following snippet of code in portal_vnops.c ... cmsg = mtod(cm, struct cmsghdr *); newfds = (cmsg->cmsg_len - sizeof(*cmsg)) / sizeof (int); if (newfds == 0) { error = ECONNREFUSED; goto bad; } /* * At this point the rights message consists of a control message * header, followed by a data region containing a vector of * integer file descriptors. The fds were allocated by the action * of receiving the control message. */ ip = (int *) (cmsg + 1); fd = *ip++; if (newfds > 1) { /* * Close extra fds. */ int i; printf("portal_open: %d extra fds\n", newfds - 1); for (i = 1; i < newfds; i++) { portal_closefd(td, *ip); ip++; } } It seems that newfds gets calculated wrong and fd gets picked too early in the message. After that the correct fd gets treated as extra and closed. >How-To-Repeat: See full description above. >Fix: Apparently some further jugglery with the control message is needed to get the data alignment right. At the time of this writing I do not have a patch. >Release-Note: >Audit-Trail: >Unformatted: