PCI Power Management / Interrupt Context

[David T Eger]

So I'm writing some code for a PCI card that is a framebuffer device, and
happily filling in the functions for the probe() and remove() functions
when I read documentation (Documentation/pci.txt) which mentions that
remove() can be called from interrupt context.

Now in order to properly tear down some things in the system, there are
some standard unregister() interfaces.  For instance,
unregister_framebuffer() and unregister_netdev().  After which, drivers
believe all is safe and go on about releasing ioremap()'d regions and
such.

One of the first things that unregister_netdev() does is to down() the
rtnl semaphore.  *cough* *cough*  This is a blocking operation, I believe,
which, umm - you can't do that from an interrupt, correct?

Reading code in my sister frame buffer devices, I see that
unregister_framebuffer() can fail.  I can easily see a nice happy console
or user app diddling away on the framebuffer writing to the memory on the
device, and then poof! someone yanks the card, processor takes an
interrupt, and then... and then?  what to do? 

In fact, here's an interesting snippet from cyber2000fb.c:

static void __devexit cyberpro_remove(struct pci_dev *dev)
{
	struct cfb_info *cfb = (struct cfb_info *)dev->driver_data;

	if (cfb) {
	/*
	* If unregister_framebuffer fails, then
	* we will be leaving hooks that could cause
	* oopsen laying around.
	*/
	if (unregister_framebuffer(&cfb->fb))
		printk(KERN_WARNING "%s: danger Will Robinson, "
			"danger danger!  Oopsen imminent!\n",
	cfb->fb.fix.id);
	cyberpro_unmap_smem(cfb);
	cyberpro_unmap_mmio(cfb);
	cyberpro_free_fb_info(cfb);

	/*
	* Ensure that the driver data is no longer
	* valid.
	*/
	dev->driver_data = NULL;
	if (cfb == int_cfb_info)
	int_cfb_info = NULL;
	}
}

So, umm, is there a consensus on what to do if someone currently expects
to be writing to memory that doesn't exist any more?  Leave the mappings
there?  Take them out and laugh as our users' machine suddenly oopses to a
halt? Pray? Laugh? Cry?
					
-David Thomas Eger ([e-mail])