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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/