From: Larry Finger <Larry.Finger@lwfinger.net>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Neal Cardwell <ncardwell@google.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Regression in staging:r8712u since 3.4 merge
Date: Thu, 26 Jul 2012 14:12:23 -0500 [thread overview]
Message-ID: <50119697.5050807@lwfinger.net> (raw)
Since kernel 3.4, driver r8712u has yielded intermittent errors when connected
to a secure connection. With Firefox, the message is "Secure Connection Failed:
SSL received a record with an incorrect Message Authentication Code (Error code:
ssl_error_bad_mac_read)". A retry may work eventually, When using wget with an
https URL, the error message is "SSL3_GET_RECORD: decryption failed or bad
record mac".
This regression is the basis for https://bugzilla.kernel.org/show_bug.cgi?id=45071.
Although intermittent, I managed to bisect the problem. The bad commit is
==========================================================================
commit c8628155ece363487b57d33441ea0359018c0fa7
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun Mar 18 11:07:47 2012 +0000
tcp: reduce out_of_order memory use
With increasing receive window sizes, but speed of light not improved
that much, out of order queue can contain a huge number of skbs, waiting
to be moved to receive_queue when missing packets can fill the holes.
Some devices happen to use fat skbs (truesize of 4096 + sizeof(struct
sk_buff)) to store regular (MTU <= 1500) frames. This makes highly
probable sk_rmem_alloc hits sk_rcvbuf limit, which can be 4Mbytes in
many cases.
When limit is hit, tcp stack calls tcp_collapse_ofo_queue(), a true
latency killer and cpu cache blower.
Doing the coalescing attempt each time we add a frame in ofo queue
permits to keep memory use tight and in many cases avoid the
tcp_collapse() thing later.
Tested on various wireless setups (b43, ath9k, ...) known to use big skb
truesize, this patch removed the "packets collapsed in receive queue due
to low socket buffer" I had before.
This also reduced average memory used by tcp sockets.
With help from Neal Cardwell.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: H.K. Jerry Chu <hkchu@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
============================================================================
As every other network driver is OK with this patch, I know the problem is in
r8712u. Do you have any thoughts on what it might be doing wrong to cause this
problem?
Thanks,
Larry
reply other threads:[~2012-07-26 19:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=50119697.5050807@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=ncardwell@google.com \
/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).