Re: something funny about tty's on 2.6.4-rc1-mm1

Re: something funny about tty's on 2.6.4-rc1-mm1

[Albert Cahalan]

Andrew Morton writes:

> The (untested) first-fit patch I proposed uses
> a radix tree, so it should in fact be faster
> than the old code.
>
> Are you now thinking that we might need to
> change the pty allocator?

I just re-read Edgar Toernig's comment... oh yeah.
Contemplate BOTH parts of the utmp quote:

: char ut_id[4];     /* init id or abbrev. ttyname */
: ...
: xterm(1) and other terminal emulators directly create
: a USER_PROCESS record and generate the ut_id by using
: the last two letters of /dev/ttyp%c or by using p%d
: for /dev/pts/%d. If they find a DEAD_PROCESS for this
: id, they recycle it, otherwise they create a new entry.

The utmp or utmpx record is about 1/2 a kilobyte.
The records get added to a file. They only get
recycled when the tty is recycled.

So that's a 20 bit minor, 9 bits of utmpx record size...
and thus a file that grows to half a gigabyte.

The reasons are adding up quickly:

1. half-gigabyte utmp,wtmp,wtmpx,utmpx file
2. breaks ut_id, even if 1000 ptys not used
3. a pain to type ("ps -t 1018493")
4. screws up column widths (ps, w, top...)
5. breaks old dev_t, even if 256 ttys not used

Re: something funny about tty's on 2.6.4-rc1-mm1

[Albert Cahalan]

> As RBJ said, ptys are now recycled in pid-like fashion,
> which means numbers won't be reused until wraparound
> happens.  This is good for security/fault tolerance,
> at least to some minor degree.

Ouch. It's bad for display and bad for typing.
What is easier to type?

ps -t pts/6
ps -t pts/1014962

(and yes, I really type these -- I don't have a
third hand to operate the mouse simultaneously)

What looks better?

UID        PID  PPID  C    SZ  RSS PSR STIME TTY          TIME CMD
albert    3339  2114  0   771 1684   0 Feb26 pts/6    00:00:00 bash
albert    3149  2514  0   771 1684   0 Feb26 pts/1004922 00:00:00 bash
albert    3835  2164  0   771 1684   0 Feb26 pts/8    00:00:00 bash
albert    4136  3114  0   771 1684   0 Feb26 pts/1013866 00:00:00 bash
albert    4739  2119  0   771 1684   0 Feb26 pts/9    00:00:00 bash

Better way:

Have a soft limit, initially set at 99. When 2/3 of
the ptys are in use, increase the soft limit to 999,
then to 9999, 99999, and finally to 999999.

This way, a plain 1-person desktop user would never
have a pty name longer than pts/99 and an insanely
busy server could go as high as needed.

Re: something funny about tty's on 2.6.4-rc1-mm1

[H. Peter Anvin]

Followup to:  <1078254284.2232.385.camel@cube>
By author:    Albert Cahalan <albert@users.sourceforge.net>
In newsgroup: linux.dev.kernel
>
> > As RBJ said, ptys are now recycled in pid-like fashion,
> > which means numbers won't be reused until wraparound
> > happens.  This is good for security/fault tolerance,
> > at least to some minor degree.
> 
> Ouch. It's bad for display and bad for typing.
> What is easier to type?
> 
> ps -t pts/6
> ps -t pts/1014962
> 
> (and yes, I really type these -- I don't have a
> third hand to operate the mouse simultaneously)
> 

(Programmable) tab completion, anyone?

	-hpa

Re: something funny about tty's on 2.6.4-rc1-mm1

[Edgar Toernig]

Albert Cahalan wrote:
>
> > As RBJ said, ptys are now recycled in pid-like fashion,
> > which means numbers won't be reused until wraparound
> > happens.  This is good for security/fault tolerance,
> > at least to some minor degree.
> 
> Ouch. It's bad for display and bad for typing.
> What is easier to type?
> 
> ps -t pts/6
> ps -t pts/1014962

IMHO more important: what about utmp?  It would become terribly
large.  Beside that, such huge numbers won't fit into ut_id.

Ciao, ET.

--[man utmp extract]--
...
    char ut_id[4];     /* init id or abbrev. ttyname */
...
    xterm(1)  and  other  terminal emulators directly create a
    USER_PROCESS record and generate the ut_id  by  using  the
    last  two  letters  of  /dev/ttyp%c  or  by  using p%d for
    /dev/pts/%d.  If they find a  DEAD_PROCESS  for  this  id,
    they  recycle  it,  otherwise they create a new entry.
...

Re: something funny about tty's on 2.6.4-rc1-mm1

[H. Peter Anvin]

Edgar Toernig wrote:
> 
> IMHO more important: what about utmp?  It would become terribly
> large.  Beside that, such huge numbers won't fit into ut_id.
> 
> Ciao, ET.
> 
> --[man utmp extract]--
> ...
>     char ut_id[4];     /* init id or abbrev. ttyname */
> ...
>     xterm(1)  and  other  terminal emulators directly create a
>     USER_PROCESS record and generate the ut_id  by  using  the
>     last  two  letters  of  /dev/ttyp%c  or  by  using p%d for
>     /dev/pts/%d.  If they find a  DEAD_PROCESS  for  this  id,
>     they  recycle  it,  otherwise they create a new entry.
> ...

That's broken for anything more than 1000 ptys, OR if you're using BSD 
and Unix98 ptys at the same time.

In other words, it's totally broken.

	-hpa

something funny about tty's on 2.6.4-rc1-mm1

[Nuno Monteiro]

Hi all,

I just took 2.6.4-rc1-mm1 for a spin, and there's definitely something  
funny about tty's. I left the computer unattended and had visitors over,  
among them small children who, apparently, decided I needed 350 aterm's  
open ;-). So, after they left I issued a 'killall -9 aterm' and fired up  
a new one, and here's something definitely interesting:

nuno@hobbes:~$ w
 18:33:56 up  4:08, 157 users,  load average: 0.03, 0.89, 1.51
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
nuno     :0        14:26   ?xdm?   3:55   0.95s gnome-session
nuno     pts/358   18:30    0.00s  0.10s  0.00s w


I know for a fact that I don't have 157 logged in users (well, there's  
only 45 processes running right now), and shouldn't pts' be recycled, and  
a lower number be assigned? The last kernel I ran was 2.6.3, and none of  
this happened.

My config is:

CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=512

and this is a plain jane static /dev -- not devfs nor udev. Despite the  
supposedly 157 users logged in, /dev/pts only contains '358', which is  
the one allocated to this instance of aterm right now.

nuno@hobbes:~$ ls -l /dev/pts
total 0
crw--w----    1 nuno     users    136, 102 Mar  1 18:41 358

In the mean time I'll fall back to 2.6.3.


Regards,


		Nuno

Re: something funny about tty's on 2.6.4-rc1-mm1

[Richard B. Johnson]

On Mon, 1 Mar 2004, Nuno Monteiro wrote:

>
> Hi all,
>
> I just took 2.6.4-rc1-mm1 for a spin, and there's definitely something
> funny about tty's. I left the computer unattended and had visitors over,
> among them small children who, apparently, decided I needed 350 aterm's
> open ;-). So, after they left I issued a 'killall -9 aterm' and fired up
> a new one, and here's something definitely interesting:
>
> nuno@hobbes:~$ w
>  18:33:56 up  4:08, 157 users,  load average: 0.03, 0.89, 1.51
> USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
> nuno     :0        14:26   ?xdm?   3:55   0.95s gnome-session
> nuno     pts/358   18:30    0.00s  0.10s  0.00s w
>

But `w` just reads /var/run/utmp to see who's logged on. It reads
/proc for info. If you just killed all the tasks as you state,
(with KILL instead of TERM) utmp probably doesn't have logout
entries. This seems like a `w` problem, not a kernel problem.

The pts ttys will get recycled just like pids. There is no
error here either.

>
> I know for a fact that I don't have 157 logged in users (well, there's
> only 45 processes running right now), and shouldn't pts' be recycled, and
> a lower number be assigned? The last kernel I ran was 2.6.3, and none of
> this happened.
>
> My config is:
>
> CONFIG_UNIX98_PTYS=y
> CONFIG_LEGACY_PTYS=y
> CONFIG_LEGACY_PTY_COUNT=512
>
> and this is a plain jane static /dev -- not devfs nor udev. Despite the
> supposedly 157 users logged in, /dev/pts only contains '358', which is
> the one allocated to this instance of aterm right now.
>
> nuno@hobbes:~$ ls -l /dev/pts
> total 0
> crw--w----    1 nuno     users    136, 102 Mar  1 18:41 358
>
> In the mean time I'll fall back to 2.6.3.
>
>
> Regards,
>
>
> 		Nuno
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: something funny about tty's on 2.6.4-rc1-mm1

[H. Peter Anvin]

Followup to:  <20040301184512.GA21285@hobbes.itsari.int>
By author:    Nuno Monteiro <nuno@itsari.org>
In newsgroup: linux.dev.kernel
> 
> I know for a fact that I don't have 157 logged in users (well, there's  
> only 45 processes running right now), and shouldn't pts' be recycled, and  
> a lower number be assigned? The last kernel I ran was 2.6.3, and none of  
> this happened.
> 
> My config is:
> 
> CONFIG_UNIX98_PTYS=y
> CONFIG_LEGACY_PTYS=y
> CONFIG_LEGACY_PTY_COUNT=512
> 
> and this is a plain jane static /dev -- not devfs nor udev. Despite the  
> supposedly 157 users logged in, /dev/pts only contains '358', which is  
> the one allocated to this instance of aterm right now.
> 
> nuno@hobbes:~$ ls -l /dev/pts
> total 0
> crw--w----    1 nuno     users    136, 102 Mar  1 18:41 358
> 
> In the mean time I'll fall back to 2.6.3.
> 

No need to, as there is no error (except that you need a newer libc or
ls to properly show the device number.)

As RBJ said, ptys are now recycled in pid-like fashion, which means
numbers won't be reused until wraparound happens.  This is good for
security/fault tolerance, at least to some minor degree.

	-hpa

Re: something funny about tty's on 2.6.4-rc1-mm1

[James H. Cloos Jr.]

>>>>> "Peter" == H Peter Anvin <hpa@zytor.com> writes:

Peter> As RBJ said, ptys are now recycled in pid-like fashion, which
Peter> means numbers won't be reused until wraparound happens.

Ouch.  I've been using the tty name in $HISTFILE for some time now
(at least on laptops and workstations); I do not see any reasonable
alternative to prevent overwriting while still saving history.

Will patching in the old behavior wrt re-use, while not disrupting
the other improvements, be a lot of work?  I've looked thru the src, 
but haven't yet spotted the point where the new pis number is chosen.

-JimC

Re: something funny about tty's on 2.6.4-rc1-mm1

[Richard B. Johnson]

On Tue, 2 Mar 2004, James H. Cloos Jr. wrote:

> >>>>> "Peter" == H Peter Anvin <hpa@zytor.com> writes:
>
> Peter> As RBJ said, ptys are now recycled in pid-like fashion, which
> Peter> means numbers won't be reused until wraparound happens.
>
> Ouch.  I've been using the tty name in $HISTFILE for some time now
> (at least on laptops and workstations); I do not see any reasonable
> alternative to prevent overwriting while still saving history.
>
> Will patching in the old behavior wrt re-use, while not disrupting
> the other improvements, be a lot of work?  I've looked thru the src,
> but haven't yet spotted the point where the new pis number is chosen.
>
> -JimC
>

I think /dev/tty, used in the context of any process, always refers
to the current processes terminal. You should not have to "hard-code"
a particular terminal.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: something funny about tty's on 2.6.4-rc1-mm1

[James H. Cloos Jr.]

>>>>> "Richard" == Richard B Johnson <root@chaos.analogic.com> writes:

Richard> I think /dev/tty, used in the context of any process, always
Richard> refers to the current processes terminal. You should not have
Richard> to "hard-code" a particular terminal.

No, I obviously was ambiguous.  I use:

export HISTFILE=~/.bash_history_${USER}_$(tty|sed s_^/dev/__|tr / _)

in my ~/.bashrc to ensure that each term has a unique and repeatable
HISTFILE.  I do not see any alternative tuple that is unique and
repeatable.

This change makes that idiom useless, with no alternative available.

On a multi-user server the change is clearly the right thing to do,
but on a workstation, laptop or handheld, where few ptys are typically
allocated, the case isn't so clear.

-JimC

Re: something funny about tty's on 2.6.4-rc1-mm1

[H. Peter Anvin]

James H. Cloos Jr. wrote:
>>>>>>"Peter" == H Peter Anvin <hpa@zytor.com> writes:
> 
> Peter> As RBJ said, ptys are now recycled in pid-like fashion, which
> Peter> means numbers won't be reused until wraparound happens.
> 
> Ouch.  I've been using the tty name in $HISTFILE for some time now
> (at least on laptops and workstations); I do not see any reasonable
> alternative to prevent overwriting while still saving history.
> 

????

> Will patching in the old behavior wrt re-use, while not disrupting
> the other improvements, be a lot of work?  I've looked thru the src, 
> but haven't yet spotted the point where the new pis number is chosen.

Not a lot of work, but the performance would suffer big time.

Re: something funny about tty's on 2.6.4-rc1-mm1

[Andrew Morton]

"H. Peter Anvin" <hpa@zytor.com> wrote:
>
> > Will patching in the old behavior wrt re-use, while not disrupting
> > the other improvements, be a lot of work?  I've looked thru the src, 
> > but haven't yet spotted the point where the new pis number is chosen.
> 
> Not a lot of work, but the performance would suffer big time.

The (untested) first-fit patch I proposed uses a radix tree, so it should
in fact be faster than the old code.

Are you now thinking that we might need to change the pty allocator?



 drivers/char/tty_io.c |   50 ++++++++++++++++++++++++++++++++++++++++----------
 1 files changed, 40 insertions(+), 10 deletions(-)

diff -puN drivers/char/tty_io.c~pty-allocation-first-fit drivers/char/tty_io.c
--- 25/drivers/char/tty_io.c~pty-allocation-first-fit	2004-02-26 18:59:21.000000000 -0800
+++ 25-akpm/drivers/char/tty_io.c	2004-02-26 18:59:58.000000000 -0800
@@ -91,6 +91,7 @@
 #include <linux/module.h>
 #include <linux/smp_lock.h>
 #include <linux/device.h>
+#include <linux/idr.h>
 
 #include <asm/uaccess.h>
 #include <asm/system.h>
@@ -125,6 +126,8 @@ struct tty_ldisc ldiscs[NR_LDISCS];	/* l
 #ifdef CONFIG_UNIX98_PTYS
 extern struct tty_driver *ptm_driver;	/* Unix98 pty masters; for /dev/ptmx */
 extern int pty_limit;		/* Config limit on Unix98 ptys */
+static struct idr allocated_ptys;
+static DECLARE_MUTEX(allocated_ptys_lock);
 #endif
 
 extern void disable_early_printk(void);
@@ -1305,6 +1308,14 @@ static void release_dev(struct file * fi
 	 */
 	flush_scheduled_work();
 
+#ifdef CONFIG_UNIX98_PTYS
+	if (filp->f_dentry->d_inode->i_rdev == MKDEV(TTYAUX_MAJOR,2)) {
+		down(&allocated_ptys_lock);
+		idr_remove(&allocated_ptys, idx);
+		up(&allocated_ptys_lock);
+	}
+#endif
+
 	/* 
 	 * The release_mem function takes care of the details of clearing
 	 * the slots and preserving the termios structure.
@@ -1329,7 +1340,7 @@ static int tty_open(struct inode * inode
 	struct tty_struct *tty;
 	int noctty, retval;
 	struct tty_driver *driver;
-	int index;
+	int index = -1;
 	dev_t device = inode->i_rdev;
 	unsigned short saved_flags = filp->f_flags;
 retry_open:
@@ -1372,22 +1383,32 @@ retry_open:
 #ifdef CONFIG_UNIX98_PTYS
 	if (device == MKDEV(TTYAUX_MAJOR,2)) {
 		/* find a device that is not in use. */
-		static int next_ptmx_dev = 0;
-		retval = -1;
+		down(&allocated_ptys_lock);
+		if (!idr_pre_get(&allocated_ptys, GFP_KERNEL)) {
+			up(&allocated_ptys_lock);
+			return -ENOMEM;
+		}
+		index = idr_get_new(&allocated_ptys, NULL);
+		if (index >= pty_limit) {
+			idr_remove(&allocated_ptys, index);
+			up(&allocated_ptys_lock);
+			return -EIO;
+		}
 		driver = ptm_driver;
-		while (driver->refcount < pty_limit) {
-			index = next_ptmx_dev;
-			next_ptmx_dev = (next_ptmx_dev+1) % driver->num;
-			if (!init_dev(driver, index, &tty))
-				goto ptmx_found; /* ok! */
+		retval = init_dev(driver, index, &tty);
+		if (retval) {
+			idr_remove(&allocated_ptys, index);
+			up(&allocated_ptys_lock);
+			return retval;
 		}
-		return -EIO; /* no free ptys */
-	ptmx_found:
 		set_bit(TTY_PTY_LOCK, &tty->flags); /* LOCK THE SLAVE */
 		if (devpts_pty_new(tty->link)) {
 			/* BADNESS - need to destroy both ptm and pts! */
+			idr_remove(&allocated_ptys, index);
+			up(&allocated_ptys_lock);
 			return -ENOMEM;
 		}
+		up(&allocated_ptys_lock);
 		noctty = 1;
 	} else
 #endif
@@ -1425,6 +1446,14 @@ got_driver:
 		       tty->name);
 #endif
 
+#ifdef CONFIG_UNIX98_PTYS
+		if (index != -1) {
+			down(&allocated_ptys_lock);
+			idr_remove(&allocated_ptys, index);
+			up(&allocated_ptys_lock);
+		}
+#endif
+
 		release_dev(filp);
 		if (retval != -ERESTARTSYS)
 			return retval;
@@ -2435,6 +2464,7 @@ static int __init tty_init(void)
 	kobject_register(&tty_kobj);
 
 #ifdef CONFIG_UNIX98_PTYS
+	idr_init(&allocated_ptys);
 	strcpy(ptmx_cdev.kobj.name, "dev.ptmx");
 	cdev_init(&ptmx_cdev, &tty_fops);
 	if (cdev_add(&ptmx_cdev, MKDEV(TTYAUX_MAJOR, 2), 1) ||

_

Re: something funny about tty's on 2.6.4-rc1-mm1

[H. Peter Anvin]

Andrew Morton wrote:
> "H. Peter Anvin" <hpa@zytor.com> wrote:
> 
>>>Will patching in the old behavior wrt re-use, while not disrupting
>>>the other improvements, be a lot of work?  I've looked thru the src, 
>>>but haven't yet spotted the point where the new pis number is chosen.
>>
>>Not a lot of work, but the performance would suffer big time.
> 
> The (untested) first-fit patch I proposed uses a radix tree, so it should
> in fact be faster than the old code.
> 
> Are you now thinking that we might need to change the pty allocator?
> 

I don't; I think this is a total joke.  The utmp issue is a more severe 
one; it might be reason to stick to the old behaviour at least for 2.6.

Linear scan of utmp and not removing entries on logout is clearly bad 
chicken.  Effectively utmp seems to be tied to the current structure, 
mostly because it tries to go beyond it -- it's so bad at doing so that 
it actually *causes* problems!

	-hpa