kernel threads and close method in a device driver
I'm involved with modifying a device driver for new hardware.
The architecture is currently:
open device
do IOCTL (spinning a kernel thread and doing initialization)
There is currently an IOCTL which short-circuits to the close method. Turns out it seems necessary to do this IOCTL -- close never gets invoked.
What can cause a close not to get invoked? BTW, the close is returning with a 0 status to the application ...(it definitely did NOT get invoked in the driver)
In ps:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 040 33839 750 1 7 0 1064 348 end D pts/2 0:00 ./openinit 040 33839 630 1 0 0 1064 348 end D pts/0 0:00 ./openinit
These are the kernel threads which won't go away.
I'm running 2.2.12 with the bigphysarea patch...
(leave my work address on the distribution -- I get linux kernel at home...)
marty [email protected]
Don't confuse education with schooling.
Milton Friedman to Yogi Berra
Quoted 6 lines · Marty Leisner
open device
do IOCTL (spinning a kernel thread and doing initialization)There is currently an IOCTL which short-circuits to the close method. Turns out it seems necessary to do this IOCTL -- close never gets invoked.
Call daemonize() in the kernel thread.
-Andi
Quoted 3 lines
What can cause a close not to get invoked? BTW, the close is returning with a 0 status to the application ...(it definitely did NOT get invoked in the driver)
The driver release function is invoked when the use count of the handle hits zero. Make sure you are not muddling release and flush ?
Quoted 6 lines · [email protected] said:
The architecture is currently:
open device
do IOCTL (spinning a kernel thread and doing initialization)
There is currently an IOCTL which short-circuits to the close method. Turns out it seems necessary to do this IOCTL -- close never gets invoked.
Your kernel thread is probably sharing filedescriptors with the parent process, so although your application closes its copy, because the kernel thread hasn't closed its copy, the ->release() method never gets called.
Make sure you're cleaning up properly when starting the kernel thread. See how other kernel threads do it. As Andi says, daemonize() is a good start, although it's not always sufficient.
--
dwmw2