On Thu, Feb 11, 2016 at 10:56:47PM -0500, Stefan Berger wrote:
>    Updated the branch. Are you going to upstream your patch? Otherwise I
>    would just add your Signed-off-by to it if that's ok ?

Yes, sorry about that. Just add it to your series with your
tested-by/reviewed-by. It will need some rebasing to go on top of
Jarkko's final patch that adds the devm_ (just delete it from
tpm_alloc and use my version for tpmm_alloc)

The other thing that has come to my mind is device removal. Right now
the tpm core is still fairly broken in that regard, and we have
largely got away with ignoring that because drviers are rarely
removed.

However, you are adding something that actually requires removal to
work and be race free, so we'll also have to fix core removal :(

The basic approach I'd suggest would be the same as what the rtc
subsystem does.

Add a mutex around 'chip->ops' and every place that
uses ops has to hold the lock.

Upon removal grab the mutex and null ops.

Every place that graps the lock for ops has to check for null. Null
means the device is being destroyed and the call must fail.

Make changes to tpm_chip_find_get to check for null, and make it do
put_device. Reconsider the use of module locking there, not sure it
makes any sense to do that if we have proper safe removal support.

Jason

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
tpmdd-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Reply via email to