Kernel deferring driver 'close' call: workaround?
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.
Quoted 3 lines
'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
Quoted 4 lines · Alan Cox
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
Quoted 11 lines · On Wed, 26 Jan 2011 14:29:50 +0000 Evan Lavelle <[email protected]> wrote:
Quoted 4 lines · Alan Cox
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
Quoted 10 lines · Alan Cox
Quoted 7 lines · On Wed, 26 Jan 2011 14:29:50 +0000 Evan Lavelle<[email protected]> wrote:
Quoted 4 lines · Alan Cox
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.
Quoted 7 lines
Quoted 4 lines
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