Kernel deferring driver 'close' call: workaround?

Evan Lavelle
2011-01-26T13:10:38Z

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.