From: dave.long@linaro.org (David Long)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3] ARM: uprobes need icache flush after xol write
Date: Fri, 25 Apr 2014 16:16:53 -0400 [thread overview]
Message-ID: <535AC2B5.7070205@linaro.org> (raw)
In-Reply-To: <20140416.171354.2030799647571837439.davem@davemloft.net>
On 04/16/14 17:13, David Miller wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> Date: Wed, 16 Apr 2014 21:22:43 +0100
>
>> I'm thinking that both flush_icache_alias() and flush_pfn_alias() want
>> at least a preemption disabled around each so that we don't end up with
>> two threads being preempted here.
>
> Yes, you would need to disable preemption to keep another thread of
> control from potentially using the same flush slot.
>
Sorry for the delay in replying.
I guess the above potential problem is largely independent of the
uprobes caching issue.
I spent a while reading up on ARM cache operations and MMFR3 register
contents. I don't pretend to understand all the details but, based on
what I do, it looks to me like Victor's v3 patch addresses all the
issues that we think it needs to. I also see now why the
dcache_flush_page() is needed rather than a call to the lower-level
clean_dcache_line() function.
Victor, maybe you could remove the "#ifdef CONFIG_SMP"s from it and send
it out as an official (non-RFC) uprobes patch? It would be really nice
to get this into V3.15, if at all possible.
-dl
next prev parent reply other threads:[~2014-04-25 20:16 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
2014-04-16 20:22 ` Russell King - ARM Linux
2014-04-16 21:13 ` David Miller
2014-04-25 20:16 ` David Long [this message]
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=535AC2B5.7070205@linaro.org \
--to=dave.long@linaro.org \
--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).