- From: Calin A. Culianu <calin_at_ajvar.org>
- Date: Thu, 3 Jul 2003 13:28:57 -0400 (EDT)
On Thu, 3 Jul 2003, Frank Mori Hess wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday 03 July 2003 10:36 am, Calin A. Culianu wrote: > > What happens if, theoretically speaking, more than one kernel thread > > calls comedi_device_attach() for the same board -- say as a result of > > two processes doing a devconfig ioctl simultaneously? > > When a process does an ioctl, it calls lock_kernel(). The big kernel lock > doesn't get released except while the process is suspended or when it > finishes the ioctl. Just something for you to keep in mind while looking > at the code. Really? Is that true even in 2.4 kernels? Even ones with preemptive kernel patches? Jeez that seems kind of slow to me.. to lock the whole kernel but I guess in the end it reduces code complexity and it's only done for relatively computationally inexpensive execution paths.... Well even so, this new fact for me doesn't solve the potential for race conditions in comedi setup code. For instance setup code calls kmalloc() which can potentially suspend the current running task (and thus release the BKL). Granted this is unlikely, but still theoretically possible. Again, these are rare cases that may never happen in any real system, but as a software engineer.. it worries me that they _can_ happen. The question is how bad would it be to do something like have comedi_device_attach() grab the comedi lock or something? Or am I missing something here and is this a red herring?? -Calin > > - -- > Frank > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE/BGDA5vihyNWuA4URAiv7AJwJ2j8D8s0Kf0LEIjGRIAxLpcV25wCgt8pO > SLhn6FhSoNBP6ueRIqzx/ic= > =4mVd > -----END PGP SIGNATURE----- >
Received on 2003-07-03Z16:28:57