From: James Hogan <james.hogan@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>, <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 11:15:15 +0100 [thread overview]
Message-ID: <55B0BEB3.7010502@imgtec.com> (raw)
In-Reply-To: <b02d2b2d33026271c663207dc68bfa0531b16251.1437644062.git.ralf@linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
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?
Cheers
James
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> ---
> arch/mips/mm/fault.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
> index 36c0f26..852a41c 100644
> --- a/arch/mips/mm/fault.c
> +++ b/arch/mips/mm/fault.c
> @@ -133,7 +133,8 @@ good_area:
> #endif
> goto bad_area;
> }
> - 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(),
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>,
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 11:15:15 +0100 [thread overview]
Message-ID: <55B0BEB3.7010502@imgtec.com> (raw)
Message-ID: <20150723101515.lDI1ycy6LL7TPNYTEAhfxktbQ1S1P33Kk3Fg1ML81VE@z> (raw)
In-Reply-To: <b02d2b2d33026271c663207dc68bfa0531b16251.1437644062.git.ralf@linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
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?
Cheers
James
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> ---
> arch/mips/mm/fault.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
> index 36c0f26..852a41c 100644
> --- a/arch/mips/mm/fault.c
> +++ b/arch/mips/mm/fault.c
> @@ -133,7 +133,8 @@ good_area:
> #endif
> goto bad_area;
> }
> - 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(),
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-07-23 10:15 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 [this message]
2015-07-23 10:15 ` James Hogan
2015-07-23 12:35 ` Ralf Baechle
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=55B0BEB3.7010502@imgtec.com \
--to=james.hogan@imgtec.com \
--cc=Markos.Chandras@imgtec.com \
--cc=ddaney@caviumnetworks.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@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.