From owner-freebsd-current Tue Jul 3 18:35:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (Postfix) with ESMTP id A2ECB37B405; Tue, 3 Jul 2001 18:35:10 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from nantai.utsunomiya-u.ac.jp by nasu.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/26Jan01-1134AM) id f641YxB21803; Wed, 4 Jul 2001 10:34:59 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp by nantai.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/30Jan01-0241PM) id f641YwI28237; Wed, 4 Jul 2001 10:34:58 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:5u41PQjeJpWxYkDW3PanOKiIWacZW30k@zodiac.mech.utsunomiya-u.ac.jp [160.12.43.7]) by zodiac.mech.utsunomiya-u.ac.jp (8.9.3+3.2W/3.7W/zodiac-May2000) with ESMTP id KAA05714; Wed, 4 Jul 2001 10:44:30 +0900 (JST) Message-Id: <200107040144.KAA05714@zodiac.mech.utsunomiya-u.ac.jp> To: Bruce Evans Cc: Ruslan Ermilov , Alfred Perlstein , current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: TIOCSCTTY In-reply-to: Your message of "Wed, 04 Jul 2001 01:15:17 +1000." References: Date: Wed, 04 Jul 2001 10:44:29 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >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