linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Xinwei Hu <huxinwei@huawei.com>, Zefan Li <lizefan@huawei.com>,
	Tianhong Ding <dingtianhong@huawei.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/1] arm64: fix flush_cache_range
Date: Wed, 25 May 2016 11:50:22 +0100	[thread overview]
Message-ID: <20160525105022.GC5996@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <57451DC6.7080106@huawei.com>

On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote:
> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote:
> > On 2016/5/24 21:02, Catalin Marinas wrote:
> >> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
> >>> On 2016/5/24 19:37, Mark Rutland wrote:
> >>>> It looks like the test may be missing I-cache maintenance regardless of
> >>>> the semantics of mprotect in this case.
> >>>>
> >>>> I have not yet devled into flush_cache_range and how it is called.
> >>>
> >>> SYSCALL_DEFINE3(mprotect ---> mprotect_fixup ---> change_protection ---> change_protection_range --> flush_cache_range
> >>
> >> The change_protection() shouldn't need to flush the caches in
> >> flush_cache_range(). The change_pte_range() function eventually ends up
> >> calling set_pte_at() which calls __sync_icache_dcache() if the mapping
> >> is executable.
> > 
> > OK, I see.
> > But I'm afraid it entered the "if (pte_present(oldpte))" branch in
> > function change_pte_range. Because the test case called mmap to
> > create pte first, then called pte_modify. I will check it later.
> 
> I have checked that it entered "if (pte_present(oldpte))" branch.

This path eventually calls set_pte_at() via ptep_modify_prot_commit().

> But I don't known why I add flush_icache_range is OK, but add
> __sync_icache_dcache have no effect.

Do you mean you modified set_pte_at() to use flush_icache_range()
instead of __sync_icache_dcache() and it works?

What happens is that __sync_icache_dcache() only takes care of the first
time a page is mapped in user space and flushes the caches, marking it
as "clean" (PG_dcache_clean) afterwards. Subsequent changes to this
mapping or writes to it are entirely the responsibility of the user. So
if the user plans to execute instructions, it better explicitly flush
the caches (as Mark Rutland already stated in a previous reply).

I ran our internal LTP version yesterday and it was fine but didn't
realise that we actually patched mprotect04.c to include:

	__clear_cache((char *)func, (char *)func + page_sz);

just after memcpy().

(we still need to investigate whether the I-cache invalidation is
actually needed in flush_cache_range() or it's just something we forgot
to remove)

-- 
Catalin

  reply	other threads:[~2016-05-25 10:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-24 11:16 [PATCH 1/1] arm64: fix flush_cache_range Zhen Lei
2016-05-24 11:37 ` Mark Rutland
2016-05-24 12:19   ` Leizhen (ThunderTown)
2016-05-24 13:02     ` Catalin Marinas
2016-05-25  1:20       ` Leizhen (ThunderTown)
2016-05-25  3:36         ` Leizhen (ThunderTown)
2016-05-25 10:50           ` Catalin Marinas [this message]
2016-05-26  3:40             ` Leizhen (ThunderTown)
2016-05-26 11:46             ` Leizhen (ThunderTown)
2016-05-26 12:04               ` Russell King - ARM Linux
2016-05-26 16:36               ` Catalin Marinas
2016-05-24 15:12     ` Mark Rutland
2016-05-25 15:22       ` Catalin Marinas
2016-05-25 17:27         ` Russell King - ARM Linux
2016-05-26 16:44           ` Catalin Marinas

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=20160525105022.GC5996@e104818-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=dingtianhong@huawei.com \
    --cc=guohanjun@huawei.com \
    --cc=huxinwei@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=thunder.leizhen@huawei.com \
    --cc=will.deacon@arm.com \
    /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;
as well as URLs for NNTP newsgroup(s).