Date: Fri, 13 Jul 2007 11:00:41 +0200 From: Attilio Rao <attilio@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Julian Elischer <julian@elischer.org>, FreeBSD Current <current@freebsd.org> Subject: Re: crash in tty code in 6.1.. fixed since? Message-ID: <46973F39.2050508@FreeBSD.org> In-Reply-To: <200707131055.12084.hselasky@c2i.net> References: <46970DF7.3000803@elischer.org> <200707131021.59966.hselasky@c2i.net> <46973708.2040401@FreeBSD.org> <200707131055.12084.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Petter Selasky wrote:
> On Friday 13 July 2007 10:25, Attilio Rao wrote:
>> Hans Petter Selasky wrote:
>>> If TTY was not Giant locked, you would have had an error there if another
>>> mutex was locked, and the problem would have been solved years ago :-)
>> Not sure what you mean, but the first evidence is that you would have
>> explicitly drop/pickup the mutex so that you would have handled the race
>> not trasparently as Giant does.
>> Moreover, it seems that tty should be partially locked with a sleeping
>> primitive (sx probabilly).
>>
>
> If you lock a mutex first and then a sx-lock, you should get a warning, right?
No, a panic.
What I mean is that if you had a mutex here instead than Giant what
would have probabilly happened is having code like this:
mtx_lock(&tty_mtx);
...
if (tp->t_session) {
mtx_unlock(&tty_mtx);
sx_slock(&proctree_lock);
mtx_lock(&tty_mtx);
if (tp->t_session && tp->t_session->s_leader) {
struct proc *p;
What changes really here is that you explicitly check again the state of
t_session ptr since it can be changed while dropping/pickingup again the
tty_mtx. Since you used a mutex differently from Giant you know you have
to do that.
With Giant the problem is that the dropping/pickingup happens implicitly
in our primitives so you can just make (easy) mistakes like these.
Attilio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46973F39.2050508>