Date: Thu, 24 Apr 2014 11:34:36 GMT From: Justin Cormack <justin@specialbusservice.com> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/188952: read after revoke giving error not eof Message-ID: <201404241134.s3OBYao3023589@cgiserv.freebsd.org> Resent-Message-ID: <201404241140.s3OBe0JP029835@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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<O_RDWR|O_NOCTTY>,<unused>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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404241134.s3OBYao3023589>