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. AttilioReceived on Fri Jul 13 2007 - 07:01:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:14 UTC