From: "Bjørn Mork" <bjorn-yOkvZcmFvRU@public.gmane.org>
To: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH net] net: usbnet: prevent buggy devices from killing us
Date: Fri, 25 Jan 2013 13:27:07 +0100 [thread overview]
Message-ID: <87obgde9d0.fsf@nemi.mork.no> (raw)
In-Reply-To: <1659086.jLlTU1VIap-7ztolUikljGernLeA6q8OA@public.gmane.org> (Oliver Neukum's message of "Fri, 25 Jan 2013 13:02:38 +0100")
Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org> writes:
> On Friday 25 January 2013 08:13:15 Bjørn Mork wrote:
>> Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org> writes:
>> > On Thursday 24 January 2013 20:16:56 Bjørn Mork wrote:
>> >> A device sending 0 length frames as fast as it can has been
>> >> observed killing the host system due to the resulting memory
>> >> pressure.
>> >>
>> >> Temporarily disable RX skb allocation and URB submission when
>> >> the current error ratio is high, preventing us from trying to
>> >> allocate an infinite number of skbs. Reenable as soon as we
>> >> are finished processing the done queue, allowing the device
>> >> to continue working after short error bursts.
>> >>
>> >> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>> >> ---
>> >> So is this starting to look OK?
>> >
>> > It seems to me that we at least need to try some error recovery.
>>
>> Won't the disabling code in usbnet_bh do? RX will only stay disabled
>> until the done queue is handled.
>
> So will the burst of bogus packets stop by itself?
No, in the case I am looking at it won't. So we end up switching this
off/on endlessly.
But I believe that is fine. There is no way we can *know* that the
errors won't stop unless we start receiving packets again. Other
devices may have similar temporary bugs, making them start working again
after a while. If we permanently disable RX then we will just make any
such device fail for no good reason.
My only wish for this patch is that it makes usbnet survive the buggy
device without bringing the host down. Not magically fix the device (of
course impossible), or even hide the bug in any way. A non-functional
device will still appear as a non-functional device. Manual user
intervention is required to make it work. This might involve a firmware
upgrade for all we know...
>> > How about resetting the device when it is no longer used?
>>
>> Yes, that we should do. I guess usbnet_open is the place to reset the
>> flag and counters? I'll send another version taking care of this and
>> Joes comment.
>
> I was thinking about resetting the device, not just counters.
What's the point? We only risk making the issue worse if some device has
a similar temporary bug, fixing itself a while after reset. I think we
should leave any such actions to the user.
> But yes, open() needs to reset the counters, too.
OK, will add that.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-01-25 12:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-24 10:25 [RFC] net: usbnet: prevent buggy devices from killing us Bjørn Mork
[not found] ` <1359023152-32576-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
2013-01-24 10:46 ` Oliver Neukum
[not found] ` <6505263.QGCG9bfoCC-7ztolUikljGernLeA6q8OA@public.gmane.org>
2013-01-24 10:52 ` Bjørn Mork
[not found] ` <87bocehmzd.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2013-01-24 11:03 ` Oliver Neukum
[not found] ` <2321910.EQLkSoxl50-7ztolUikljGernLeA6q8OA@public.gmane.org>
2013-01-24 11:22 ` Bjørn Mork
[not found] ` <877gn2hlkh.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2013-01-24 11:31 ` Oliver Neukum
2013-01-24 12:47 ` Bjørn Mork
[not found] ` <87y5fig32r.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2013-01-24 13:12 ` Oliver Neukum
[not found] ` <2556579.vjYlY1iKn5-7ztolUikljGernLeA6q8OA@public.gmane.org>
2013-01-24 13:42 ` Bjørn Mork
2013-01-24 19:16 ` [PATCH net] " Bjørn Mork
2013-01-24 22:09 ` Oliver Neukum
2013-01-25 7:13 ` Bjørn Mork
2013-01-25 12:02 ` Oliver Neukum
[not found] ` <1659086.jLlTU1VIap-7ztolUikljGernLeA6q8OA@public.gmane.org>
2013-01-25 12:27 ` Bjørn Mork [this message]
[not found] ` <1359055016-13603-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
2013-01-24 23:57 ` Joe Perches
2013-01-25 8:14 ` Bjørn Mork
2013-01-24 10:47 ` [RFC] " Bjørn Mork
2013-01-24 12:39 ` Sergei Shtylyov
[not found] ` <51012B76.1060600-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
2013-01-24 13:01 ` Joe Perches
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=87obgde9d0.fsf@nemi.mork.no \
--to=bjorn-yokvzcmfvru@public.gmane.org \
--cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.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).