From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH v4 3/8] tpm: validate event log access before tpm_bios_log_setup Date: Sun, 2 Oct 2016 15:25:51 -0600 Message-ID: <20161002212551.GB25872@obsidianresearch.com> References: <1475051682-23060-1-git-send-email-nayna@linux.vnet.ibm.com> <1475051682-23060-4-git-send-email-nayna@linux.vnet.ibm.com> <20161001120125.GC8664@intel.com> <20161001165436.GB13462@obsidianresearch.com> <20161001193239.GA3862@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20161001193239.GA3862-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jarkko Sakkinen Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: tpmdd-devel@lists.sourceforge.net 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. Jason ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot