kern/188952: read after revoke giving error not eof

[Justin Cormack]

>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 at 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: