From: Al Viro <viro@ZenIV.linux.org.uk>
To: alexmcwhirter@triadic.us
Cc: David Miller <davem@davemloft.net>,
rlwinm@sdf.org, chunkeey@googlemail.com,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Al Viro <viro@ftp.linux.org.uk>
Subject: Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
Date: Thu, 28 Jul 2016 02:22:53 +0100 [thread overview]
Message-ID: <20160728012253.GT2356@ZenIV.linux.org.uk> (raw)
In-Reply-To: <8b3126f66186015956e0f8090fb70532@triadic.us>
On Wed, Jul 27, 2016 at 08:26:48PM -0400, alexmcwhirter@triadic.us wrote:
> I'm going to go ahead and say this is where my issue and the op's issue
> begin to branch apart from one another. He's seeing this on all incoming
> data, whereas i am only seeing it on ssl data and not on sun4v.
>
> At this point i would say data from my issue is only going to cloud this
> issue as they seem to be two completely different issues revolving around
> the same commit. If i come across any relevant data for x86_64 ill be sure
> to post it if this isn't resolved by then, but for now i'm going to refrain
> from submitting anything sparc related.
Which just might mean that we have *three* issues here -
(1) buggered __copy_to_user_inatomic() (and friends) on some sparcs
(2) your ssl-only corruption
(3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc
anywhere, and no multi-segment recvmsg(). Which would strongly argue in
favour of some kind of copy_page_to_iter() breakage triggered when handling
a fragmented skb, as in (1). Except that I don't see anything similar in
x86_64 uaccess primitives...
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
To: alexmcwhirter-O8/uFoRGvHWcqzYg7KEe8g@public.gmane.org
Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
rlwinm-WF+c3Tt1nJM@public.gmane.org,
chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Al Viro <viro-rfM+Q5joDG/XmaaqVzeoHQ@public.gmane.org>
Subject: Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
Date: Thu, 28 Jul 2016 02:22:53 +0100 [thread overview]
Message-ID: <20160728012253.GT2356@ZenIV.linux.org.uk> (raw)
In-Reply-To: <8b3126f66186015956e0f8090fb70532-O8/uFoRGvHWcqzYg7KEe8g@public.gmane.org>
On Wed, Jul 27, 2016 at 08:26:48PM -0400, alexmcwhirter-O8/uFoRGvHWcqzYg7KEe8g@public.gmane.org wrote:
> I'm going to go ahead and say this is where my issue and the op's issue
> begin to branch apart from one another. He's seeing this on all incoming
> data, whereas i am only seeing it on ssl data and not on sun4v.
>
> At this point i would say data from my issue is only going to cloud this
> issue as they seem to be two completely different issues revolving around
> the same commit. If i come across any relevant data for x86_64 ill be sure
> to post it if this isn't resolved by then, but for now i'm going to refrain
> from submitting anything sparc related.
Which just might mean that we have *three* issues here -
(1) buggered __copy_to_user_inatomic() (and friends) on some sparcs
(2) your ssl-only corruption
(3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc
anywhere, and no multi-segment recvmsg(). Which would strongly argue in
favour of some kind of copy_page_to_iter() breakage triggered when handling
a fragmented skb, as in (1). Except that I don't see anything similar in
x86_64 uaccess primitives...
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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:[~2016-07-28 1:22 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-24 3:35 PROBLEM: network data corruption (bisected to e5a4b0bb803b) Alan Curry
2016-07-24 17:45 ` Christian Lamparter
2016-07-24 17:45 ` Christian Lamparter
2016-07-24 19:02 ` Al Viro
2016-07-24 19:02 ` Al Viro
2016-07-26 4:57 ` Alan Curry
2016-07-26 13:59 ` Christian Lamparter
2016-07-26 18:15 ` alexmcwhirter
2016-07-27 6:39 ` Kalle Valo
2016-07-27 1:14 ` Alan Curry
2016-07-27 10:32 ` Alan Curry
2016-07-27 18:04 ` alexmcwhirter
2016-07-27 23:02 ` alexmcwhirter
2016-07-27 23:45 ` David Miller
2016-07-28 0:31 ` Al Viro
2016-07-28 0:26 ` alexmcwhirter
2016-07-28 1:22 ` Al Viro [this message]
2016-07-28 1:22 ` Al Viro
2016-08-03 3:49 ` Alan Curry
2016-08-03 12:43 ` Christian Lamparter
2016-08-03 23:25 ` Alan Curry
[not found] ` <20160803054118.GG2356@ZenIV.linux.org.uk>
[not found] ` <2363167.YiBS7sFNO2@debian64>
[not found] ` <20160809145836.GQ2356@ZenIV.linux.org.uk>
[not found] ` <20170210081126.GA14157@ZenIV.linux.org.uk>
2017-02-10 21:45 ` Al Viro
2017-02-11 19:37 ` Christian Lamparter
2017-02-12 5:42 ` Al Viro
2017-02-13 21:56 ` Christian Lamparter
2017-02-14 1:33 ` [PATCH][CFT] Saner error handling in skb_copy_datagram_iter() et.al. (was Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)) Al Viro
2017-02-17 15:54 ` [PATCH][CFT] Saner error handling in skb_copy_datagram_iter() et.al David Miller
2017-02-17 17:03 ` Al Viro
2017-02-18 0:02 ` Al Viro
2017-02-18 2:24 ` Al Viro
2017-02-19 19:19 ` Christian Lamparter
2017-02-20 15:14 ` David Miller
2017-02-21 13:25 ` David Laight
2016-07-26 4:32 ` PROBLEM: network data corruption (bisected to e5a4b0bb803b) Alan Curry
2016-07-26 4:38 ` alexmcwhirter
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=20160728012253.GT2356@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=alexmcwhirter@triadic.us \
--cc=chunkeey@googlemail.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rlwinm@sdf.org \
--cc=viro@ftp.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.