From: Oliver Freyermuth <o.freyermuth@googlemail.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: netdev@vger.kernel.org
Subject: Re: Memory corruption with r8169 across several device revisions and kernels
Date: Mon, 22 Jan 2018 01:44:33 +0100 [thread overview]
Message-ID: <3fb413aa-997f-42f5-2a43-c29d8de51d3d@googlemail.com> (raw)
In-Reply-To: <20180122000922.GA3020@electric-eye.fr.zoreil.com>
Am 22.01.2018 um 01:09 schrieb Francois Romieu:
> You said:
>
> Oliver Freyermuth <o.freyermuth@googlemail.com> :
> [...]
>> The values found in overwritten memory match those contained in
>> /proc/self/net/dev for the realtek ethernet device.
>
> Are you able to retrieve the layout ? That is, does it appear to match:
>
> - r8169 hardware stats DMA buffer ?
> TxOk, RxOk, TxErr, RxErr, ...
>
> - rtnl_link_stats ?
> rx_packets, tx_packets, rx_bytes, tx_bytes, ...
>
> or something else ?
Not cleanly.
Since I'm no expert in kernel module development, I can only deduce from what I get in mapped memory,
e.g. with memtester. What I found there I found back in /proc/self/net/dev,
I'm not sure anymore whether it was RX or TX bytes / packets (but it was none of the error counters).
I can try to reproduce to clarify, but it's a somwhat dangerous undertaking.
Also, from a time when the physical offset was in low memory, I got the following in syslog:
Oct 12 10:05:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065b8ea
Oct 12 10:10:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065be39
Oct 12 10:11:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065be8c
Oct 12 10:12:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065bef8
Oct 12 10:13:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065bfbe
Oct 12 10:18:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065c37a
Oct 12 10:19:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065c3db
Oct 12 10:31:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065cc48
Oct 12 10:35:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065d402
Oct 12 10:47:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065dcbb
Oct 12 10:53:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 0065e0a3
Oct 12 11:39:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 006602f2
Oct 12 11:44:02 desktop1 kernel: Corrupted low memory at ffff880000009000 (9000 phys) = 00661ef0
Also, I'm not sure whether the low memory scanner continues after a single corruption was found, potentially it would only see the first corrupted region.
memtester in userspace stops on the first corruption and then tries another pass. At least I only ever saw one corrupted region with the tools I used.
The same was true for the corrupted btrfs filesystem: As far as I could tell, there was a single corrupted region, no series of counters, i.e. not a full structure.
Cheers,
Oliver
next prev parent reply other threads:[~2018-01-22 0:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-20 20:18 Memory corruption with r8169 across several device revisions and kernels Oliver Freyermuth
2018-01-21 20:48 ` Francois Romieu
2018-01-21 20:50 ` Oliver Freyermuth
2018-01-22 0:09 ` Francois Romieu
2018-01-22 0:44 ` Oliver Freyermuth [this message]
2018-01-22 22:55 ` Oliver Freyermuth
2018-01-23 15:28 ` David Miller
2018-01-23 15:47 ` Oliver Freyermuth
2018-01-24 5:31 ` Andreas Hartmann
2018-01-24 7:05 ` Andreas Hartmann
2018-01-23 22:13 ` Francois Romieu
2018-01-24 1:21 ` Oliver Freyermuth
2018-01-24 1:33 ` David Miller
2018-01-26 0:53 ` [PATCH net 1/1] r8169: fix memory corruption on retrieval of hardware statistics Francois Romieu
2018-01-26 2:34 ` David Miller
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=3fb413aa-997f-42f5-2a43-c29d8de51d3d@googlemail.com \
--to=o.freyermuth@googlemail.com \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.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).