From: Roland Dreier <rdreier@cisco.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: "Bryan O'Sullivan" <bos@pathscale.com>,
Hugh Dickins <hugh@veritas.com>, Andrew Morton <akpm@osdl.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
hch@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: Remapping pages mapped to userspace
Date: Fri, 17 Mar 2006 14:58:06 -0800 [thread overview]
Message-ID: <adak6ashe69.fsf@cisco.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0603170921470.3618@g5.osdl.org> (Linus Torvalds's message of "Fri, 17 Mar 2006 09:30:26 -0800 (PST)")
Linus> Generally, replacing the mmap with an anonymous zero-mapped
Linus> mapping would be a horribly bad idea.
Linus> The fact is, you can't avoid the race of seeing the removed
Linus> state (which _usually_ means that you will read 0xffffffff
Linus> from the bus - normal PC's won't result in bus errors
Linus> etc). Whatever the kernel does, it can do only after the
Linus> device has already been removed - we no longer live in a
Linus> world where the administrator can tell the system
Linus> before-hand that something will go away.
Linus> Replacing the MMIO map with a zero map would be absolutely
Linus> horrible. It would be inconsistent, and not even help the
Linus> fact that the user will haev seen the removed state.
Linus> In fact, I think even "revert" is pretty useless. You're
Linus> much better off just sending a perfectly good signal -
Linus> something that the app will get regardless of whether it
Linus> reads the MMIO space at that point in time or not. After
Linus> all, the only thing the "revert" would really do is to send
Linus> a signal, but then only if the user is trying to access the
Linus> device.
Hmm, you're probably right for the hot unplug case. However, there
are a couple of other related situations I've thought of in this context:
- Module remove: userspace has PCI memory mmap()ed. The module is
removed. Userspace still has access to PCI memory. And if the
module is reloaded, userspace still has access to the device that
the driver doesn't know about, so the driver may hand off the same
access to another process.
The obvious solution here is to just take a module reference when
userspace mmap()s the device. However unprivileged processes can
get direct access to IB devices, and it may not be so nice for
unprivileged processes to be able to hold off module removal.
- PCI error recovery (or internal device error recovery): if the
driver detects a problem with the PCI bus or device, it might have
to reset the device. The most natural way to model this is as hot
unplug followed by hot plug. However we don't want userspace
processes to keep their BAR mapping across the device reset,
because the device is probably not set up to handle it right after reset.
Really in this case at least, revoking an mmap() seems the cleanest
solution to me.
Any further thoughts?
Thanks,
Roland
next prev parent reply other threads:[~2006-03-17 22:58 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <71644dd19420ddb07a75.1141922823@localhost.localdomain>
2006-03-09 23:28 ` [PATCH 10 of 20] ipath - support for userspace apps using core driver Roland Dreier
2006-03-09 23:55 ` Bryan O'Sullivan
2006-03-10 0:01 ` Roland Dreier
2006-03-10 0:07 ` Bryan O'Sullivan
2006-03-10 0:32 ` Roland Dreier
2006-03-10 0:36 ` Bryan O'Sullivan
2006-03-10 0:37 ` Andrew Morton
2006-03-10 0:50 ` Bryan O'Sullivan
2006-03-16 0:56 ` Bryan O'Sullivan
2006-03-16 1:51 ` Roland Dreier
2006-03-16 2:11 ` Bryan O'Sullivan
2006-03-16 2:37 ` Roland Dreier
2006-03-16 2:52 ` Bryan O'Sullivan
2006-03-16 2:56 ` Bryan O'Sullivan
2006-03-16 3:28 ` Andrew Morton
2006-03-16 4:58 ` Bryan O'Sullivan
2006-03-16 5:38 ` Andrew Morton
2006-03-16 5:54 ` Roland Dreier
2006-03-16 6:17 ` Andrew Morton
2006-03-16 6:44 ` Nick Piggin
2006-03-16 9:39 ` Andrew Morton
2006-03-16 10:00 ` Nick Piggin
2006-03-16 7:25 ` Roland Dreier
2006-03-16 16:46 ` Linus Torvalds
2006-03-16 14:57 ` Hugh Dickins
2006-03-16 6:31 ` Nick Piggin
2006-03-16 14:34 ` Hugh Dickins
2006-03-17 0:37 ` Nick Piggin
2006-03-17 1:09 ` Roland Dreier
2006-03-17 15:27 ` Hugh Dickins
2006-03-17 22:21 ` Nick Piggin
2006-03-17 16:11 ` Bryan O'Sullivan
2006-03-17 16:28 ` Linus Torvalds
2006-03-17 16:40 ` Bryan O'Sullivan
2006-03-17 22:28 ` Nick Piggin
2006-03-17 22:14 ` Nick Piggin
2006-03-16 15:12 ` Bryan O'Sullivan
2006-03-16 17:08 ` Linus Torvalds
2006-03-16 17:46 ` Hugh Dickins
2006-03-16 17:53 ` Bryan O'Sullivan
2006-03-16 14:24 ` Hugh Dickins
2006-03-16 15:33 ` Bryan O'Sullivan
2006-03-16 17:23 ` Hugh Dickins
2006-03-16 17:40 ` Bryan O'Sullivan
2006-03-16 19:52 ` Bryan O'Sullivan
2006-03-16 20:10 ` Hugh Dickins
2006-03-16 20:35 ` Linus Torvalds
2006-03-16 20:43 ` Bryan O'Sullivan
2006-03-21 20:52 ` Bryan O'Sullivan
2006-03-21 23:20 ` Hugh Dickins
2006-03-22 15:58 ` Bryan O'Sullivan
2006-03-22 16:19 ` Linus Torvalds
2006-03-22 16:43 ` Bryan O'Sullivan
2006-03-22 17:46 ` Hugh Dickins
2006-03-22 17:53 ` Bryan O'Sullivan
2006-03-16 23:37 ` Roland Dreier
2006-03-16 23:51 ` Remapping pages mapped to userspace (was: [PATCH 10 of 20] ipath - support for userspace apps using core driver) Roland Dreier
2006-03-16 23:56 ` Bryan O'Sullivan
2006-03-17 1:10 ` Remapping pages mapped to userspace Roland Dreier
2006-03-17 1:12 ` Roland Dreier
2006-03-17 1:28 ` Alan Cox
2006-03-17 2:16 ` Roland Dreier
2006-03-17 17:13 ` Remapping pages mapped to userspace (was: [PATCH 10 of 20] ipath - support for userspace apps using core driver) Hugh Dickins
2006-03-17 17:17 ` Bryan O'Sullivan
2006-03-17 17:30 ` Linus Torvalds
2006-03-17 18:20 ` Hugh Dickins
2006-03-17 22:58 ` Roland Dreier [this message]
2006-03-16 15:08 ` [PATCH 10 of 20] ipath - support for userspace apps using core driver Bryan O'Sullivan
2006-03-16 17:27 ` Hugh Dickins
2006-03-16 17:44 ` Bryan O'Sullivan
2006-03-16 16:52 ` Bryan O'Sullivan
2006-03-16 3:58 ` Linus Torvalds
2006-03-16 4:53 ` Roland Dreier
2006-03-16 2:28 ` Linus Torvalds
2006-03-09 23:33 ` Roland Dreier
2006-03-09 23:56 ` Bryan O'Sullivan
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=adak6ashe69.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bos@pathscale.com \
--cc=hch@infradead.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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