All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 5 Sep 2011 21:57:14 +0200	[thread overview]
Message-ID: <20110905195714.GC29025@philter> (raw)
In-Reply-To: <20110902172850.GB6619@n2100.arm.linux.org.uk>

Hi,

On Fri, Sep 02, 2011 at 06:28:50PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 02, 2011 at 02:46:17PM +0100, Ben Hutchings wrote:
> > On Fri, 2011-09-02 at 13:08 +0200, Phil Sutter wrote:
> > > This flushes the cache before and after accessing the mmapped packet
> > > buffer. It seems like the call to flush_dcache_page from inside
> > > __packet_get_status is not enough on Kirkwood (or ARM in general).
> > > ---
> > > I know this is far from an optimal solution, but it's in fact the only working
> > > one I found.
> > [...]
> > 
> > This is ridiculous.  If flush_dcache_page() isn't doing everything it
> > should, you need to fix that.
> 
> It does do everything it should - which is to perform maintanence on
> page cache pages.  It flushes the kernel mapping of the page.  It
> also flushes the userspace mappings of the page which it finds by
> walking the mmap list via the associated struct page.  It does not
> touch vmalloc mappings because it has no way to know whether they
> exist or not.
> 
> It doesn't do so much for anonymous pages - to do so would only
> duplicate what flush_anon_page() does at the very same callsites.
> Plus the mmap list isn't available for such pages so there's no
> way to find out what userspace addresses to flush.

Indeed very interesting information, thanks a lot!

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.

> If the AF_PACKET buffers are created from anonymous pages and it's
> using flush_dcache_page(), it's using the wrong interface.

So, in order to fix this, which alternative would you suggest? Quite a
lot of work has been done regarding memory allocation, so I guess
changing that side is a no-go.

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

WARNING: multiple messages have this Message-ID (diff)
From: Phil Sutter <phil.sutter@viprinet.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Ben Hutchings <bhutchings@solarflare.com>,
	linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
Date: Mon, 5 Sep 2011 21:57:14 +0200	[thread overview]
Message-ID: <20110905195714.GC29025@philter> (raw)
In-Reply-To: <20110902172850.GB6619@n2100.arm.linux.org.uk>

Hi,

On Fri, Sep 02, 2011 at 06:28:50PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 02, 2011 at 02:46:17PM +0100, Ben Hutchings wrote:
> > On Fri, 2011-09-02 at 13:08 +0200, Phil Sutter wrote:
> > > This flushes the cache before and after accessing the mmapped packet
> > > buffer. It seems like the call to flush_dcache_page from inside
> > > __packet_get_status is not enough on Kirkwood (or ARM in general).
> > > ---
> > > I know this is far from an optimal solution, but it's in fact the only working
> > > one I found.
> > [...]
> > 
> > This is ridiculous.  If flush_dcache_page() isn't doing everything it
> > should, you need to fix that.
> 
> It does do everything it should - which is to perform maintanence on
> page cache pages.  It flushes the kernel mapping of the page.  It
> also flushes the userspace mappings of the page which it finds by
> walking the mmap list via the associated struct page.  It does not
> touch vmalloc mappings because it has no way to know whether they
> exist or not.
> 
> It doesn't do so much for anonymous pages - to do so would only
> duplicate what flush_anon_page() does at the very same callsites.
> Plus the mmap list isn't available for such pages so there's no
> way to find out what userspace addresses to flush.

Indeed very interesting information, thanks a lot!

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.

> If the AF_PACKET buffers are created from anonymous pages and it's
> using flush_dcache_page(), it's using the wrong interface.

So, in order to fix this, which alternative would you suggest? Quite a
lot of work has been done regarding memory allocation, so I guess
changing that side is a no-go.

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

  reply	other threads:[~2011-09-05 19:57 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 [this message]
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
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=20110905195714.GC29025@philter \
    --to=phil.sutter@viprinet.com \
    --cc=linux-arm-kernel@lists.infradead.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.