All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org,
	David Daney <ddaney@caviumnetworks.com>,
	Markos Chandras <Markos.Chandras@imgtec.com>
Subject: Re: [PATCH 1/2] MIPS: Handle page faults of executable but unreadable pages correctly.
Date: Thu, 23 Jul 2015 14:35:44 +0200	[thread overview]
Message-ID: <20150723123544.GH8099@linux-mips.org> (raw)
In-Reply-To: <55B0BEB3.7010502@imgtec.com>

On Thu, Jul 23, 2015 at 11:15:15AM +0100, James Hogan wrote:

> On 23/07/15 10:10, Ralf Baechle wrote:
> > Without this we end taking execeptions in an endless loop hanging the
> > thread.
> 
> A little more explanation would be nice. Under what situations does this
> occur? Does this mean any VM_EXEC and !VM_READ page can't actually be
> faulted in without it being treated as an RI violation, or does it only
> affect when read from kernel emulation code?

> > -			if (!(vma->vm_flags & VM_READ)) {
> > +			if (!(vma->vm_flags & VM_READ) &&
> > +			    exception_epc(regs) != address) {
> >  #if 0
> >  				pr_notice("Cpu%d[%s:%d:%0*lx:%ld:%0*lx] RI violation\n",
> >  					  raw_smp_processor_id(),
> > 
> 

The general idea is the change the code to treat loads of an instruction
just like an instruction fetch.  Which is achieved by adding the second
condition "exception_epc(regs) != address" to the if above.
exception_epc(regs) == address means

It would all be easier if Linux was enabling the separate exception codes
for read and execution failure but short of that, a test like above must
provide if a fault was an attempted instruction fetch or happend fetching
data.

  Ralf

  reply	other threads:[~2015-07-23 12:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-23  9:34 [PATCH 0/2] RIXI fixes Ralf Baechle
2015-07-23  9:10 ` [PATCH 1/2] MIPS: Handle page faults of executable but unreadable pages correctly Ralf Baechle
2015-07-23 10:15   ` James Hogan
2015-07-23 10:15     ` James Hogan
2015-07-23 12:35     ` Ralf Baechle [this message]
2015-07-23  9:10 ` [PATCH 2/2] MIPS: Partially disable RIXI support Ralf Baechle
2015-07-23 10:06   ` James Hogan
2015-07-23 10:06     ` James Hogan

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=20150723123544.GH8099@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=Markos.Chandras@imgtec.com \
    --cc=ddaney@caviumnetworks.com \
    --cc=james.hogan@imgtec.com \
    --cc=linux-mips@linux-mips.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.