David T Eger wrote:
> when I read documentation (Documentation/pci.txt) which mentions that
> remove() can be called from interrupt context.
ignore that. You can sleep in remove, and it will not be called from
interrupt context.
> 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?
if someone yanks the card, how is it going to deliver an interrupt to
the CPU?
> 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?
huh? what are you talking about? oops or random memory corruption
occurs. there is no consensus necessary.
If you are worried about unregister_framebuffer failure, then don't
deallocate the memory, or sleep until unregister_framebuffer succeeds,
or any one of a number of workarounds.
Jeff
-- Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:15 EST