All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 2/2] ARM: Handle user space mapped pages in flush_kernel_dcache_page
Date: Wed, 8 May 2013 16:28:19 +0100	[thread overview]
Message-ID: <20130508152819.GJ2703@arm.com> (raw)
In-Reply-To: <20130505222645.GA1433@schnuecks.de>

On Sun, May 05, 2013 at 11:26:47PM +0100, Simon Baatz wrote:
> On Fri, May 03, 2013 at 11:02:42AM +0100, Catalin Marinas wrote:
> > On Thu, May 02, 2013 at 08:38:36PM +0100, Simon Baatz wrote:
> ...
> > I haven't run the tests but I can see  why it fails without
> > flush_kernel_dcache_page(). So I think this function needs to be
> > implemented for aliasing VIPT or VIVT caches.
> > 
> > > It is even needed in flush_dcache_page() as long as everybody
> > > continues to use flush_dcache_page() instead of
> > > flush_kernel_dcache_page() when appropriate...
> > > (This is probably the main reason why the problem I reported is so
> > > uncommon: Everybody seems to use flush_dcache_page() and since it
> > > flushes the kernel mapping in these cases, everything is fine.)
> > 
> > That's why for non-aliasing VIPT we could make it just a clear_bit() and
> > let the callers fix their API usage.
> 
> Do you mean the unnecessary flush for anon pages or also the D/I
> flush for user space mapped page cache pages?

flush_dcache_page() should just ignore anonymous pages. The D/I
coherency would be handled in __sync_icache_dcache() later. Do we have
cases where a page is already mapped in user space (pte valid) and the
kernel writes any code to it? I don't think we have. PowerPC have a
simplified flush_dcache_page() and they haven't seen any issues.

> For anon pages, that was the content of the patch you acked ([1])
> once.  However, Russel did not like the idea to use the
> PG_dcache_clean bit also for anon pages.

I think Russell was right, the kernel does not have any guarantees about
the PG_arch_1 bit on anonymous pages. Do we could remove the !mapping
code path in flush_dcache_page().

> I have a newer version that does the following: Do nothing for
> mapping == NULL on non-aliasing VIPT in flush_dcache_page().  

Can this mapping == NULL be generalised for aliasing caches?

> In __sync_icache_dcache() flush if mapping == NULL (always on aliasing
> VIPT, only if pte_exec() on non-aliasing VIPT).

If the page is anonymous, do we expect user code to execute from a
clear page? When the page is first allocated, clear_user_highpage should
take care of the aliases already.

-- 
Catalin

  reply	other threads:[~2013-05-08 15:28 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-07 11:29 [PATCH V2 0/2] fix and improvement of flush(_kernel)_dcache_page() Simon Baatz
2012-10-07 11:29 ` [PATCH V2 1/2] ARM: remove unnecessary flush of anon pages in flush_dcache_page() Simon Baatz
2012-10-08 11:36   ` Catalin Marinas
2012-10-08 17:38     ` Simon Baatz
2012-10-08 17:43       ` Catalin Marinas
2012-10-07 11:29 ` [PATCH V3 2/2] ARM: Handle user space mapped pages in flush_kernel_dcache_page Simon Baatz
2012-10-08 17:44   ` Catalin Marinas
2012-10-08 20:02     ` Simon Baatz
2012-10-08 20:20       ` Russell King - ARM Linux
2012-10-08 23:07         ` Simon Baatz
2012-11-18 21:10           ` Jason Cooper
2013-04-18 11:16             ` Jason Cooper
2013-04-18 11:22               ` Russell King - ARM Linux
2013-04-18 11:40                 ` Jason Cooper
2013-04-18 13:51                   ` Catalin Marinas
2013-04-21 22:06                     ` Simon Baatz
2013-04-30 11:22                       ` Catalin Marinas
2013-04-30 21:04                         ` Simon Baatz
2013-05-01 14:22                           ` Catalin Marinas
2013-05-01 19:04                             ` Simon Baatz
2013-05-02  9:54                               ` Catalin Marinas
2013-05-02 19:38                                 ` Simon Baatz
2013-05-03 10:02                                   ` Catalin Marinas
2013-05-04  8:21                                     ` Ming Lei
2013-05-08 15:08                                       ` Catalin Marinas
2013-05-08 18:43                                         ` Russell King - ARM Linux
2013-05-08 19:31                                           ` Simon Baatz
2013-05-08 21:13                                             ` Catalin Marinas
2013-05-09  1:52                                         ` Ming Lei
2013-05-11  6:27                                       ` Simon Baatz
2013-05-13  3:12                                         ` Ming Lei
2013-05-05 22:26                                     ` Simon Baatz
2013-05-08 15:28                                       ` Catalin Marinas [this message]
2013-04-18 19:39                   ` Simon Baatz
2013-04-18 19:00                 ` Simon Baatz

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=20130508152819.GJ2703@arm.com \
    --to=catalin.marinas@arm.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.