Messages in this thread | | | Date | Wed, 3 Jan 2007 14:22:59 -0500 | From | Jeff Dike <> | Subject | Re: [uml-devel] [PATCH 1/6] UML - Console locking fixes |
| |
On Wed, Jan 03, 2007 at 04:07:34PM +0100, Blaisorblade wrote: > > + spin_lock(&line->count_lock); > > + if(!line->valid) > > + goto out_unlock; > > + > > + err = 0; > > + if(tty->count > 1) > > + goto out_unlock; > > > > - /* The IRQ which takes this lock is not yet enabled and won't be run > > - * before the end, so we don't need to use spin_lock_irq.*/ > > - spin_lock(&line->lock); > > + mutex_lock(&line->open_mutex); > > + spin_unlock(&line->count_lock); > > This is an obnoxious thing to do unless you specifically prove otherwise.
Didn't I? The proof goes like this: we only take the semaphore if tty->count == 1, in which case we are opening the device for the first time and there can't be anyone else looking at it, so the mutex_lock won't sleep.
However, now that you're making me think about it again, I'm wondering about the sanity of introducing a mutex which is guaranteed not to sleep.
This is starting to make sense, with (tty->count > 1) being the OPENING flag:
> In the first solution, you can create a OPENING flag (via a state variable), > and add the rule that (unlike the count) nobody but the original setter is > allowed to change it, and that who finds it set (say a concurrent open) must > return without touching it.
Then, I think the mutex can just be thrown away.
Jeff
-- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |