l?rdag 06 august 2005, 23:54, skrev Johannes Stezenbach: > On Sat, Aug 06, 2005 Kenneth Aafl?y wrote: > > l?rdag 06 august 2005, 21:08, skrev Johannes Stezenbach: > > > Kenneth Aafl?y wrote: > > > > Is changing all down_interruptible (that protects freeing a > > > > structure) to down(), or will this have other unseen side-effects? > > > > > > Generally speaking, a driver should only sleep uninterruptibly > > > if you can make absolutely sure it won't sleep forever, even > > > in an obscure error case. If you can guarantee that from > > > reading the code, then it's best to change the down() to > > > down_interruptible(), otherwise it's better to handle the > > > error from down_interruptible() correctly. > > > > > > (If a process is stuck in uninterruptible sleep you usually > > > have to reboot to get rid of it, which is bad.) > > > > Ok, but do you think it is better interrupt freeing a resource > > that can't be reclaimed later, or _maybe_ break some other part > > because of deadlocks? > > Choose your poison... > > Maybe you could explain the "can't be reclaimed later" part? > Why is it not possible to handle down_interruptible() interruption > currectly? And, BTW, what exactly is the problem that you found? I found that filters is lost because down_interruptible is interrupted, and not re-entered. This is in dmxdev.c's release for section filters, where the signal is SIGINT. > I guess if you experimentally change it to down() you will soon > find out if it causes problems I would just prefer if you read > the code and think about what could cause it to hang indefinitely > (e.g. buggy driver or hardware problems). I can't see any reason why the specific case above in dmxdev.c's release would cause it to hang indefinatly. If there is a buggy driver, this will only expose the bug, which imho is not critical! Hardware problems should be handled with timeouts in the critical sections. I don't see the problem here. Kenneth
