linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: anfei.zhou@gmail.com (anfei)
To: linux-arm-kernel@lists.infradead.org
Subject: kernel virtual memory access (from app) does not generatesegfault
Date: Wed, 21 Apr 2010 20:43:17 +0800	[thread overview]
Message-ID: <20100421124317.GA9408@desktop> (raw)
In-Reply-To: <000001cae144$4281a9a0$4044010a@Emea.Arm.com>

On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. Martin wrote:
>  
> 
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
> > Sent: 20 April 2010 23:41
> > To: Jamie Lokier
> > Cc: Ben Dooks; anfei; Dave P Martin; 
> > linux-arm-kernel at lists.infradead.org
> > Subject: Re: kernel virtual memory access (from app) does not 
> > generatesegfault
> 
> [...]
> 
> > The difference between instruction faults and data faults is 
> > that we always interpret instruction faults on pre-ARMv6 CPUs 
> > as a 'translation fault' rather than a permission fault since 
> > they can't tell us what the problem was.
> 
> Note that my observations were on an armv7 kernel.  Should we still hit the
> same bit of code in this case, or have I misdiagnosed the problem?
> 
You said your kernel is .28, so it seems too old and this commit may fix
it: 
commit d25ef8b86e6a58f5476bf6e4a8da730b335f68fa
	ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7

Cheers,
Anfei.

> Cheers
> ---Dave
> 
> 
> 

  reply	other threads:[~2010-04-21 12:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-20  9:14 kernel virtual memory access (from app) does not generate segfault Sasha Sirotkin
2010-04-20  9:34 ` Ben Dooks
2010-04-20 10:27   ` Dave P. Martin
2010-04-20 14:20     ` anfei
2010-04-20 17:09       ` Ben Dooks
2010-04-20 19:28         ` Russell King - ARM Linux
2010-04-20 22:31           ` Jamie Lokier
2010-04-20 22:41             ` Russell King - ARM Linux
2010-04-21  0:33               ` Jamie Lokier
2010-04-21 11:17               ` kernel virtual memory access (from app) does not generatesegfault Dave P. Martin
2010-04-21 12:43                 ` anfei [this message]
2010-04-21 16:07                   ` Dave P. Martin
2010-04-21 19:16                     ` Jamie Lokier
2010-04-21 19:40                       ` Russell King - ARM Linux
2010-04-21 21:00                         ` Jamie Lokier
2010-04-21 19:36                   ` Russell King - ARM Linux
2010-04-21 19:35                 ` Russell King - ARM Linux
2010-04-21 21:24                   ` Nicolas Pitre
2010-04-21 21:44                     ` Russell King - ARM Linux
2010-04-21 21:54                       ` Russell King - ARM Linux
2010-04-21 22:59                         ` Nicolas Pitre
2010-04-22 10:56                           ` Dave P. Martin
2010-04-22 12:29                             ` anfei
2010-04-22 13:18                               ` Dave P. Martin
2010-04-22 15:59                                 ` Jamie Lokier
2010-04-21 13:11           ` kernel virtual memory access (from app) does not generate segfault anfei
2010-04-21 19:45             ` Jamie Lokier
2010-06-08 13:29             ` anfei
2010-06-08 13:36               ` Russell King - ARM Linux
2010-06-08 14:19                 ` anfei

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=20100421124317.GA9408@desktop \
    --to=anfei.zhou@gmail.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).