From: guido@kiener-muenchen.de
To: George McCollister <george.mccollister@gmail.com>
Cc: linux-usb@vger.kernel.org, guido.kiener@rohde-schwarz.com
Subject: Re: usbtmc: stb race condition introduced by 4f3c8d6eddc272b386464524235440a418ed2029
Date: Tue, 01 Sep 2020 18:59:03 +0000 [thread overview]
Message-ID: <20200901185903.Horde.NHT9rmY1GQT34m6C6YMUCNF@webmail.kiener-muenchen.de> (raw)
In-Reply-To: <CAFSKS=Pv1Ji4XqHjVMCAnszq_HjFYYk7GuzeeCCScHd1NMumDA@mail.gmail.com>
George,
Thanks for your question.
> 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.
The SRQ notification is an important message and must not be missed
in userspace applications. The new implementation does not miss the
SRQ event anymore, even when multiple threads are waiting for the SRQ event.
Your coding relies on the previous behavior and did not fail for your
use case and timing. However we could not develop reliable applications with
the previous implementation.
There are now two ways to wait for the SRQ event:
1. Using the poll/select method
2. Using the new ioctl USBTMC488_IOCTL_WAIT_SRQ (preferred way)
When receiving the SRQ event, you should immediately read the stb with
USBTMC488_IOCTL_READ_STB within the same thread to prevent races or
reading stale status byte information.
More info see:
https://github.com/GuidoKiener/linux-usbtmc/blob/master/README.md
> 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().
Did you start reading (read()) without checking the Status Byte after
poll() event?
Regards,
Guido
next prev parent reply other threads:[~2020-09-01 19:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 14:31 usbtmc: stb race condition introduced by 4f3c8d6eddc272b386464524235440a418ed2029 George McCollister
2020-09-01 18:59 ` guido [this message]
2020-09-01 22:21 ` George McCollister
2020-09-02 15:25 ` guido
2020-09-03 14:42 ` George McCollister
2020-09-03 16:54 ` guido
2020-09-22 15:33 ` guido
2020-09-28 13:58 ` George McCollister
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200901185903.Horde.NHT9rmY1GQT34m6C6YMUCNF@webmail.kiener-muenchen.de \
--to=guido@kiener-muenchen.de \
--cc=george.mccollister@gmail.com \
--cc=guido.kiener@rohde-schwarz.com \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).