On Tue, Feb 16, 2016 at 02:26:56PM -0500, Stefan Berger wrote: > The re-ordering of the tpm_chip and vtpm_dev release actually solved that > problem.
? You mean you don't see the lock up because there is no error unwind? > [My feeling is, something outside of the vtpm driver doesn't unroll properly > and locks up if there's lots of concurrency]. Hum, I'd be surprised if this is not caused by something outside tpm/vtpm.. It would be very nice to know, but perhaps not essential. I didn't see anything obvious in vtpm either. > > One other thing you can look at is ditching the vtpm struct > > device. With the last patches I sent the tpm core would only need two > > more lines to work with a null parent device, which would be even > > simpler for vtpm. > > Not having a parent device isn't really necessary, except for not having it > appear in sysfs maybe? Dropping the dummy parent out of vtpm makes it work a little more more like the rest of the virtual stuff and slightly changes the sysfs paths visble to user space. If this is the right way to go it would be great to do that at the start. It wasn't worth bringing up before, but now that I wrote the parent removal patch it is pretty trivial. 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
