usbtmc: stb race condition introduced by 4f3c8d6eddc272b386464524235440a418ed2029

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Since 4f3c8d6eddc272b386464524235440a418ed2029 I'm experiencing this
STB race condition. TL;DR an old, cached STB value can be used after a
new one is reported in reply to a control message. Hacking up the
latest driver code to ignore the cached stb value gets around the
issue.

My USBTMC device has an interrupt endpoint with a 1ms interval.

1) A query is sent to the USBTMC device.

2) An SRQ is reported via the interrupt endpoint with MAV set.

3) Userspace performs a read to get the reply since MAV is set after
being notified by poll().

4) A condition on the USBTMC device triggers an SRQ before the
response is read but is not reported until later due to 1ms poll
interval. MAV is still set in the reported stb.

5) The USBTMC device submits a reply and clears MAV.

6) Userspace receives the reply and does USBTMC488_IOCTL_READ_STB.

[ 2584.683589] 000: usbtmc 1-1.1:1.0: Enter ioctl_read_stb iin_ep_present: 1

7) The SRQ comes in but too late to be used as a cached value by
usbtmc488_ioctl_read_stb() so it is stored for later.
[ 2584.683673] 000: usbtmc 1-1.1:1.0: int status: 0 len 2
[ 2584.683684] 000: usbtmc 1-1.1:1.0: srq received bTag 81 stb 51

8) A control msg is sent and the interrupt endpoint replies with the
STB. MAV is (correctly) not set.
[ 2584.684657] 000: usbtmc 1-1.1:1.0: int status: 0 len 2
[ 2584.687642] 000: usbtmc 1-1.1:1.0: stb:0x41 received 0

9) Userspace sends a query in response to the device condition
reported in the first STB bit.

10) Userspace does USBTMC488_IOCTL_READ_STB before waiting with poll()
and finds MAV is already set (incorrectly) since the cached value from
the last SRQ is used even though the bit was more recently reported
not set in response to a control message.

11) Userspace then attempts to read based on this false MAV 3and finds
no response.


Am I making any incorrect assumptions about how this should work? If
not what could we do to fix this behavior other than not using a
cached stb value? FWIW I'm the author of the userspace code and the
USBTMC device firmware.

Regards,
George McCollister
Software Architect
NovaTech LLC



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux