On Thu, 2023-06-15 at 22:09 +0100, Matthew Garrett wrote: > We're running into a situation where concurrent TPM accesses can > trigger EBUSY on write due to there either being a queued command or > a response not yet having been read. Obviously one approach would be > to retry, but that involves us either spinning or waiting for an > arbitrary amount of time between attempts, which doesn't seem ideal. > There's a poll interface that tells us whether there's a response to > read but (a) that doesn't help in the enqueued command situation and > (b) this would still be racy - we could be notified that the > response has been read, be preempted, and have another process > perform a write before we get the opportunity to. That's by design: the fd interface is command/response per open fd, so if you try to send another command before you get a response you'll get an EBUSY by design. If you didn't, how would you know which response belonged to which command (there's no counter or other identifier)? However, this behaviour is per-fd, why can't you just open multiple fd's for your multiple accesses? /dev/tpmrm0 will assure that they don't see each other and that the commands are properly sequenced without giving you an EBUSY. And bonus you don't have to keep global track of how many transient resources you've used. James
