History log of /freebsd/sys/kern/tty.c (Results 226 – 250 of 858)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 74bb9e3a 30-Aug-2008 Ed Schouten <ed@FreeBSD.org>

Fix some edge cases in the TTY queues:

- In the current design, when a TTY decreases its baud rate, it tries to
shrink the queues. This may not always be possible, because it will
not free any b

Fix some edge cases in the TTY queues:

- In the current design, when a TTY decreases its baud rate, it tries to
shrink the queues. This may not always be possible, because it will
not free any blocks that are still filled with data.

Change the TTY queues to store a `quota' value as well, which means it
will not free any blocks when changing the baud rate, but when placing
blocks back into the queue. When the amount of blocks exceeds the
quota, they get freed.

It also fixes some edge cases, where TIOCSETA during read()/
write()-calls could actually make the queue a tiny bit bigger than in
normal cases.

- Don't leak blocks of memory when calling TIOCSETA when the device
driver abandons the TTY while allocating memory.

- Create ttyoutq_init() and ttyinq_init() to initialize the queues,
instead of initializing them by hand. The new TTY snoop driver also
creates an outq, so it's good to have a proper interface to do this.

Obtained from: //depot/projects/mpsafetty/...

show more ...


# ceef66c0 27-Aug-2008 Ed Schouten <ed@FreeBSD.org>

Properly unlock the init/lock-state devices when invoking TIOCSETA.

For some reason a return-statement crept into this code, where it
shouldn't belong. This means we didn't properly unlock the TTY b

Properly unlock the init/lock-state devices when invoking TIOCSETA.

For some reason a return-statement crept into this code, where it
shouldn't belong. This means we didn't properly unlock the TTY before
returning to userspace.

Submitted by: Tor Egge <tor egge cvsup no freebsd org>

show more ...


# 0f0a7c27 22-Aug-2008 Ed Schouten <ed@FreeBSD.org>

Fix two small bugs in tcsetattr().

- According to POSIX, tcsetattr() must not fail when any of the bits in
the structure are unsupported, but it must leave the unsupported flags
alone.

- The CI

Fix two small bugs in tcsetattr().

- According to POSIX, tcsetattr() must not fail when any of the bits in
the structure are unsupported, but it must leave the unsupported flags
alone.

- The CIGNORE flag (set by TCSASOFT, extension) was not cleared from
c_cflag, which means using it would cause it to be applied during its
entire lifespan. Eventually make sure we clear the flag.

I don't really like CIGNORE, but I think we must keep it alive right
now. With our new TTY layer, we don't actually need this mechanism,
because if you leave c_cflag, c_ispeed and c_ospeed alone, we won't make
a call into the device driver anyway.

Reported by: naddy
Tested by: naddy

show more ...


# 7dc843ca 22-Aug-2008 Ed Schouten <ed@FreeBSD.org>

Prevent VSTART flooding when turning on software flow control.

It turned out we transmitted VSTART after each successful read on a TTY
when software flow control was turned on. This was because of a

Prevent VSTART flooding when turning on software flow control.

It turned out we transmitted VSTART after each successful read on a TTY
when software flow control was turned on. This was because of a very
evil bug where we tested the TF_HIWAT_IN flag the other way around.

Reported by: Christian Weisgerber <naddy mips inka de>

show more ...


# bc093719 20-Aug-2008 Ed Schouten <ed@FreeBSD.org>

Integrate the new MPSAFE TTY layer to the FreeBSD operating system.

The last half year I've been working on a replacement TTY layer for the
FreeBSD kernel. The new TTY layer was designed to improve

Integrate the new MPSAFE TTY layer to the FreeBSD operating system.

The last half year I've been working on a replacement TTY layer for the
FreeBSD kernel. The new TTY layer was designed to improve the following:

- Improved driver model:

The old TTY layer has a driver model that is not abstract enough to
make it friendly to use. A good example is the output path, where the
device drivers directly access the output buffers. This means that an
in-kernel PPP implementation must always convert network buffers into
TTY buffers.

If a PPP implementation would be built on top of the new TTY layer
(still needs a hooks layer, though), it would allow the PPP
implementation to directly hand the data to the TTY driver.

- Improved hotplugging:

With the old TTY layer, it isn't entirely safe to destroy TTY's from
the system. This implementation has a two-step destructing design,
where the driver first abandons the TTY. After all threads have left
the TTY, the TTY layer calls a routine in the driver, which can be
used to free resources (unit numbers, etc).

The pts(4) driver also implements this feature, which means
posix_openpt() will now return PTY's that are created on the fly.

- Improved performance:

One of the major improvements is the per-TTY mutex, which is expected
to improve scalability when compared to the old Giant locking.
Another change is the unbuffered copying to userspace, which is both
used on TTY device nodes and PTY masters.

Upgrading should be quite straightforward. Unlike previous versions,
existing kernel configuration files do not need to be changed, except
when they reference device drivers that are listed in UPDATING.

Obtained from: //depot/projects/mpsafetty/...
Approved by: philip (ex-mentor)
Discussed: on the lists, at BSDCan, at the DevSummit
Sponsored by: Snow B.V., the Netherlands
dcons(4) fixed by: kan

show more ...


# bea45cdd 25-Jul-2008 Ed Schouten <ed@FreeBSD.org>

Move ttyinfo() into its own C file.

The ttyinfo() routine generates the fancy output when pressing ^T. Right
now it is stored in tty.c. In the MPSAFE TTY code it is already stored
in tty_info.c. To

Move ttyinfo() into its own C file.

The ttyinfo() routine generates the fancy output when pressing ^T. Right
now it is stored in tty.c. In the MPSAFE TTY code it is already stored
in tty_info.c. To make integration of the MPSAFE TTY code a little
easier, take the same approach.

This makes the TTY code a little bit more readable, because having the
proc_*/thread_* routines in tty.c is very distractful.

Approved by: philip (mentor)

show more ...


# 15822fcd 23-May-2008 Konstantin Belousov <kib@FreeBSD.org>

Rev. 1.274 put the ttyrel() call before the destroy_dev() in the
ttyfree(), freeing the tty. Since destroy_dev() may call d_purge()
cdevsw method, that is the ttypurge() for the tty, the code ends up

Rev. 1.274 put the ttyrel() call before the destroy_dev() in the
ttyfree(), freeing the tty. Since destroy_dev() may call d_purge()
cdevsw method, that is the ttypurge() for the tty, the code ends up
accessing freed tty structure.

Put the ttyrel() after destroy_dev() in the ttyfree. To prevent the
panic the rev. 1.274 provided fix for, check the TS_GONE in sysctl
handler and refuse to provide information on such tty.

Reported, debugging help and tested by: pho
DIscussed with and reviewed by: jhb
MFC after: 1 week

show more ...


# cc57af35 23-May-2008 Konstantin Belousov <kib@FreeBSD.org>

The dev_refthread() in the tty_gettp() may fail, because Giant is taken
in the giant_trick routines after the dev_refthread increments the
si_threadcount. Remove assert, do not perform dev_relthread(

The dev_refthread() in the tty_gettp() may fail, because Giant is taken
in the giant_trick routines after the dev_refthread increments the
si_threadcount. Remove assert, do not perform dev_relthread() for failed
dev_refthread(), and handle failure in the tty_gettp() callers (cdevsw
tty methods).

Before kern_conf.c 1.210 and 1.211, the kernel usually paniced in the
giant_trick routines dereferencing NULL cdevsw, not taking this fault.

Reported by: Vince Hoffman <jhary unsane co uk>
Debugging help and tested by: pho
Reviewed by: jhb
MFC after: 1 week

show more ...


# ca091c56 23-May-2008 Konstantin Belousov <kib@FreeBSD.org>

Use the t_state for the TS_GONE test.

Submitted by: jhb
MFC after: 3 days


# 8837b0dd 23-May-2008 Ed Schouten <ed@FreeBSD.org>

Move TTY unrelated bits out of <sys/tty.h>.

For some reason, the <sys/tty.h> header file also contains routines of the
clists and console that are used inside the TTY layer. Because the clists
are n

Move TTY unrelated bits out of <sys/tty.h>.

For some reason, the <sys/tty.h> header file also contains routines of the
clists and console that are used inside the TTY layer. Because the clists
are not only used by the TTY layer (example: various input drivers), we'd
better move the entire clist programming interface into <sys/clist.h>. Also
remove a declaration of nonexistent variable.

The <sys/tty.h> header also contains various definitions for the console
code (tty_cons.c). Also move these to <sys/cons.h>, because they are
not implemented inside the TTY layer.

While there, create separate malloc pools for the clist and console code.

Approved by: philip (mentor)

show more ...


# d61f3de6 15-Apr-2008 David Xu <davidxu@FreeBSD.org>

Implement POSIX function tcgetsid() which returns session id.

PR: stand/107561


# 374ae2a3 19-Mar-2008 Jeff Roberson <jeff@FreeBSD.org>

- Relax requirements for p_numthreads, p_threads, p_swtick, and p_nice from
requiring the per-process spinlock to only requiring the process lock.
- Reflect these changes in the proc.h documentat

- Relax requirements for p_numthreads, p_threads, p_swtick, and p_nice from
requiring the per-process spinlock to only requiring the process lock.
- Reflect these changes in the proc.h documentation and consumers throughout
the kernel. This is a substantial reduction in locking cost for these
fields and was made possible by recent changes to threading support.

show more ...


Revision tags: release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0
# 39033470 08-Jan-2008 John Baldwin <jhb@FreeBSD.org>

Close a race in the kern.ttys sysctl handler that resulted in panics in
dev2udev() when a tty was being detached concurrently with the sysctl
handler:
- Hold the 'tty_list_mutex' lock while we read a

Close a race in the kern.ttys sysctl handler that resulted in panics in
dev2udev() when a tty was being detached concurrently with the sysctl
handler:
- Hold the 'tty_list_mutex' lock while we read all the fields out of the
struct tty for copying out later. Previously the pty(4) and pts(4)
destroy routines could set t_dev to NULL, drop their reference on the
tty and destroy the cdev while the sysctl handler was attempting to
invoke dev2udev() on the cdev being destroyed. This happened when the
sysctl handler read the value of t_dev prior to it being set to NULL
either due to it being stale or due to timing races. By holding the
list lock we guarantee that the destroy routines will block in ttyrel()
in that case and not destroy the cdev until after we've copied all of our
data. We may see a NULL cdev pointer or we may see the previous value,
but the previous value will no longer point to a destroyed cdev if we
see it.
- Fix the ttyfree() routine used by tty device drivers in their detach
methods to use ttyrel() on the tty so we don't leak them. Also, fix it
to use the same order of operations as pty/pts destruction (set t_dev
NULL, ttyrel(), destroy_dev()) so it cooperates with the sysctl handler.

MFC after: 3 days
Tested by: avatar

show more ...


# e69aee31 20-Jul-2007 Konstantin Belousov <kib@FreeBSD.org>

ttyfree() frees the cdev(). But if there are pending kevents,
filt_ttyrdetach() etc would later attempt to dereference cdev->si_tty,
causing a 0xdeadc0de dereference. Change kn_hook value from cdev

ttyfree() frees the cdev(). But if there are pending kevents,
filt_ttyrdetach() etc would later attempt to dereference cdev->si_tty,
causing a 0xdeadc0de dereference. Change kn_hook value from cdev to
struct tty to avoid dereferencing freed cdev.

In ttygone(), wake up select(), sigio and kevent() users in addition
to the queue sleepers.

Return EV_EOF from kevent filters if TS_GONE is set.

Submitted by: peter
Tested by: Peter Holm
Approved by: re (kensmith)
MFC after: 2 weeks

show more ...


# 03d03260 01-Jul-2007 Jeff Roberson <jeff@FreeBSD.org>

- Use rufetchcalc() rather than calcru() in ttyinfo so that we get
correct system and user time stats.

Approved by: re
Reported by: kris
Discussed with: Attilio


# e411ce02 11-Jun-2007 Olivier Houchard <cognet@FreeBSD.org>

Re-acquire the PROC_SLOCK before calling calcru(), and release it after,
since calcru() expects it to be locked.

Reviewed by: attilio


# 26756b7a 10-Jun-2007 Matt Jacob <mjacob@FreeBSD.org>

The new compiler can't quite follow the logic of has_stime and
complains about using uninitialized tags in stime.


# 07a61420 05-Jun-2007 Jeff Roberson <jeff@FreeBSD.org>

Commit 9/14 of sched_lock decomposition.
- Attempt to return the ttyinfo() selection algorithm to something sane
as it has been broken and disabled for some time. Adapt this algorithm
in such

Commit 9/14 of sched_lock decomposition.
- Attempt to return the ttyinfo() selection algorithm to something sane
as it has been broken and disabled for some time. Adapt this algorithm
in such a way that it does not conflict with per-cpu scheduler locking.

Tested by: kris, current@
Tested on: i386, amd64, ULE, 4BSD, libthr, libkse, PREEMPTION, etc.
Discussed with: kris, attilio, kmacy, jhb, julian, bde (small parts each)

show more ...


Revision tags: release/6.2.0_cvs, release/6.2.0
# cd1b20d5 20-Dec-2006 Martin Blapp <mbr@FreeBSD.org>

Back out rev. 1.266. The real cause for the recent panics has been fixed
in rev. 1.267 and there is no need to keep this test.


# b472f371 19-Dec-2006 Martin Blapp <mbr@FreeBSD.org>

Giant might have been temporarily dropped while waiting for proctree_lock, allowing for an
intervening tty_close() that cleared tp->t_session.

Submitted by: tegge
MFC: 1 day


# e0b43fcf 19-Dec-2006 Martin Blapp <mbr@FreeBSD.org>

Add the tp->t_refcnt validity check back. There are still some race
conditions where tp->t_refcnt can go to zero.


# ad1e7d28 06-Dec-2006 Julian Elischer <julian@FreeBSD.org>

Threading cleanup.. part 2 of several.

Make part of John Birrell's KSE patch permanent..
Specifically, remove:
Any reference of the ksegrp structure. This feature was
never fully utilised and made t

Threading cleanup.. part 2 of several.

Make part of John Birrell's KSE patch permanent..
Specifically, remove:
Any reference of the ksegrp structure. This feature was
never fully utilised and made things overly complicated.
All code in the scheduler that tried to make threaded programs
fair to unthreaded programs. Libpthread processes will already
do this to some extent and libthr processes already disable it.

Also:
Since this makes such a big change to the scheduler(s), take the opportunity
to rename some structures and elements that had to be moved anyhow.
This makes the code a lot more readable.

The ULE scheduler compiles again but I have no idea if it works.

The 4bsd scheduler still reqires a little cleaning and some functions that now do
ALMOST nothing will go away, but I thought I'd do that as a separate commit.

Tested by David Xu, and Dan Eischen using libthr and libpthread.

show more ...


# 40dee3da 06-Nov-2006 Tor Egge <tegge@FreeBSD.org>

Don't drop reference to tty in tty_close() if TS_ISOPEN is already cleared.

Reviewed by: bde


# acd3428b 06-Nov-2006 Robert Watson <rwatson@FreeBSD.org>

Sweep kernel replacing suser(9) calls with priv(9) calls, assigning
specific privilege names to a broad range of privileges. These may
require some future tweaking.

Sponsored by: nCircle

Sweep kernel replacing suser(9) calls with priv(9) calls, assigning
specific privilege names to a broad range of privileges. These may
require some future tweaking.

Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>

show more ...


# 8460a577 26-Oct-2006 John Birrell <jb@FreeBSD.org>

Make KSE a kernel option, turned on by default in all GENERIC
kernel configs except sun4v (which doesn't process signals properly
with KSE).

Reviewed by: davidxu@


12345678910>>...35