ed 2008-09-26 18:17:04 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
SVN rev 183386 on 2008-09-26 18:17:04Z by ed
Don't forget to initialize `int error' in ttydev_open().
I've had some reports in the past that opening an already opened
ed 2008-09-24 11:16:09 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
SVN rev 183324 on 2008-09-24 11:16:09Z by ed
Fix a crash when calling tty_rel_free() while draining during closure.
Yesterday I got two reports of potential crashes, r
ed 2008-09-22 19:25:14 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c tty_ttydisc.c
sys/sys tty.h ttydevsw.h ttydisc.h
usr.sbin/pstat pstat.8 pstat.c
Added files:
sys/sys ttyhook.h
Log:
SVN rev 183276 on
ed 2008-09-06 14:43:32 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
SVN rev 182815 on 2008-09-06 14:43:32Z by ed
Make TIOCCONS use priv_check() instead of checking /dev/console permissions.
As discussed with Robert on IRC, checking the
ed 2008-08-30 09:18:27 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c tty_inq.c tty_outq.c
sys/sys ttyqueue.h
Log:
SVN rev 182471 on 2008-08-30 09:18:27Z by ed
Fix some edge cases in the TTY queues:
- In the current design,
ed 2008-08-27 19:37:21 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
SVN rev 182296 on 2008-08-27 19:37:21Z by ed
Properly unlock the init/lock-state devices when invoking TIOCSETA.
For some reason a return-statement crept into this cod
ed 2008-08-22 21:27:37 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
SVN rev 182023 on 2008-08-22 21:27:37Z by ed
Fix two small bugs in tcsetattr().
- According to POSIX, tcsetattr() must not fail when any of the bits in
the structu
ed 2008-08-22 05:15:52 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
SVN rev 181993 on 2008-08-22 05:15:52Z by ed
Prevent VSTART flooding when turning on software flow control.
It turned out we transmitted VSTART after each successful r
kib 2008-05-30 11:13:30 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/kern tty.c
Log:
MFC rev. 1.280:
Rev. 1.274 put the ttyrel() call before the destroy_dev() in the
ttyfree(), freeing the tty. Since destroy_dev() may call d_purg
kib 2008-05-30 11:12:26 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/kern tty.c
Log:
MFC rev. 1.279:
The dev_refthread() in the tty_gettp() may fail, because Giant is taken
in the giant_trick routines after the dev_refthread incr
kib 2008-05-23 16:47:55 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
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
kib 2008-05-23 16:46:27 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
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
kib 2008-05-23 16:43:59 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
Use the t_state for the TS_GONE test.
Submitted by: jhb
MFC after: 3 days
Revision ChangesPath
1.278 +1 -1 src/sys/kern/tty.c
ed 2008-05-23 16:06:35 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c tty_cons.c tty_subr.c
sys/sys clist.h cons.h tty.h
Log:
Move TTY unrelated bits out of .
For some reason, the header file also contains routines of the
clis
On Jan 11, 2008 4:20 PM, John Baldwin <[EMAIL PROTECTED]> wrote:
> jhb 2008-01-12 00:20:06 UTC
>
> FreeBSD src repository
>
> Modified files:(Branch: RELENG_7_0)
> sys/kern tty.c
> Log:
> MFC: Close a race in the kern.ttys sysctl handler that resulted in pani
jhb 2008-01-12 00:20:06 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7_0)
sys/kern tty.c
Log:
MFC: Close a race in the kern.ttys sysctl handler that resulted in panics
in dev2udev().
Approved by:re (gnn)
Revision ChangesP
jhb 2008-01-12 00:19:33 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/kern tty.c
Log:
MFC: Close a race in the kern.ttys sysctl handler that resulted in panics
in dev2udev().
Approved by:re (gnn)
Revision ChangesPat
On Tue, 2008-01-08 at 04:53 +, John Baldwin wrote:
> jhb 2008-01-08 04:53:29 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/kern tty.c
> Log:
> Close a race in the kern.ttys sysctl handler that resulted in panics in
> dev2udev() when a tty was bein
jhb 2008-01-08 04:53:29 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
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
kib 2007-08-03 14:24:38 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/kern tty.c
Log:
MFC rev. 1.273, submitted by peter:
Change kn_hook value from cdev to struct tty to avoid dereferencing freed
cdev.
In ttygone(), wake up sele
kib 2007-07-20 09:41:54 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
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. Chan
jeff2007-07-01 00:17:59 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
- 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: Att
cognet 2007-06-11 21:05:42 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
Re-acquire the PROC_SLOCK before calling calcru(), and release it after,
since calcru() expects it to be locked.
Reviewed by:attilio
Revision ChangesPath
mjacob 2007-06-10 01:49:17 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
The new compiler can't quite follow the logic of has_stime and
complains about using uninitialized tags in stime.
Revision ChangesPath
1.270 +1 -1 src/sys
jeff2007-06-04 23:55:33 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
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
Hi,
Submitted by: tegge
Approved by:re (kensmith)
Hurray! Thanks for all the work and effort you put into this!
I'm glad we finally found the bad code !
Martin
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
On Thursday 21 December 2006 17:25, Martin Blapp wrote:
> mbr 2006-12-21 16:25:42 UTC
>
> FreeBSD src repository
>
> Modified files:(Branch: RELENG_6_2)
> sys/kern tty.c
> Log:
> MFC Rev. 1.267
>
> Retest tp->t_session because Giant might have been temporar
mbr 2006-12-21 16:26:28 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_5)
sys/kern tty.c
Log:
MFC Rev. 1.267
Retest tp->t_session because Giant might have been temporarily dropped
while waiting for proctree_lock, allowing for an interveni
mbr 2006-12-21 16:25:42 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6_2)
sys/kern tty.c
Log:
MFC Rev. 1.267
Retest tp->t_session because Giant might have been temporarily dropped
while waiting for proctree_lock, allowing for an interve
mbr 2006-12-21 16:24:22 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/kern tty.c
Log:
MFC Rev. 1.267
Retest tp->t_session because Giant might have been temporarily dropped
while waiting for proctree_lock, allowing for an interveni
Hi,
Ok, after a quick look at the patch (and this note) it makes more
sense to me, but then would not be cleaner to do something like:
sx_slock(&proctree_lock);
if (tp->t_session && tp->t_session->s_leader) { ...
}
sx_sunlock(&proctree_lock);
You mean to restore rev. 1.258 ?
http://www.fre
2006/12/20, Martin Blapp <[EMAIL PROTECTED]>:
Hi,
> Since proctree_lock is a sx lock which uses 2 condition variables,
> they alredy drop Giant (DROP_GIANT()) before sleeping. Are you secure
> it is the right thing to do here?
Sorry, the commit message was not 100% clear. It should have been:
2006/12/20, Martin Blapp <[EMAIL PROTECTED]>:
Hi,
> No, it drops Giant for all the time it sleeps.
> Maybe the race is somewhere else.
Yep, you are correct. It drops Giant for all the time.
And during this time the session could be cleared
somewhere else because we don't held GIANT anymore.
Hi,
No, it drops Giant for all the time it sleeps.
Maybe the race is somewhere else.
Yep, you are correct. It drops Giant for all the time.
And during this time the session could be cleared
somewhere else because we don't held GIANT anymore.
I don't understand your problem ?
Martin
___
2006/12/20, Martin Blapp <[EMAIL PROTECTED]>:
Hi,
> Since proctree_lock is a sx lock which uses 2 condition variables,
> they alredy drop Giant (DROP_GIANT()) before sleeping. Are you secure
> it is the right thing to do here?
Yes I am.
sx_slock() can call cv_wait() which later can call cv_wa
Hi,
Since proctree_lock is a sx lock which uses 2 condition variables,
they alredy drop Giant (DROP_GIANT()) before sleeping. Are you secure
it is the right thing to do here?
Yes I am.
sx_slock() can call cv_wait() which later can call cv_wait_unlock ...
if there is already a lock we need to
2006/12/19, Martin Blapp <[EMAIL PROTECTED]>:
mbr 2006-12-19 22:34:33 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
Giant might have been temporarily dropped while waiting for proctree_lock,
allowing for an
intervening tty_close() that cleared tp->t
Hi,
Since proctree_lock is a sx lock which uses 2 condition variables,
they alredy drop Giant (DROP_GIANT()) before sleeping. Are you secure
it is the right thing to do here?
Sorry, the commit message was not 100% clear. It should have been:
Retest a variable after sx_slock has been called.
mbr 2006-12-20 02:49:59 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
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.
Revision ChangesPath
1.268 +1 -1
In message: <[EMAIL PROTECTED]>
Martin Blapp <[EMAIL PROTECTED]> writes:
:
: Hi,
:
: > That is not what I was asking for. You said "there are races" but
: > didn't identify them. It would be helpful to know what these races are
: > so someone other than you doesn't need to guess why
mbr 2006-12-19 22:34:33 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
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
MF
Hi,
That is not what I was asking for. You said "there are races" but
didn't identify them. It would be helpful to know what these races are
so someone other than you doesn't need to guess why you made this change.
The reason for this is currently unknown (it shouldn't happen, tegges patch
Martin Blapp wrote:
>
> Hi Sam,
>
> I'll have got again a setup box in the next week and work hard
> with bde, gib and tegge to solve them. For RELENG_6_2 it's
> too late. I hope to get that small workaround again committed,
> but for more serios work we would have to delay 6.2 for half a
> year
Hi Sam,
I'll have got again a setup box in the next week and work hard
with bde, gib and tegge to solve them. For RELENG_6_2 it's
too late. I hope to get that small workaround again committed,
but for more serios work we would have to delay 6.2 for half a
year ;-)
The full tty locking stuff is
Martin Blapp wrote:
> mbr 2006-12-19 16:46:14 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/kern tty.c
> Log:
> Add the tp->t_refcnt validity check back. There are still some race
> conditions where tp->t_refcnt can go to zero.
Can you please identif
mbr 2006-12-19 16:46:14 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
Add the tp->t_refcnt validity check back. There are still some race
conditions where tp->t_refcnt can go to zero.
Revision ChangesPath
1.266 +1 -1 src/sys
tegge 2006-11-10 20:43:54 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/kern tty.c
Log:
MFC: Don't drop reference to tty in tty_close() if TS_ISOPEN is already
cleared.
Approved by:re (kensmith)
Revision ChangesP
tegge 2006-11-06 22:12:43 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
Don't drop reference to tty in tty_close() if TS_ISOPEN is already cleared.
Reviewed by:bde
Revision ChangesPath
1.264 +6 -7 src/sys/kern/tty.c
___
mbr 2006-09-30 20:58:48 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/kern tty.c
Log:
MFC rev. 1.260
Any call of tty_close() with a tty refcount of <= 1 is wrong and we will
free the tty in this case. This is a workaround until th
On Sat, Sep 30, 2006 at 04:19:10PM +0200, Martin Blapp wrote:
>
> Hi Peter,
>
> Current is currenlty broken for pty tress tests.
> It happens also for the tty tty_pts implementation.
>
> This is a CURRENT only problem, since in RELENG_6 we
> don't free any cdevs.
>
OK, I'll turn my attention t
Hi Peter,
Current is currenlty broken for pty tress tests.
It happens also for the tty tty_pts implementation.
This is a CURRENT only problem, since in RELENG_6 we
don't free any cdevs.
I hope tegge, bde will solve this problem in the
next few days.
Martin
I still have a problem with ptys:
On Sat, Sep 30, 2006 at 08:11:52AM +, Martin Blapp wrote:
> mbr 2006-09-30 08:11:52 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/kern tty.c
> Log:
> Any call of tty_close() with a tty refcount of <= 1 is wrong and we will
> free the tty in this c
On Sat, 30 Sep 2006, Martin Blapp wrote:
mbr 2006-09-30 08:11:52 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
Any call of tty_close() with a tty refcount of <= 1 is wrong and we will
free the tty in this case. This is a workaround until the underla
mbr 2006-09-30 08:11:52 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
Any call of tty_close() with a tty refcount of <= 1 is wrong and we will
free the tty in this case. This is a workaround until the underlaying
devfs/tty problems are fixed.
Hi,
Does kern_pts.c have the same problem?
Smilar but different problems. Those are addressed in a PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=99758
Martin
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
T
On Sat, Sep 23, 2006 at 02:52:47PM +, Martin Blapp wrote:
> mbr 2006-09-23 14:52:47 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/kern tty.c tty_pty.c
> Log:
> Check for tp->t_refcnt == 0 before doing anything in tty_open().
>
> PR:
mbr 2006-09-23 14:52:47 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c tty_pty.c
Log:
Check for tp->t_refcnt == 0 before doing anything in tty_open().
PR: 103520
MFC after: 1 week
Revision ChangesPath
1.260 +6 -0
mbr 2006-09-21 14:09:26 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
Back out rev. 1.258. The real race cause has been fixed
in rev. 1.241 of kern_proc.c.
Requested by: jhb
Revision ChangesPath
1.259 +2 -2 src/sys/ke
Rev. 1.272 was my commit, I can't remember the context of the
conversations around the Giant push down there, but it's quite possible
that I jumped the gun and made a mistake, because I am not sure how much
analysis of the TTY locking I did there.
Should we roll back that commit and Pickup G
On Mon, 11 Sep 2006, John Baldwin wrote:
I've told Martin numerous times that t_session is not locked by the proctree
lock and thus by default it is covered by Giant. I think much of the session
stuff still belongs under Giant in fact.
I thought that the session stuff was already locked. It
Hi,
I've told Martin numerous times that t_session is not locked by the proctree
It was definitly not clear to me where to put the asserts. And I didn't got a
clear response after I asked again. You remember, I did not have a additional
box to make tests this time when you proposed me to do
On Monday 11 September 2006 12:29, Max Laier wrote:
> On Monday 11 September 2006 16:48, John Baldwin wrote:
> > On Sunday 10 September 2006 12:51, Martin Blapp wrote:
> > > mbr 2006-09-10 16:51:56 UTC
> > >
> > > FreeBSD src repository
> > >
> > > Modified files:
> > > sys/kern
On Monday 11 September 2006 16:48, John Baldwin wrote:
> On Sunday 10 September 2006 12:51, Martin Blapp wrote:
> > mbr 2006-09-10 16:51:56 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > sys/kern tty.c
> > Log:
> > Fix locking race in ttymodem(). The
On Sunday 10 September 2006 12:51, Martin Blapp wrote:
> mbr 2006-09-10 16:51:56 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/kern tty.c
> Log:
> Fix locking race in ttymodem(). The locking of the proctree happens too
> late and opens a small race wi
On Sun, 2006-09-10 at 16:51 +, Martin Blapp wrote:
> mbr 2006-09-10 16:51:56 UTC
>
> Modified files:
> sys/kern tty.c
> Log:
> Fix locking race in ttymodem(). The locking of the proctree happens too late
> and opens a small race window before tp->t_session->s_l
Hi,
Since nobody wants to burn his fingers and touch the tty subsystem,
I've committed this fix as a bandaid to CURRENT and will MCF it after
a week. More work is needed to properly lock and protect the tty subsystem
of course.
During two month of testing this patch stopped the frequent panics
mbr 2006-09-10 16:51:56 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
Fix locking race in ttymodem(). The locking of the proctree happens too late
and opens a small race window before tp->t_session->s_leader is accessed. In
case
tp->t_session
phk 2006-01-04 08:22:39 UTC
FreeBSD src repository
Modified files:
sys/kern tty.c
Log:
Use MTX_SYSINIT to set up the tty list mutex.
Revision ChangesPath
1.255 +1 -6 src/sys/kern/tty.c
___
cvs-all@fr
jhb 2005-11-06 16:09:32 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/kern tty.c
Log:
MFC: Revert most of revision 1.235 and fix the problem a different way as
we can't acquire an sx lock in ttyinfo() as it is almost always called
fr
69 matches
Mail list logo
