On Wed, Oct 12, 2016 at 12:41:05AM +0530, Nayna wrote: > Yeah, I actually tried this today. > And on call of securityfs_remove(), release() gets called for the > opened
Are you saying securityfs_remove somehow causes a synchronous call to release? How does that come about? > There are actually two private data: > inode->private > seq->private > > I understand inode->private is where we pass sfs_data has both chip and > seqops. This is the one being used in open(), release() and defined as NULL > in teardown(). > But seq->private is used by seq_ops. And I am still not sure how passing > seq->private as chip can help. > I might be missing something basic, so can you please help me to understand > that. open does: struct tpm_chip *chip = inode->i_private get_device(&chip->dev); seq = file->private_data; seq->private = chip; release does: struct seq_file *seq = file->private_data; struct tpm_chip *chip = seq->private; put_device(&chip->dev); seqops like tpm_bios_measurements_start do: struct tpm_chip *chip = m->private; struct tpm_bios_log *log = &chip->log; [locking, error handling, and other stuff elided] open is the only thing that ever looks a inode->i_private. open krefs's chip and stores it in seq->private seqop accessors use seq->private->log to access the log, the memory of which is guared by the kref. release drops the kref on chip and does not use inode->i_private Jason ------------------------------------------------------------------------------ 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
