John Tyner wrote: >How is your userspace app getting the request to shutdown? If your driver >plays nice with signals, then your blocked I/O call should return with the >error that it was interrupted by some signal (assuming you're using a >signal to send the shutdown request). Then you can do your close and all >of that good stuff. > Good question. If the blocking in the driver is handled with a wait_event_interruptible, ctrl-c interrupts that, the blocked I/O releases, and (I think) everything cleans up nicely and the driver can be unloaded. With that in mind, how can I tell if I have memory leaks after the app has shut down? The biggest concern that I have is that the user app crashes and can not send/do anything. My driver is still hanging out trying to service the blocked request. Under those circumstances I have two concerns. What happens if the app is dead and gone and the driver finally unblocks and tries a copy_to_user. Secondly if the driver never gets whatever it is waiting for to unblock, it can't be unloaded because it thinks it is busy. What if a user then restarts the app and in comes another request that will be blocked. I have tried to make this reentrant, but at this point life is getting messy. Lastly, if the app is nicely asked to shutdown, how should it tell the driver to unblock? If a signal is the answer, what kind? I am using pthread here(in fact the blocked reqeusts are ioctl requests from threads spawned off of the main application). My biggest concern is the drivers stability. The app can be restarted and fixed, but I need the driver to recover fully. Thanks again. -- Best regards, David Stroupe Keyed-Up Software 5307 Faireast Court Arlington, Texas 76018-1683 817/557-4903 voice 817/472-0408 fax -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
