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
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 [email protected]
> 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.
Followup to: <[email protected]>
By author: Nuno Monteiro <[email protected]>
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
>>>>> "Peter" == H Peter Anvin <[email protected]> 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
On Tue, 2 Mar 2004, James H. Cloos Jr. wrote:
> >>>>> "Peter" == H Peter Anvin <[email protected]> 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.
James H. Cloos Jr. wrote:
>>>>>>"Peter" == H Peter Anvin <[email protected]> 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.
>>>>> "Richard" == Richard B Johnson <[email protected]> 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
> 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.
Followup to: <1078254284.2232.385.camel@cube>
By author: Albert Cahalan <[email protected]>
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
"H. Peter Anvin" <[email protected]> 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) ||
_
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.
...
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
Andrew Morton wrote:
> "H. Peter Anvin" <[email protected]> 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
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