- From: Frank Mori Hess <fmhess_at_users.sourceforge.net>
- Date: Thu, 3 Jul 2003 15:45:24 -0500
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 03 July 2003 12:28 pm, Calin A. Culianu wrote: > > > > 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?? > It does look like a race is possible. You can't hold a spinlock while executing code that may sleep though. You would need to use a mutex. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/BJXl5vihyNWuA4URAmp+AJ9czVZ6nIJ2XACSSlu2iizKCGrVUACgoO4q +dh2aE1LYJbQ9udxCUYZj0k= =fGBF -----END PGP SIGNATURE-----
Received on 2003-07-03Z19:45:24