From: "Bjørn Mork" <bjorn@mork.no>
To: Oliver Neukum <oneukum@suse.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] cdc-wdm: fix "out-of-sync" due to missing notifications
Date: Mon, 04 Jul 2016 13:54:43 +0200 [thread overview]
Message-ID: <87d1mt62kc.fsf@nemi.mork.no> (raw)
In-Reply-To: <1467619450.9978.3.camel@suse.com> (Oliver Neukum's message of "Mon, 04 Jul 2016 10:04:10 +0200")
Oliver Neukum <oneukum@suse.com> writes:
> On Sun, 2016-07-03 at 21:59 +0200, Bjørn Mork wrote:
>> default:
>> @@ -200,10 +200,29 @@ static void wdm_in_callback(struct urb *urb)
>> desc->reslength = length;
>> }
>> }
>> +
>> + /*
>> + * If desc->resp_count is unset, then the urb was submitted
>> + * without a prior notification. If the device returned any
>> + * data, then this implies that it had messages queued without
>> + * notifying us. Continue reading until that queue is flushed.
>> + */
>> + if (!desc->resp_count) {
>> + if (!length) {
>> + /* do not propagate the expected -EPIPE */
>> + desc->rerr = 0;
>> + goto unlock;
>> + }
>> + dev_dbg(&desc->intf->dev, "got %d bytes without notification\n", length);
>> + set_bit(WDM_RESPONDING, &desc->flags);
>> + usb_submit_urb(desc->response, GFP_ATOMIC);
>
> You must check for being in an overflow condition.
No, I don't think that will give the wanted/expected result. The main
point here is to flush whatever the data the device has queued up, but
haven't notified us about (or for which we've lost the notification for
some reason). We want to continue flushing whether or not we can store
the received data. The goal is to get back into a syncronouos state,
not necessarily to save everything the device has queued. If we
overflow, then the lines just before this hunk will handle that just
fine by setting the WDM_OVERFLOW bit and dropping the data. That's what
we want.
>> + }
>> +
>> skip_error:
>> wake_up(&desc->wait);
>>
>> set_bit(WDM_READ, &desc->flags);
>> +unlock:
>> spin_unlock(&desc->iuspin);
>> }
>>
>> @@ -647,6 +666,16 @@ static int wdm_open(struct inode *inode, struct file *file)
>
> If you go for that approack you also need to do it
> in resume()
Yes, I wondered about that... But I didn't add it because I am unable
to provoke the problem there, so I cannot really test if it has any
positive effect. Do you still want it?
Bjørn
next prev parent reply other threads:[~2016-07-04 12:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-03 19:59 [PATCH v2] cdc-wdm: fix "out-of-sync" due to missing notifications Bjørn Mork
2016-07-04 8:04 ` Oliver Neukum
2016-07-04 11:54 ` Bjørn Mork [this message]
2016-07-04 12:48 ` Oliver Neukum
2016-07-04 13:09 ` Bjørn Mork
2016-07-04 17:01 ` Bjørn Mork
2016-07-05 12:52 ` Oliver Neukum
2016-07-09 18:31 ` Bjørn Mork
2016-07-10 12:47 ` Oliver Neukum
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=87d1mt62kc.fsf@nemi.mork.no \
--to=bjorn@mork.no \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=stable@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