On 10/12/2016 01:45 AM, Jason Gunthorpe wrote:
> 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?

Sorry, I realized , that I missed to answer this in previous response.
I think I misinterpreted the sequence and there is no release() call on 
securityfs_remove().. Sorry for the confusion.

Thanks & Regards,
    - Nayna

>
>> 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

Reply via email to