On Mon, Oct 03, 2016 at 03:20:13PM +0300, Jarkko Sakkinen wrote: > On Sun, Oct 02, 2016 at 03:25:51PM -0600, Jason Gunthorpe wrote: > > On Sat, Oct 01, 2016 at 10:32:39PM +0300, Jarkko Sakkinen wrote: > > > > chip held for the duration of any fops. Can open() start after the > > > > kref is dropped, etc. > > > > > > Why not make tpm_securityfs_data refcounted in order to remove > > > binding to the chip? > > > > The chip is already kref'd. How does swapping one kref for another > > solve anything? > > > > The possible issue is that the krefs are not covering > > the right code. > > > > The scheme you suggested is also way off the mark for how fops works, > > fops->close has no relation to the needed duration for 'data', the > > duration is related to securityfs_remove. > > Right, the above would not work because it's not linked to > securityfs_remove by any means. > > Are you trying to say that after securityfs_remove() there might be a > "grace period" when user space could still see the files visible and > open them?
You have to provide something factors more concrete. Otherwise, I'm inclined to accept the approach in Naynas patch. It's an improvement. /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
