Re: Remapping pages mapped to userspace (was: [PATCH 10 of 20] ipath- support for userspace apps using core driver)

[Linus Torvalds]

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 
external module/driver.

[ 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. ]

		Linus
-
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/