All of lore.kernel.org
 help / color / mirror / Atom feed
* ops_sem and tpm_mutex
@ 2016-07-05 11:06 Jarkko Sakkinen
       [not found] ` <20160705110647.GA28275-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 2+ messages in thread
From: Jarkko Sakkinen @ 2016-07-05 11:06 UTC (permalink / raw)
  To: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: ops_sem and tpm_mutex
       [not found] ` <20160705110647.GA28275-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
@ 2016-07-05 16:01   ` Jason Gunthorpe
  0 siblings, 0 replies; 2+ messages in thread
From: Jason Gunthorpe @ 2016-07-05 16:01 UTC (permalink / raw)
  To: Jarkko Sakkinen; +Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

On Tue, Jul 05, 2016 at 02:06:47PM +0300, Jarkko Sakkinen wrote:

> This is the basic pattern. Basically we always loose the benefit of
> RW-lock because in every use case we also lock a mutex.

The only purpose of the rw lock is protect against unregister, and
that is the benifit it provides.

> 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().

No, it needs to be a lock, the unregister path must block and sleep,
and a kref cannot do that alone, by the time you build in the locking
you've made something more expensive than a rwlock.

The performance alternative is to use srcu for the rwlock, but since
we don't really have a performance concern in TPM I would rather not
see such complexity.

Another alternative would be to merge the rw-lock and mutex together
(ie hold mutex before touching ops at all), however this semantically
changes things by linking the lifetime and concurrancy models
together.

I belive I looked at that before doing the rwsem and decided it was a
huge amount of tricky work.

Jason

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-07-05 16:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-05 11:06 ops_sem and tpm_mutex Jarkko Sakkinen
     [not found] ` <20160705110647.GA28275-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-07-05 16:01   ` Jason Gunthorpe

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.