Strange /dev/tty behaviour on 7.0-PRELEASE

Jesper Louis Andersen jesper.louis.andersen at gmail.com
Thu Jan 17 16:44:16 PST 2008


I am certainly not a kernel hacker, so I might be totally off, but I have
found some behaviour of the 7.0-PRELEASE kernel
that perplexes me. First, I am on a kernel from

FreeBSD ogre 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #9: Thu Jan 17 23:34:07
CET 2008     root at ogre:/usr/obj/usr/src/sys/OGRE  amd64

Just built. Now, I installed /usr/ports/devel/plan9port on the system.
Ignore the ONLY_FOR_ARCH i386, comment it out on amd64 and let it compile
(if you are on i386 I have the same problem there, so it is not only
affecting the amd64 arch. I have no access to a sparc64 at the moment). When
this has compiled add /usr/local/plan9/bin to your $PATH and execute acme(1)
(Rob Pike's text editor btw). Then execute the win(1) command via

9 win rc

(yes, the 9 is a shell script from /usr/local/plan9/bin which shoves in some
plumbing before invocation, so you must remember to add it)

to get an rc-shell directly into acme. This makes for some really strange
behaviour on my system. whenever I need to get access to a pty/tty things
lock up for me. I have the following strange thing in /dev

ogre% ls -l /dev
total 2
[SNIP]
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty
crw-rw-rw-  1 root    wheel       1,  46 Jan 18 00:56 tty

... which I am pretty sure is bad. I also wondered why my zsh(1) invocation
failed to do anything, so enter ktrace/kdump of a zsh invocation:

 1319 zsh      RET   sigaction 0
  1319 zsh      CALL  sigaction(SIGINT,0x7fffffffe530,0)
  1319 zsh      RET   sigaction 0
  1319 zsh      CALL  sigaction(SIGINT,0x7fffffffe530,0)
  1319 zsh      RET   sigaction 0
  1319 zsh      CALL  sigaction(SIGINT,0x7fffffffe530,0)
  1319 zsh      RET   sigaction 0
  1319 zsh      CALL  sigprocmask(SIG_BLOCK,0x3b8fab60,0x3b8fab90)
  1319 zsh      RET   sigprocmask 0
  1319 zsh      CALL  sigprocmask(SIG_BLOCK,0x3b8fab60,0x3b8fab90)
  1319 zsh      RET   sigprocmask 0
  1319 zsh      CALL  sigprocmask(SIG_BLOCK,0x3b8fab60,0x3b8fab90)
  1319 zsh      RET   sigprocmask 0
  1319 zsh      CALL  sigprocmask(SIG_BLOCK,0x3b8fab60,0x3b8fab90)
  1319 zsh      RET   sigprocmask 0
  1319 zsh      CALL
open(0x542930,O_WRONLY|O_CREAT|O_TRUNC|O_NOCTTY,S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)
  1319 zsh      NAMI  "/dev/tty"

Hmmm. At this point the system is barely usable. Almost everything you wish
to play with hangs. What I do not like about it is that it works like an
effective DOS on the system because it would seem like everybody would be
able to do something like this (no root required at all). The problem is
deterministic with the above usage of acme+win on amd64 and i386. I don't
know if it is present on 6.x or some earlier 7.0-FOO release since I just
recently began playing with the devel/plan9port port.

And now for the questions:

* Is this a bug or a feature? In the case it is a feature, can anybody point
me to the explanation or explain it? I would be grateful for it and I think
there may be more readers that would.

* Should it be PR'ed?

* Is there some way to fix the behaviour?

J.


More information about the freebsd-current mailing list