kernel threads and close method in a device driver

kernel threads and close method in a device driver

[Marty Leisner]

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		mleisner@eng.mc.xerox.com   
Don't  confuse education with schooling.
	Milton Friedman to Yogi Berra

Re: kernel threads and close method in a device driver

[Alan Cox]

> 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 ?

Re: kernel threads and close method in a device driver

[Andi Kleen]

On Tue, Apr 17, 2001 at 05:04:28PM -0400, Marty Leisner wrote:
> 	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

Re: kernel threads and close method in a device driver

[David Woodhouse]

mleisner@eng.mc.xerox.com 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

Re: kernel threads and close method in a device driver

[Marty Leisner]

I ment to send this correspondence to the list.
It seems to be working much better now -- but is this
CLONE_FILES flag correct?

Is there a device to look at which does a kernel_thread on open,
and kills the thread on close (I'd like to see an example).

Thanks for the help...

Marty

- ------- Forwarded Message

To: Andi Kleen <ak@suse.de>
Subject: Re: kernel threads and close method in a device driver 
In-Reply-To: Your message of "Tue, 17 Apr 2001 23:43:39 +0200."
             <20010417234339.A18288@gruyere.muc.suse.de> 
Date: Wed, 18 Apr 2001 10:49:04 -0400
From: "Marty Leisner" <mleisner@eng.mc.xerox.com>

In message <20010417234339.A18288@gruyere.muc.suse.de>,   you write:
>On Tue, Apr 17, 2001 at 05:04:28PM -0400, Marty Leisner wrote:
>> 	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

It seemed like daemonize was a good idea (after thinking about it,
it makes a lot of sense...there are multiple instances of the file
open...[I'm not used to opening files NOT in user space ;-))]

daemonize wasn't in 2.2.12 (I copied it from 2.2.18):

static void daemonize(void)
{  
        struct fs_struct *fs;

        /*
         * If we were started as result of loading a module, close all of the
         * user space pages.  We don't need them, and if we didn't close them
         * they would be locked into memory.
         */                
        printk("want to daemonize");
        exit_mm(current);

        current->session = 1;
        current->pgrp = 1;

        /* Become as one with the init task */

        exit_fs(current);       /* current->fs->count--; */
        fs = init_task.fs;
        current->fs = fs;
        atomic_inc(&fs->count);
}

This seems reasonable, get rid of your files and inherit init's

However, 
:1 mleisner@piquin; lsof -p 630
COMMAND   PID     USER   FD   TYPE DEVICE SIZE NODE NAME
aicCtrlTh 630 mleisner  cwd    DIR    3,1 1024    2 /
aicCtrlTh 630 mleisner  rtd    DIR    3,1 1024    2 /
aicCtrlTh 630 mleisner    0u   CHR  136,0         2 /dev/pts/0
aicCtrlTh 630 mleisner    1u   CHR  136,0         2 /dev/pts/0
aicCtrlTh 630 mleisner    2u   CHR  136,0         2 /dev/pts/0
aicCtrlTh 630 mleisner    3u   CHR   43,0      8034 /dev/aicdrv

which is the original file handles from the application...

Any hints?  I played around with the CLONE_FILES flag on thread_creation,
and at least now I can get through to close (I have to look at the thread kill strategy).

But now I have (after an open, create thread, close cycle)
bash3 :3 mleisner@piquin; lsof -p 584
COMMAND   PID     USER   FD   TYPE DEVICE SIZE NODE NAME
aicCtrlTh 584 mleisner  cwd    DIR    3,1 1024    2 /
aicCtrlTh 584 mleisner  rtd    DIR    3,1 1024    2 /
aicCtrlTh 584 mleisner    0u   CHR  136,0         2 /dev/pts/0
aicCtrlTh 584 mleisner    1u   CHR  136,0         2 /dev/pts/0
aicCtrlTh 584 mleisner    2u   CHR  136,0         2 /dev/pts/0
bash3 :3 mleisner@piquin; lsmod
Module                  Size  Used by
aicdrv                 18104   0 
nfs                    29656   1  (autoclean)
nfsd                  144060   8  (autoclean)
lockd                  30984   1  (autoclean) [nfs nfsd]
sunrpc                 52516   1  (autoclean) [nfs nfsd lockd]
fa311                   4404   1  (autoclean)

marty
mleisner@eng.mc.xerox.com

- ------- End of Forwarded Message