-
-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Q: Release
interaction with Call
#234
Comments
Maybe @matejcik and @szymonlesisz can comment on this? Is this desirable to be able to call Release while a Call is still running? |
Hi, The Lines 435 to 456 in 106e5e9
But it seems to try interrupting the sending without acquiring a mutex. |
I wouldn't rely on any libusb magic, it's generally not cross-OS reliable. Releasing while a call is in progress seems like asking for trouble, but an usecase I can envision goes like this: If we disallow releasing while a call is in progress, the user can only resolve this by reconnecting the Trezor. Also how would this interact with using Post/Read instead of Call ? |
I've been trying to simulate two applications attempting to race the bridge at the same time, one is racing to It seems that the bridge doesn't handle multiple applications well when they are aggressively racing to acquire a handle to the device. If two applications are aggressively calling the bridge they will return either The bridge version that I'm using is Additionally to the behavior above, I've managed to produce two strange messages that might indicate funky stuff going on. Use before acquiring or after releasingIt seems like I've managed to produce a scenario where the bridge attempts to use the device before having claimed the device, or perhaps after it had released its claim.
Bigger log:
Strange disconnect warApplication 1 racing to get
Application 2 racing to get
Lots and lots of USB resetting going on when fighting over sessionsLots and lots of resetting of the USB device..
|
Resetting is expected, bridge needs to reset the device at acquire time. I don't exactly remember why :) but some things go bad when we omit the reset.
This seems like expected behavior? Bridge is not exactly trying to multiplex access to device -- that doesn't work well with the device itself, we'd have to put |
There are mutexes to prevent simultaneously reading and writing within a single session:
trezord-go/core/core.go
Lines 629 to 656 in 106e5e9
I do not see the
Release
function acquiring locks for these mutexes so it seems like we'd be able to release a session whilst it's busy reading and writing? Perhaps I'm missing somelibusb
magic locking mechanisms here.trezord-go/core/core.go
Lines 354 to 372 in 106e5e9
There are locks on the session maps, but those only apply to adding and removing values within the map.
If it's not a desirable and deliberate property then I'm willing to contribute a fix.
The text was updated successfully, but these errors were encountered: