From: oleg@redhat.com (Oleg Nesterov)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3] ARM: uprobes need icache flush after xol write
Date: Wed, 16 Apr 2014 18:53:05 +0200 [thread overview]
Message-ID: <20140416165305.GB15739@redhat.com> (raw)
In-Reply-To: <20140416.114740.1805744923904673839.davem@davemloft.net>
On 04/16, David Miller wrote:
>
> From: Oleg Nesterov <oleg@redhat.com>
> Date: Wed, 16 Apr 2014 17:29:46 +0200
>
> > On 04/16, David Miller wrote:
> >>
> >> From: Oleg Nesterov <oleg@redhat.com>
> >> Date: Wed, 16 Apr 2014 17:06:46 +0200
> >>
> >> > Off-topic, I am just curious... can't someone explain why flush_pfn_alias()
> >> > or flush_icache_alias() can't race with itself ? I have no idea what they do,
> >> > but what if another thread calls the same function with the same CACHE_COLOUR()
> >> > right after set_pte_ext?
> >>
> >> PTE modifications are supposed to run with the page table lock held.
> >
> > OK, but __access_remote_vm() doesn't take ptl?
> >
> > And on arm copy_to_user_page()->flush_ptrace_access()->flush_pfn_alias()
> > does this.
>
> Well, for one thing, PTE's can't gain permissions except under mmap_sem
> which __access_remote_vm() does hold.
>
> But I see what you're saying, flush_pfn_alias() is doing something
> different. It's not making user mappings, but kernel ones in order
> to implement the cache flush.
Yees, this is what I was able to understand, to some degree.
> Furthermore, in ARMs case, the code explicitly states that these
> mappings are not used on SMP. See the comment above the FLUSH_ALIAS_START
> definition in arch/arm/mm/mm.h
Ah, and this is what I missed, despite the fact the comment is close to
set_top_pte().
Thanks!
Oleg.
next prev parent reply other threads:[~2014-04-16 16:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 4:38 [RFC PATCH v3] ARM: uprobes need icache flush after xol write Victor Kamensky
2014-04-16 4:38 ` Victor Kamensky
2014-04-16 15:06 ` Oleg Nesterov
2014-04-16 15:10 ` David Miller
[not found] ` <20140416152946.GA13564@redhat.com>
2014-04-16 15:47 ` David Miller
2014-04-16 16:53 ` Oleg Nesterov [this message]
2014-04-16 20:22 ` Russell King - ARM Linux
2014-04-16 21:13 ` David Miller
2014-04-25 20:16 ` David Long
2014-04-25 20:37 ` Victor Kamensky
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=20140416165305.GB15739@redhat.com \
--to=oleg@redhat.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 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).