lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 3 Jan 2007 14:22:59 -0500 From: Jeff Dike <jdike@...toit.com> To: Blaisorblade <blaisorblade@...oo.it> Cc: user-mode-linux-devel@...ts.sourceforge.net, akpm@...l.org, linux-kernel@...r.kernel.org 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists