From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
To: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Chris Healy <cphealy@gmail.com>
Subject: igb driver can cause cache invalidation of non-owned memory?
Date: Mon, 10 Oct 2016 11:52:06 +0300 [thread overview]
Message-ID: <0b57cbe2-84f7-6c0a-904a-d166571234b5@cogentembedded.com> (raw)
Hi
DMA mapping scheme introduced in commit cbc8e55f6fda ('igb: Map entire
page and sync half instead of mapping and unmapping half pages') back in
2012, and used up to now, can probably cause breakage of unrelated code
on archs with non-coherent caches.
With this scheme, page used for Rx is completely dma_map()ed at
allocation time, split into two buffers, and individual buffer is
sync_to_cpu()ed AND PASSED TO NETWORK STACK via skb_add_rx_frag() -
while driver driver still uses other buffer. Later, when driver decides
to no longer use this page, it will dma_unmap() it completely - which on
archs with non-coherent caches means cache invalidation. This cache
invalidation will include area that is already passed elsewhere. If
external code has performed any writes to that area and writes still are
in cache only, cache invalidation will cause writes to be lost.
I'm not sure if this breakage is indeed possible. I did not face it,
just found while checking how things work.
Code in question is in kernel already for 4 years. However, since (1)
igb is mostly used on x86 where caches are coherent, and (2) Rx buffers
are normally not written to, it could stay unnoticed all that time.
Could somebody please comment on this?
Nikita Yushchenko
next reply other threads:[~2016-10-10 8:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-10 8:52 Nikita Yushchenko [this message]
2016-10-10 9:01 ` igb driver can cause cache invalidation of non-owned memory? David Miller
2016-10-10 9:51 ` Nikita Yushchenko
2016-10-10 11:57 ` David Miller
2016-10-10 12:27 ` Nikita Yushchenko
2016-10-10 12:31 ` Nikita Yushchenko
2016-10-10 15:11 ` Alexander Duyck
2016-10-10 17:00 ` Nikita Yushchenko
2016-10-10 17:38 ` Alexander Duyck
2016-10-12 6:55 ` Nikita Yushchenko
2016-10-12 15:32 ` Alexander Duyck
2016-10-12 16:03 ` David Laight
2016-10-12 16:11 ` Nikita Yushchenko
2016-10-12 17:56 ` Alexander Duyck
2016-10-12 18:12 ` Nikita Yushchenko
2016-10-12 18:30 ` Alexander Duyck
2016-10-13 10:39 ` David Laight
2016-10-13 11:00 ` Nikita Yushchenko
2016-10-13 20:32 ` Alexander Duyck
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=0b57cbe2-84f7-6c0a-904a-d166571234b5@cogentembedded.com \
--to=nikita.yoush@cogentembedded.com \
--cc=cphealy@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@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