linux-kernel - Kernel deferring driver 'close' call: workaround?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D401824.6090109@cyconix.com>
Date:	Wed, 26 Jan 2011 12:48:36 +0000
From:	Evan Lavelle <sa212+lkml@...onix.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/