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
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
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
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.
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
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
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
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:
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
31 matches
Mail list logo
