Re: Remapping pages mapped to userspace (was: [PATCH 10 of 20] ipath- support for userspace apps using core driver)
From: Linus Torvalds
Date: Fri Mar 17 2006 - 12:27:53 EST
On Fri, 17 Mar 2006, Bryan O'Sullivan wrote:
> It would be unfortunate if userspace were spinning on a chip register,
> waiting for the register to transition from zero to non-zero, and we
> replaced that mapping with an anonymous page. In that case, userspace
> could potentially spin forever, having no way to detect the demise of
> the device.
Generally, replacing the mmap with an anonymous zero-mapped mapping would
be a horribly bad idea.
The fact is, you can't avoid the race of seeing the removed state (which
_usually_ means that you will read 0xffffffff from the bus - normal PC's
won't result in bus errors etc). Whatever the kernel does, it can do only
after the device has already been removed - we no longer live in a world
where the administrator can tell the system before-hand that something
will go away.
Replacing the MMIO map with a zero map would be absolutely horrible. It
would be inconsistent, and not even help the fact that the user will haev
seen the removed state.
In fact, I think even "revert" is pretty useless. You're much better off
just sending a perfectly good signal - something that the app will get
regardless of whether it reads the MMIO space at that point in time or
not. After all, the only thing the "revert" would really do is to send a
signal, but then only if the user is trying to access the device.
Anyway, zap_page_range() would do what you want, but it's not exported,
and I'm not convinced it's even something we want to export. You can only
zap a page range from within the context of the zappee, not from an
[ Maybe it works if somebody else calls it, maybe it doesn't. I wouldn't
bet on it, and more importantly, I can pretty much _guarantee_ that a
driver will get the "struct mm_struct" reference counting wrong. ]
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/