From: Ezequiel Garcia <email@example.com>
To: Russell King - ARM Linux <firstname.lastname@example.org>
Cc: email@example.com, David Miller <firstname.lastname@example.org>,
Subject: Re: [PATCH 2/2] net: mv643xx_eth: Fix highmem support in non-TSO egress path
Date: Wed, 21 Jan 2015 20:34:30 -0300 [thread overview]
Message-ID: <54C03786.email@example.com> (raw)
On 01/21/2015 02:40 PM, Russell King - ARM Linux wrote:
> On Wed, Jan 21, 2015 at 09:54:10AM -0300, Ezequiel Garcia wrote:
>> Commit 69ad0dd7af22b61d9e0e68e56b6290121618b0fb
>> Author: Ezequiel Garcia <firstname.lastname@example.org>
>> Date: Mon May 19 13:59:59 2014 -0300
>> net: mv643xx_eth: Use dma_map_single() to map the skb fragments
>> caused a nasty regression by removing the support for highmem skb
>> fragments. By using page_address() to get the address of a fragment's
>> page, we are assuming a lowmem page. However, such assumption is incorrect,
>> as fragments can be in highmem pages, resulting in very nasty issues.
>> This commit fixes this by using the skb_frag_dma_map() helper,
>> which takes care of mapping the skb fragment properly.
> This seems fine, so:
I have just realised that the non-TSO and the TSO paths must work
simultaneously (we don't know which path an egress skb will take).
So, with these patches, the unmapping is done using dma_unmap_page() which
is only correct if the skb took the non-TSO paths. In other words,
these fixes are wrong (although I have no idea the effect of
using dma_unmap_page on a mapping done with dma_map_single).
And the problem is that in the TSO path, the linear and the non-linear
fragments use the same kind of descriptors, so we can't distinguish
them in the cleanup, and can't decide if _single or _page should be used.
I guess we could keep track in some data structure of the type of mapping
on each descriptor. Or alternatively, avoid highmem fragments altogether
by mapping to a lowmem page.
I'll try to come up with some more patches following the first idea.
Sorry for the crappiness,
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
next prev parent reply other threads:[~2015-01-21 23:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 12:54 [PATCH net 0/2] net: marvell: Fix highmem support on non-TSO path Ezequiel Garcia
2015-01-21 12:54 ` [PATCH 1/2] net: mvneta: Fix highmem support in the non-TSO egress path Ezequiel Garcia
2015-01-26 22:40 ` David Miller
2015-01-21 12:54 ` [PATCH 2/2] net: mv643xx_eth: Fix highmem support in " Ezequiel Garcia
2015-01-21 17:40 ` Russell King - ARM Linux
2015-01-21 23:34 ` Ezequiel Garcia [this message]
2015-01-22 0:11 ` Russell King - ARM Linux
2015-01-22 12:17 ` Ezequiel Garcia
2015-01-26 22:40 ` David Miller
2015-01-21 15:01 ` [PATCH net 0/2] net: marvell: Fix highmem support on non-TSO path Russell King - ARM Linux
2015-01-22 18:41 ` Dean Gehnert
2015-01-22 18:45 ` Ezequiel Garcia
2015-01-22 19:01 ` Dean Gehnert
2015-01-22 21:09 ` Russell King - ARM Linux
2015-01-22 21:27 ` Dean Gehnert
2015-01-22 21:49 ` Russell King - ARM Linux
2015-01-22 23:06 ` Russell King - ARM Linux
2015-01-22 23:09 ` Dean Gehnert
2015-01-22 23:08 ` Dean Gehnert
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.