Date: Wed, 04 Jul 2001 10:44:29 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Bruce Evans <bde@zeta.org.au> Cc: Ruslan Ermilov <ru@freebsd.org>, Alfred Perlstein <bright@sneakerz.org>, current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: TIOCSCTTY Message-ID: <200107040144.KAA05714@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Wed, 04 Jul 2001 01:15:17 %2B1000." <Pine.BSF.4.21.0107032328020.41126-100000@besplex.bde.org> References: <Pine.BSF.4.21.0107032328020.41126-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>The bug seems to be caused by a combination of sloppy code in moused, >dubious aliasing in syscons and a known bug in cnclose(): >1. moused opens /dev/consolectl before becoming a daemon. This shouldn't > be a problem, since /dev/consolectl should be a completely different device > from the controlling terminal (which is /dev/console, although you can't > really see that from the ps output since "consolectl" is a poorly chosen > name which is indistinguishable from "console" after ps truncates it to > 3 characters). However: >2. syscons.c makes /dev/consolectl a sort of alias for /dev/consolectl: > > dev = make_dev(&sc_cdevsw, SC_CONSOLECTL, > UID_ROOT, GID_WHEEL, 0600, "consolectl"); > dev->si_tty = sc_console_tty = ttymalloc(sc_console_tty); > > This obviously breaks the pstat output and complicates debugging (pstat > should display "console" instead of "consolectl"). It apparently also > breaks last-close stuff when /dev/console is closed. >3. cnclose() already has broken handling of controlling terminals when > /dev/console is last-closed while the physical device underlying the > console is open and /dev/console is a controlling terminal. > /dev/consolectl is different from the physical device underlying > /dev/console (even if the latter is /dev/ttyv0), and is not understood > by cnclose(), but I think the same problem and fix apply. [...] >I think I understand the details now: >- on i386's, sccnprobe() sets the physical device for /dev/console to > /dev/consolectl. Thus /dev/consolectl is more than "sort of" an > alias for /dev/console, and bug (3) bites. I don't understand the > minor detail that pstat prefers the "consolectl" alias. Yes, the dev_t (and its tty struct) for /dev/console and /dev/consolectl is one and the same. This has been so for a long time by now. Their key input and screen output take place in the same screen as ttyv0, though. >- on alphas, sccnattach() sets the physical device for /dev/console to > /dev/ttyv0. Thus the bugs are gratuitously different. When syscons was ported to alpha, it was done this way... I don't remember why. ;-( We may provide two separate copies of dev_t (and tty struct) for /dev/console and /dev/consolectl. (/dev/console's I/O will still be done in the same screen as ttyv0.) But, that won't entirely solve the bug (3), will it? /dev/console still can be accessed via /dev/console (major:0, minor:0) and via the underlaying dev_t (major:XX, minor:YY). (As a kludge, we can make /dev/console's underlaying dev_t invisible from the userland, so that it will never be open()ed directly. Ha, ha.) Kazu >I use the following fix for (3). This is not suitable for committing, >due to probable races clearing the state. E.g., p_session can apparently >change before d_close() returns, so my closing_ctty flag may become >invalid, but since there is no explicit locking it's not clear that >other fatal changes can't happen. Hopefully everything is protected >by Giant until d_close() blocks, but the code after d_close() blocks >isn't very careful about the state. It needs to be, because d_open() >can be called successfully while d_close() is blocked! Note that >d_close() can block for arbitrarily long waiting for output to drain, >and it is useful for d_open() to succeed while d_close() is busy, >if only to unblock the close by changing the drain wait time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107040144.KAA05714>