From: Roland Dreier <rdreier@cisco.com>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: linux-kernel@vger.kernel.org, Andi Kleen <ak@suse.de>
Subject: Re: mapping PCI registers with write combining (and PAT on x86)...
Date: Tue, 12 Dec 2006 16:01:57 -0800 [thread overview]
Message-ID: <adad56ou0i2.fsf@cisco.com> (raw)
In-Reply-To: <m1irggrasw.fsf@ebiederm.dsl.xmission.com> (Eric W. Biederman's message of "Tue, 12 Dec 2006 15:47:43 -0700")
> So I think we may simplify this but there is pci_mmap_page_range. That
> already handles this for the architectures that currently support it.
> So it is probably the case the fbdev should be changed to use that.
Thanks... I was not aware of pci_mmap_page_range(), but that doesn't
seem to be quite the right interface. It uses vma->vm_pgoff to say
what to remap. A typical use for what I have in mind would be for a
userspace process to open a magic file and do mmap() at some
well-known offset (like 0), and have the kernel driver map the right
PCI registers into userspace, without userspace having to know what
offset to ask for.
This is especially important when the kernel has to handle picking a
"context" or "port" to avoid multiple userspace processes stepping on
each other.
And of course arch/i386/pci/i386.c has the following in its
pci_mmap_page_range() anyway:
/* Write-combine setting is ignored, it is changed via the mtrr
* interfaces on this platform.
*/
so the write_combine parameter is ignored...
> No one had any serious objections to my patches as they were. The actual
> problem was that the patches were incomplete. In particular if you
> mismatch page protections it is possible to get silent data corruption
> or processor crashes. So we need checks to ensure all mappings of
> a given page are using the same protections.
>
> To a certain extent I think adding those checks really is a strawman
> and should not stop the merge effort, because we have this feature and
> those possible bugs on other architectures right now and we don't have
> those checks. But I also think in the long term we need them, it just
> requires several days of going through the mm so we don't leave any
> path uncovered.
It does seem somewhat hard to make sure there aren't multiple mappings
of the same thing, and I'm not sure it's worth trying to avoid it. If
a device driver lets me mmap PCI memory with write-combining on, and
then (as root) I mmap raw PCI resources to get the same memory, whose
fault is it if things break?
I'm kind of an mm dummy but I don't even see a good way to avoid
multiple mappings like that.
- R.
next prev parent reply other threads:[~2006-12-13 0:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-12 22:05 mapping PCI registers with write combining (and PAT on x86) Roland Dreier
2006-12-12 22:47 ` Eric W. Biederman
2006-12-13 0:01 ` Roland Dreier [this message]
2006-12-13 0:22 ` Eric W. Biederman
2006-12-13 2:18 ` Kyle McMartin
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=adad56ou0i2.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=ak@suse.de \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@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