linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico@fluxnic.net>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: Please help with the OMAP static mapping mess
Date: Tue, 04 Oct 2011 19:20:57 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.02.1110041900590.9106@xanadu.home> (raw)
In-Reply-To: <20111004225424.GA32102@n2100.arm.linux.org.uk>

On Tue, 4 Oct 2011, Russell King - ARM Linux wrote:

> On Tue, Oct 04, 2011 at 05:10:36PM -0400, Nicolas Pitre wrote:
> > Which makes me think... with all those architectures intercepting 
> > ioremap calls in order to provide an equivalent static mapping address, 
> > they already get an unexpected domain given that static mappings are 
> > mostly DOMAIN_IO and not DOMAIN_KERNEL as would result from an non 
> > intercepted ioremap call.
> 
> That's a necessary evil - otherwise we have to separate out the
> ioremap from vmalloc.
> 
> Incidentally, how are you dealing with the problem of a static mapping
> setting up a L1 page table entry for DOMAIN_IO, and then a vmalloc
> request coming in, overlapping that L1 page table?
> 
> If this memory then gets accessed with get_user() with set_fs(get_ds()),
> the kernel will oops as we don't switch DOMAIN_IO memory on set_fs().
> (I don't know if this happens in practice, but there's nothing to say
> that it's illegal to do this.)

I suppose that didn't happen so far.  Granted, moving the ioremap 
optimization into core code for all machines will increase the 
possibility for this to happen, even if still small.

With CPU_USE_DOMAINS not set, set_fs() is a no-op anyway, besides 
addr_limit that is.

Is there a strong benefit in having static mappings being DOMAIN_IO 
instead of DOMAIN_KERNEL?


Nicolas

  reply	other threads:[~2011-10-04 23:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03 18:59 Please help with the OMAP static mapping mess Nicolas Pitre
2011-10-03 20:56 ` Tony Lindgren
2011-10-03 22:09   ` Nicolas Pitre
2011-10-03 22:38     ` Tony Lindgren
2011-10-04  7:04       ` Santosh Shilimkar
2011-10-04 21:21         ` Nicolas Pitre
2011-10-05  2:09           ` Rob Herring
2011-10-05  2:39             ` Nicolas Pitre
2011-10-05  6:16               ` Santosh Shilimkar
2011-10-03 22:39     ` Nicolas Pitre
2011-10-03 22:59       ` Tony Lindgren
2011-10-04  6:18         ` Shilimkar, Santosh
2011-10-04 17:50           ` Tony Lindgren
2011-10-03 22:44     ` Russell King - ARM Linux
2011-10-04 21:10       ` Nicolas Pitre
2011-10-04 22:54         ` Russell King - ARM Linux
2011-10-04 23:20           ` Nicolas Pitre [this message]
2011-10-05  0:42             ` Tony Lindgren
2011-10-05  0:57               ` Nicolas Pitre
2011-10-05  1:35                 ` Tony Lindgren

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=alpine.LFD.2.02.1110041900590.9106@xanadu.home \
    --to=nico@fluxnic.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=tony@atomide.com \
    /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).