From: Phil Sutter <phil.sutter@viprinet.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Ben Hutchings <bhutchings@solarflare.com>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
Date: Tue, 6 Sep 2011 13:05:03 +0200 [thread overview]
Message-ID: <20110906110503.GE29025@philter> (raw)
In-Reply-To: <20110906095722.GK6619@n2100.arm.linux.org.uk>
On Tue, Sep 06, 2011 at 10:57:22AM +0100, Russell King - ARM Linux wrote:
> > The code in question uses __get_free_pages(), and if that fails uses
> > vmalloc() (see alloc_one_pg_vec_page() for reference). Both code paths
> > show result in the same faulty behaviour.
>
> So, what you're wanting is cache coherency between vmalloc() and
> userspace. There is no API in the kernel to do that, and you'll see
> the same failures of this interface not only on ARM but also other
> architectures with virtual caches.
>
> It sounds like we need an API to flush the cache using both the
> userspace address, plus the kernel side address be that in the direct
> map or the vmalloc map areas.
>
> Or maybe the right solution is to simply disable AF_PACKET MMAP support
> for virtual cached architectures - it may be that adding cache flushing
> calls makes the thing too expensive and the benefits of mmap over normal
> read/write are lost.
OK, that's horrible. Of course we depend on just this combination to
work flawlessly, i.e. PACKET_MMAP && VIVT. :(
Another userspace-interface I'm working on uses a different solution:
memory is allocated in userspace and accessed from kernelspace using
get_user_pages(). I did not explicitly search for the earlier described
fault pattern, but we didn't notice any problem with this approach on
the very same hardware either. I already see myself writing TPACKET_V3.
;)
What do you think?
Greetings, Phil
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Zentrale: +49-6721-49030-0
Durchwahl: +49-6721-49030-134
Fax: +49-6721-49030-209
phil.sutter@viprinet.com
http://www.viprinet.com
Sitz der Gesellschaft: Bingen am Rhein
Handelsregister: Amtsgericht Mainz HRB40380
Geschäftsführer: Simon Kissel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: phil.sutter@viprinet.com (Phil Sutter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
Date: Tue, 6 Sep 2011 13:05:03 +0200 [thread overview]
Message-ID: <20110906110503.GE29025@philter> (raw)
In-Reply-To: <20110906095722.GK6619@n2100.arm.linux.org.uk>
On Tue, Sep 06, 2011 at 10:57:22AM +0100, Russell King - ARM Linux wrote:
> > The code in question uses __get_free_pages(), and if that fails uses
> > vmalloc() (see alloc_one_pg_vec_page() for reference). Both code paths
> > show result in the same faulty behaviour.
>
> So, what you're wanting is cache coherency between vmalloc() and
> userspace. There is no API in the kernel to do that, and you'll see
> the same failures of this interface not only on ARM but also other
> architectures with virtual caches.
>
> It sounds like we need an API to flush the cache using both the
> userspace address, plus the kernel side address be that in the direct
> map or the vmalloc map areas.
>
> Or maybe the right solution is to simply disable AF_PACKET MMAP support
> for virtual cached architectures - it may be that adding cache flushing
> calls makes the thing too expensive and the benefits of mmap over normal
> read/write are lost.
OK, that's horrible. Of course we depend on just this combination to
work flawlessly, i.e. PACKET_MMAP && VIVT. :(
Another userspace-interface I'm working on uses a different solution:
memory is allocated in userspace and accessed from kernelspace using
get_user_pages(). I did not explicitly search for the earlier described
fault pattern, but we didn't notice any problem with this approach on
the very same hardware either. I already see myself writing TPACKET_V3.
;)
What do you think?
Greetings, Phil
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Zentrale: +49-6721-49030-0
Durchwahl: +49-6721-49030-134
Fax: +49-6721-49030-209
phil.sutter at viprinet.com
http://www.viprinet.com
Sitz der Gesellschaft: Bingen am Rhein
Handelsregister: Amtsgericht Mainz HRB40380
Gesch?ftsf?hrer: Simon Kissel
next prev parent reply other threads:[~2011-09-06 11:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-08 13:06 ARM, AF_PACKET: caching problems on Marvell Kirkwood Phil Sutter
2011-04-08 13:06 ` Phil Sutter
2011-05-05 14:11 ` Phil Sutter
2011-05-05 14:11 ` Phil Sutter
2011-05-05 14:56 ` Eric Dumazet
2011-05-05 14:56 ` Eric Dumazet
2011-05-06 16:12 ` Phil Sutter
2011-05-06 16:12 ` Phil Sutter
2011-05-05 19:46 ` Andrew Lunn
2011-05-05 19:46 ` Andrew Lunn
2011-05-06 16:17 ` Phil Sutter
2011-05-06 16:17 ` Phil Sutter
2011-05-09 8:59 ` Phil Sutter
2011-05-09 8:59 ` Phil Sutter
2011-05-25 10:32 ` Phil Sutter
2011-05-25 10:32 ` Phil Sutter
2011-09-02 11:08 ` [PATCH] af_packet: flush complete kernel cache in packet_sendmsg Phil Sutter
2011-09-02 11:08 ` Phil Sutter
2011-09-02 13:46 ` Ben Hutchings
2011-09-02 13:46 ` Ben Hutchings
2011-09-02 13:59 ` Phil Sutter
2011-09-02 13:59 ` Phil Sutter
2011-09-02 17:28 ` Russell King - ARM Linux
2011-09-02 17:28 ` Russell King - ARM Linux
2011-09-05 19:57 ` Phil Sutter
2011-09-05 19:57 ` Phil Sutter
2011-09-06 9:57 ` Russell King - ARM Linux
2011-09-06 9:57 ` Russell King - ARM Linux
2011-09-06 11:05 ` Phil Sutter [this message]
2011-09-06 11:05 ` Phil Sutter
[not found] ` <D3F292ADF945FB49B35E96C94C2061B90A239361@nsmail.netscout.com>
2011-09-02 14:00 ` FW: " chetan loke
2011-09-02 14:00 ` chetan loke
2011-09-02 15:31 ` Phil Sutter
2011-09-02 15:31 ` Phil Sutter
2011-09-02 16:49 ` chetan loke
2011-09-02 16:49 ` chetan loke
2011-09-06 9:44 ` Phil Sutter
2011-09-06 9:44 ` Phil Sutter
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=20110906110503.GE29025@philter \
--to=phil.sutter@viprinet.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--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 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.