All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>,
	tip-bot for Marcin Nowakowski <tipbot@zytor.com>,
	linux-tip-commits@vger.kernel.org, linux-kernel@vger.kernel.org,
	peterz@infradead.org, alexander.shishkin@linux.intel.com,
	acme@kernel.org, acme@redhat.com, mingo@kernel.org,
	victor.kamensky@linaro.org, jolsa@redhat.com, hpa@zytor.com,
	torvalds@linux-foundation.org, tglx@linutronix.de
Subject: Re: [tip:perf/urgent] uprobes: Fix uprobes on MIPS, allow for a cache flush after ixol breakpoint creation
Date: Wed, 21 Dec 2016 12:24:43 +0100	[thread overview]
Message-ID: <20161221112443.GA13145@linux-mips.org> (raw)
In-Reply-To: <20161220175004.GB7776@redhat.com>

On Tue, Dec 20, 2016 at 06:50:05PM +0100, Oleg Nesterov wrote:

> >>> Commit:
> >>>
> >>>   72e6ae285a1d ('ARM: 8043/1: uprobes need icache flush after xol write'
> >>>
> >>> ... has introduced an arch-specific method to ensure all caches are
> >>> flushed appropriately after an instruction is written to an XOL page.
> >>
> >> when this page is already mmaped,
> >>
> >>> However, when the XOL area is created and the out-of-line breakpoint
> >>> instruction is copied, caches are not flushed at all and stale data may
> >>> be found in icache.
> >>
> >> but in this case the page is not mmaped yet, the probed application will
> >> take a page fault if it tries to execute this insn,
> >
> > In case of MIPS (and AFAICT ARM as well, and these are the only  
> > architectures that implement arch_uprobe_copy_ixol), the cache flushing  
> > is done through the kernel addresses of that page, so the fact that it  
> > is not mapped yet is not an issue.
> 
> OK, thanks,
> 
> > Do I understand correctly that your statement implies that after the  
> > page fault and mmapping the xol page, the page is guaranteed to be  
> > updated in the cache? As definitely that is not something that is  
> > happening at the moment.
> 
> Well, I do not know. Let me repeat I don't understand this flush_.*cache
> magic.
> 
> But. do_read_fault() does
> 
> 	__do_fault(..., &fault_page, ...);
> 
> 	alloc_set_pte(fault_page);
> 
> and alloc_set_pte() does flush_icache_page(vma, page)... Hmm, which is nop
> on MIPS.
> 
> >> OK, I know nothing about MIPS, but could you help me understand this change?
> >>
> >> See above. If we really need flush_icache_range() here then perhaps we should
> >> modify install_special_mapping() and/or __do_fault/special_mapping_fault paths
> >> instead?
> >
> > Are you suggesting that those should be updated to force a cache update?
> 
> Again, I do not know. But perhaps it makes more sense to actually implement
> flush_icache_page() ? Otherwise another user of install_special_mapping()
> can hit the same problem?

Documentation/cachetlb.txt says about flush_icache_page:

  void flush_icache_page(struct vm_area_struct *vma, struct page *page)
        All the functionality of flush_icache_page can be implemented in
        flush_dcache_page and update_mmu_cache. In the future, the hope
        is to remove this interface completely.

And that's exactly what MIPS already does, thus flush_icache_page() is a
no-op.  The new interfaces flush_dcache_page and update_mmu_cache
generally are much more efficient.

  Ralf

      reply	other threads:[~2016-12-21 11:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-13 10:40 [PATCH] uprobes: allow for a cache flush after ixol breakpoint creation Marcin Nowakowski
2016-12-13 10:40 ` Marcin Nowakowski
2016-12-20  7:58 ` [tip:perf/urgent] uprobes: Fix uprobes on MIPS, " tip-bot for Marcin Nowakowski
2016-12-20 13:08   ` Oleg Nesterov
2016-12-20 15:21     ` Marcin Nowakowski
2016-12-20 17:50       ` Oleg Nesterov
2016-12-21 11:24         ` Ralf Baechle [this message]

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=20161221112443.GA13145@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=marcin.nowakowski@imgtec.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tipbot@zytor.com \
    --cc=torvalds@linux-foundation.org \
    --cc=victor.kamensky@linaro.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.