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? /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 tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
