Re: [PATCH] tpm: don't destroy chip device prematurely
From: Jason Gunthorpe
Date: Wed Oct 05 2016 - 12:28:08 EST
On Wed, Oct 05, 2016 at 01:02:34PM +0300, Jarkko Sakkinen wrote:
> I'll repeat my question: what worse can happen than returning -EPIPE? I
> though the whole rw lock scheme was introduced just for this purpose.
I thought I explained this, if device_del is moved after ops = null
then if sysfs looses the race it will oops the kernel. device_del hard
> Why there's even that branch in tpm-dev.c if it's so bad to let it
Because cdev_del and device_del do not guarentee that the cdev is
fenced. They just prevent new calls into open(). So the branch in
tpm-dev.c is necessary to avoid a kernel oops if user space holds the
fd open across unregister.
It is the same sitatuion you identified in the securityfs discussion -
user space holding the fd open across a driver unregister.