All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Venki Pallipadi <venkatesh.pallipadi@intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] x86, PAT: honor CONFIG_STRICT_DEVMEM if pat is disable]
Date: Fri, 22 Jul 2011 09:15:08 -0700	[thread overview]
Message-ID: <4E29A20C.70402@zytor.com> (raw)
In-Reply-To: <20110722091151.GA4004@tiehlicka.suse.cz>

On 07/22/2011 02:11 AM, Michal Hocko wrote:
> Hi,
> I have just come across a strange behavior of /dev/[k]mem when PAT is
> configured while STRICT_DEVMEM is disabled. 
> One would expect that /dev/kmem would allow to access also the
> system RAM in that configuration but that is not obviously true as pat
> code defines range_is_allowed to protect from accessing that memory.
> 
> AFAICS this behavior was introduced in 0124cecf (x86, PAT: disable
> /dev/mem mmap RAM with PAT) which says that it disables [k]mem with PAT
> because it is safer. There is no explanation why it allows to access
> that memory if CONFIG_NONPROMISC_DEVMEM (CONFIG_STRICT_DEVMEM now).
> 
> The thing is even more complicated by the fact that the access is
> allowed when nopat kernel parameter is specified because
> range_is_allowed just does't call devmem_is_allowed in that case.
> 
> While I do agree that the feature is not safe in general we should honor
> STRICT_DEVMEM setting in some way IMO.
> 
> What do you think about the following fix? I have tried to preserve
> "disabled for PAT" by default behavior.

The reason it is disabled for PAT is that it is very hard to track maps
of that memory that are created by mapping /dev/[k]mem, since those maps
don't have a defined PAT type and really should be transparently
tracking the consensus caching type; this is a facility that *could* be
created but has no other user.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


  reply	other threads:[~2011-07-22 16:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-22  9:11 [PATCH] x86, PAT: honor CONFIG_STRICT_DEVMEM if pat is disable] Michal Hocko
2011-07-22 16:15 ` H. Peter Anvin [this message]
2011-07-22 17:31   ` Michal Hocko
2011-07-22 18:30     ` H. Peter Anvin
2011-07-23 12:39       ` Michal Hocko

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=4E29A20C.70402@zytor.com \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=mingo@elte.hu \
    --cc=venkatesh.pallipadi@intel.com \
    --cc=x86@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 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.