From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: ops_sem and tpm_mutex Date: Tue, 5 Jul 2016 14:06:47 +0300 Message-ID: <20160705110647.GA28275@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: tpmdd-devel@lists.sourceforge.net Hi I started to looking at ops_sem and tpm_mutex because it would be nicer to have one lock. When we do something that uses ops_sem we do this: 1. read lock for ops_sem 2. lock tpm_mutex This is the basic pattern. Basically we always loose the benefit of RW-lock because in every use case we also lock a mutex. And the mutex of course cannot be taken off because we want to mutually exclude the TPM access. What I was thinking that maybe we could have kref for ops instead of lock. In the places where we now use read lock you could use kref_get_unless_zero() to avoid races with tpm_chip_unregister(). /Jarkko ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape