Kernel deferring driver 'close' call: workaround?

Kernel deferring driver 'close' call: workaround?

[Evan Lavelle]

I've written a PCIe driver for a specialist card, which can only have a 
single user ('open' returns EBUSY if the board is already open). A user 
has complained that they can't do this with the card:

1 - open()    // Ok
2 - close()
3 - open()    // fails

'strace' shows that the 'close' succeeds, but the driver debug output 
shows that the driver close/release (step 2) is not called before the 
next open (step 3), so the open fails.

I appreciate that the kernel may want to defer the driver 'close', even 
though the open count is only 1. However, I'm surprised that the kernel 
calls the driver open code at step (3) without first calling the 
deferred close from step (2).

Is this expected behaviour? If so, can anyone suggest a work-around, at 
either driver or user level?

Thanks.

Re: Kernel deferring driver 'close' call: workaround?

[Alan Cox]

> 'strace' shows that the 'close' succeeds, but the driver debug output 
> shows that the driver close/release (step 2) is not called before the 
> next open (step 3), so the open fails.

I imagine the user has a bug in their app. The close method is called on
the final close of the handle. That means if for example you do something
like fork off a child process and forget to close the handle then it
won't actually close down until the final user closes it.

Alan

Re: Kernel deferring driver 'close' call: workaround?

[Evan Lavelle]

On 26/01/2011 13:17, Alan Cox wrote:

> I imagine the user has a bug in their app. The close method is called on
> the final close of the handle. That means if for example you do something
> like fork off a child process and forget to close the handle then it
> won't actually close down until the final user closes it.

That was my first reaction, but the strace output only shows an open and 
close of two shared libs, open and close for this board, some mmaps from 
the driver, and the basic brk/fstat/etc stuff. Unfortunately, I haven't 
got the app source, or even the board... :(

-Evan

Re: Kernel deferring driver 'close' call: workaround?

[Alan Cox]

On Wed, 26 Jan 2011 14:29:50 +0000
Evan Lavelle <sa212+lkml@cyconix.com> wrote:

> On 26/01/2011 13:17, Alan Cox wrote:
> 
> > I imagine the user has a bug in their app. The close method is called on
> > the final close of the handle. That means if for example you do something
> > like fork off a child process and forget to close the handle then it
> > won't actually close down until the final user closes it.
> 
> That was my first reaction, but the strace output only shows an open and 
> close of two shared libs, open and close for this board, some mmaps from 
> the driver, and the basic brk/fstat/etc stuff. Unfortunately, I haven't 
> got the app source, or even the board... :(

An mmap reference counts as an open .... it won't be released until the
mmaps are gone

Re: Kernel deferring driver 'close' call: workaround?

[Evan Lavelle]

On 26/01/2011 14:38, Alan Cox wrote:
> On Wed, 26 Jan 2011 14:29:50 +0000
> Evan Lavelle<sa212+lkml@cyconix.com>  wrote:
>
>> On 26/01/2011 13:17, Alan Cox wrote:
>>
>>> I imagine the user has a bug in their app. The close method is called on
>>> the final close of the handle. That means if for example you do something
>>> like fork off a child process and forget to close the handle then it
>>> won't actually close down until the final user closes it.
>>
>> That was my first reaction, but the strace output only shows an open and
>> close of two shared libs, open and close for this board, some mmaps from
>> the driver, and the basic brk/fstat/etc stuff. Unfortunately, I haven't
>> got the app source, or even the board... :(
>
> An mmap reference counts as an open .... it won't be released until the
> mmaps are gone

Excellent! Fixed - well done.

-Evan