linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: linux-arch@vger.kernel.org
Subject: Re: You might need vmalloc_sync_all()
Date: Tue, 1 May 2007 20:20:37 +0100	[thread overview]
Message-ID: <20070501192037.GD19872@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20070501113733.GW25929@bingen.suse.de>

On Tue, May 01, 2007 at 01:37:33PM +0200, Andi Kleen wrote:
> > What's this?
> 
> Hmm, when I look now at your source I don't see one either. Maybe
> the reporter had a strangely patched kernel.
> 
> Anyways, point stands -- for on demand module mappings you likely
> want vmalloc_sync_all to avoid nested faults. If you think you 
> can handle the nested faults safely then ignore it @)
> 
> > 
> > > Apparently at least ARM has this problem.
> > 
> > Is there a bug report?
> 
> Forwarded it.

For the record here, Andi forwarded the report about kprobes on ARM
causing recursive page faults.  In essence, my opinion is that the
kprobes hook is probably incorrectly placed - probably far too early
in the data exception processing.

Since the data exception path is used for all sorts of things (missing
page table entries, permission, ECC errors, hardware errors, alignment
faults, etc) putting a call designed to intercept page faults early
will pick up all this other noise.

If it's placed in the same way as i386 then there shouldn't be an issue.

Since I haven't seen the code which adds this hook to ARM, I can only
speculate at the time being.  So I feel that until the hook comes up
as a candidate for merging, there's no point in fixing a problem in
mainline which doesn't yet exist there.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

      reply	other threads:[~2007-05-01 19:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-01  4:26 You might need vmalloc_sync_all() Andi Kleen
2007-05-01  7:44 ` Russell King
2007-05-01 11:37   ` Andi Kleen
2007-05-01 19:20     ` Russell King [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=20070501192037.GD19872@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=linux-arch@vger.kernel.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).