From owner-freebsd-bugs@FreeBSD.ORG Thu Apr 24 11:40:01 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44EB9243 for ; Thu, 24 Apr 2014 11:40:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21A5C1C83 for ; Thu, 24 Apr 2014 11:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3OBe0nx029836 for ; Thu, 24 Apr 2014 11:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3OBe0JP029835; Thu, 24 Apr 2014 11:40:00 GMT (envelope-from gnats) Resent-Date: Thu, 24 Apr 2014 11:40:00 GMT Resent-Message-Id: <201404241140.s3OBe0JP029835@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, Justin Cormack Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC8E7170 for ; Thu, 24 Apr 2014 11:34:36 +0000 (UTC) Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEF871C48 for ; Thu, 24 Apr 2014 11:34:36 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s3OBYaqc023595 for ; Thu, 24 Apr 2014 11:34:36 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s3OBYao3023589; Thu, 24 Apr 2014 11:34:36 GMT (envelope-from nobody) Message-Id: <201404241134.s3OBYao3023589@cgiserv.freebsd.org> Date: Thu, 24 Apr 2014 11:34:36 GMT From: Justin Cormack To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: kern/188952: read after revoke giving error not eof X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:40:01 -0000 >Number: 188952 >Category: kern >Synopsis: read after revoke giving error not eof >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Thu Apr 24 11:40:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Justin Cormack >Release: 10 >Organization: >Environment: FreeBSD freebsd10 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >Description: I have this ktrace of revoking a pty device: 43214 luajit-2.0.2 CALL posix_openpt(0x8002) 43214 luajit-2.0.2 RET posix_openpt 3 43214 luajit-2.0.2 CALL ioctl(0x3,TIOCPTMASTER,0) 43214 luajit-2.0.2 RET ioctl 0 43214 luajit-2.0.2 CALL ioctl(0x3,TIOCPTMASTER,0) 43214 luajit-2.0.2 RET ioctl 0 43214 luajit-2.0.2 CALL ioctl(0x3,TIOCPTMASTER,0) 43214 luajit-2.0.2 RET ioctl 0 43214 luajit-2.0.2 CALL ioctl(0x3,FIODGNAME,0x64560) 43214 luajit-2.0.2 RET ioctl 0 43214 luajit-2.0.2 CALL open(0xfebc8,0x8002,0) 43214 luajit-2.0.2 NAMI "/dev/pts/1" 43214 luajit-2.0.2 RET open 4 43214 luajit-2.0.2 CALL revoke(0xfebc8) 43214 luajit-2.0.2 NAMI "/dev/pts/1" 43214 luajit-2.0.2 RET revoke 0 43214 luajit-2.0.2 CALL read(0x4,0xa4170,0x1000) 43214 luajit-2.0.2 RET read -1 errno 6 Device not configured As you can see the revoke succeeds but the read is an error. The man page says: The revoke() system call invalidates all current open file descriptors in the system for the file named by path. Subsequent operations on any such descriptors fail, with the exceptions that a read() from a character device file which has been revoked returns a count of zero (end of file), and a close() system call will succeed. If the file is a special file for a device which is open, the device close function is called as if all open references to the file had been closed. So the read should be giving a count of zero not an error according to the docs (this happens eg in NetBSD), although maybe the sentence after is trying to tell me something else. I assume this is a documentation bug, but it could be that revoke(2) should conform to this, it is a non standard function so unclear. NetBSD and OpenBSD do conform to this documentation, with read(2) giving zero length. I have not tested with non pty devices. >How-To-Repeat: revoke(2) access to a pty then read(2). >Fix: >Release-Note: >Audit-Trail: >Unformatted: